Building for Intent

Most teams are remarkably good at building things. The harder question is whether they are building the right thing. Intent sits upstream of every product, experience and decision, yet it is often the first thing sacrificed when the pressure to execute begins.

The question that changes everything

Before we talk about what to build, I think there is a more important question:

What are we actually trying to achieve?

It sounds obvious. In practice, it is surprisingly easy to skip.

A brief arrives. A requirement has already been written. A roadmap has been approved. A team starts researching, designing, building and measuring. The work moves forward. But somewhere between the original request and the finished product, the reason for doing it can quietly disappear.

We begin designing for what people say they want, rather than understanding what they are actually trying to accomplish.

That distinction is where intent begins.

Intent is not always what people say

People don't wake up wanting to navigate a product. They want to get something done. They want to solve a problem, make a decision, complete a task, discover something useful or simply move on with their day. The interface is only the means.

And even the outcome they want is not always fixed.

I saw this while working on an in-store experience for grocery shoppers in the UK. At first glance, it would have been easy to define the shopper's intent as something like:

Find what I need, buy it and check out.

And for much of the week, that was broadly true. A shopper could arrive with a saved list, move through the store with purpose, pick up what they needed and leave. Speed and certainty mattered. The experience needed to help them stay on track rather than distract them.

But the same person could behave very differently on a weekend. There was more willingness to browse. To notice offers. To discover something new. To see what was coming up. To wander a little.

The intent had changed. Not because the person had changed. The context had changed.

That distinction matters. If we treat intent as a fixed characteristic of a user, we can easily design an experience that is optimized for one moment and frustrating in another.

It also changes how we think about things like discounts, loyalty programmes and shopping lists.

• A discount isn't simply a mechanism to increase conversion.
• A shopping list isn't simply a feature.
• A loyalty programme isn't simply a retention tool.

Their value depends on the intent and context in which people encounter them. Understanding intent means understanding the outcome someone is seeking, and the context in which they are seeking it.

The danger of solving the problem we were given

One of the most revealing projects I've worked on started with what appeared to be a straightforward problem. Customers in a remote rural region of Odisha were accumulating unpaid bills. The initial assumption was understandable: perhaps people were struggling to pay, or the challenge was somewhere in the bill-collection process. So that was where the problem seemed to be.

But when we spent time understanding the situation, a different problem emerged. People were struggling to understand the bill. The bills were written in English, while many of the people receiving them primarily understood regional languages. The bills were also dense and complicated, making comprehension difficult.

The issue wasn't simply that people didn't want to pay. They didn't fully understand what they were being asked to pay.

That changed the problem completely.

When the problem changes, the solution changes

Imagine we had decided to move faster.

• We could have optimized the collection process.
• We could have introduced better reminders.
• We could have improved payment channels.
• We could have automated parts of the workflow.
• We could have measured the results and celebrated the efficiency gains.

And we could have done all of that very quickly. But we would still have been solving the wrong problem.

The real opportunity was somewhere earlier in the chain:

Comprehension → transparency → trust → payment

When the bill itself was difficult to understand, improving the collection mechanism was unlikely to solve the underlying issue. This is why problem framing matters so much. It creates the direction in which execution happens.

A well-executed wrong answer is still wrong.

AI makes this more important

This question becomes even more important now because the economics of execution are changing.

With access to AI, a team can increasingly create virtual partners across the work:

• A researcher.
• An analyst.
• An engineer.
• A writing partner.
• A testing partner.

A team can explore more ideas, prototype more concepts and test more possibilities in a fraction of the time it once took. That is enormously powerful. It can help small teams operate with capabilities that previously required much larger organizations. It can shorten the distance between an idea and something you can actually test. And I expect that capability to continue improving.

But there is a paradox here.

AI doesn't ask whether the brief is worth pursuing. It doesn't automatically know whether the problem has been framed correctly. It can help you explore a solution brilliantly while remaining completely indifferent to whether the original question was the right one.

That means the role of human judgment doesn't disappear as execution accelerates. It becomes more important upstream.

From designing journeys to designing outcomes

This is perhaps the biggest shift I see happening in product experience. For a long time, we designed journeys. We thought about screens, flows, navigation and interactions. But people don't experience products as a collection of interfaces. They experience them through intent.

Think about how we increasingly interact with AI systems. We don't navigate through a hierarchy to find the right function. We say:

• Summarize this.
• Write that.
• Plan this.
• Help me understand this.

The interface becomes less important because the system is increasingly responding to the intent behind the request. That doesn't mean interfaces disappear. It means the best experience may increasingly be the one that understands what someone is trying to achieve without making them work through unnecessary steps to express it.

The closer a product gets to intent, the less the interface has to get in the way.

Building for Intent

For me, Building With Intent is not about slowing down before every decision. It is about making sure that speed is applied to something worth doing. It means asking better questions before committing to answers.

“The wise man doesn't give the right answers, he poses the right questions.”

• Before building: What are we actually trying to achieve?
• Before designing: What is the person really trying to accomplish?
• Before optimizing: What tells us this is the right problem to solve?
• Before accelerating: Are we certain we are moving in the right direction?

These questions don't eliminate ambiguity. They help us understand which ambiguity is worth exploring. And that is an important distinction.

Intent isn't a one-time exercise at the beginning of a project. It needs to remain alive as context changes, evidence emerges and assumptions are challenged. The grocery shopper's intent changed with the day. The bill-payment problem changed when we understood the user's context. AI is changing the economics of how quickly teams can act.

The job is therefore not to find one perfect definition of intent and lock it into the roadmap. It is to keep asking whether our understanding still holds.

The discipline of staying curious longer

The pressure to move is real.

• Teams want answers.
• Leaders want progress.
• Customers want outcomes.

Technology keeps making execution faster. But sometimes the most strategic thing a team can do is stay in the question a little longer.

Not indefinitely. Not as an excuse for inaction. Long enough to understand what is really happening.

Because once the direction is clear, speed becomes an advantage.

• You can research faster.
• Prototype faster.
• Build faster.
• Test faster.
• Learn faster.

And now, with AI, you can do much of that at an entirely different scale. But acceleration only creates value when it is pointed somewhere meaningful.

That is what it means to build for intent.