Quality Engineering Newsletter

Quality Engineering Newsletter

Share this post

Quality Engineering Newsletter
Quality Engineering Newsletter
Notes from Agile Manchester 2025

Notes from Agile Manchester 2025

My personal notes from my favourite talks at Agile Manchester 2025.

Jit Gosai's avatar
Jit Gosai
Jun 29, 2025
∙ Paid
1

Share this post

Quality Engineering Newsletter
Quality Engineering Newsletter
Notes from Agile Manchester 2025
Share

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:

  • Jobs to Be Done: Turning Insights into Action

  • The Secret Skillset of the Most Successful Product People

  • Why Your Team Is Underperforming

  • It's All Just as Bad as You Think It Is: A Message of Hope in Turbulent Times

  • Becoming a Service Organisation

  • 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

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. You can apply JTBD to competitor analysis

    • By mapping desired outcomes against how well competitors support them, you can identify opportunity gaps.

  7. Job stories improve design alignment

    • They bring context and motivation into focus:
      “When I [situation], I want to [motivation], so I can [desired outcome].”

  8. 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.

  9. 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.

  10. 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 them

  • Competitor 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.

Already a paid subscriber? Sign in
© 2025 Jitesh Gosai
Privacy ∙ Terms ∙ Collection notice
Start writingGet the app
Substack is the home for great culture

Share