One of the most underrated superpowers of an effective product manager is the ability to empower engineers and designers to do their best work. Early in my career, I fell into a trap: I would walk into meetings with a pre-defined solution in mind—exact wireframes, specific user flows, and step-by-step functionalities. What happened? The engineering and design teams felt like they were just “button pushers,” implementing someone else’s idea without room for creativity. Not surprisingly, the final outcome often missed the mark, failing to deliver the best experience for the users.
Over time, I discovered that the best solutions emerged when I presented a compelling problem rather than a prescriptive solution. By clearly articulating the story behind a feature, I invited the entire team to brainstorm. As a result, the team brought innovative solutions to the table, and designers refined user flows beyond what I had imagined. This is where storytelling became my secret weapon: it helps define the problem in a relatable way that motivates everyone to find the best possible solution.
The “Unfinished Story” framework
The key to successful collaboration is to set a clear stage. I like to transform my problem statements into engaging narratives. People love stories—it’s human nature.
I use a simple, five-step storytelling framework to define problems. However, there’s a trick: I skip the happy ending. The solution is deliberately left out so that the engineers and designers have the freedom to propose how to achieve the resolution.
- Introduction
- Build Up
- Problem
- Exploration
- Resolution (where I stop, letting the team create the solution)
This framework can be applied to feature kickoffs, product requirement documents (PRDs), user stories, or even smaller tasks. It can be used when developing new features or improving current ones. Let’s dive into each piece.
1. Introduction (Context & Background)
Definition
- The story begins by providing all relevant background information that the engineering and design teams might not have.
- We also define the “hero” of the story, which is the end user who will be interacting with the feature.
- The introduction will offer business context that will help understand the problem (eg. Market swifts, user behavior changes).
- It may also explain what the current user experience is. The hops users currently go through.
Example
- Credit card customers who usually don’t like being charged fees or interest often pay in advance and track their payments very carefully.
- They use our mobile app to schedule a payment for the day before it is due. The system “waits” to charge the customer until a specified date.
- The system processes the payment successfully. However, bank transactions usually take between 1 to 3 business days to process.
- We’ve noticed that our biggest support call driver is credit card customers asking for confirmation on whether their payment went through.
2. Build Up (The ‘Why’ & Business Impact)
Definition
- People are motivated by impact. As the story builds up, we need to demonstrate why the problem is important to solve. We want to show the magnitude of the problem
- The build-up can either show the negative impact the hero is experiencing (eg. X mins to resolve support ticket) and/or the positive impact if the pain point is resolved (eg. enter X market, increase retention by X%)
Example
- This is the #1 customer call driver, which translates to ~25% or 2k calls per month. High call volumes put pressure on our customer support team, increasing wait times and operational costs.
- From user surveys, around 20% of our users who switched credit card companies stated that our lack of payment transparency in our app is a major setback.
3. Problem
Definition
- This section marks the climax of our story, where the core conflict comes into sharp focus.
- We pinpoint what is holding our hero back and the struggles they are facing.
- A well-defined problem shines a light on the root cause, giving everyone clarity on what truly needs to be solved.
Example
- After scheduling an online payment, users don’t receive a clear confirmation that they payment was processed and that the new state of their account. When customers can’t verify their payments, they panic and call support for help.
4. Exploration(Use cases and examples)
Definition
- The exploration section shares the different scenarios and paths the hero might take. Outline use cases to guide tactical conversations, acknowledging that these can evolve as the project moves forward.
- It elaborates on the problem statement, which is usually the longest part of the document. Provide as many use cases as possible. Share the different paths that the hero takes to accomplish the current workflow
- Examples will help you to drive more tactical conversations. These use cases will be revised multiple times as the solution is being built.
- The “Exploration” is dynamic. Scenarios may shift or grow in complexity as we uncover new information, making this documentation a living resource that keeps everyone aligned.
Example
| Priority | Use Case |
| P1 | User scheduled payment for 1 day before payment is due. The payment covers the entire balance, and it was successfully processed. No fees or interest is charged |
| P1 | User scheduled payment for 1 day before payment is due. Payment is declined due to lack of funds or wrong bank account. User is subject to fees and interest. |
| P1 | User scheduled payment for 1 day before payment is due. System failed to process payment. Customer shouldn’t be liable to pay fees and interest. |
| P2 | User scheduled payment for 1 day before payment is due. The next day, he/she changes his/her mind and cancels the transaction |
| P3 | User schedule multiple payments in advance. The sum of all of them exceed the balance. |
5. Resolution
Purpose
- The story won’t have a happy ending yet, so leave the final resolution undefined.
- Crafting a solution for the hero’s pain point is a collaborative approach where product managers, engineers and designers come together to solve.
- As the solution is crafted, it’s important to keep in mind that all the use cases are covered.
- Resources are limited. In many cases, the team won’t be able to tackle all of them. This is where prioritization is put into practice and the team decides to explicitly ignore certain use cases. That’s an acceptable outcome.
Example
| Priority | Use Case | Resolution |
| P1 | User scheduled payment for 1 day before payment is due. The payment covers the entire balance, and it was successfully processed. No fees or interest is charged. | Send a confirmation email and app push notification. Clicking the |
| P1 | User scheduled payment for 1 day before payment is due. Payment is declined due to lack of funds or wrong bank account. User is subject to fees and interest. | Send a failed payment email and app push notification. Fees and interest may be applied. |
| P1 | User scheduled payment for 1 day before payment is due. System failed to process payment. Customer shouldn’t be liable to pay fees and interest. | Re-try 3 times within a span of 10 mins. If all re-tries fail, email the customer and send a push notification. Do not apply any fees or interest yet. |
| P2 | User scheduled payment for 1 day before payment is due. The next day, he/she changes his/her mind and cancels the transaction | Display a history of future payments in the app. Users will be able to update or cancel any of them. |
| P3 | User schedule multiple payments in advance. The sum of all of them exceed the balance. | We won’t do it. We will allow multiple payments but we won’t warn the user if the sum exceeds the balance. |
Beware: When defining the problem turns into defining the solution
It’s easy to accidentally slip from problem definition to solution design. For instance, you might go from stating, “The credit card customer doesn’t know if her payment went through” to prescribing, “We need a text message confirmation and a take it to the future transaction view as soon as the user schedules the payment”. Suddenly, you’ve tied the team’s hands, and you might lose out on creative, possibly simpler or more robust alternatives.
Conclusion
By using the Storytelling Framework—Introduction, Build up, Problem, Battle, and Resolution—you can define problems in a way that sparks creativity within your engineering and design teams. This approach keeps everyone focused on the real user needs, encourages collaboration, and ultimately leads to more innovative and user-centric solutions. And remember, skip the happy ending so the entire team can write it altogether.
With this framework in your toolkit, you’ll find that even the most complex challenges become opportunities for your teams to shine—because when the team owns the solution, they are more passionate about building the best experience possible for your hero.
Tools to create workflows are Excalidraw, Diagrams.net , Lucidchart
Comments
Join the community
Sign up for free to share your thoughts