Notes from Agile Manchester 2025
My personal notes from my favourite talks at Agile Manchester 2025.
Here are my notes from Agile Manchester 2025. A mix of talk summaries, reflections, and key takeaways from the sessions that stood out to me.
If you're after my overall impressions of the conference, head to: My Takeaways from Agile Manchester 2025.
This post includes write-ups on:
It's All Just as Bad as You Think It Is: A Message of Hope in Turbulent Times
Continuous Compliance in Agile: Ensuring Quality and Regulatory Adherence at Pace
This is a lengthy post, so it may be best viewed online, as email clients can sometimes truncate the content.
Jobs to Be Done: Turning Insights into Action
About the Session
Jobs to Be Done (JTBD) is a product development theory turned framework that helps teams understand what a user is trying to achieve - their “job” - and how they measure success in completing it. Products are “hired” to do these jobs. If they fail, they’re “fired”.
In this session, Nic walked through the entire JTBD framework, showing how product teams can use it to:
Solve the right user problems
Uncover innovation opportunities
Support more focused product development
Takeaways
JTBD is about outcomes, not features
The central idea is that users "hire" products to help them achieve specific outcomes. Products that don't help effectively get "fired".
This reframes product development from building features to supporting user goals.
Core Functional Job ≠ Product Functionality
The core job is evergreen - it doesn't change with technology or products.
It's expressed simply as: Verb + Object + Context.
Example: “Make high-quality filter coffee at home” is a job, not a feature.
Desired Outcomes are the user's success criteria
These are what users care about most when getting a job done (e.g. speed, ease, accuracy).
They follow a formula: Direction + Metric + Object of Control + Contextual Clarifier.
JTBD uncovers hidden user behaviour
Like why someone might “fire” a coffee machine and “hire” a cafetière - it’s often about ease, not just quality.
These behaviours can only be surfaced through thoughtful, contextual interviews.
JTBD is a structured, repeatable method
It includes canvases, interview questions, outcome formulas, and mapping tools (e.g. the 8-stage user journey).
Tools like the Outcome-Driven Innovation (ODI) survey help prioritise innovation opportunities by plotting importance vs satisfaction.
You can apply JTBD to competitor analysis
By mapping desired outcomes against how well competitors support them, you can identify opportunity gaps.
Job stories improve design alignment
They bring context and motivation into focus:
“When I [situation], I want to [motivation], so I can [desired outcome].”
The Four Forces model explains switching behaviour
Helps understand what pulls users toward or pushes them away from a product - including habits and anxieties.
Crucial for thinking about adoption, retention, and change resistance.
JTBD can support Quality Engineers (QEs)
You see potential in using JTBD to help QEs understand end-user goals and journeys.
This insight allows QEs to focus on what matters most to users - e.g. usability, reliability, speed - and build relevant quality attributes and measures around those.
Clayton Christensen’s version feels more conceptual
While the talk focused on practical JTBD tooling, you gravitate toward Christensen’s high-level theory, which might align better with strategic quality thinking.
My Reflections
A very thorough talk that covered the framework end to end
Particularly useful for UX practitioners
Personally, I lean more toward Clayton Christensen’s high-level and theoretical framing of JTBD
That said, I see strong value in using JTBD to help Quality Engineers understand the end-user’s goal and how they get there
This helps identify which quality attributes matter most and how to measure the product against them
Key Concepts & Notes
Why JTBD?
JTBD offers a user-focused mindset. It shifts attention from what features users want to why they want them - what job they’re trying to get done.
What Is a “Job to Be Done”?
A “job” is the end goal a user is trying to achieve. Products are tools they “hire” to help them get there.
Example:
Nic wanted good filter coffee - not instant.
She had a coffee machine that should do the job… but she never used it.
Instead, she stuck with her cafetière - easier and quicker.
So she fired the machine and hired the cafetière.
🔍 What was the last thing you hired or fired?
The JTBD Framework
JTBD has evolved into a structured framework. It includes:
Core Functional Job: The high-level goal the user is trying to achieve
Desired Outcomes: How users measure success when doing that job
There’s also a Jobs to Be Done canvas to map it out:
Core Functional Job
This is the anchor point of the framework - a simple statement that defines what the user wants to achieve.
🧩 Formula:
Verb + Object (noun) + Contextual Clarifier
Guidelines:
Evergreen (not tied to a product or tech)
Objective (no emotion)
Specific, but not too narrow
Desired Outcomes
These are the user’s success criteria. What does “doing the job well” look like?
🧩 Formula:
Direction + Metric + Object of Control + Contextual Clarifier
To discover these, conduct JTBD interviews. Ask:
What were you looking to achieve?
What does success look like?
What steps did you take?
What tools did you use - and why?
What helped or hindered your success?
Rules of thumb:
Take time to get these statements right
Use sparring partners to challenge and validate
Involve observers to reduce bias
Mapping the Journey
You can map user needs across the entire job journey - 8 stages from start to finish.
Summary of the Framework
JTBD: Understand user end goals
Core Job: What they’re trying to do
Desired Outcome: How they judge success
What Do You Do with All This?
JTBD insights help you innovate and make better product decisions. Some of the tools mentioned:
Outcome-Driven Innovation (ODI) surveys
→ Measure how much users value different outcomes and how well you meet themCompetitor reviews
→ Are others doing a better job at meeting these outcomes?Four Forces diagram
→ Understand what motivates or prevents switching behaviour
ODI survey outputs are plotted visually to highlight opportunities:
Job Stories
Unlike traditional user stories, job stories focus on:
The context
The motivation
The desired outcome
When I [situation], I want to [motivation], so I can [outcome]
They help create deeper understanding of real user situations.
Competitor Analysis
Compare how well competitors meet the same desired outcomes.
The Four Forces
This tool explores what drives people to hire or fire a product.
Use it to understand:
Pulls toward your product
Pushes away from it
Habits anchor users to old solutions
Anxieties about switching
Where Should You Start?
Define the problem space clearly
Understand how successful your product is at helping users achieve their goals
Identify gaps and opportunities for innovation
📚 Suggested reading:
Final Thoughts
A rich, in-depth talk packed with practical detail. Great for:
UX and product folks looking to better understand user needs
Teams wanting to move from features to outcomes
Quality Engineers exploring ways to align quality with real user value
For me, the most exciting bit is applying JTBD in a quality engineering context:
Understand what users are actually trying to achieve
Identify the quality attributes that matter most
Develop meaningful metrics and measures to support them
JTBD isn’t just a product strategy - it’s a way to focus everyone on what really matters.
The Secret Skillset of the Most Successful Product People
About
Lessons learned from working with difficult people, and an introduction to the Product Environment Canvas: an easy tool that helps people move from adversarial relationships to productive ones.
My takeaways
Keep reading with a 7-day free trial
Subscribe to Quality Engineering Newsletter to keep reading this post and get 7 days of free access to the full post archives.