Using the Product Discovery Canvas, Part 5: Tell Stories about the Product

June 4, 2025 Bill Allen
Off
User Story Maps

So far in this blog series, we’ve written our elevator pitch, identified our users and customers, and established our goals and success measures. Now we’re ready to tackle Discovery Box 6 on the Product Discovery Canvas: Tell Stories about the Product. This is where things get really interesting—and really human.

Why Stories Matter in Product Discovery

Here’s the thing about stories: they’re how we make sense of the world. When Jeff Patton talks about user story mapping in his book User Story Mapping: Discover the Whole Story, Build the Right Product, he’s not just talking about a technique. He’s talking about how we understand what people really do and why they do it.

Think about it this way: you can have all the personas and requirements documents in the world, but until you can tell a compelling story about someone using your product, you don’t really get it. Stories force us to think through the messy, human reality of how products actually get used.

I’ve seen too many teams jump straight into feature discussions—“We need login, and shopping cart, and notifications.” But Patton’s insight is brilliant: talk about the user’s journey through your product by building a simple model that tells your user’s story as you do. Suddenly, those features have context. They have purpose.

User Story Mapping: Your Story Structure

If you’ve been following this blog series, you probably noticed that I mentioned story mapping would be coming up. Well, here we are! User story mapping is essentially a way to organize your product stories so they make sense.

Picture this: instead of a flat list of features, you create a visual backbone that shows the customer journey from left to right. Under each step of that journey, you stack the stories that support that step. The result? You can see the whole story of your product.

This approach keeps your users and what they’re doing with your product front and center, which is way better than getting lost in feature arguments—like what normally happens in software development.

Getting Practical: How to Tell Your Product Stories

Let me share how I guide teams through this discovery box. First, get your team together—and I mean everyone. You want people who understand the business, people who understand users, and people who understand technology all working together. No handoffs. No silos.

Start with the backbone. Ask: “What’s the basic journey someone takes when they use our product?” For our Card SafeZone example from earlier posts, it might be: Discover threat → Check safety → Make decision → Use card → Get feedback.

Now, under each step, start telling stories:

  • “Sarah’s rushing through the airport when she gets a fraud alert on her phone…”
  • “Marcus is at a new restaurant downtown and wants to pay, but something feels off about the card reader…”
  • “Lisa just moved to a new city and doesn’t know which ATMs are safe to use…”

These aren’t requirements. They’re human moments that help you understand what you’re really building.

The Card SafeZone Story Map

Let’s apply this to our Card SafeZone example. Our backbone might look like this:

Discover → Assess → Decide → Act → Learn

Under “Discover,” we might have stories like:

  • Consumer hears about card fraud on the news
  • Retailer wants to advertise their security measures
  • Bank customer calls about suspicious activity

Under “Assess,” we get into the meat of our product:

  • Consumer checks safety rating before entering store
  • Retailer views their security score
  • Bank monitors fraud patterns in real-time

You get the idea. Each story helps you understand not just what features you need, but why they matter.

Making Stories Real

Here’s what I’ve learned from years of doing this: the best product stories feel real because they are real. Don’t just make stuff up. And this is important…  you need to actually observe and understand your users.

Go talk to people. Watch them. Understand their context. Are they stressed? Hurried? Distracted? Are they on mobile or desktop? In a noisy environment or a quiet one? All of this context shapes your stories, and your stories shape your product.

Stories as Shared Understanding

One of the things I love about Patton’s approach is how changeable story maps enable your team to hold better conversations about the project throughout the development process. Your team will learn to come away with a shared understanding of what you’re attempting to build and why.

I’ve seen this magic happen in dojos. A developer will say, “Wait, why would someone do that?” A designer will respond, “Because they’re scared their card information was stolen.” Suddenly, the whole team gets it. The feature isn’t just a checkbox—it’s solving a real human problem.

From Stories to Development

Here’s the beautiful thing about user story mapping: it doesn’t just help with discovery. It guides everything that comes after. Your story map becomes your roadmap. It helps you decide what to build first (the minimum viable story), what can wait, and what might not be needed at all.

With experience you will find that the goal isn’t to build every story. The goal is to understand the complete user journey so you can identify the minimum viable experience that delivers real value.

Keeping Stories Alive

One last thing: these stories aren’t written once and forgotten. They evolve as you learn. As you move through the rest of the Product Discovery Canvas—especially when you get to validation and learning—you’ll discover new stories, modify existing ones, and sometimes kill stories that are nio longer relevant.

That’s the point. Stories are living documents that help you stay connected to the human reality of your product. They remind you that behind every feature, every design decision, every line of code, there’s a person trying to get something done.

In the following blog (ideally without a 10-year delay), we’ll move into Discovery Box 7: Validate if it is the right Product to build. That’s where we take these user stories and test them against reality. Because as much as we love our stories, what matters most is whether they’re true.

Explore the Product Discovery Canvas, read the previous blogs, then try story mapping with your own product idea. And as always, I’d love to hear about your experiences—the successes, the frustrations, and everything in between.

References and Further Reading:

User Story Maps

Comments are closed.

Recent Comments