I think a lot of growth teams are good at writing the upside of an idea and much worse at writing the conditions that would let the idea work.
We write the hypothesis.
We define the segment.
We name the target metric.
We talk about the message, the flow, the prompt, the channel, the win condition.
Then we act surprised when the idea lands in the real world and immediately meets a pile of unglamorous limits.
The admin rights are missing.
The CSV lives on a different machine.
The teammate who can approve the integration is out this week.
The user is on mobile when the flow really assumes desktop.
The setup asks for legal review before the value is obvious.
The reminder lands during a workday that leaves no room for the task it suggests.
None of that means the original idea was foolish.
It means the product was designed as if motivation were the only scarce thing.
A lot of the time it is not.
The missing ingredient is usually not desire
I keep coming back to the Fogg Behavior Model because it is so easy to misuse in useful ways.
Most people remember the motivation part.
They remember prompts too.
Those are the exciting levers.
The sharper CTA.
The better reminder.
The more persuasive landing page.
The cleaner social proof.
But the most quietly expensive part is often ability.
Not abstract ability.
Contextual ability.
Do I have what I need right now.
Can I do this from where I am.
Can I finish this without pulling in another person.
Can I complete the first useful move before my time, authority, or patience runs out.
When a growth team ignores that layer, it ends up treating environmental constraints as user hesitation.
That is how teams over-message a problem that really needs redesign.
A lot of friction is not product friction in the narrow sense
This is one reason I think growth product work benefits from borrowing more from service design.
The GOV.UK pattern for checking whether a service is suitable is useful because it starts with a simple respect for the user’s situation.
Help people understand whether this thing is right for them.
Tell them what it will cost.
Tell them how long it will take.
Tell them what they will need.
That is not only public-sector design advice.
It is practical growth advice.
A lot of products do not fail because the value proposition was unclear.
They fail because the path assumed capabilities, permissions, timing, or attention that the user did not actually have in that moment.
I think about this the same way I think about trying to cook a decent meal in a vacation rental kitchen.
The recipe may be fine.
The ingredients may be right.
Your intent may be sincere.
Then you discover there is no sharp knife, one working burner, and nothing resembling a mixing bowl.
The dinner plan did not become bad.
The environment made it less executable.
Products do this to users all the time.
Growth teams often instrument intent and ignore prerequisites
This is where many dashboards get a little dishonest.
They record that the user clicked into setup.
They record that the user opened the invite flow.
They record that the user reached the import step.
Sometimes they even record a half-finished action as proof of healthy activation momentum.
What the dashboard often does not capture is whether the user had the conditions needed to complete the path.
Did they have the document.
Did they have the authority.
Did they have the right device.
Did they have the teammate.
Did they have enough uninterrupted time.
Did they know the answer to the question the form just asked.
Without that context, teams can draw the wrong lesson from decent-looking funnel entries.
They say users are unconvinced.
Sometimes users are simply under-equipped.
The product should not make people discover constraints by accident
Another GOV.UK pattern I like here is Start using a service. It keeps coming back to an idea that sounds simple and turns out to be rare in product work.
Give the user enough information before they begin.
What the service does.
What it costs.
How long it takes.
What they will need.
Whether they can resume later.
That is good onboarding judgment.
It also raises the bar for growth work.
If a product knows that success usually depends on a spreadsheet, an admin login, a budget owner, or twenty minutes of quiet time, it should not hide that fact until the user has already invested effort in the wrong conditions.
The team should not think of that as negative friction.
It is preparation.
The product is helping the user bring the right materials to the job.
The artifact I like is a constraint ledger
When a team keeps seeing good top-of-funnel intent but unreliable completion in a setup, activation, or expansion flow, I would write a constraint ledger.
Not a massive dependency audit.
Not a risk register for executive theater.
Just a working artifact for one journey where execution keeps breaking in predictable ways.
Constraint ledger
- The user job
- The step where momentum most often stalls
- The prerequisite the team assumed would already be true
- Whether that prerequisite is technical, social, legal, financial, or time-based
- How the user currently discovers the missing prerequisite
- What the product could say or show earlier
- What can be deferred, prefilled, simulated, or split into a smaller first move
- What fallback path still lets the user make progress
- What evidence would show that this is a constraint problem rather than a persuasion problem
- Owner
I like this artifact because it changes the room.
The conversation gets less theatrical.
Instead of arguing about better copy, the team has to say out loud what real-world conditions its design quietly depends on.
That usually exposes something useful.
The onboarding assumes procurement happens faster than it does.
The invite flow assumes one person can explain the tool to the next person.
The integration step assumes the evaluator has admin access.
The lifecycle email assumes the user has returned to the same device.
The experiment assumes the task can be done in one sitting.
Those are not edge cases.
They are operating conditions.
This changes how I think about product judgment
I still love a clean hypothesis.
I still want sharper positioning and better prompts.
But I trust a growth idea more when the team can explain the constraints that surround it.
A good product team does not only ask what behavior it wants to change.
It asks what has to be true in the user’s environment for that behavior to be reasonably available at all.
That is a less glamorous question.
It is also a more honest one.
When a test underperforms, I do not only want to know whether the message was compelling.
I want to know whether the path was actually buildable inside the user’s day, authority, tools, and timing.
If the answer is no, the product did not really meet resistance.
It asked for a move the environment could not support.
That is not a motivation problem.
It is a design problem.
