Step 2 — Opportunity Assessment

You have a real problem now, felt and written down. The next question is the one most teams never stop to ask: should you solve it.

Not can you. Should you. Those are different questions, and the order matters more than almost anything else in this process. Should-we is worth far more to the business than can-we. There are countless things you're perfectly able to build that aren't worth a single hour of an engineer's time.

Before anyone designs a solution or estimates the work, you decide whether the problem is worth solving at all.

The wrong first question

"Can we build it?" is the wrong first question.

I know the objection: if we can't build it, why even assess it? Fair. But watch what happens when teams lead with "can we." They find a problem, get excited, and huddle with engineering to scope the build. Now there's a chunk of work scoped in the tracking tool, an estimate, three people attached, and a quiet assumption baked into all of it: that this is worth doing. Nobody decided that. They skipped straight to how and never asked whether. The right first question isn't "can we build it." It's "is this worth building at all."

The way I think about whether something is worth building comes down to four gates. Three come from the classic desirability-viability-feasibility framework that IDEO popularized in human-centered design, and the fourth is one I've added.

• Desirability: does anyone want it?
• Viability: can you make money from it?
• Feasibility: can you build it?
• Ethicality: should you build it, even if the first three all say yes?

IDEO's framework is usually drawn as a Venn diagram: what's desirable from a human point of view, what's technologically feasible, what's economically viable, with real innovation living in the overlap. The overlap is the point: a thing has to clear all three to be worth building.

Something you can build that nobody wants makes no money.

Something everybody wants can still sink you if the economics never work.

All three are required. (Marty Cagan, the product-management writer a lot of this playbook leans on, covers the same ground with different labels: his four big product risks are value, usability, feasibility, and business viability. Different slicing, same instinct: name the ways a thing can fail before you build it.)

Required, though, doesn't mean equal, and it doesn't mean you settle all four in this one step. Two of them you can decide right now, with research: desirability and viability. Feasibility, whether you can actually build it, you pressure-test with engineering later, in Step 4. Ethicality is the gut-check you run one last time at the very end, right before you commit to build in Step 6. So this step is really about the first two. And there's one of those two I always check first.

Start with desirability

Desirability is the most important gate, and it's where you start. The logic is plain: if no one wants the solution, or no one cares about the problem, none of the rest matters. Viability, feasibility, ethics, all of it is downstream of one customer actually wanting the thing. Get a no here and you can stop. There's nothing left to assess.

A request I've gotten on a lot of different products makes this concrete. Someone wants to add a voice assistant. Let's add a voice assistant to our app so people can just speak to it. The feasibility of that is genuinely complex. It is not an easy thing to overlay onto an existing product. Say you take the request at face value and start building anyway. Engineering burns months and a pile of money, which throws viability out the window, because you've spent so much building it that you've lost any path to making the money back.

And even then, after all that, the biggest question is the one I always start with anyway: does anyone want it? If no one wants it, what is the point of building it? You could nail the feasibility, find a path to profit, and it still wouldn't matter. Nobody asked to talk to your app.

That's why desirability leads. A no here is cheap to find now and brutally expensive to find after you've already built the thing.

Assess it for real

Desirability isn't a gut call, and neither is the viability sitting right behind it. You assess the two of them across four areas, the way I run an opportunity assessment. The first two areas, User and Expected Outcome, get at desirability: who exactly has this problem, and what solving it would be worth. The last two, Market Size and Competitors, get at viability: whether enough people have it, and whether there's a real business in solving it for them.

User. Get specific about who actually has this problem. Lean on whatever you already know about your customers: the segments you've grouped them into, or the personas you've built (a persona is just a short profile of one specific type of customer, what they do, what they need, what gets in their way). You're not solving for "customers" in the abstract, you're solving for a particular customer in a particular situation. If you have access to them, you can survey them: do they have the problem, how much does it hurt, how do they handle it today, would they pay to make it go away.

One hard caveat on that survey: surveys are not a valid way to confirm desirability of a solution. They're useful to a point. People will tell you a problem is real, and that's worth knowing. But a survey is people predicting their own future behavior, and people are terrible at that. "Would you use this?" gets you a yes that costs them nothing and tells you almost nothing. Desirability gets proven later, when something real is in front of them. The survey is a hint, not a verdict.

Expected Outcome. If you solve this, what do you expect to happen, and how would you know? Name the number you would expect to move: how many customers stick around instead of leaving, the hours they save, the support calls that stop coming in. You're forming a picture of what success looks like, in real terms, before you chase it.

Market Size. The total number of likely buyers for the solution within a given market. Size it by understanding your target customer, then gauge demand: look at competitor sales and share, run interviews and focus groups. A few tools help you put a number on it. Google Trends shows you the relative volume of search terms over time, and Google Ads Keyword Planner gives you average monthly searches for a keyword, so you can estimate the real demand behind a problem. Then use that number to decide whether the investment is worth the risk and the work.

Competitors. Find out who else is solving this and what they've shipped. Look at adoption, pricing, and reviews, and pay close attention to what users love and hate about the existing options. That tells you where the real opening is. The tool Moz can audit competitor sites and show you how they rank and what content of theirs gets shared. And your competition isn't always another product. Sometimes it's a manual workaround, a spreadsheet, or a workflow your customer has lived with for years. The thing you're really competing against is whatever they do today.

Market size and competitors are where viability comes together, because viability really comes down to one question: is there enough of a business here to be worth it? Market size tells you how many people would pay. Competitors tell you whether you can win them, and what they would pay. Put those together and you know whether the money is actually there. A problem can be painfully real for a handful of people and still not be worth solving, because there just aren't enough of them to make a market.

Should you, even if you can?

Here's the fourth gate, and it's the one most teams never put on the table. Even if a thing is desirable, viable, and feasible: should you build it?

Picture the last time you tried to cancel something. Not the signup, the cancel. Signing up took thirty seconds and one click. Cancelling took a phone tree, a "retention specialist" who would not take cancel for an answer, and a surprise discount you could have had all along. That gap, easy in and hard out, isn't an accident. Somebody designed it that way on purpose.

Run that design through the first three gates and it sails. Desirable? To the business, absolutely. Every person who gives up halfway through the cancel flow is another month of revenue, and the retention numbers look fantastic. Viable? It makes money directly. Feasible? You don't even build anything, you just add friction. Desirable, viable, feasible: a clean sweep.

And there are receipts. In 2014 a customer named Ryan Block recorded his Comcast cancellation call: the rep spent more than eight minutes refusing to process it, demanding again and again why he'd ever want to leave. It went viral, and Comcast had to publicly apologize and call the behavior unacceptable. Gyms turned the same idea into an art form. In 2025 the FTC sued LA Fitness, alleging it let people join in seconds online but made them cancel in person. One manager. Weekdays only, nine to five. Or by mail, after clearing a login gauntlet. The agency says that design pulled hundreds of millions of dollars out of people who just wanted out.

Notice what's different about this gate. The other three are about what you couldn't know yet. This one isn't. Nobody stumbles into a cancel flow like that. It's a deliberate choice to trap the people who have already decided to leave, because trapping them pays. All three of the first gates say ship it. The fourth says no. A product person who only ever asks the first three will eventually build something they should be ashamed of.

That's the gate. You'll find, at some point, a problem that clears desirability, viability, and feasibility and still shouldn't be built, because of what it does to the people on the other end of it. And if, by the time you're making that build call, the steps and activities you've taken up to that point don't give you enough data to answer the question of ethicality, go find the data. Do more work through testing, surveys, alpha/beta groups, etc. until you can answer it clearly. (A survey is fine here. You're not asking people to predict their own behavior this time; you're asking what the thing does to them.)

Most opportunities never come near this line. But the few that do are exactly the ones where the money is pushing hardest to ignore the question, and you don't get to. Ask it on purpose.

Knowing when to walk away

The real value of this step is the no. It's deciding not to build something while it's still cheap to decide that.

Yes is the most expensive word in life and business.

I learned this the expensive way. A team I ran once spent about six months building a chat bot so our interns could manage their schedules by typing to it, like talking to Siri but over text. Two undergrad interns and two part-time PhD students, half a year of work. And it ran. It did the job. It was also an absurdly complex solution to a simple problem. We could have bought a ten-dollar whiteboard and had the interns write their schedules on it, updating it when things changed. A whiteboard. Or a shared google sheet.

The kicker is what else my team was doing at the same time. We had a project that, at its kickoff, was estimated to be worth up to $10 million in increased sales. A ten-dollar problem and a ten-million-dollar problem, getting the same attention. Nobody ever asked whether the bot was worth building. The closest we came was the feeling that it was a cool experiment and the learnings would ultimately be valuable elsewhere. That feeling was the entire assessment. If anyone had run it through these gates, the answer would have been obvious in an afternoon, and we'd have handed that half-year back to the project that actually mattered.

That's what this step buys you: a clear-eyed decision about where your team's time is worth spending, made before the time is already spent.

That's Step 2. You've decided this problem is worth solving. Next you turn it into a hypothesis: a clear statement of what you believe is true, written so you can actually go test it.