Feature requests: digging for the real problem

Megan from sales read Sofia's interview notes and was delighted: customers were telling CatChow exactly what to build. Treats in the box, choosing the delivery day, a pause button and an app that reorders when you scan the bag. Her plan: put all four into the first version. Customers asked for them, so they'll pay for them.

The list is valuable, just not as a to-do list. Each feature request is two things at once: a sign that something in the customer's life isn't working, and the customer's guess at a fix. The sign is valuable. The guess may be wrong. So the list becomes a set of questions to ask, not tasks to do.

Shortcuts that skip this step don't work either:

• building only the most popular request still skips the “why”: even the most frequent one can hide a need that a simpler fix would meet better;
• sending a survey that asks customers to rank the features collects opinions about imagined products.

The right next step is slower but cheaper in the end: go back to the people who asked and find out what problem each request is meant to solve.

Megan objected: isn't it arrogant to ignore what customers literally ask for? Nobody is ignoring them. Customers are experts in their own lives, not in designing products. That's why the split works: they own the problem; you own the solution. You're simply making sure you understand what they're asking for before you build it.

A cautionary tale from CatChow itself: last year the website team added a food comparison table because three customers asked for it. Almost nobody used it. When someone finally asked those customers what they wanted, it turned out their cats had kidney problems, and they wanted to know which food was safe. They needed a vet's recommendation, not a table. One question would have saved a month of work.

So what do you do with a request? Write it down, word for word: the exact wording keeps details that may matter later. Leaving it out of your notes would throw away a clue. Just don't put it on the roadmap until you know what it's for.

Sofia asked: what if the person asking is an expert? Vet clinics send CatChow requests too. Tom, a clinic administrator, says: “You should add a comparison table of all your kidney-diet foods.”

The rule still holds. A feature request tells you that something in the customer's life isn't working, plus their guess at a fix, and that's true even when the person asking is a professional. Tom is an expert in running a clinic, not in designing CatChow's product.

So handle every request the same way:

• Write it down word for word. Exact wording keeps details you may need later.
• Mark it as a clue, not a task, and don't rephrase it into your own conclusion. “Clinics need better product information” sounds tidy, but it's your interpretation before any digging.
• Dig before you plan: ask what he'd use it for. And don't promise anything yet.

Even a well-informed request can point to a need it doesn't name. A clinic asking for a table may really need fewer phone calls from owners asking about diets. Only digging tells you which.

How do you find out what a request is for without sounding as if you're rejecting it? Be curious about it. That's digging: following a request, an opinion or a strong reaction down to the motive underneath.

Each digging question uncovers a different layer behind a request:

• “Why do you want that?” reveals the motive.
• “What would it let you do?” reveals the outcome they're after, which may be reachable another way.
• “How do you manage without it now?” reveals the current workaround and what it costs them.
• “If it came a month after launch, would that be a problem?” shows how much it really matters. A shrug means nice-to-have; a worried face means you're near something important.

Together they move from the request to the life around it. Notice that none of them asks the customer to design anything: no “Which days would suit you?” or “Should it also do X?” You're collecting facts about their situation, and the solution stays your job.

Sofia tried this with Andrew, who had asked to choose the delivery day.

If you know the five whys from root-cause analysis, digging is its gentler cousin. Three questions, asked with curiosity, do most of the work:

• “Why do you want that?”
• “What would it let you do?”
• “How do you manage without it now?”

Don't count questions, and don't repeat “why?” mechanically. “Why? And why is that? And why?” feels like an interrogation, and a friendly chat turns into a defence. People get defensive and start inventing reasons just to make it stop, which is worse than no answer at all.

So how do you know you've reached the bottom? When you hear a specific event: what happened, what it cost, how they cope now. At that point stop digging and listen. The story will usually tell you more than any further “why”.

The goal is the story underneath, not a number of questions. Sometimes you reach it after one question, sometimes after four, and sometimes the honest bottom is “I don't really know, it just sounded nice”, which is useful to learn too.

When a customer asks for a feature, the friendliest-sounding reply is often the most harmful: you accept the idea and start shaping it together. “Which days would suit you?”, “Should it remind you too?”, “Would you want it in the app or by email?” It feels collaborative, and the customer enjoys it.

But every design question quietly accepts their solution. You learn which colour, day or channel they'd pick for a feature that may not fit their problem at all. Andrew, a customer who asked to choose the delivery day, works rotating shifts at a hospital, and twice a courier came while he was on a night shift, so the parcel went back to the warehouse. Asked which day he'd like, he would have happily named a weekday, and CatChow would have built a calendar for someone whose shifts change every week.

Go the other way: from the feature back to the life around it.

• “Why does that matter to you?”
• “What happened the last time?”
• “How do you manage now?”

Only these questions can reveal that the real problem is receiving food while he's out, and that a parcel locker, which he already uses, might solve it.

Designing is still your job, just later, back at the office, with the real problem in front of you.

Digging often shows that the request and the real need are different things: the perceived problem versus the real problem.

Andrew asked to choose the delivery day. Sofia asked why the day matters. He works shifts at a hospital, and twice the courier came while he was on a night shift, so the parcel went back to the warehouse. How does he manage now? He has everything delivered to a parcel locker near the hospital and picks it up after his shift. It works, except the lockers are often full.

So the real problem isn't the calendar; it's receiving food without being home. Would picking a weekday even help someone on rotating shifts? Probably not. His workaround, the locker, already mostly works, and it points to a simpler fix than the one he asked for: delivery to a parcel locker, which is also much easier to build.

Stay strict about what the answers support. They show a need and a workaround that mostly works. They don't show that he'll subscribe if CatChow adds lockers: nothing he said is a commitment, and that conclusion is still a guess.

Sofia found something else in her notes. When she asked Hannah about deliveries, Hannah said: “Ugh, don't get me started on couriers!” Sofia wrote “dislikes couriers” and moved on, walking straight past a signpost.

Strong emotion in a call, whether annoyance, embarrassment or excitement, marks the spot where something important happened. Stop and dig right there. Acknowledge the feeling and invite the story:

• “That sounds frustrating. What happened?”
• “The worst part? Sounds like there's a story there.”
• “You sound really keen on that. Why does it matter so much?”

Isn't it more polite not to pry? Usually not: people want to tell that story. Give them room, then be quiet and let them vent.

What you shouldn't do at that moment:

• pitch your product (“Then you'll love our subscription!”);
• change the subject (“Next question: how many cats do you have?”);
• jump to a hypothetical fix (“Would a reminder app make it better?”).

Each one turns a promising moment into a polite answer, and the story behind the emotion stays untold.

Megan needed something for Friday's planning meeting, but Sofia had dug into only two of the four requests. When the team wants an update before the research is finished, split what you have into three parts:

• What we know: only what customers told you actually happened. Events, workarounds, money or time spent. “Twice a courier came while Andrew was on a night shift” and “he collects from a parcel locker that is often full” belong here.
• What we're guessing: conclusions and predictions that sound likely but haven't been tested, such as “locker delivery would make Andrew subscribe”. However likely it sounds, it's a guess.
• How we'll find out: the next conversations or tests for each guess, and for each request nobody has dug into yet.

An undug request goes under “find out”, not “know”. “Customers want treats in the box” rests on one question Olivia asked right after hearing the pitch. The pause button hasn't been explored at all. A request tells you there's a clue, not what it means.

“We don't know yet, and here's how we'll find out” is a perfectly good answer at a planning meeting.