How to Choose Between Building for Depth of Behaviour and Breadth of Audience

Every product team faces a version of this decision, and most of them face it more than once. Do you build something that does a great deal for a specific group of people, or something that works reasonably well for as many people as possible? The language shifts depending on who is in the room. Founders call it focus versus scale. Designers call it depth versus breadth. Commercial leads call it retention versus acquisition. But the underlying question is always the same: who is this product really for, and how far are you willing to go for them?

The question is never just about audience size. It is about what your product must actually do for someone.

The answer shapes everything downstream. It determines your information architecture, your onboarding logic, your pricing model, your marketing channels, and the kind of feedback that counts as a signal versus noise. Get it wrong early and you do not just build the wrong features; you build the wrong culture around the product. Teams optimising for breadth and teams optimising for depth make fundamentally different decisions at every fork in the road, and those decisions compound.

What follows is not a ranking of one approach over the other. Depth is right in some contexts. Breadth is right in others. The goal here is to give you the thinking to tell the difference before you build, rather than after you have already spent the budget finding out.

What the Decision Actually Is (and Why It Keeps Coming Back)

Depth of behaviour means your product asks users to do more, know more, or change more than they currently do. It is built around a specific pattern of use and a specific type of person. The product rewards engagement because it was designed around engagement. Think of a strength training app built for competitive powerlifters, not people who occasionally go to the gym. The feature set is narrower, the language is more specific, and a casual user would find it confusing. That is by design.

Breadth of audience means the opposite. The product works across a wide range of users, use cases, and levels of prior knowledge. It sacrifices specificity to reduce the barrier to entry. A general fitness tracker that counts steps, logs meals, and reminds you to drink water is the obvious counterpart. Most people can use it on day one without guidance.

This decision keeps returning because the product does not stay still. A product launched for depth often attracts adjacent users who want something simpler, and the team starts adding features to accommodate them. A product launched for breadth often finds that its most engaged users want something deeper, and the team starts adding complexity. Both paths create pressure to drift toward the other, and that drift is where products lose their identity.

The decision is made again every time the roadmap is prioritised, every time a new user segment appears in the data, and every time a board meeting asks why churn is up.

The Commercial Case for Depth: Smaller Markets, Stronger Retention

Building for depth tends to produce a smaller total addressable market, but it changes the economics of that market considerably. When a product genuinely solves a problem that a specific group of people cannot solve well any other way, the willingness to pay rises, churn drops, and word of mouth within that community becomes a meaningful acquisition channel.

There is research from McKinsey suggesting that businesses focused on niche markets can achieve profit margins up to 50% higher than those targeting broader audiences. The mechanism is straightforward: specificity creates switching costs. A user who has built their workflow around your product, learned its logic, and integrated it into their daily behaviour faces a real cost to leave. That cost is the natural result of a product that actually fits how they work.

Depth also changes the nature of the feedback you receive. Users who are genuinely embedded in a product give you richer, more actionable feedback than users who use it occasionally. They notice edge cases. They articulate workarounds. They tell you what the product almost does but does not quite do yet. That feedback is a competitive asset, and you do not get it by serving everyone at a surface level.

The retention picture reflects this too. A depth-oriented product earns loyalty because the user's ability to do the thing they care about depends on it. That is a different retention mechanism than habit loops or notification nudges, and it tends to hold up better under competitive pressure.

The Commercial Case for Breadth: Scale, Network Effects and Revenue Ceilings

Depth has a ceiling, and that ceiling is the size of the niche. If the addressable market is small, margin improvement only goes so far. At some point, growth requires either moving into adjacent markets or accepting that the business will stay small. Neither is automatically wrong, but it needs to be a conscious choice rather than a surprise.

Breadth creates different dynamics. A larger addressable market means acquisition volume can stay high even with higher churn, provided the unit economics work. And in products where network effects operate, breadth becomes self-reinforcing: the product becomes more useful as more people use it, which attracts more people, which increases its usefulness. Social platforms, marketplaces, and communication tools all sit in this category.

There is also a revenue ceiling problem with depth-oriented products that does not get discussed enough. A highly specialised product may have strong retention among a small group of deeply engaged users, but if that group is small and price-sensitive, the ceiling on annual recurring revenue is low. Breadth allows you to monetise across a wider base, run tiered pricing across different engagement levels, and capture occasional users who would never pay for a specialised product but will pay for a general one.

Breadth gives you volume and velocity. Depth gives you margin and loyalty. Neither is wrong.

The commercial case for breadth also depends heavily on the cost of onboarding. A product that works immediately for a wide range of users keeps acquisition costs lower because it reduces the friction between a new user arriving and a new user experiencing value.

How User Expertise Changes What Your Product Must Do

One of the clearest ways to think about the depth versus breadth decision is through the lens of user expertise, because expertise changes what a product needs to provide. A novice needs orientation. An expert needs efficiency. A product that serves both simultaneously almost always compromises both.

We have seen this play out directly in the financial trading space. A product with technically better interaction design, one that guides users through decisions and surfaces contextual information, can actually feel less useful than a more technically dense competitor when the audience consists of experienced traders working against the clock. For those users, every additional step in the flow is a cost. They already understand the domain. They do not need orientation. What they need is the fastest possible path to executing a trade. Stripping away guidance is the right move for that audience, even though in almost any other product context, stripping guidance would create confusion, anxiety, and abandonment.

This is the inverse of most product design intuition, where more guidance is assumed to reduce friction for everyone. The assumption only holds when users are genuinely unfamiliar with the domain. Change the audience and the criteria for what feels intuitive changes completely.

Before deciding how much guidance to build into your product, map your users' existing domain knowledge separately from their familiarity with your product specifically. The two are not the same, and conflating them produces the wrong design decisions.

The practical implication is that depth-oriented products often need to do less, not more. The feature count can stay low because the user is bringing expertise to the interaction. Breadth-oriented products need to do more work upfront because the user is not.

When Behaviour Change Is the Product

Some products are built around a transaction. Others are built around a change in how someone behaves over time. The distinction matters here because behaviour change products almost always require depth, whether or not the founding team sets out to build a depth-oriented product.

A charity fundraising platform that processes one-off donations is a transaction product. A platform designed to turn occasional donors into regular givers is a behaviour change product. The second one needs to understand the emotional arc of the donor relationship, the moments where motivation peaks and drops, and the friction points that break a recurring commitment. Surface-level design will not reach those dynamics.

Designing for behaviour change also means designing for the actual emotional state of the user who arrives, not the ideal one. On one project we worked on, a meditation app had been designed as though every incoming user was already calm and ready to engage. In practice, a large proportion of the people downloading meditation apps are arriving in a state of anxiety, looking for relief from something specific. The product had been built for the ideal user rather than the actual one, and that gap was audible in every piece of user feedback the team had collected but not acted on.

Behaviour change products reward depth because genuine change requires repeated, specific engagement. A product that works for everyone at a shallow level rarely changes anyone's behaviour in a meaningful way.

The Concierge Problem: Why Surface Coverage Can Undermine Real Value

There is a pattern that appears in products trying to serve broad audiences: the product touches many things but resolves few of them. Users can find information but cannot act on it. They can log data but cannot see what it means. They can access a feature but cannot do anything useful with it. The product has wide surface coverage and low depth at each point, and the result is an experience that feels administrative rather than valuable.

We built a concierge app for residents moving into a new block of flats, typically high-net-worth individuals, and one of the earliest decisions we made was not to surface all the building information at once. The instinct from a breadth perspective would be to give users everything on arrival: recycling locations, emergency procedures, local area guides, maintenance request forms. But the emotional state of someone who has just moved is rarely receptive to large volumes of information. Some users had just bought their first property. Others were moving following a separation or bereavement. Presenting everything immediately would have been technically comprehensive and humanly useless.

Instead, we drip-fed notifications over time, matched to when users would actually need the information: recycling details a couple of days after move-in, local area recommendations over the first weekend. The product did less at any given moment, but it did the right thing at the right moment, which is a fundamentally different design logic.

Ask whether your product is giving users information because they need it now, or because surfacing it feels complete. Completeness and usefulness are not the same thing, and designing for the former often undermines the latter.

Broad surface coverage creates an impression of value without delivering it. Depth at the right moments delivers value without requiring the user to wade through everything else to find it.

Technical Debt Is Not Symmetrical Across the Two Paths

The technical consequences of the depth versus breadth decision are not equivalent, and teams that switch direction mid-build discover this the hard way. Moving from a depth-oriented architecture to a broad one typically requires rebuilding the user model from the ground up. A product built around a specific user type, with specific data structures, specific flows, and specific assumptions baked into the logic, does not scale to a general audience by adding features. The foundations are wrong for the new goal.

Moving the other way, from breadth to depth, is a different problem. The architecture is usually more flexible, but the product has accumulated assumptions about user behaviour that are too general to support the specialised experience a depth-oriented product needs. You end up in a position where the product technically works for a specific audience but does not feel built for them, because it was not.

We have also seen the internal contradiction problem in products where different parts of the build received different levels of discovery and investment. On a dating app project, significant effort went into onboarding verification. But messaging, which was equally central to how the product would be used, was built generically without equivalent discovery. The result was that the very behaviour the verification process was designed to prevent, fake and automated messages, was enabled by the messaging feature that sat directly alongside it. Coherence across the product requires that the depth-versus-breadth decision is applied consistently, not just to the parts the team finds most interesting.

The Cost of Switching

Teams that build for depth and then pivot to breadth typically face a longer rebuild than they estimate. The specialist logic that made the product valuable for a narrow audience is also the logic that makes it hard to generalise. Budget for that work honestly before committing to the pivot.

How to Assess Your Market's Actual Readiness to Change Behaviour

A depth-oriented product often asks users to change something: a habit, a workflow, a mental model of how a task should be done. That ask has a cost, and markets vary widely in their readiness to pay it. Assessing that readiness before building is one of the most useful things a product team can do, and one of the most consistently skipped.

The starting point is understanding how users currently meet the need your product addresses, and how they feel about that process. If users are broadly content with a manual approach, or if they have workarounds that are good enough, the case for a technical solution is weaker than it looks from the outside. The behaviour change you are asking for needs to be proportionate to the genuine frustration with the status quo.

The most reliable way to assess this is to ask people directly, in a structured way, before you build. Focus groups, user interviews, and surveys designed to surface emotional responses to current workflows give you a real picture of the gap between what exists and what people actually want. This is different from asking people whether they would use your product. People say yes to that question reflexively. Asking how they feel about the way they currently do something gets you closer to whether the behaviour change is worth making.

Run at least one round of qualitative research specifically around your users' current process before finalising the product direction. You are looking for genuine frustration, not mild preference. Mild preference does not sustain behaviour change.

The Founder Bias Problem: When Pre-Built Assumptions Corrupt the Decision

The depth-versus-breadth decision is vulnerable to a specific form of founder bias. A founder who has personally experienced a problem tends to design around their own experience of it, which means they build for depth by default, for someone who thinks and behaves the way they do. The problem is that this person is rarely representative of the market they are trying to reach.

Simon has observed this pattern repeatedly: it is very easy to think "I have this problem, therefore everyone has this problem, " and that assumption simply does not hold. The founder's experience is a valid starting point for hypothesis generation. It is not a substitute for market research.

We have also seen the other failure mode, where a founder decides to build for breadth because breadth implies scale, and scale is what the pitch deck requires. The decision is driven by what the investment story needs rather than what the market evidence supports. Neither path is right or wrong on its own terms. The problem is when the choice is made to satisfy an internal audience rather than an external one.

The most reliable protection against this is structured exposure to the actual people the product will serve, early and repeatedly. Not to validate the existing plan, but to genuinely test whether the depth-versus-breadth assumption holds when it meets real users with real needs.

When Research Becomes a Formality

We walked away from one engagement where the founder had already decided how the product would work and was using the research process to confirm it. When our findings showed that a significant portion of the target user base did not want certain features and preferred alternatives, the evidence was dismissed. The product launched a year later unchanged and, by every measure we are aware of, failed for exactly the reasons the research had identified. Research only protects you if you are willing to act on what it shows.

A Decision Framework: Which Path Is Right for This Product?

The table below sets out the conditions that favour each path. These are the questions that, taken together, point in one direction more clearly than the other.

No product sits neatly in one column. But if you find that five or six of these dimensions point the same way, the decision is probably not as hard as it feels. The ambiguity usually lives in the two or three that point the other way, and it is worth working through those specifically rather than treating the whole decision as unresolved.

How to Validate the Choice Before You Build

Validation is a series of increasingly costly commitments, each one giving you more confidence before you spend more money. The goal is to move from assumption to evidence as cheaply as possible, and to stop before the expensive stage if the evidence is pointing against you.

1. Map the current behaviour and how users feel about it. This tells you whether the behaviour change you are planning is proportionate to real frustration.
2. Run structured interviews with ten to fifteen people from your target audience. Ask about the current process, the workarounds, and the moments of genuine friction. Do not introduce your product concept until you have heard what they say without it.
3. Build a prototype that tests the core interaction, not the full product. For a depth-oriented product, this prototype should demand something of the user. If they are not willing to engage at that level with a prototype, they are not your audience.
4. Measure activation, not just interest. Interest is cheap to generate. Whether someone actually completes the core action your product is built around is the real signal.
5. Check whether the people who activate look like the audience you were designing for, or a different one. If a different group is engaging, that is information worth acting on before you scale.

According to Amplitude's 2025 Product Benchmark Report, more than 98% of users who do not experience value within two weeks will churn. The validation process exists to ensure the path to that value experience is visible and achievable for the right audience before you build the full product around it.

Every product launch we have been involved in has produced feedback that sent the product in a direction the internal team did not fully anticipate. That is a feature of real markets. The question is whether you surface that feedback at prototype stage, when acting on it is inexpensive, or at launch stage, when it costs significantly more.

Conclusion

The depth-versus-breadth decision is not a one-time strategic call that gets made in a workshop and then implemented. It is a recurring pressure on every product, and the teams that navigate it best are the ones that have thought it through clearly enough to hold the line when that pressure increases.

Depth produces loyalty, specificity, and switching costs. Breadth produces volume, network effects, and wider revenue potential. Both are legitimate and both have limits. The mistake is treating one as inherently superior, or letting the investment narrative rather than the market evidence make the decision for you.

What we have found, across projects in quite different sectors, is that the decision usually comes down to two things: who actually arrives at your product, and what they need to do there. A product built around a hypothetical ideal user, calm, expert, and fully committed, will disappoint real users who arrive in a different state. A product built around the real user, with their actual expertise, their actual emotional state, and their actual tolerance for change, has a chance of doing what it needs to do.

Start with the real user. Map the current behaviour and the frustration underneath it. Let that evidence point you toward depth or breadth before you commit to either. And if the evidence points somewhere uncomfortable, that is worth knowing now rather than twelve months after launch.

If you are working through this decision and want a structured way to think about it, let's talk about your product direction.

Frequently Asked Questions