Storytelling via Roadmaps

Most roadmaps are timelines. Rows and boxes and dates. They’re useful, but they rarely tell the real story of why we’re building anything, or what our work means for the person on the other end of the screen.

Customer stories, on the other hand, create instant clarity. They show us the stakes. They reveal the make-or-break moments. And they help teams align on the problem long before we talk about solutions. Ali Maaxa calls this the core dilemma — the moment where a customer’s adrenaline spikes because something matters. When we understand that moment deeply, the roadmap becomes less about features, and more about resolution.

What if we took a step back from our timelines and asked a different question:
What single customer story would explain our roadmap better than our roadmap?

Not a persona. Not a workflow diagram. But a customer story about a moment when something shifts in their world and they have a need. You can usually find the story by tracing backward from urgency: an alert, a deadline, a mistake, a handoff, a moment of pain. Look for the core dilemma or the moment that carries emotional weight for the user. Is it confusion? Risk? Embarrassment? Desire? Compulsion?

Once you spot that moment, the rest of the story becomes easier to see: the environment they were in, the people involved, the tools around them, the friction they’ve learned to tolerate. Are there workarounds they are using? Do some tools help or get in the way? And then to project into the future, what does the user hope will happen if things go right? What’s at stake if it doesn’t?

These elements form the real narrative spine of your product, and if you follow it honestly, you’ll often find your roadmap sitting right inside it. Some roadmap items resolve the tension beautifully. Others don’t belong at all. And sometimes you realize you’re missing the one thing that would change the entire experience.

When a team aligns on a story, the roadmap stops being a list and becomes a sort of promise: we understand this user moment, and we’re building toward a better one. Stories give teams meaning. And meaning invites better decisions.

---

STAND-UP EXERCISE

In your next team meeting or retrospective, ask everyone to individually jot down:
What is one customer story that explains why this roadmap exists?

Encourage simplicity. Look for the core dilemma.

Then, share your stories. Instead of debating accuracy, listen for:

• patterns

• emotional moments

• stakes

• recurring characters

• recurring friction

Then see if you can coalesce around a story or two, and piece those into your roadmap.
If this story were our north star, what on the roadmap feels essential?
What feels optional?
What feels missing?

Continue to come back to your customer story during roadmap reviews and share-outs, and find and refine new ones over time.

A Gratitude Practice for Product Teams

We spend a lot of our time scanning for gaps - what’s missing, what’s broken, what needs to be better. It’s a big part of our job. But November is a good moment to pause and notice the scaffolding we don’t usually talk about: the customer behavior that reveals something meaningful, the constraint that sharpened our thinking, the teammate who quietly made things easier.

Gratitude in a product context isn’t fluff.
It’s a tool for clarity.
It can help us see where value actually comes from, and what enables good work to happen. It is worth taking some time to recognize the things we build on, not just the things we build next.

Teams that practice noticing what’s working (not just what’s missing) can make better contextual decisions. They communicate with more generosity. They can catch customer signals earlier. They avoid unnecessary tension. And they build more trust, which is the quiet backbone of any healthy product org.

Gratitude helps teams name the inputs worth protecting - the relationships, habits, and insights that give the work its sturdiness.

Where to look for gratitude in a product team setting:

1. Gratitude for Customers
   What’s something a customer did, said, or struggled with recently that made our product better? Think about the small moments like a surprising workaround, an offhand comment, a behavior that reframed your understanding.

2. Gratitude for Constraints
   What limitation (timeline, tech, scope, capacity) forced us to simplify or focus? Which constraint improved the outcome once the frustration faded?

3. Gratitude for the Team Behind the Scenes
   Who made your job easier this month in a way no dashboard captures? A clear diagram. A thoughtful question. A fast bug fix. A structured meeting.

4. Gratitude for Steady Systems
   What process, ritual, or tool quietly holds more weight than we acknowledge?Which of our habits would actually hurt if they disappeared?

5. Gratitude for Growth Moments
   What moment stretched you, and ultimately made you better? A tough conversation. A pointed critique. A tradeoff that clarified what mattered.

Teams often think their value is defined by velocity. But the real story is the network of relationships, insights, constraints, and micro-moments that support the work. Naming these things isn’t just “feel-good energy.” It strengthens alignment. It builds trust. And it reminds teams that progress is never a solo achievement; it’s collective.

Gratitude helps us understand what enables us, not just what we produce. As we move into the last stretch of the year, this practice helps teams end on steadiness, grounded, connected, and aware of the things that truly matter.

---

STAND-UP EXERCISE

Using the five prompts of where to look for gratitude (above), ask the team to individually finish this sentence:

“Our product is better because _________.”

You might set a specific time frame (last 2 quarters, last year) to help focus the exercise. Capture the responses as a type of retrospective and way to tell the story of your product and team.

Tooling (and AI, of course)

The market is overflowing with tools - AI assistants, collaboration platforms, analytics dashboards, niche SaaS products (with AI integrated!) for every imaginable workflow. It’s tempting to try them all. But tooling is not strategy. A good tool accelerates existing strengths; a poor one multiplies inefficiencies.

Some organizations love to collect tools like shiny objects. Every pain point comes with a new platform, subscription, or “quick fix.” And of course AI has entered the landscape by force, as chat but also wizards within other platforms. Some teams are being mandated to be using AI, so that the business is not “left behind”. The problem: tools don’t solve problems. People do. Tools only accelerate (or complicate) the work depending on how they’re introduced and adopted.

Effective teams treat tools as part of their operating model, not as shiny objects. They introduce them intentionally, guided by a few questions:

1. Fit — Does the tool align with the way people already work? If it requires people to constantly context-switch or feels like extra work, adoption will die fast. Tools should dissolve into existing habits, not demand entirely new ones.

2. Friction — Does it remove barriers or add new ones? Does it work for everyone on the team or just a subset of folks?

3. Focus — Is it solving the right problem, or just a problem? Does this distract from what we should be actually working on?

4. Flexibility — What’s the plan if the tool doesn’t work out? Too often, teams get stuck with tools that don’t scale or can’t integrate. Part of “trying something new” should always include the question: If this doesn’t work, how do we exit?
   

Organizations that answer these questions up front could save themselves months of rework and resistance.

Too often, teams focus on what tools to use instead of how to use tools well. A team that doesn’t know how to run effective meetings won’t suddenly become effective with an AI note-taker. A company that avoids tough prioritization decisions won’t magically improve by adding another project management suite.

The tools that truly stick for your team might not be the buzzy ones. FigJam for collaboration. Miro for brainstorming. ContentSquare for understanding behavior. Yes, ChatGPT for drafting and discovery. But sometimes a shared doc and a standing meeting are still the most powerful tools you can have.

The best teams don’t chase every new tool. They learn how to audit, experiment, and fold the right ones into their culture. That’s how tools stop being shiny objects and start being leverage.

---

STAND-UP EXERCISE

At your next team stand-up, run a quick tooling audit together:

• List the top 3–5 tools your team uses daily.

• For each tool, ask:

  • How does this fit into our flow of work?

  • What friction does it remove? What friction does it add?

  • Are we using it to solve the right problems?

• Choose one tool to experiment with improving. Compare notes on how each other uses it. Does someone need more training? Are there ways to be using it more effectively? Simplifying? Or a need to sunset it or an overlapping tool?

The goal isn’t to chase the next new platform. It’s to ensure the tools in use are actually serving the team, the process, and the outcomes.

Time Estimation

Estimation is becoming harder. Figuring out how long a given task might take has always been a little fraught, as many organizations have an expectation of speed, but with the advent of new AI tooling, there are more unknowns. But estimation is as important as ever in the product development process.

Estimation does three things for a team:

1. Provides transparency

2. Opens up a conversation

3. Reinforces prioritization

First, providing estimates on work gives information to the team and stakeholders, making the process more transparent and generally collaborative. Your stakeholders have more realistic expectations about when a feature they’ve requested might launch. Product managers and scrum masters know when to check in with the development team without being intrusive. It removes an element of surprise from everyone.

Secondly, delivering an estimate on a piece of work begins a conversation. Questions about if elements are included or not can be answered. Information about if that fits into the timeline of the larger epic or campaign or project can be given. Complexity or dependencies can surface earlier, instead of waiting until they are more emergencies.

Third, understanding how long work might take gives clarity to how necessary the work is. For both the product team and the stakeholders, the question can then be asked, given this amount of time and effort, do we want to continue with the work as is? Or is something else best suited to begin now? Estimations can help clarify if we are on track for the goals of the product.

Estimation does not always need to be rigorous. Words like “ballpark” and “t-shirt sizing” are appropriate when talking about work to be done. Story points are more exact and often used, but also have their dissenters. The important part though is the dialogue that comes from the act of estimation and delivering that estimation to interested parties.

---

STAND-UP EXERCISE

In your product team, review your estimation process. Is everyone on the same page about how estimating work happens, where it is logged, and what to do when/if estimates change? Talk about examples of when presenting an estimate to a stakeholder changed the work - was it de-scoped or expanded, were complexities discovered, did the overall project take a different shape?

If you have been tracking estimation over time and have begun to use AI tooling, is that changing the way that you estimate?

For your team, when are estimates presented to stakeholders and how does that conversation emerge? Are there opportunities to improve that process and relationship?

Uncovering and Challenging Our Hidden Assumptions

Product teams constantly make decisions rooted in beliefs about their users, market conditions, and solutions. The challenge emerges when these beliefs remain unexamined—when teams operate as if their assumptions are established facts. In Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value, Teresa Torres highlights how teams must actively identify and test the assumptions that drive their product decisions, particularly those tied to meaningful business outcomes.

The risk lies not in holding assumptions, but in failing to recognize them as such. Unacknowledged assumptions become invisible drivers of product direction, potentially leading teams to build solutions for non-existent problems or chase metrics that don't actually matter. When assumptions masquerade as certainties, teams lose their capacity for genuine learning and user-centered discovery.

Torres advocates for connecting discovery work directly to desired outcomes, but this connection only works when teams honestly surface what they're taking for granted. High-performing product teams distinguish themselves by making assumption identification a regular practice, transforming invisible beliefs into testable hypotheses. Testing your assumptions is a much quicker and more repeatable process than testing new features. To test an assumption, you are simply looking for confirming or disconfirming evidence to support or dispute, which can prevent continuing on an unadvisable path.

Torres groups assumptions into five categories: Desirability, Viability, Feasibility, Usability, and Ethical. Grouping assumptions can help you see where your blind spots are, or in what ways you might carry bias.

Consider a recent feature your team shipped or is currently building. Chances are, it's built on a foundation of assumptions about user behavior, business impact, technical feasibility, and competitive landscape. Some of these assumptions may be well-founded, others completely wrong. Without a deliberate practice of assumption identification and testing, you're essentially building blindfolded.

---

STAND-UP EXERCISE

Choose a current project, feature, or initiative your team is working on. As a group, spend 15-20 minutes identifying the assumptions underlying this work. Use these prompting questions:

User Assumptions:

• What do we assume about who will use this feature? Does anyone want it?

• What problem do we assume this solves for them? How prevalent is that problem?

• How do we assume users will discover and adopt this?

• Is there any potential harm to our users in building this? (Think about data storage, categorization, user habits / dark patterns, disruption, etc.)

Business Assumptions:

• What impact do we assume this will have on our key metrics? Or will it support our broader business goals?

• What do we assume about the competitive advantage this creates?

Technical Assumptions:

• What do we assume about the technical feasibility or complexity?

• Do we assume this passes our legal / security / compliance safe guards?

• What do we assume about performance, scalability, or maintenance?

Market Assumptions:

• What do we assume about timing—why now?

• What do we assume about our users' current alternatives?

After identifying 8-12 assumptions, categorize them:

• Validated: We have evidence supporting this assumption

• Testable: We could easily gather evidence for this assumption

• Risky: This assumption, if wrong, would significantly impact the project's success

Pick the 2-3 most risky assumptions and discuss: What's the smallest test we could run to validate or challenge this assumption? Could we test it through a customer interview, analytics review, prototype, or small experiment?

Remember: This exercise aims to illuminate assumptions, not eliminate them entirely—that would be impossible and counterproductive. The value lies in making hidden beliefs visible and focusing testing efforts on assumptions that could significantly impact your project's trajectory. Torres' approach to continuous discovery centers on weaving customer insights into everyday product decisions, and systematic assumption testing provides a concrete method for achieving this integration.

This exercise works best when teams approach it with curiosity rather than defensiveness. The assumptions you uncover aren't failures—they're opportunities to learn and build better products.