Article
Your Customer’s Progress Is Bigger Than Your Product
Understanding customers is only the beginning. The harder question is what role your company should actually play in their progress.
01 · Something looks wrong
Imagine you build a procurement system for schools.
The workflow is clear. Requests move through defined stages. Users can compare suppliers, follow approvals, track purchasing decisions and keep the process organized in one place.
At least, that is how it is supposed to work.
Then people start using it.
- They skip steps.
- They make selections that seem inconsistent.
- They ignore features that were designed to make the process easier.
- Sometimes they find their own way around the flow.
Okay. Usability problem.
Maybe the labels are unclear. Maybe the value of certain features is not obvious. Maybe users need more training. Maybe the workflow needs stronger guidance.
All reasonable explanations.
02 · The reality around the screen
Then you spend more time looking at the reality around the screen.
The person using the system may be handling procurement alongside an entirely different job. They may be coordinating approvals across several people, working around compliance requirements, trying to compare suppliers without procurement expertise, and dealing with exceptions the clean workflow did not anticipate.
Suddenly, some of the strange behavior looks less strange.
The user is not simply failing to follow the process.
They may be responding rationally to a world the process does not fully represent.
And that changes the question.
Instead of asking only:
How do we get people to use the system correctly?
we start asking:
What progress are they actually trying to make, what is shaping that progress, and what role should the product play inside it?
That sequence of questions has become increasingly important to how I think about experience strategy.
Because customer understanding is only one part of the job. The harder work happens in the translation between what we observe, what we believe it means, and what the company chooses to do about it.
03 · Story
Behavior needs a world around it
One of the reasons Jobs-to-be-Done has stayed useful is that it starts outside the product.
That way of thinking matters because behavior rarely explains itself.
- A user skips a step.
- A buyer delays a purchase.
- A team ignores automation.
- A customer abandons a workflow.
Those are observations.
The surrounding story gives them meaning.
By story, I mean the sequence and context around the behavior: where someone started, what changed, what they were trying to accomplish or protect, which alternatives existed, what created resistance, what they eventually chose, and what happened next.
The story helps us preserve the system around the behavior.
But it still does not explain the behavior for us.
Pattern and mechanism are different things
Suppose we keep seeing procurement users move outside the intended flow.
That is a pattern.
One possible explanation might be:
The workflow assumes people can follow the formal procurement process as designed, while their real work requires them to manage constraints, exceptions and missing context the system does not fully carry.
Now we have something different.
A mechanism hypothesis.
That distinction matters.
An opportunity tells us where progress could improve.
A mechanism hypothesis tries to explain why the current situation behaves the way it does.
Two users may show the same behavior — skipping a step, for example — for completely different reasons.
One may not understand what the step is for.
Another may understand it perfectly but be dealing with an exception that makes following it impractical.
Same behavior.
Different mechanism.
Very different response.
And because the mechanism is an explanation, it should stay a hypothesis until the evidence earns more confidence.
A good story can make an explanation plausible.
It cannot make it true.
So I want to know what else we would expect to see if the explanation were right. Where does it fail? What would another explanation predict? Does behavior support what people told us?
The point is not perfect certainty.
It is avoiding the very easy jump from:
“This explanation makes sense.”
to:
“Therefore, this is why people behave this way.”
There is usually more work hiding in between.
04 · The strategic turn
Understanding the customer still does not tell us what to do
Suppose we have done that work well.
We understand the progress. We have identified a meaningful opportunity. We have a mechanism hypothesis that has survived some scrutiny.
We still do not know what the company should do.
This is the part I think gets compressed too quickly.
A customer problem becomes visible, and almost immediately it becomes our problem to solve.
But the customer’s progress is bigger than the company.
Their reality already includes other tools, people, habits, institutional rules, workarounds, expertise and constraints.
The company enters that system.
It does not own it.
That matters strategically.
Because understanding the customer’s progress gives us visibility into an opportunity.
It does not give us automatic ownership of it.
A company has to earn its role
Go back to the procurement system.
Suppose we learn that part of the difficulty comes from people having to carry too much of the process themselves: remembering requirements, coordinating information and understanding decisions that sit outside their normal expertise.
There are many possible responses.
- We could add more guidance.
- We could provide training.
- We could automate specific steps.
- We could simplify the interface.
All reasonable.
Or we might make a larger strategic choice:
The product should carry more of the procurement complexity, so the people using it do not have to.
That changes the role of the system.
Now it is not simply a place where procurement tasks happen.
It can guide the process, carry relevant rules and context, make comparisons easier, preserve history and help people understand what needs to happen next.
The customer understanding gave us the possibility.
It did not choose that role for us.
Strategy did.
That is what I mean when I say a company has to earn its role in the customer’s progress.
A company has to earn its role in the customer’s progress.
- The role needs to matter to the customer.
- It needs to fit how the company intends to create value.
- The organization needs the capability to deliver it reliably.
- And the relationship needs to support the responsibility the company is asking the customer to give it.
Helping someone understand a procurement rule and becoming the system that carries the procurement process are both ways of “helping with procurement.”
They are not the same role.
A role should change decisions
This distinction matters because otherwise the role becomes another nice sentence sitting in a strategy deck.
A useful role creates constraints.
If the product chooses to carry more of the procurement complexity, that logic should influence decisions across the experience.
The workflow might make required steps visible when they matter.
The interface might help people compare relevant information rather than simply display it.
The system might preserve status and history instead of relying on users to reconstruct them.
Exceptions might need room for human judgment rather than being forced through an apparently perfect flow.
Different product decisions.
Same underlying reason.
That is coherence.
And this is where customer understanding becomes more useful than an insight report.
It becomes decision logic.
05 · Reality
Then reality gets a vote
Even after all of that, we still do not know which solution will work.
That separation protects against a very normal human habit.
We understand something interesting.
We have a plausible explanation.
We get excited.
And somehow, twenty minutes later, there is a feature in Jira.
Continuous Discovery slows down that jump.
For me, there are two additional questions inside that movement:
What do we believe is actually producing this behavior?
and:
What role are we choosing to play in changing it?
Then the solution becomes a hypothesis about how to express that role.
Eventually, though, the company acts.
And that is where experience becomes interesting in a different way.
Experience is not only what our decisions produce.
It is also where our model meets reality.
Maybe users follow the procurement flow more easily once the system carries more of the context.
Maybe they still leave the flow when a particular compliance case behaves differently.
Maybe one part of the process can be automated while another still needs judgment.
Each of those outcomes tells us something.
Maybe our explanation was incomplete.
Maybe the company chose the right role but expressed it poorly.
Maybe the role works in one part of the process but reaches too far in another.
And sometimes the deeper learning is not:
“We need to improve the feature.”
It is:
“We should be playing a different part in this progress.”
That is a much bigger update.
06 · The model
Progress Architecture
I have started thinking of this whole relationship as Progress Architecture.
Not as a replacement for Jobs-to-be-Done, Continuous Discovery, service theory or strategy.
Those bodies of work already explain important parts of the system extremely well.
What interests me is the relationship between them.
At its simplest:
- 1
Model the progress
Understand what the person is trying to achieve, change, avoid or preserve. Preserve enough context for the behavior to have meaning. Form mechanism hypotheses carefully enough that they can be challenged.
- 2
Choose the role
Decide which part of that progress the company can credibly participate in. That choice should create trade-offs and enough shared logic for different teams to make coherent decisions.
- 3
Let experience update the model
Act. Test assumptions. Observe what happens. Update the solution, the explanation and, when necessary, the company’s role itself.
The interesting part is not the sequence.
It is the translation between the layers.
Behavior needs context before it has meaning.
Understanding needs strategy before it becomes direction.
Strategy needs experience before we know whether it survives contact with reality.
That is the loop.
And maybe the most important part is remembering that the customer’s progress never belonged to the company in the first place.
We get to participate in it.
Sometimes meaningfully.
Sometimes briefly.
Sometimes we discover that the best strategic decision is to play a smaller role than we originally imagined.
That, too, is understanding the customer.
Intellectual lineage and further reading
- Clayton Christensen, Taddy Hall, Karen Dillon & David Duncan — Jobs to Be Done: Know Your Customers’ “Jobs to Be Done”, Harvard Business Review.
- Bob Moesta & Chris Spiek — Demand-side JTBD: Jobs to Be Done and Forces of Progress.
- Stephen Vargo & Robert Lusch — Service-Dominant Logic: foundational work on value in use, context and resource integration.
- Christian Grönroos — Service Logic: Value co-creation in service logic: A critical analysis.
- Teresa Torres — Continuous Discovery: Opportunity Solution Trees and assumption testing.
- Michael Porter — Strategy: What Is Strategy?