Before You Build the Feature, Count Who Has the Problem

Your biggest customer wants something nobody else has asked for, and near the bottom of the email they mention that their renewal is coming up. Any other request would go on the list, and if it were already there, you'd put a plus one next to it. Over time that list has become how you decide whether a problem is real. By that logic, a request from the biggest name on it, with a renewal attached, outranks everything else on the page.

You can build what they asked for and hope. Or you can find out first whether anybody else has the problem.

Meridian's request

Meridian is the fictional composite company I've used throughout The Operator's Guide to Product Leadership, the video series this essay accompanies. It has 40 people and 60 customers, six engineers and one designer, and it sells shift scheduling software to logistics operators. Its biggest customer wants a custom integration into their warehouse system.

Meridian knows what integrations cost, because two of its six engineers already spend most of their week maintaining them for three accounts. It also has a written rule against building custom integrations, so the request goes to its head of product, and she calls the customer herself to find out what's underneath it. Someone on their operations team retypes numbers from one screen into another, for about 40 minutes a day. She comes off the call wanting to know whether anyone else has this problem.

A request describes a solution

Ryan Singer and Chris Spiek made a short video in 2017 for a channel called Demand Thinking. It has about 8,000 views. It splits the world into supply, which is what you build and ship, and demand, which is what's happening in your customer's life and isn't yours to control. A feature request belongs to supply, however much it sounds like the customer talking, because it describes something for you to build.

Their example is a project management tool. A customer wrote in asking for permissions, so that contractors couldn't archive projects. When the team asked her what had happened before she wrote, the story came out: a contractor had archived a shared project without realizing it would vanish for everyone else, and her team had stopped trusting the tool. Permissions would have been a big build with no obvious end. The need underneath was trust. The fix they sketch is a warning on the archive screen showing who else an archive will affect, and they figure a designer could make it in an afternoon.

Counting plus ones was a reasonable instinct, because one request on its own tells you very little. But each plus one on your list is somebody proposing the same solution, and the list records nothing about how many of those people have the problem. Your biggest customer's email adds one more plus one, with the most important name on the list attached to it.

A test you can afford

Marty Cagan, who runs the Silicon Valley Product Group, lists four big risks to deal with before you build anything, and value comes first: whether customers will buy it or users will choose to use it. For one customer's request, value risk is the head of product's question with a threshold added. Does anyone besides this customer have the problem badly enough to do something about it? If nobody does, the other three risks never come up.

Product management's answer to value risk is discovery: finding out whether an idea deserves to be built before you build it. Teresa Torres, who coaches product teams and wrote Continuous Discovery Habits, defines the continuous version as the team building the product talking with customers every week, and Cagan has described the best teams running 10 to 30 discovery iterations a week. Both are describing a product manager, a designer and an engineer working together, and Torres has estimated that something like 98% of the industry has never worked on a team like that. Meridian has six engineers, one designer and one head of product, with no research team, so it's easy to decide that discovery is for somebody else, and then the loudest request decides. In part two's audit of Meridian, nobody was deciding what evidence justifies solving a problem.

The principle under all that weekly discovery is cheap. Cagan, who sells transformation services for a living, wrote it down in an article called "Discovery Excuses": "if we can't test out an idea in at least an order of magnitude less time and effort than actually building it, then you're doing something very wrong." An order of magnitude is ten times, so a request that would cost your engineers three months deserves a test of about a week and a half. Very few people out there have sustainable science fair budgets, and a week and a half of phone calls fits almost any budget.

Write the bar before the calls

Before the head of product calls anyone besides the customer who asked, she writes down how much evidence it will take to change her answer. The bar gets written first because once you've started looking, every answer starts to sound like agreement, and a maybe starts to sound like a yes. When I set a bar, I write it so that only demand can clear it, because polite interest will clear any bar you leave loose. A loose bar sounds like "a few customers seem interested." A tight one answers three questions:

The bar, written before the first call 1. Who has to have the problem. 2. How many of them. 3. What counts as having it: something they're already doing about it, like a spreadsheet somebody keeps or somebody's time spent on it every day.

Meridian's bar starts from a rule it wrote in part six: its answer on custom integrations changes only if three customers in its focus, the market it chose to serve, need the same thing. Three can sound like a small number, but out of 60 customers it's enough to tell a pattern from one relationship. To that rule the head of product adds the third line.

Ask what already happened

Y Combinator has a talk about asking customers the right questions, and it has nearly half a million views. Eric Migicovsky gave it as a partner there, after starting the smartwatch company Pebble, and built it on a book called The Mom Test. The title comes from asking your mom whether your idea is any good: she loves you, so she says yes. (Your mom is a fine judge of whether your explanation makes sense. She's a poor judge of whether anyone will buy.)

Migicovsky lists three mistakes from the book: pitching your idea, asking about hypotheticals and talking too much. He also says to throw out compliments, which aren't specific enough to use. Hypotheticals do the most damage, because people asked whether they'd use a feature say yes to avoid being rude. So he asks about the past, and two of his questions fit a request like Meridian's: "Tell me about the last time that you encountered this problem," and "What, if anything, have you done to try to solve this problem?"

The second question does the most work, because a customer who has already done something about the problem has shown you they have it. My version of it is one question: what are you doing about this today? The answer is what the problem already costs them: a spreadsheet somebody maintains, a person hired to deal with it, 40 minutes a day of retyping. Nobody funds a workaround for a problem they don't have.

For the conversation itself, Singer and Spiek ask about the moment the need showed up: what was happening the day before you wrote to us? That question is what gets Meridian's head of product to the retyping on her first call. Asked that way, the customer stops talking about the integration and describes the person on their operations team moving numbers between two screens every day. The integration they asked for was supply, in Singer and Spiek's terms, and the retyping is demand: a problem the head of product can count across her other customers.

Ten orders for a crashed demo

The strongest evidence of a problem is money, and the clearest case of it I've seen came from a trade show. Years ago we took a piece of desktop software, about $2,500 a copy, to a trade show for its first public showing. Our booth had a Mac on each of its four corners, and our software, debuting on one of them, crashed on startup. Back then a crashed Mac showed a big bomb on the screen, and our head of sales stood in front of that bomb and talked to people about their own problems and what the software was going to do about them.

We came home with ten contingent purchase orders at full price. We couldn't bill any of them until we'd fixed the crash and shipped, and when we did, we collected $25,000. Ten people had committed money to software they had watched fail to start, because of conversations about problems they already had.

A pace a 40-person company can keep

Torres argues that teams who say they have no time for discovery are picturing the old kind of research project, and that continuous discovery can start with as little as one interview a week. At 40 people, I run it this way:

One week of discovery at 40 people 1. One standing conversation a week with a customer. 2. Borrowed help: support and account managers are on the phone with customers all day, and Torres suggests using them to line up your conversations. 3. The question about what they're doing today, asked as the last line of a call you were already going to have.

Two of sixty

With the bar on paper, Meridian starts counting. An email to all 60 customers asking whether they'd like a warehouse integration would have produced a pile of polite yeses. So for two weeks, the support team and the account managers finish every call with one question: the last time you needed your schedule inside another system, what did you do?

Most customers have never needed their schedule anywhere else. Their scheduling and their warehouse run separately, and nobody moves numbers between them. Nine say an integration would be nice, and none of the nine is doing anything about it today. When the head of product adds it up, two of the 60 have the problem: the customer who asked, and a small operator whose office manager keeps a spreadsheet for exactly this.

Two is under the bar, so the answer stays no. Two customers can feel like plenty when one of them is your biggest, and the bar, written before the first call, says they're one short.

The renewal is still a real risk. But it's one relationship, and the head of product handles it as one: she calls the customer back, tells them the integration isn't coming and why, and asks what those 40 minutes a day cost them. She could still build the integration for this one customer. Torres says everything in the backlog is a bet, whether or not you did any discovery. The head of product can make this one, as long as she calls it a bet.

What I can't tell you

Setting the bar first is my own practice. None of the sources I've cited recommends it, and I couldn't find a study measuring whether it leads to better decisions. What I can say is narrower: Meridian's bar was on paper before the first call, so two of 60 couldn't quietly become enough.

One line on your own list

Pick one line on your own list, the one with a single name next to it. Before you call anybody, write down how many other customers would have to have that problem.

Dave Saunders is the founder of Base Reality Group and a Fractional CPO for product companies. He was a founder and operator at Galen Robotics, where the surgical-robotics platform earned FDA De Novo authorization in 2023, and he managed a 35-patent portfolio licensed from Johns Hopkins. He wrote Founders Who Finish and publishes The Build. More about Dave →