Finding opportunities with techniques that check each other

Today's product teams are exposed to more signals and pressure than ever. Competitors move faster and seem more aggressive, new ones appear every week, and the boom in open-source alternatives has made investors skeptical of anything easy to copy. That puts investors and directors among the loudest channels, next to customers and sales.

The biggest account asks for features because it’s big enough to ask. Support hears the same complaint every week from people annoyed enough to write in. A dashboard shows a drop, but only among people who already use the product. When a signal is loud, the lean is easy to miss, and a team can spend a quarter building for one large customer or for a handful of power users.

Each of those asks points to a possible opportunity, and the pressure is to find which one is worth pursuing. In this article, I argue that every technique for finding and validating opportunities has a blind spot, and mixing in another technique usually covers it. A signal is worth pursuing once at least two techniques point the same way.

Every technique has a pair that covers its blind spot

A request points to a need you still have to find

A request describes a solution someone has already pictured, so treat it as an input. To find the need behind it, look at what people do today to get the job done anyway: spreadsheets, a second tool, copy-paste next to your product, etc. Their routine shows the need with no solution attached, and the time people spend on workarounds could be a tell of what the need is worth to them.

It can still mislead you in two ways. One user’s preference says little about everyone else, and a workaround may be good enough, so replacing it may not be worth the effort. Product analytics could answer the first, since tracking user actions shows how many accounts do the same thing and how often. Testing whether a user would drop their own thing usually depends on how big of a problem you are solving. Test that with interviews (“The Mom Test” by Rob Fitzpatrick gives a practical guide on how to avoid being misled by polite customers), and make users compare their problems by ranking them.

Test demand before anyone builds

Two techniques test whether people want something before it exists, and they cover each other well.

A smoke test, or fake door, puts an entry point in the product for something that isn’t there yet: a button, a menu item, a plan on the pricing page. Clicking it could open a note that it’s coming, with a short survey. It’s probably my favorite technique. It’s cheap and measures interest, and the survey tells you why they clicked. Set a deadline before it goes live, and use it sparingly: a door that never opens costs trust. Alberto Savoia’s The Right It describes a whole family of tests like this.

A click can still be curiosity. Testing by hand covers that: do the job manually for a few customers and keep an eye on their engagement. Eric Ries called this a Concierge MVP (which I like better than Alberto Savoia’s “Mechanical Turk”, and I challenge you to find out why).

Both techniques test the need. Testing a solution is the next step, and cheap prototypes have made it fast. I wrote about that in Bring engineering what users have already tested.

A business need still has to be a customer need

When an investor asks how you’ll secure the moat, start from what the business lacks, such as data a competitor can’t copy. Then look for a job users already want done, where that data comes as a by-product.

While stakeholders may be impatient to see a string of AI features in your roadmap, pivoting with new products is not always the most effective way to acquire or retain customers. Measuring your users’ satisfaction with the features they find most important is probably the easiest way to control your retention.

Customers who stop paying point to people who never bought

When downgrades climb, churn and downgrade interviews may tell you why, but people tidy up their reasons after the fact. Analyze your product data for the common behavior change for those accounts before they left. Find out what the threshold is for the negative action (or lack thereof) and set up an automation that would tell you who needs attention. The earlier you get to talk to them, the higher the chance of finding out what really makes them want to leave.

Fixing a reason people leave can pay off twice: you may keep the customer, and win people who never bought for the same reasons, the ones who never file tickets or show up in your data.

Pursue an opportunity once a pair of signals agrees

With so much pressure to meet everyone’s expectations, it is important to back priorities with evidence, even if it is just to say “no”. If you haven’t used some of these techniques yet, the cards below are a place to start. Each one says what the technique is, where it breaks, and who argues for it, with links to read more. Many are cheap enough to try on the next signal that lands in your inbox.

Keep each piece of evidence where the team can see it, in an opportunity solution tree or a short assessment, and update it each time a test comes back. The signal you choose is still a hypothesis. I cover what comes next in Understanding the problem (coming soon), and testing solutions in Bring engineering what users have already tested.

Every technique on the map breaks somewhere