Product management
A core aspect of Amplio’s product management approach is combining the jobs to be done framework with a focus on the quickest valuable release.
The goal up front of product management is not to get complete requirements. It is to be a guide so when we discover more about what we need, we don’t create any wasted effort.
JTBD allows for this by focusing on the objectives instead of the details.
Amplio’s product management focuses on stakeholders, not just users. The term “users” evokes someone using the system. But very often there are others involved who do not use the system but get benefit from it. It is worth making this knowledge explicit.
The Jobs to be Done Framework
The Jobs to Be Done (JTBD) perspective begins with a simple but powerful idea: people do not buy products for their features, they “hire” them to make progress in their lives. Seen this way, design and development are about understanding the jobs people face, the situations that trigger them, and the outcomes they care about. JTBD offers a broad and relatively stable map of demand — the enduring reasons why people turn to solutions.
This is perhaps the biggest shift in using the JTBD perspective. The common approach of using wants and needs to generate features and stories focuses on problems that people have and how to overcome them. But a focus on problems inherently derives solutions to those problems. Innovation is often the result of looking at the objectives people are trying to do. There are often ways to achieve those objectives that take completely different approaches, ones that often don’t have nearly as many challenges to implement.
JTBD focuses on the progress stakeholders seek, not just their stated needs or preferences. By identifying these jobs, we can design solutions that align with real goals, not just surface-level requests.
The JTBD approach inherently has us look at the way our stakeholders work. This is often called the “customer journey.” When developers understand how the people they are creating value for work, it is much less likely that they will become feature factories. This context also improves communication between those studying what will create stakeholder value and those who will implement this.
The advantage of using JTBD over “wants and needs.”
Discovering wants and needs has been so ineffective it’s resulted in many people thinking that identifying objectives up front is not possible.
The JTBD approach inherently puts how a stakeholder is working in front of us. Too often requirements are stated without the proper context. This leads to misunderstandings.
Wants and needs are inherently about problems being faced. This immediately evokes solutions. Design thinking has taught us that we need to make sure we’re working on the right problem before offering solutions. This is inherent in the jobs to be done approach.
Avoids becoming feature factories or being at the effect of incomplete requirements.
When developers understand the workflows of the people they are creating value for they are more likely to create value and not merely pop out features.
Job Stories
A common way to capture a JTBD insight is with a job story: When [situation], I want to [motivation], so I can [value]. This form grounds the team in context, ensuring we anchor design in lived situations rather than abstract features. For example: When boarding a flight without network access, I want my boarding pass available, so I can get through the gate quickly. This statement reflects the demand signal, not a proposed solution.
A Caution About Who To Listen to Regarding Jobs to be Done.
As people are becoming aware of the power of jobs to be done, several agile thought leaders are putting JTBD practices into the common Agile frameworks of using features and stories. However, this represents a misunderstanding of the JTBD framework which is based on a different perspective than user stories.
Comparing job stories with user stories, demonstrates a misunderstanding of the jobs to be done approach. It’s comparable to putting the Daily Scrum into a waterfall approach. What’s missing in the bigger picture of the JTBD approach. When you understand that, you’ll stop using user stories, which are limited in many other ways besides what I’ve talked about here.
For a more in depth article on the Jobs to be Done approach, see Agile’s Next Step: From Wants and Features to Jobs and Outcomes
Watch a viedo on the perspective shifts of a jobs to be done approach here.
Aspects of Jobs to be done
This setion contains more detail on the Jobs to be Done Framework.
Perspectives of Jobs to be done
It’s not as important as who they are as what situation they are in.
Old view: Customers are defined by who they are (age, gender, income, role).
New view: Customers are defined by the situation they’re in when they “hire” a product to make progress.
Implication: Market segmentation shifts from who people are to when and why they act.
Example: A 40-year-old exec and a 20-year-old student both “hire” Uber when stuck in the rain.
Role takeaway: Marketers—segment by situation, not persona.
Shift 2: Features → Progress
What they use is not as important as what problem they solve.
Old view: Products are bundles of features.
New view: Products are tools customers hire to achieve progress toward a desired outcome.
Implication: Teams stop asking “what feature should we build?” and start asking “what progress is the customer trying to make?”
Example: Spotify’s offline mode isn’t just a feature—it lets users keep their gym routine uninterrupted when Wi-Fi drops.
Role takeaway: Developers & PMs—prioritize features that unlock progress.
Shift 3: Wants and Needs → Outcomes
Wants are driven by problems they face. Solutions become limited.
Jobs to be done represent progress to success.
Old view: Customers have “needs” that are often expressed as vague wants (“I want faster delivery”).
New view: Customers define success in measurable outcomes—reduce time, minimize effort, increase certainty—bounded by constraints (money, time, rules).
Implication: A shared measurement language between marketing and development emerges.
Example: “I want healthier meals” becomes “reduce the time it takes to prepare a fresh meal from 40 minutes to 15.”
Role takeaway: BAs—translate wants into measurable outcomes.
Shift 4: Competitors → Alternatives
Looking at competitors has us look at solutions.
Looking at alternatives enables innovation.
Old view: Competitors are other companies in your category.
New view: Competitors are any alternative a customer might “hire”—including non-consumption.
Implication: Marketers and product managers broaden their competitive radar.
Example: The Kindle doesn’t just compete with books, but also with Netflix, podcasts, and doing nothing.
Role takeaway: Marketers & PMs—look beyond your industry.
Shift 5: Solution-First → Problem Discovery
Looking at wants and needs focuses on solutions to problems.
Starting with jobs enables us to create innovative solutions.
Old view: Start wants and needs to overcome problems → find solutions.
New view: Teams start with understanding customers’ jobs, then develop solutions.
Implication: BAs and developers frame work around validated problems rather than speculative features.
Example: Payment app job = ‘make me confident my transfer is safe.’
Role takeaway: POs & BAs—frame backlog items around objectives.
Shift 6: Transaction → Ongoing Value
It’s not “one and done.”
Look for ongoing value delivery.
Old view: Value delivered at time of purchase.
New view: Jobs are continuous value added; products are re-hired or fired.
Implication: Product managers and owners must think in terms of customer lifecycle jobs, not single transactions.
Example: Meal-kit services are re-hired every week—or fired if they fail to make weekday dinners reliably easier.
Role takeaway: PMs—design for retention and continuous value, not just initial sale.
Shift 7: User Stories → Job Stories
By shifting from specifying value to specifying objectives we can see more solutions.
Old view: As a [persona], I want [to perform some action] so that [I can achieve some goal/benefit].
New view: When [situation], I want to [motivation], so I can [outcome].
Implication: Developers and product owners gain clearer context about why a feature matters.
Example: “When I’m boarding a plane with kids, I want to scan quickly, so I don’t hold up the line.”
Role takeaway: Developers & POs—code toward situation, not role.
Shift 8: Inside-Out → Outside-In
Instead of building in pieces build from the big picture.
Old view: Companies think in terms of capabilities and offerings.
New view: Companies align to the customer’s frame of reference, designing backward from customer progress.
Implication: Cross-functional teams align around customer progress language rather than departmental KPIs.
Example: Apple’s AirPods weren’t “wireless earbuds”—they solved “seamless connection + portability.”
Role takeaway: Everyone—align to customer progress.