# Feature requests: digging for the real problem

> How to handle feature requests: why they're clues, not specs; which questions uncover the customer need behind them; and why strong emotions and your own pitching matter.

- Course: [Customer Development: Talking to Customers](https://productovi.com/courses/customer-interviews.md)
- Module: Bad data
- Lesson 6/15, ~40 min
- Source: https://productovi.com/courses/customer-interviews/feature-requests-and-digging

## Megan's wishlist

**Alex Tutor:** Your interview notes have started circulating beyond CatChow's product team, and Megan from sales has read them.

**Megan:** Great news: customers are telling us exactly what to build! From our calls and your notes: treats in the box, choosing the delivery day, a pause button and an app that reorders when you scan the bag.

**Megan:** I say we put all four into the first version. Customers asked for them, so they'll pay for them.

**Sofia:** That's a lot for a first version. But it does come straight from customers…

**Alex Tutor:** It does, and that's what makes it valuable. Just not as a to-do list. Each **feature request** is a clue that something in the customer's life isn't working. The request is their guess at a fix.

![A detective with a magnifying glass studies a wishlist of small pictures: a box of treats, a calendar, a pause button and a phone.](https://productovi.com/courses/customer-interviews/inline/feature-requests-and-digging-illustration-2.webp)

*Each request points at a problem. The job is to find which one.*

**Sofia:** So we need to find out what's behind each one.

**Alex Tutor:** Yes. Treat the list as questions to ask, not tasks to do.

> **Exercise:** Megan wants all four customer requests in the first version. What is the best next step?

## Why a feature request isn't a spec

**Megan:** But isn't it arrogant to ignore what customers literally ask for?

**Alex Tutor:** Nobody's ignoring them. They own the problem, we own the solution. Customers are experts in their own lives, not in designing products.

**Alex Tutor:** Last year the website team added a food comparison table because three customers asked for it. Almost nobody used it.

**Sofia:** What did those customers actually want?

**Alex Tutor:** Someone finally asked. 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.

**Alex Tutor:** So write every request down, word for word. Just don't put it on the roadmap until you know what it's for.

> **Exercise:** Writing a customer's feature request down in your interview notes is a mistake, because it tempts the team to build it.

**Sofia:** Even when the person asking is an expert? Vet clinics send us requests too.

**Alex Tutor:** Even then. They're experts in their own work, not in designing our product. Their request is still a guess at a fix.

**Alex Tutor:** So the rule holds: write it down word for word, mark it as a clue, and don't promise anything yet.

**Alex Tutor:** Try it with a request from a clinic.

> **Exercise:** Tom, a vet clinic administrator, tells Sofia: “You should add a comparison table of all your kidney-diet foods.” What should Sofia do with this request?

## How to handle feature requests: three digging questions

**Sofia:** How do I find out what a request is for, without sounding like I'm rejecting it?

**Alex Tutor:** Be curious about it. Three questions do most of the work: “Why do you want that?”, “What would it let you do?” and “How do you manage without it now?”

**Alex Tutor:** That's **digging**: following a request, an opinion or a strong reaction down to the motive underneath. To check how much it matters: “If it came a month after launch, would that be a problem?”

**Alex Tutor:** If you know the **five whys** from root-cause analysis, this is a gentler cousin: three questions asked with curiosity, and you stop once you reach a real story instead of counting to five.

![A person with a spade digs under a small flower and uncovers a large tangled root spreading deep underground.](https://productovi.com/courses/customer-interviews/inline/feature-requests-and-digging-illustration-3.webp)

**Sofia:** Let me try it on Andrew's “I want to choose the delivery day”. I'll call him now.

**Alex Tutor:** Good. First, check you know what each question is for.

> **Exercise:** Match each digging question to what it helps you find out.

**Sofia:** So no counting to five. But how do I know I've reached the bottom?

**Alex Tutor:** When you hear a specific event: what happened, what it cost, how they cope now. Then stop digging and listen.

**Alex Tutor:** Keep pushing past that point and a friendly chat turns into an interrogation. People start inventing reasons just to make it stop.

**Alex Tutor:** Quick check before you call Andrew.

> **Exercise:** Digging works best when you ask “why?” exactly five times in a row, whatever the customer answers.

**Alex Tutor:** One more before you dial. Andrew picks up and repeats: “I'd really like to choose the delivery day.” Which reply starts the digging?

> **Exercise:** Andrew: “I'd really like to choose the delivery day.” Which reply should Sofia give?

## What Andrew really needed

**Sofia:** I asked why the day matters. He works shifts at a hospital. Twice the courier came while he was on a night shift, and the parcel went back to the warehouse.

**Alex Tutor:** And how does he manage now?

**Sofia:** He has everything delivered to a parcel locker near the hospital and picks it up after his shift. He says it works, except the lockers are often full.

**Alex Tutor:** So his real need isn't a calendar; it's getting food without being home. He already has a **workaround** that mostly works. Would picking a weekday even help someone on rotating shifts?

![At dawn, a tired nurse in scrubs takes a cat-food bag out of a parcel locker next to a hospital after his night shift.](https://productovi.com/courses/customer-interviews/inline/feature-requests-and-digging-illustration-4.webp)

*He asked for a delivery day; what he needed was food that waits for him.*

**Sofia:** Probably not. Delivery to a parcel locker would, and it's much simpler to build.

![Digging under Andrew's request to choose the delivery day: night shifts, a parcel-locker workaround, and the real need of getting food without being home.](https://productovi.com/courses/customer-interviews/diagrams/m2-l3-digging.png)

> **Exercise:** Andrew asked to choose the delivery day. When Sofia dug, he told her he works rotating shifts at a hospital, twice the courier came while he was on a night shift and the parcel went back to the warehouse, and he now has everything delivered to a parcel locker near the hospital, which is often full. Which conclusions do his answers support? Select all that apply.

## Olivia's treats

**Sofia:** Now the treats. This is from my very first call with Olivia, right after I described the subscription:

**Olivia:** Will there be treats in the box too? Whiskers adores them.

**Sofia:** Megan's already pricing them.

**Alex Tutor:** Same approach. There could be many reasons behind it. Maybe she forgets to buy treats. Maybe she wants to try new ones without buying a whole pack. Maybe she was just being friendly.

**Sofia:** And each reason means a different product.

**Alex Tutor:** Or no product at all. Write the questions you'd ask her. Keep them about her life, not our box.

> **Exercise:** Olivia asked: “Will there be treats in the box too?” Write 2–3 **digging** questions to find out what's behind this request.

## Emotions are signposts

**Sofia:** Something else in my notes. When I asked Hannah about deliveries, she said “Ugh, don't get me started on couriers!” I wrote “dislikes couriers” and moved on.

**Alex Tutor:** You walked past a signpost. Strong emotion, whether annoyance, embarrassment or excitement, marks the spot where something important happened. Stop and dig right there.

**Sofia:** Isn't it more polite not to pry?

**Alex Tutor:** People usually want to tell that story. Just give them room: “That sounds frustrating. What happened?” Then be quiet and let her vent.

**Alex Tutor:** It works for excitement too: “You sound really keen on that. Why does it matter so much?”

> **Exercise:** A customer sighs: “Honestly, reordering food is the worst part of my week.” What is the best response?

## Talk less, stop pitching

**Sofia:** Confession: in the Andrew call I slipped. He said “So it's like a food delivery app?” and I jumped in to explain how we're different. For two minutes.

**Alex Tutor:** What did he say after that?

**Sofia:** “Sounds good.” And nothing else useful.

**Alex Tutor:** That's what **pitching** costs. The moment you sell, people stop talking about their problems and turn polite. And by correcting him, you lost something valuable: how he sees the idea.

**Alex Tutor:** Everyone slips. When you notice, stop and own it: “Sorry, I got carried away. You were telling me about the night shifts?” If he's curious about the product, promise to tell him at the end.

**Alex Tutor:** A simple check for any call: if you're talking more than they are, something's gone wrong.

> **Exercise:** Sofia realises she has been **pitching** for two minutes after Andrew asked “So it's like a food delivery app?” Write what she could say (1–2 sentences) to stop and bring the conversation back to his story.

## Answering Megan

**Megan:** OK, I get it: don't build the list blindly. But I need something for Friday's planning meeting. What do I tell them?

**Alex Tutor:** What we know, what we're guessing and how we'll find out. You've dug into two of the four. Write it up for her.

**Sofia:** The pause button and the scanning app still need digging, though.

**Alex Tutor:** Then say so. “We don't know yet, and here's how we'll find out” is a perfectly good answer at a planning meeting.

> **Exercise:** Write Megan a note for Friday's planning meeting about the four customer requests.

**Sofia:** Before I send it: how do I decide what counts as “what we know”?

**Alex Tutor:** Only what someone told you actually happened: events, workarounds, money spent. Everything else is a guess, however likely it sounds.

**Sofia:** Including the things a customer asked for that nobody has dug into yet?

**Alex Tutor:** Those most of all. An undug request tells you there's a clue, not what it means. Sort the list for Megan.

> **Exercise:** Which statements can Sofia put under **“What we know”** in her update for Megan? Select all that apply.

## What to remember

**Sofia:** So a feature request is the start of a conversation, not the end of one.

**Alex Tutor:** Exactly. Ask why, ask how they cope today, follow the emotion, and save your pitch for later. You're really building for the problem underneath.

> **Key ideas**
>
> - A **feature request** is a clue to a problem, not a spec. Write it down; don't put it on the roadmap yet.
> - Dig: “Why do you want that?”, “What would it let you do?”, “How do you manage without it now?”
> - The existing **workaround** often points to a simpler solution than the one requested.
> - Strong emotions mark where to dig. Give people room to tell the story.
> - Stop **pitching**: when you sell, they stop talking about their problems. Talk less than they do.

**Alex Tutor:** That's module 2: compliments, fluff and feature requests. Next module: preparing for the questions you'd rather avoid, and for the ones that matter most.

- Previous lesson: [Fluff: vague answers and the say-do gap](https://productovi.com/courses/customer-interviews/fluff.md)
- Next lesson: [Scary questions you avoid](https://productovi.com/courses/customer-interviews/scary-questions.md)

---
Productovi Learning. Free, no sign-up needed to read.