Opportunity Canvas: Frame a Problem Before You Build

The Opportunity Canvas is Jeff Patton's one-page tool for thinking through a proposed feature or solution before you build it. It reframes your idea as an opportunity to evaluate by mapping the users, their problems, your solution ideas, the value and metrics, adoption, and the business case side by side.

Quick Answer: An Opportunity Canvas is a single-page template that forces you to describe the users, their current problems, your proposed solution, the value users would gain, how you'll measure it, how they'll adopt it, and the business problem it solves. It turns a feature idea into an opportunity you can weigh before writing code.

Most feature decisions start backwards. Someone proposes a solution, everyone debates whether to build it, and the actual problem it solves stays fuzzy the whole time. The Opportunity Canvas fixes the sequence. It takes the solution you already have in mind, sets it aside for a moment, and asks you to reconstruct the opportunity underneath it. By the time the canvas is full, you either have a defensible case for building or a clear reason not to.

Why frame an opportunity before jumping to features

Framing an opportunity first prevents you from committing engineering time to a solution that never had a real problem behind it. The Opportunity Canvas exists because product teams default to solution-mode: they fall in love with a feature and reverse-engineer justifications for it.

Ideas arrive as solutions, not problems. A stakeholder says "we should add a dashboard," a founder says "we need an AI assistant," a sales rep says "the enterprise deal needs SSO." Each is a solution wearing the costume of a requirement. None of them names the user, the problem, or the value in a way you can test. The canvas makes you unwrap the solution and inspect what's inside.

The canvas is deliberately lightweight. Patton designed it as a one-page, fill-in-the-boxes tool precisely so a team can complete it in a working session rather than a month of documentation. It borrows from Marty Cagan's opportunity assessment and the lean-canvas tradition, but it is tuned for a single feature or product decision, not an entire business model. You are not writing a business plan; you are pressure-testing one idea.

It surfaces disagreement early and cheaply. When three people fill in the "Problems" box and write three different problems, you have just discovered — in fifteen minutes, on a whiteboard — that the team is not aligned on what they are building or why. That disagreement would otherwise have surfaced mid-sprint, after the expensive part had already started.

The canvas is not a validation method by itself. It is a thinking tool that organizes your assumptions so you can see which ones are load-bearing and dangerous. It pairs naturally with the art of problem discovery, which is where the raw material for the problem and user boxes actually comes from.

What the Opportunity Canvas boxes cover: a full overview

The Opportunity Canvas is organized into roughly ten boxes that move from users and problems, through solution ideas and value, into adoption and the business case. Each box answers one question, and the boxes are sequenced so that later answers depend on earlier ones.

Before filling anything in, it helps to see the whole map at once. The table below lists each box, the question it answers, and the failure it is designed to catch when you leave it blank or answer it lazily.

The pattern in that final column is the point of the whole exercise: every empty box is a specific, nameable way the feature can fail. The canvas does not guarantee success. It guarantees that if you proceed, you did so with each of these questions consciously answered rather than quietly skipped.

Box 1 and 2: define the users and the problems they have today

Start with the users and their problems, because everything downstream is only as valid as these two boxes. If you cannot name a specific user and a specific problem, the rest of the canvas is fiction built on a guess.

Users and customers name who has the problem — and who pays. Patton deliberately separates the two, because they are often different people. The user of an expense tool is the traveling employee; the customer who buys it is the finance director. A feature that delights users but never moves the buyer will not get funded, and a feature the buyer demands but users resent will not get adopted. Write down the specific user types, not a demographic blur. "Field sales reps who file reports from their phones" is a user. "SMBs" is not.

Problems describe what those users struggle with today, in their words. This is the box teams rush, and it is the most important one. The problem must be stated independently of your solution. "Users can't export to CSV" is a missing feature, not a problem. "Users rebuild the same report by hand every Monday and it takes an hour" is a problem — it has a task, a frequency, and a cost, and several different solutions could address it.

Keep the problem box honest with a few checks:

• Is it stated without naming your feature? If you can't describe the problem without describing your solution, you haven't found the problem yet.
• Does it have a frequency and a cost? Problems that happen often and hurt a lot are worth solving; rare, mild annoyances are not.
• Would the user recognize it? If you read the problem back to a real user and they say "that's not really an issue for me," the canvas has done its job before you wrote any code.

This is exactly where real discovery conversations earn their keep. The problem box should be filled with what you heard from users, not what you assume they feel.

Box 3 and 4: map current solutions and your solution ideas

Document how users solve the problem today before you list what you'd build, because the incumbent behavior is the real competitor you have to beat. "Solutions today" is the box that keeps founders humble.

Solutions today is the workaround audit. Nobody with a real problem is doing nothing about it. They have a spreadsheet, a manual process, a rival product, an intern, or a stubborn tolerance for the pain. Whatever it is, that is your baseline. If the current workaround is "good enough," your solution has to be dramatically better to displace it, because switching costs are real and inertia is powerful. Listing the status quo tells you how high the bar actually sits.

Solution ideas is where your feature finally appears — as one option among several. The canvas asks for solution ideas, plural, on purpose. The moment you write two or three possible solutions instead of one, you break the grip of the single idea you walked in with. Maybe the report problem is solved by an export, or by a scheduled email, or by a saved template, or by removing the need for the report entirely. The canvas is not asking you to pick yet; it is asking you to hold options open long enough to compare them.

A useful discipline here is to write each solution idea as the smallest thing that could address the problem, not the fully-featured version. The canvas is a decision tool, and small, comparable ideas are easier to evaluate than one maximalist vision.

Box 5 and 6: articulate users' value and the metrics that prove it

State the value in terms of what users could newly do, then define the behavior you'd measure to confirm they actually got that value. These two boxes convert good intentions into something testable.

Users' value is a before-and-after, not an adjective. The weak version of this box says the feature will make users "more productive" or "happier." Those are unmeasurable. The strong version says what the user will be able to do after the solution exists that they cannot do today. "A sales rep can file a complete expense report from the airport in under two minutes" is a value statement with a clear before and after. If you cannot describe a concrete new capability, the value probably isn't there.

User metrics name the observable behavior that signals value. This is the box that separates the Opportunity Canvas from a wish list. If users are getting value, something in their behavior changes — they log in more, complete a task they used to abandon, return the next week, or stop contacting support about the old pain. You are not inventing target numbers on the canvas; you are naming which behavior you would watch to know whether the value landed. The number comes later, from a real experiment.

The two boxes are a matched pair, and it is worth writing them next to each other:

The takeaway from that pairing is simple: if a value statement has no plausible metric beside it, you have written a hope, not an opportunity. Force every value into a measurable behavior, and the vague benefits fall away on their own.

Box 7: describe how users will discover and adopt the solution

Explain how real users will learn the solution exists and start using it, because a valuable feature nobody discovers delivers zero value. Adoption strategy is the box that punctures "build it and they will come."

Adoption is a distribution problem, not a quality problem. Teams assume that if the solution is good enough, usage will follow automatically. It rarely does. Existing users have to notice the new capability, understand why it matters, and change an established habit to use it. New users have to find their way to it at all. The canvas asks you to name the actual path: in-app announcement, onboarding change, sales enablement, email, a hook inside an existing workflow.

Adoption strategy also tests whether the solution fits real behavior. If the only way users would adopt the feature is a heavy behavior change or a training program, that is a warning about the solution itself. The best solutions slot into a moment users already reach — the report gets offered exactly when they open the reporting screen. If you cannot describe a natural adoption moment, reconsider the solution before you consider the marketing.

Box 8, 9, and 10: connect the business problem, metrics, and budget

Close the canvas by naming the business problem the solution solves for you, the business metric that would move, and the budget you're willing to spend — this is what makes it an opportunity rather than a favor. A feature can help users and still be a bad investment for the company.

Business problem asks what this does for you, not the user. Every solution costs the business something to build and maintain, so it has to earn its place. Does this feature reduce churn, unlock a market segment, shorten sales cycles, cut support load, or open a new revenue line? If the honest answer is "it would be nice for users but doesn't move anything for us," that is a legitimate reason to defer it — and far better to learn it now than after a quarter of engineering.

Business metrics tie the feature to an outcome the company already tracks. Like user metrics, these are the numbers you'd watch to know the bet paid off: retention, conversion, expansion revenue, support ticket volume, activation rate. You are linking the feature to a metric that already matters, not inventing a vanity number. If no existing business metric would plausibly move, the opportunity is weaker than it felt.

Budget bounds the bet before you fall further in. The final box asks how much time, money, and effort this opportunity is worth given everything above it. Budget is not a detailed estimate; it is a ceiling that reflects your confidence. A well-evidenced opportunity with a clear metric earns a bigger budget than a hunch. Setting the number forces a final gut check: knowing what you now know from the other nine boxes, how much are you actually willing to risk on this?

A worked example: filling in an Opportunity Canvas

Here is how the boxes come together for one feature idea, so the abstract structure becomes concrete. Imagine a small B2B SaaS team considering a "scheduled report email" feature. Watch how the canvas either builds the case or exposes the gap.

• Users and customers: Users are operations managers who send a weekly performance summary to their leadership. The customer who pays is the VP of Operations who owns the account.
• Problems: Every Monday morning, operations managers manually rebuild the same summary, copy numbers into an email, and send it. It is repetitive, error-prone, and eats the start of their week.
• Solutions today: They keep a saved spreadsheet, re-pull the data by hand, and paste it into an email. Some have built fragile automations; most just tolerate the chore.
• Solution ideas: (1) A scheduled email that sends a saved report automatically. (2) A shareable live link instead of an email. (3) A one-click "resend last week's report" button.
• Users' value: An operations manager gets Monday morning back — the summary goes out on its own, accurately, without manual assembly.
• User metrics: Share of recurring reports set to auto-send; reduction in manual report-building sessions; continued use of the schedule over subsequent weeks.
• Adoption strategy: Offer the "schedule this" option directly on the existing report screen, at the exact moment a user finishes a report they clearly repeat.
• Business problem: These operations managers are the account's power users, and their weekly ritual is a retention anchor. Making it effortless deepens the habit the whole account renews on.
• Business metrics: Feature adoption among power users; account retention and expansion within that segment.
• Budget: A modest, time-boxed build, justified because the problem is frequent, specific, and tied to a retention metric the team already watches.

Notice what the canvas did. It took a vague "let's add scheduled emails" and turned it into a defensible opportunity — a frequent problem, a real workaround to beat, a natural adoption moment, and a link to retention. Had any box come up empty (no clear metric, no business problem, no adoption moment), the same canvas would have flagged the feature as a weaker bet before anyone opened an editor. For a fuller, reusable layout you can copy, see the opportunity canvas template and example.

How the Opportunity Canvas feeds a validation plan

The canvas doesn't validate anything on its own — it produces a ranked list of assumptions that a validation plan then tests. Its real output is not the filled-in page; it is knowing which box you're least sure about.

Every box is an assumption until evidence says otherwise. When the canvas is complete, read it as a set of claims: we assume these users exist, we assume this is their problem, we assume they'll adopt it this way, we assume this metric will move. Some of those claims you already have evidence for. Others are guesses that would sink the whole feature if wrong. Those are your riskiest assumptions, and they are what you test first.

Match each risky box to the cheapest test that could disprove it. A shaky problem box calls for customer interviews before anything else. A shaky adoption box calls for a fake-door or landing-page test to see whether anyone reaches for the feature. A shaky value box calls for a small prototype or concierge test. The canvas tells you what to test; a lightweight experiment tells you whether it holds. Running those tests in order of risk is where a platform like Edmired helps founders keep the evidence and the assumptions attached to each other.

Re-run the canvas as evidence arrives. The Opportunity Canvas is not a document you archive. When an interview reveals the real problem is different, you rewrite the problem box, and the value, metric, and adoption boxes shift with it. The canvas is a living snapshot of your current best understanding, and it should look different after discovery than it did before.

This is the natural handoff from framing to testing: the canvas frames the opportunity, and a validation plan decides whether it's real.

Common Opportunity Canvas mistakes to avoid

The most common mistake is filling in the canvas to justify a solution you've already decided to build, which turns a thinking tool into a rubber stamp. A few failure patterns recur.

• Writing the solution in the problem box. "Users need a CSV export" is a solution restated as a problem. If your problem box only makes sense once you know your feature, you skipped the actual problem.
• Naming "everyone" as the user. A canvas built for all users is built for none. Vague users produce vague problems, vague value, and metrics that never move. Get specific enough to name a person you could go interview.
• Leaving the metrics boxes empty or aspirational. Metrics are not a formality at the bottom of the page. A value with no measurable behavior beside it is a hope. If you can't name the behavior that would prove success, you can't tell success from motion.
• Skipping "solutions today." Ignoring the current workaround means ignoring your real competition. The spreadsheet users already trust is a harder rival than any product, because it's free and familiar.
• Treating the canvas as a deliverable, not a debate. The value is in the disagreement it surfaces while filling it in. A canvas completed silently by one person and filed away captured none of that.
• Confusing it with a business-model canvas. The Opportunity Canvas evaluates one feature or solution, not a whole company. Reaching for it to model your entire business is the wrong tool. To see where the line falls, compare the opportunity canvas vs the lean canvas.

Key Takeaways

• The Opportunity Canvas reframes a proposed solution as an opportunity to evaluate, forcing you to reconstruct the users, problems, value, and business case underneath an idea before you build it.
• It is a one-page thinking tool, not a business plan — Jeff Patton designed it to be filled in during a working session to pressure-test a single feature or product decision.
• Users and problems are the load-bearing boxes; every downstream answer is only as valid as the specific user and specific problem you can name at the top.
• Value and metrics travel as a pair — a value statement with no measurable behavior beside it is a hope, and the canvas is designed to expose exactly that gap.
• "Solutions today" and "adoption strategy" catch the failures teams ignore: the workaround you must beat and the "build it and they will come" assumption.
• The business boxes make it an opportunity, not a favor — a feature that helps users but moves no business metric is a legitimate thing to defer.
• The canvas outputs assumptions, and a validation plan tests them; read each box as a claim, find the riskiest one, and run the cheapest experiment that could disprove it.

Frequently Asked Questions

What is an Opportunity Canvas used for?

An Opportunity Canvas is used to think through a proposed feature or solution before building it. It maps the users, their current problems, your solution ideas, the value users would gain, the metrics that prove it, the adoption path, and the business case on one page — so a team can evaluate whether an idea is worth the engineering time rather than debating a solution with no clear problem behind it.

Who created the Opportunity Canvas?

Jeff Patton created the Opportunity Canvas, adapting ideas from Marty Cagan's opportunity assessment and the broader lean-canvas tradition. Patton designed it as a lightweight, one-page tool aimed specifically at evaluating a single feature or product idea, rather than modeling an entire business.

What is the difference between an Opportunity Canvas and a Lean Canvas?

The Opportunity Canvas evaluates one feature or solution — its users, problem, value, and business case — while the Lean Canvas models an entire business, including channels, revenue streams, cost structure, and unfair advantage. Reach for the Opportunity Canvas when deciding what to build next inside a product, and the Lean Canvas when framing a whole company or new venture.

How long should it take to fill in an Opportunity Canvas?

Filling in an Opportunity Canvas should take a single working session, often under an hour, because it is deliberately one page. The value is less in the finished document than in the discussion it forces — especially the disagreements that surface when people fill in the users, problems, and value boxes differently.

Does the Opportunity Canvas validate an idea?

No. The Opportunity Canvas frames an idea; it does not validate it. Its output is a structured set of assumptions about users, problems, value, and business impact. You still have to test the riskiest of those assumptions with real evidence — interviews, fake-door tests, or prototypes — before treating the opportunity as proven.