As AI software experiences mature, familiar challenges are appearing in AI adoption across the teams we work with.

These challenges arise from a fundamental misunderstanding of how software gets built, used, and eventually adopted in teams, from long before AI became mainstream. In this essay, I want to talk about this problem, because not enough people care about the quality of software beyond the quality of code, even though that’s all they should care about right now. I also want to end with two optimistic versions of the future which I think more software teams should explore.

People make solutions for problems they encounter. That’s the common wisdom. It’s also far from the truth.

Most enterprise software exists because people see a niche that they know they can capture, and then they build a solution that reflects their view of how they’d do the work for the niche they’re capturing.

Consider this question: is the way you work very different from even a very close colleague’s? What about management styles in different companies in the same industry? Would they be considerably different? Where do these differences come from? The differences reflect each person’s understanding of the problem they are solving. That’s it.

Software engineers and product teams have their own views too. Look at Salesforce and Hubspot, or the differences between Google and Microsoft workspaces. Or Linear and Trello. All solving overlapping problems.

The differences in all of them are very intentional. They are literally a management style, imparted into software, that they then ask other teams to adopt.

This management style comes with a perspective on what a team can achieve. It is that aspiration that clients pay for. Nobody buys an interface so their teams can type numbers into it. It is the promise that typing numbers in this particular way will ensure some downstream benefit, like better analysis, or better communication, or better execution.

So why does software not get adopted? There are of course, a number of reasons beyond the scope of this essay but I’d ask you to consider a specific situation: a client team knows they have a problem and are willing to use software to solve it, and yet, they churn.

There is a progression of perspectives that demonstrates the problem perfectly.

Software gets used by people if it's useful.

Software gets used by people if it’s useful and beautiful.

Software gets used by people if it's useful, beautiful, and it makes sense to them.

The last one is what most people miss out on. Not enough software experiences make an effort to bring people to the point where they can see the big picture. The experience, the workflow is imposed on them.

Take a project management tool like Trello.

Trello imposes two points of view on their client teams. Project managers must be technically savvy enough to break features down into tickets, know acceptance criteria, and do all this without implementing the feature in the first place. They must also think in terms of tasks and pipeline stages.

This is only possible if the user already has all the experience required to build the system they’re taking charge of, without learning things in the process. The moment the flow breaks, the task of managing a board becomes admin overhead that users churn from.

Another example is Hubspot. CRMs assume the users understand the entire theory of sales and marketing funnels, and more importantly, naturally think about their jobs in those terms. Funnels, leads, segments, and so on. The truth is most people just don’t think like that about their jobs.

Software is often solving a very sanitary, and more sophisticated version of the problem than the user imagines. This is the tension at the heart of poor adoption rates.

There are two ways to improve this problem.

The first method is to build software that continuously adapts to the user’s expectations. During onboarding, users often are questioned about their experience level with the software. Usually that data goes towards marketing and product management efforts. I believe that information, along with the user’s actual actions, should be turned into software UX which selectively shows functionality to the user.

Unless the user self reports as an expert, and explicitly does not want to be onboarded, the application should just walk the user through completion of a basic job. Not a sophisticated funnel. Create one post, one scheduled email, plan one ticket, and so on. Lower the time to completion of a task, and certainly don’t impose a workflow on them. Have them progress from the basics.

The second comes from an anecdote. Executives both hate dashboards, and love dashboards. They hate everyone else’s dashboards, but love their own dashboards. It’s because they go through the steps of creating their own, which makes the experience of their own report intuitive. Looking at other people’s reports, which is an abstraction over data, forces them to first reason about the steps that went into producing the report.

How do I see X? What does this trend mean? And so on.

Users always respond better to being walked through a process, instead of being presented with the final outputs. We're experimenting with an idea called Replay for exactly this reason.

Instead of presenting the user with the final output of a workflow, Replay allows them to walk through the steps that produced it.

They can see what happened, in what order, and how the final solution emerges step by step.

They can stop and inspect at any point. And importantly, they can choose how much detail they want to see. The goal is to make the process of understanding someone else's work as intuitive as doing it yourself.

Adaptive software helps users progress towards more sophisticated abstractions. Replays allow them to understand the abstractions that already exist.

None of this will make your SaaS software profitable in the future, but if we all have jobs in 5 years, this experience will make some of you stand out as excellent managers.