0:00
/
0:00
Transcript

Is Your Agile Backlog a Roadmap to Nowhere?

User stories are great for execution but terrible for strategy. Discover the two-engine model that connects development to validated customer needs.

The Speed Trap of Modern Development

We all love Agile. It’s given us speed, flexibility, and a way to finally break free from the rigid, waterfall-era monoliths of the past. Your teams are running sprints, clearing backlogs, and shipping features faster than ever. It feels like progress.

But what if it's an illusion?

Speed is useless without direction. And the hard truth is that many "customer-centric" Agile teams are diligently following user stories that lead directly to a dead end. They're creating incremental improvements for a product nobody will care about in five years, all while completely missing the breakthrough innovations their customers are desperate for.

So, what's the missing link? You need a strategy engine.

The Practical Innovator's Guide to Customer-Centric Growth is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

The Real Problem with User Stories

The user story is the bedrock of most Agile development. The "As a..., I want..., so that..." format is simple, clean, and gives developers a clear task to execute. But it's also a trap.

Consider a user story from a real-world product development brief for a smart coffee maker:

"As a user, I want a carafe so I can hold the coffee."

On the surface, this seems fine. But look closer. It’s a request that is entirely locked into the existing solution. It doesn’t tell you why the user needs to hold coffee, what they're really trying to accomplish, or what struggles they have with the entire process. It asks the development team to build a better version of a known component.

This is how you end up building "faster horses" when your customers are ready for an automobile. User stories are great for execution, but they make for a terrible strategy because they start with the solution, not the problem.

Finding True North: Moving Beyond Fables to Functional Jobs

To find the right direction, you have to adopt the Jobs-to-be-Done (JTBD) mindset, which states that customers "hire" products to get a job done.

You’ve likely heard the famous milkshake story. It's a great parable because it gets you to think beyond a product's features. The lesson is that a commuter "hired" a milkshake for the "job" of making a long, boring commute more interesting. It’s a good first step in changing your thinking.

But it’s a dangerous foundation for a real innovation process. Why? Because "making a commute more interesting" is a situational story about one type of person. It's not a stable, functional job that an entire market is trying to get done. A real, data-driven innovation process needs a target that is measurable and applies to an entire market, not just a single persona.

Let's contrast that fable with a disciplined process. For years, Arm & Hammer Animal Nutrition thought their job was to "provide nutrition" to dairy herds. Their research helped them reframe the customer's job, clarifying that the customer was the dairy producer, not the nutritionist. They discovered the producer's real functional job had little to do with nutrition;

it was to "optimize herd productivity."

Unlike the milkshake story, "optimizing herd productivity" is a measurable, functional job with over 165 different desired outcomes that matter to

every dairy producer. By focusing on that stable, well-defined job, Arm & Hammer grew their revenue by over 30%, year-over-year. That's the difference between a good story and a great strategy.

Elevating the Abstraction: From Cutting Wood to Building Houses

Framing the job at the right level of abstraction is where the magic happens. If you get this wrong, you could be innovating yourself into a corner.

Imagine you're a tool company. You do research and find that your customers' job is to "cut wood." So, you invent a better circular saw. It's a fantastic product performance innovation, and you sell a lot of them.

But what if you had asked why they were cutting wood? You might have discovered their real, higher-level job was to

"build a house."

Focusing on "building a house" opens up a universe of possibilities that you'd never see if you were only thinking about "cutting wood." It forces you to ask different questions. This is precisely how you get to something as revolutionary as 3D-printed homes—a breakthrough innovation that gets the job done completely differently, often faster and cheaper.

A Powerful Partnership: The Two-Engine Model for Innovation

The solution isn't to abandon Agile or user stories. It's to connect your powerful development engine to an equally powerful strategy engine.

Engine 1: The JTBD Strategy Engine (The 'What' and 'Why')

This is your upstream, foundational work. Using a rigorous process like Practical Jobs-to-be-Done, you define the customer's core job, uncover all their needs (as measurable outcome statements), and use quantitative research to identify which of those outcomes are most underserved - from the bottom-up.

The output isn't a list of features. It's a prioritized list of unmet needs—a data-driven map of market opportunities. This engine tells you

what problems to solve and why they matter.

Engine 2: The Agile Development Engine (The 'How')

This is your downstream execution. This is where a framework like AGILE or standard Scrum shines. Your product and development teams take the prioritized opportunities from the strategy engine and use their expertise to design and build the solution.

Now, when they write a user story, it's not based on a guess. It's directly linked to a validated, unmet customer need. This ensures their incredible speed and creativity are focused on building things that create real value.

Unlocking True Innovation: Moving Beyond the Product

When you fuse these two engines, you do more than just build a better product. You create the foundation for innovating across all of Doblin's 10 Types of Innovation, creating a competitive advantage that's nearly impossible to copy.

Novel Concept Example: From Coffee Maker to "Productive Morning as a Service"

Let's go back to coffee.

  • The Limited Agile Story: "I want a smart coffee maker."

  • The Higher-Level Job: "Prepare for a productive workday."

Focusing on that higher-level job can lead you to a novel concept that's not just a product, but an entire platform: a "Productive Morning as a Service."

This is a future-forward concept that could look something like this:

  • The Solution: An integrated system designed to get the user's day started perfectly. It's a single solution that gets the job done better and with fewer visible features for the user to manage.

  • Profit Model: It's a subscription service, not a one-time product purchase.

  • Product System: A smart-brewing device is part of the subscription. It's perfectly calibrated and linked to a curated coffee bean delivery service that ensures you never run out.

  • Process/Service: The service includes automated, deep-cleaning cycles and predictive maintenance alerts. The machine takes care of itself.

  • Channel: An intelligent app serves as the hub. It does more than just control the brewer; it connects to your calendar and suggests what time you should wake up, when your coffee should be ready, and maybe even queues up a 5-minute morning meditation.

This isn't a better coffee maker. It's a completely new way of getting the job done. It elevates the level of abstraction from "brewing coffee" to "starting the day right," creating far more value.

Here's how creativity triggers can help us map this out:

Stop Wasting Your Speed

Your Agile team has a powerful engine. They can build almost anything you ask them to. The most important question you can answer for them is not how to build, but what to build and why.

Stop asking your team to be both navigators and engine builders. Give them a clear, data-driven destination derived from a deep, authentic understanding of your customer's functional Job-to-be-Done. Integrating a JTBD strategy engine with your Agile development process isn't just an improvement; it's the missing link to building truly innovative products and services that win in the market.

So, what functional job is your customer really trying to get done?

A Point of View: Integrating Strategic JTBD with Agile Execution

This is my personal take on the reality we face of working with design cultures. I’m going to break down the problem and then offer a solution. It’s really very simple…one size fits none. And one team, can’t do everything; no matter how skinny their jeans or how many of these they’ve had this morning:

“I'd like a Venti iced quad-shot upside-down caramel macchiato, made with half oat milk and half heavy cream. Please use two pumps of white chocolate mocha, three pumps of toasted vanilla syrup, and one pump of hazelnut. I'd like the cup lined with extra caramel drizzle, and please add two scoops of vanilla bean powder and a packet of raw sugar, shaken, not stirred. Top it with vanilla sweet cream cold foam, extra caramel drizzle, and a generous sprinkling of both cinnamon dolce and edible glitter. Oh, and can you add a single, sad-looking strawberry on top?”

Working with a Design Team for a Mutual Client or Stakeholder

Objective: To propose a unified innovation model for a mutual client that integrates the strategic, upstream insights of Practical Jobs-to-be-Done (JTBD) with the downstream speed and clarity of an Agile execution framework like that used by [Your Design Team]. This integrated approach is designed to de-risk innovation and ensure development efforts are focused on validated customer needs that drive growth.


Analysis of Strengths & The Opportunity for Integration

[Your Design Team]'s framework provides a clear, structured process for guiding development teams. Its focus on user stories creates an actionable language for designers and engineers, making it highly effective for improving and iterating on a known solution. It answers the question, "How can we build this solution better and faster?"

Our practical JTBD process operates at the strategic level, before a solution is finalized. It answers the fundamental questions, "What is the core problem the customer is trying to solve?" and "Which of their needs are most underserved?" By defining the market around the customer's core Job-to-be-Done, we provide a stable, data-driven "True North." This is essential for identifying opportunities for breakthrough innovation and new value creation, not just incremental improvements.

The opportunity lies in creating a powerful, two-stage innovation pipeline:

  1. Upstream Strategy (JTBD/ODI): We first identify and quantify the most promising innovation opportunities by focusing on the customer's job and desired outcomes.

  2. Downstream Execution ([Your Design Team]): [Your Design Team]'s framework then takes these validated and prioritized opportunities and translates them into actionable user stories and features for the development team.

This synergy ensures that the client's investment in Agile development is not wasted on building the wrong things. We provide the destination; [Your Design Team] provides the vehicle to get there efficiently.


Redefining the Approach: From Competing Methods to a Unified Model

The comparison below re-frames the relationship between the two approaches. Instead of viewing them as alternatives, it positions them as complementary parts of a comprehensive innovation process, highlighting how a strategic JTBD layer enhances the value of Agile execution.


Proposed Collaborative Workflow

  • Phase 1: Strategy & Discovery (Our Role): We will lead the initial research to define the core Job-to-be-Done, map the customer's desired outcomes, and field a survey (or produce novel simulations) to quantify the biggest opportunity gaps in the market.

  • Phase 2: Translation & Execution ([Your Design Team]'s Role): [Your Design Team] can take the top 3-5 prioritized opportunities from our research and use their framework to brainstorm solutions and craft targeted, effective user stories (and test the h*ll out of them!) that directly address these validated needs.

  • Phase 3: Measurement & Iteration (Joint Effort): Together, we will help the client measure success not only by development velocity and feature adoption, but by the ultimate metric: how much better and/or more cheaply we are helping the customer get their entire job done.

It’s really this simple. Any questions?

Follow me on 𝕏: https://x.com/mikeboysen

If you'd like to see how I apply a higher level of abstraction to the front-end of innovation, please reach out. My availability is limited.

Mike Boysen - www.pjtbd.com
Why fail fast when you can succeed the first time?

📆 Book an appointment: https://pjtbd.com/book-mike

Join our community: https://pjtbd.com/join

Discussion about this video