Frame the problem first: how the hero, treasure, dragon, and quest method turn vague ambition into a solvable strategy
Early in my career, I heard a story about a young executive who sat in a room full of smart people who were passionately solving the wrong problem. They were preparing a proposal for a regional bank that wanted to modernize its digital channels
The team spent three weeks designing a beautiful, scalable, technically elegant platform. Then the client’s CIO asked one quiet question:
But does this solve our real constraint, which is that our core system cannot release new features faster than twice a quarter?
It did not. They had built an answer to a question nobody had asked. They lost that deal, and it was one of the most valuable lessons of my career.
Since then, across two decades in product design, solution architecture, product ownership, and business development in Latin America, I have learned that the quality of any strategy, deal, or product is decided long before the first slide, the first line of code, or the first price table.
It is decided in the moment when we frame the problem.
Framing is the discipline of agreeing, in writing, on who is acting, what they want to achieve, what stands in the way, and therefore which question we are actually trying to answer.
There is a simple method I use to do this consistently. It comes from the work of Albrecht Enders and Arnaud Chevallier in their book “Solvable”, and it borrows four elements from classic storytelling: the hero, the treasure, the dragon, and the quest. I have applied it to product roadmaps, to multi-million-dollar RFP processes, and to personal career conversations. It works in banking, retail, telecom, and probably in whatever industry you are in. Let me walk you through it, the way I use it in real life.
Why framing the problem beats solving it faster
Most organizations do not lack solutions.
They lack clarity about which problem deserves a solution. Teams accelerate toward targets that were never aligned, and speed simply makes the misalignment more expensive.
In enterprise sales, we see this when a vendor answers every requirement in an RFP except the one the evaluation committee actually cares about. In product teams, we see it when roadmaps are full of features and empty of outcomes. In strategy, we see it when plans list initiatives but never state the obstacle that makes those initiatives necessary.
A well-framed problem does three things.
- First, it creates alignment, because everyone can repeat the same sentence and mean the same thing.
- Second, it creates boundaries, because a good frame says what we are not solving.
- Third, it creates energy, because a problem with a visible obstacle and a visible prize pulls people forward.
The method I am sharing gives you a structure to build that frame in one page, in one meeting, in plain language.
The four elements of a good frame
The method is sometimes called a strategy story, because it uses the grammar of classic narratives. Every good story has a hero with a context, a treasure they aspire to reach, a dragon that stands in the way, and a quest that summarizes the journey as one compelling question.
When you map a business situation onto these four roles, something useful happens: vague ambition becomes a concrete, solvable question.
The hero: start with context, not with you
The hero is the character whose situation we are trying to improve.
In a strategy story, the hero is rarely us. If you work in a company, the hero might be your customer, your channel partner, or the business unit that lives the problem.
If you are preparing a proposal, the hero is the client, not your firm. This is a subtle shift with enormous consequences, because it forces you to describe the context from the inside: who they are, where they operate, what they have tried, what their constraints are.
In my work across Mexico, Colombia, Peru, Chile, Argentina, Brazil and Ecuador, the hero is often a bank or a retailer with a very specific context:
- A regulator that demands data stay in the country,
- A legacy core that nobody dares to replace,
- A customer base that still prefers branches in some segments and mobile apps in others.
Writing that context down, fact by fact, prevents the most common sin in strategy and sales: projecting our own assumptions onto someone else’s reality.
A practical test I use
If you cannot describe the hero’s context in half a page without using the words “we” or “our”, the frame is not ready.
The treasure: name the aspiration in concrete terms
The treasure is what the hero wants to achieve.
Not what we want to sell, not the initiative we want to run, but the aspiration as the hero experiences it. A good treasure is specific enough that you would recognize it if you saw it: a market position, a growth target in a period of time, a service level, a cost structure, an experience that customers describe in their own words.
Weak treasures are vague: “be more digital”, “improve innovation”, “transform the operation”.
Strong treasures are testable:
- “become the first choice for small businesses in our country”,
- “cut the time to launch a new product from months to weeks”,
- “serve millions of users with an adoption rate that grows year over year”.
When I translate client objectives into product roadmaps, I insist on this translation step, because a roadmap inherited from a vague treasure will deliver features that nobody adopts.
The treasure also sets the emotional tone of the strategy.
People do not fight for KPIs; they fight for a future they can picture. A well-described treasure gives the team a picture.
The dragon: the obstacle that makes the story real
The dragon is the one big problem separating the hero from the treasure.
It creates the tension. Without a dragon, there is no story and no strategy, only a wish. And here is where most framing efforts collapse, because naming the real dragon is uncomfortable. The dragon might be a cost structure, a legacy system, a regulation, a culture, a competitor, or our own business model.
In high-stakes procurement, dragons are very concrete
- Data sovereignty mandates,
- Complex legal clauses,
- Enterprise security requirements,
- Service level penalties,
- Integration debt.
In one RFP I led, the apparent treasure was “a modern digital banking platform”, and the apparent dragon was “old technology”.
Three conversations later: The real dragon emerged
The bank could not legally move certain workloads outside the country, and no proposal without a local sovereign design would ever be signed. Every proposal that ignored that dragon was fiction, no matter how good the price was.
A useful discipline
There should be only one dragon per frame. If you list seven dragons, you have not decided which problem is the story. You can acknowledge secondary obstacles, but the frame carries one dragon, because the quest must be solvable.
The quest: compress everything into one question
The quest is the payoff.
It brings the hero, the treasure, and the dragon together into a single overarching question that the strategy, the deal, or the product will answer. A well-formed quest follows a simple grammar:
How should [hero] achieve [treasure], given [dragon]?
The bookstore example from the original material is perfect in its simplicity
How should a small local bookstore compete with online giants, given its limited inventory and high costs? You can feel the frame click into place. The question is ambitious but bounded, and it invites creative answers instead of generic ones.
In my world, a quest might read
How should a regional bank with a legacy core become the fastest lender for small businesses in its market, given strict data residency rules and a release cycle measured in quarters?
Once that sentence exists, everything downstream changes: the RFP response stops being a catalog and becomes an argument; the product roadmap stops being a wish list and becomes a sequence of bets against the dragon; the executive conversation stops being a pitch and becomes a dialogue.
I recommend writing the quest on a wall, in one sentence, and refusing to discuss solutions until the sentence survives review from the people who own the problem.
How I use the frame in RFx and deal strategy
Let me make the method operational for anyone who sells or builds technology.
Before responding to any RFI, RFP, or RFQ, I fill one page with four boxes
- Hero: the client’s context, written from their point of view, including regulators, boards, and users.
- Treasure: the aspiration as stated in their documents, translated into testable outcomes.
- Dragon: the constraint that has killed previous attempts, usually visible in their risk annexes and legal clauses more than in their marketing brief.
- Quest: the question our proposal will answer, verbatim, in the executive summary.
Then I check alignment internally.
Sales, legal, engineering, and product must agree on the same four boxes before we price anything. This single habit has saved my teams from the classic failure mode of complex deals: winning the argument we prepared while losing the deal the client actually decided.
The same page works in reverse when we are the buyers, when we evaluate vendors, or when we design our own product strategy. The frame is not a sales tool; it is a thinking tool.
The one-page template
- Hero: who lives the problem, and what is their context?
- Treasure: what do they want to achieve, in testable terms?
- Dragon: what is the one big obstacle in the way?
- Quest: how should [hero] reach [treasure], given [dragon]?
The mistakes that break the frame
After applying this method for years, I see the same four failures.
- First, the hero swap: we write the story with our company as the hero, and the client becomes a spectator in their own story.
- Second, the fake treasure: we inherit a slogan instead of an aspiration, and the quest inherits the vagueness.
- Third, the dragon avoidance: we name a comfortable obstacle instead of the real one, because the real one is politically difficult.
- Fourth, the quest inflation: we allow three quests, five quests, a portfolio of quests, until nothing is framed at all.
The cure for all four is the same: one page, one hero, one treasure, one dragon, one quest, reviewed by the person who lives the problem.
Why this stays useful no matter what changes
Tools, platforms, and markets will keep changing.
The languages we use to build software will change, the shape of contracts will change, the names of the vendors will change. But the human difficulty of agreeing on what problem we are solving does not change.
That is why I consider problem framing a permanent skill for product people, sellers, architects, and executives. The hero, treasure, dragon, and quest method is simply a memorable container for that discipline, and memorable things get used.
So the next time you open a strategy session, a discovery workshop, or a proposal war room, resist the urge to start with solutions. Start with the story. Name the hero with respect, describe the treasure with precision, face the dragon with honesty, and write the quest in one sentence. If the frame is right, the rest of the work becomes a sequence of solvable steps. If the frame is wrong, no amount of execution excellence will rescue it.
Frame the problem first. Everything else follows.
