Helping buyers work out what they were actually hiring software to do, before comparing features

Software comparison content assumes the buyer already knows what they need. In practice, businesses buy tools to treat symptoms, then switch again a year later at considerable cost.

Turn a vague internal complaint into a defensible buying decision that survives contact with adoption.

Feature comparison optimises for the wrong variable. It answers 'which tool has more', not 'what progress are we trying to make and what would have to be true for this to work here'. The expensive failure is not choosing wrong; it is never articulating the job.

If you start with the progress someone is trying to make, the shortlist usually shrinks and the real constraint becomes visible — often process or ownership rather than software.

• Structured a JTBD interview into a guided flow a non-researcher could complete honestly.
• Separated the stated request from the underlying outcome and the forces holding the current situation in place.
• Made the output a decision document rather than a comparison table.

• Built the JTBD elicitation flow and the analysis layer behind it.
• Generated consultant-style buying briefs: job statement, constraints, criteria, risks, and what to verify in a trial.
• Added a six-month forecast of likely outcomes so the decision could be reviewed against expectation later.

• Cut the time needed to produce a consultant-grade buying brief by more than 95%.
• Moved software selection from feature-first to outcome-first.
• Made briefs consistent enough to compare across decisions.

See it live→

JTBD earns its keep when it is embedded in a workflow someone already has to complete. As a workshop it is a nice afternoon; as a form field at the point of decision it changes the decision.

• Personas describe people. Jobs explain decisions.
• Stop building workflows. Start giving objectives.