Jobs
Tasks the user is trying to complete. They give us the context everything else hangs off — but a Job on its own can never authorise a feature.
FunctionalSocialEmotional
Pillar 01 · Product Thinking — how that pillar runs day to day
The future belongs to product thinkers, not engineers.
AI made it easy to build software. It didn't make it any easier to build a great product. We need to become great product thinkers and product designers. We have the engineering part covered already.
Digital future. Made in Europe.
Customer Value
The Product Thinking pillar, in full. One space describes the person, the other describes the product. If you can't write the first without naming the second, you haven't found the problem yet.
The model we run is Persona / Pain / Gain / Feature — a measurable extension of Alexander Osterwalder's Value Proposition Canvas.
Space 01
The Problem Space
The Customer Profile — the user's life, described with zero reference to our product.
Pains
Negative experiences tied to a Job. Either something going wrong now, or something that could go wrong later.
ProblemsRisks
Gains
Benefits the user is after from a Job — from the ones they'd walk away without, up to the ones they never thought to ask for.
RequiredExpectedDesiredUnexpected
Space 02
The Solution Space
The Value Map — exactly what we propose to build, and nothing that doesn't answer something opposite it.
Outcomes
What the product does about the Problem Space. Every Outcome is written as one of two things: a Reliever, which solves a Pain, or a Gain Creator, which delivers a Gain.
RelieversGain Creators
Features
The actual mechanism that delivers the Outcome — kept deliberately thin. The Feature is the last and smallest thing in the line, never the first.
Built deliberately thin
Jobs sit in the Problem Space and stay there. They explain why a Pain or a Gain matters; they don't cross over on their own.
Why we need a model at all
Holding the two spaces apart costs us discipline on every brief. This is what it buys.
The feature almost always comes first
Someone has an idea. The customer problem gets reverse-engineered to fit it, and because the problem was written to match, it always matches. The model makes that sequence structurally impossible — the justification has to exist before the thing it justifies.
The customer's reality and our product never share a box
We describe the user's life with no reference to what we're building, and only then describe what we propose to build. Two separate spaces, kept strictly apart, so we can tell whether we're solving a real issue or admiring our own idea.
Product fit stops being a feeling
It becomes a claim: that our Solution Space answers our Problem Space. A claim has a shape, so it can be traced, argued with and proven wrong. That is the whole reason the model is worth the discipline it costs.
From person to feature
Product fit is the testable claim that our Solution Space answers our Problem Space. Every feature earns its place by one of two routes. There is no third route.
-
Route A · through a Pain
Persona Job Pain Reliever Feature
-
Route B · through a Gain
Persona Job Gain Gain Creator Feature
The line reads in both directions. Forwards it's a case for building something. Backwards it's an audit: start at any feature in the product, walk left, and see whether you arrive at a real person.
The rules that make it bite
A model nobody enforces is a diagram. These four are what turn it into accountability — for real needs, not a founder's assumptions.
No orphans
A Feature must connect to at least one Reliever or Gain Creator. If it connects to nothing, it shouldn't exist — and the fix is deleting the feature, not inventing the Pain.
No shortcuts
A Job never crosses into the Solution Space without a Pain or a Gain attached. "Users need to do X" is context. It is not permission to build.
Convergence is the signal
When several independent Pains or Gains point at the same Feature, that's the strongest evidence we get that it's worth building. We look for it deliberately, and we build the convergent things first.
Prove it
Every claim in the model carries an ID, a source, and a falsifiability marker — how we would know if we were wrong. A claim nobody can disprove isn't evidence. It's an opinion with a reference number.
Where this leads
We don't justify features. We trace them.
Any feature we ship can be walked back to a person with a name, a job they're trying to do, and something specific that hurts or is missing. When that walk fails, we've learned something more useful than the feature: we've found an assumption we were about to build on.
Persona Job Pain or Gain Outcome Feature