The Product Strategy Process: Behavior, Barriers, and Benefit

Anticipating what customers need starts before a solution exists. A product strategy sets what the product is meant to change, for whom, and how you will know it did. Without one, a team can build something well and still miss the point.

Why start with product strategy?

In our view, products usually fail on assumptions, not code. Nobody checked that people wanted to do the thing, or that they were able to. Strategy is the work of validating, checking, and testing those assumptions before the budget goes into building. It is also where a team can afford to be wrong, because a wrong idea costs a conversation instead of a release.

What are the three B’s?

The three B’s are the method our product strategy team uses to frame a problem. Each one is a question to answer before design starts.

1. Behavior. What is the single most important behavior you want to change? Write it as something you can count, such as more people completing a task within a set time frame.
2. Barriers. What keeps your audience from doing it already? Look for friction, missing information, cost, habit, and timing.
3. Benefit. What do users gain when they do it? The benefit is what draws them toward the behavior, so it has to matter to them, not only to you.

A short example makes it concrete. Picture a regional grocer that wants more shoppers to reorder from its app. The behavior is a repeat order within two weeks of the first. The barriers might be a slow checkout and no reminder at the moment a shopper runs low. The benefit might be a reorder in a few taps that saves a trip. This example is hypothetical, not a client result.

The B	The question	Grocer example
Behavior	What do we want people to do?	Reorder within two weeks
Barriers	What stops them today?	Slow checkout, no reminder
Benefit	What do they gain?	A fast reorder that saves a trip

How does this line up with behavior research?

The three B’s are our method, but they sit comfortably beside published models. In the Fogg Behavior Model, from BJ Fogg, founder of the Behavior Design Lab at Stanford University, a behavior happens when motivation, ability, and a prompt come together at the same moment. When it does not happen, at least one of the three is missing. In our reading, barriers are usually a gap in ability or motivation, and the benefit is what motivates.

The Behavioural Insights Team offers a similar checklist in its EAST framework: make a behavior Easy, Attractive, Social, and Timely. Removing a barrier is the Easy part. A clear benefit is the Attractive part. We find that checking a strategy against either model is a quick way to catch a missing piece. That mapping is ours, not theirs.

How do you get started?

Start by defining the problem you hope to fix, and only then get creative. Teams often reach for a clever solution first, and a clever solution to the wrong problem is the most expensive kind.

Then test cheaply. Turn each assumption into something you can try with a few people, such as a paper sketch or a clickable prototype, and see whether the behavior changes. Treat a failed test as inexpensive information, not a setback. Each one tells you which barrier or benefit you had wrong.

If you are shaping a product and want a second pair of eyes on the assumptions, our services page explains how we work with teams, and you can see past projects in our work. Our post on build, buy, or connect covers a related strategy question for logistics teams: which systems to keep, connect, or replace. Contact us to talk through your idea.