What Belongs in a Product Strategy Before You Talk to a Development Team

Most development conversations start too late. A product team arrives at a first meeting with an agency or an internal engineering group, and within minutes everyone is discussing timelines, tech stacks, and sprint planning. The problem is that none of those things can be decided well without a foundation of thinking that very few teams actually have in place first. What gets built reflects the quality of the thinking that preceded it, and when that thinking is thin, the product usually is too.

There is a pattern we see across product projects of every size. A team has a strong sense of what they want to build. They have done some competitive research, probably mapped out a few features, and feel confident about the direction. But when you ask them what emotional problem their product solves, or what a user is feeling in the moment before they reach for it, the answers become vague. That vagueness is not a small gap. It is the gap that causes products to miss, features to confuse, and launches to underperform.

Before a development team writes a single line of code, there are four strategy artefacts that need to exist. Each one answers a question that development simply cannot answer on its own, and together they give the people building the product a clear picture of not just what to build, but why it needs to feel the way it does.

Why Strategy Artefacts Must Precede Development Conversations

Development teams are exceptionally good at solving problems that are clearly defined. Give them ambiguity and they will make their own assumptions, filling the gaps with whatever makes technical sense rather than what makes human sense. This is not a criticism. It is just how the process works when strategy hands over to execution before strategy is finished.

A lot of clients come to us with a product they want to build when in reality they are solving a problem. Those are two different starting points, and they lead to very different products. Working forward from a product concept means you are building features and hoping users find value. Working forward from a problem means every decision, including every development decision, is grounded in something real about how people think and feel.

Strategy artefacts are the bridge between insight and implementation. They are not lengthy reports that sit in a folder. They are working documents that answer the questions a development team will inevitably face. What is the user doing and feeling before they arrive here? What decisions have already been made and why? What could go wrong at a human level? What does the user need to feel when they leave? When those answers exist in writing before development begins, the entire conversation changes. The team builds toward something specific rather than away from something vague.

The User Behaviour Thesis

The first artefact is a clear written statement of what users are currently doing to solve the problem your product addresses, and how they feel about it. This sounds straightforward. It rarely is. Most product teams can describe what their product does. Far fewer can describe with precision what behaviour it is replacing and what emotional texture that existing behaviour carries.

The question to answer is this: how are people meeting this need right now, without your product, and how do they feel about that process? If users are broadly content with a manual approach, a spreadsheet, or a competitor tool, the emotional case for your product is weak regardless of how technically strong the solution is. There is no point building a product to replace something that people are quite happy doing another way.

The real question is not whether users need a better tool, but whether the current process is genuinely failing them.

When the existing process is failing people, that failure has both a functional and an emotional dimension. The functional side is usually obvious. The emotional side is where the real opportunity lives. A scheduling tool is not valuable because it stores tasks. It is valuable because forgetting tasks leads to missed appointments and the anxiety that follows. A product strategy that captures that emotional dimension gives the development team something to build toward, not just a feature list to implement.

The user behaviour thesis should also describe who the primary user actually is, including the emotional state they are likely to be in when they first reach for the product. The user journey starts before the app opens. Understanding what leads someone to your product, and what they are carrying emotionally when they arrive, shapes everything from onboarding design to notification tone.

Write down the three words that best describe how a user feels before they open your product for the first time. If your team cannot agree on those three words, the user behaviour thesis is not yet complete.

The Decision Log

Every product strategy involves choices. Which features to include. Which user needs to prioritise. Which flows to simplify and which to leave with more depth. Those choices are made continuously throughout the strategy phase, and the reasoning behind them is almost never written down. By the time development begins, the original thinking has often been lost, and the people building the product have no way of knowing whether a particular constraint is intentional or accidental.

The decision log captures every significant strategic choice alongside the reason it was made. Not just what was decided, but what alternatives were considered and why they were set aside. This matters more than it sounds. Development teams routinely encounter moments where a decision made in strategy creates a technical constraint. Without a record of why that decision was made, the temptation is to route around it or replace it with something simpler to build. Sometimes that is fine. Sometimes it undoes a deliberate emotional or behavioural design choice that took weeks of research to arrive at.

What Belongs in Each Entry

Each entry in the decision log should include the decision itself, the alternatives that were considered, the reasoning that led to the chosen direction, and any conditions under which it should be revisited. That last point is particularly useful. Some decisions are made with partial information and are explicitly provisional. Flagging them as such means the development team knows when to push back and when to hold the line.

The decision log also prevents the most common form of scope drift, which is the kind that happens when a new stakeholder joins a conversation and reopens questions that were already resolved. When the reasoning is written down, the conversation shifts from relitigating past decisions to building on them. That is a significant efficiency gain in any product process, but it is especially valuable when development time is being spent per sprint.

After every strategy session, spend ten minutes documenting what was decided and why before the context fades. A decision log built in real time is far more accurate than one reconstructed from memory a week later.

The Behavioural Risk Register

This is the artefact that most product strategies are missing entirely. A behavioural risk register maps the moments in a product where users are most likely to hesitate, disengage, or lose trust, and it does so before any design or development work begins.

The principle behind it is straightforward. Trust becomes a factor in a product whenever the product asks something of the user. Browsing a content feed carries low trust stakes. Entering financial details, granting access to contacts, or committing to a purchase carries high trust stakes. Between those extremes there is a full spectrum of moments where the emotional stakes vary and where hesitation, if unaddressed, becomes abandonment.

Mapping Stakes Against Moments

The behavioural risk register works by listing every point in the user journey where something is being asked of the user, then rating the emotional stakes of that ask. A nickname feels low-stakes. A bank sort code feels high-stakes. A permissions request for location access sits somewhere in between, depending on how clearly the product has communicated its purpose up to that point.

For each high-stakes moment, the register should include a hypothesis about the most likely cause of hesitation. Research consistently shows that hesitation at these points tends to come from one of three places: the user feels the action is irreversible, they do not fully understand what they are agreeing to, or they feel some social anxiety about making the wrong choice. Each cause requires a different design response, and the development team needs to know which one they are solving for.

• Moments where the product asks for data or permissions
• Steps that feel final or difficult to undo
• Points where the product asks users to make a choice with incomplete information
• Any step that involves financial commitment, even a small one
• Screens where users are likely to arrive in an elevated emotional state

A behavioural risk register does not eliminate these moments. It ensures they are designed with full awareness of the emotional weight they carry, rather than treated as routine interface steps.

Defining the Emotional Outcome

The fourth artefact is perhaps the most unusual one for product teams to produce, because it asks a question that most product strategies never ask. What do you want the user to feel when they have completed a core journey through your product? Not what do you want them to have done. What do you want them to feel?

This is the emotional outcome definition, and it works as a filter for every design and development decision that follows. When emotions guide decisions from the start, everything becomes more purposeful. Rather than using colours and interactions because they look good, there is a real reason behind each choice. Features get designed around how you want people to feel about them, not just what you want them to do.

The emotional outcome definition also prevents one of the most common design failures we encounter, which is the product that functions perfectly but leaves users feeling flat. A product can complete every task it was built to complete and still fail to create any emotional connection with the people using it. That flatness shows up in the numbers eventually, in session length, return visit frequency, and referral rates, but by then it is expensive to fix.

Making the Outcome Specific

Vague emotional outcomes are useless. "Users should feel confident" or "users should feel reassured" are starting points, but they are not yet decision-making tools. A useful emotional outcome statement is specific enough that two designers working independently would make the same decision when they applied it as a filter.

One practical way to arrive at this specificity is to imagine giving a eulogy for your product twenty or thirty years from now. What did it bring to people's lives? How did it make them feel? What lasting impression did it leave? That framing tends to cut through the functional thinking and surface the emotional values that should have been driving decisions all along. Once those values are written into an artefact, they travel into every subsequent conversation, including the development conversation.

Test your emotional outcome statement by reading it to someone not involved in the project. If they can picture the experience, it is specific enough. If they nod vaguely and say "that sounds nice", it needs more work.

How the Four Artefacts Work Together in Practice

Each of these artefacts is useful on its own. Together, they create something significantly more powerful, which is a shared language between the strategy team and the development team about what the product is for at a human level.

The user behaviour thesis tells the development team who they are building for and what emotional state that person arrives in. The decision log tells them what was already considered and settled so they can build confidently without relitigating strategy. The behavioural risk register tells them where to pay extra attention to detail, because the emotional stakes are high enough that a clumsy implementation will cause real drop-off. The emotional outcome definition gives them a filter to run every implementation decision through, from the colour of a confirmation screen to the copy on an error message.

When these documents exist and are genuinely used, something shifts in the development conversation. The discussion moves from "can we build this?" to "does this version of it serve the person we have described?" That is a much more productive question, and it tends to produce much better products. It also tends to reduce the number of late-stage design revisions, because the emotional intent was established before implementation began rather than discovered partway through it.

Products that feel emotionally incoherent, where the tone of one screen clashes with the next, where permissions are asked for without context, where high-stakes moments are treated with the same visual weight as low-stakes ones, are almost always the result of development beginning before this kind of thinking was in place. The artefacts are not bureaucratic. They are protective.

Conclusion

The gap between a product that works and a product that connects is almost never a technical gap. It is a thinking gap, and specifically a gap in the emotional and behavioural thinking that should precede every build decision. Development teams are not responsible for filling that gap on their own. Strategy is.

The four artefacts described here, the user behaviour thesis, the decision log, the behavioural risk register, and the emotional outcome definition, are the minimum foundation that a product strategy should have in place before a development conversation begins. They do not need to be long documents. They need to be honest ones, grounded in real understanding of the people the product is being built for.

When they exist, development conversations become cleaner, faster, and more productive. When they do not, the project tends to accumulate ambiguity gradually, and that ambiguity shows up eventually as missed timelines, expensive rework, or a product that users abandon because it never quite felt right.

Getting this thinking in place before development begins is not a process preference. It is what separates products that resonate from products that merely function. If your team is approaching a build and any of these four artefacts are missing, that is worth addressing before the first sprint begins.

Let's talk about your product strategy before development begins

This article is part of our guide to App Planning & Strategy.

Frequently Asked Questions