The Customer Asked For It Is Not a Reason
Requests are evidence of something. Rarely evidence that you should build the request.
An account manager forwards you an email. A customer who pays well has asked for a dropdown on the reports page to filter by region. The email is polite and specific, it even suggests where the dropdown should go. Your ticket writes itself. Before you write it, ask one question: what were they doing when they wanted this?
A request is a customer's guess at a solution, filtered through what they already know your product can do. They are experts in their own situation and amateurs at your product's design space. When you build the request literally, you are outsourcing design to somebody with less information than you have, and you are throwing away the part of their message that was actually valuable: the situation that produced it.
Worked example
Clarity Rooms, a meeting room booking tool
Four separate customers asked for a way to book a room for a recurring meeting and have it auto release if nobody checked in. The literal build was a check in flow with a timer and a release rule, roughly six weeks. The PM called three of the four. In every case the situation was the same: a weekly leadership meeting held a large room, the meeting got cancelled in the calendar, and the room stayed blocked because the booking lived separately. Nobody actually wanted a check in kiosk. They wanted the room to follow the calendar. The team built a two way calendar sync in eleven days. The check in feature was never built, and the requests stopped.
Four customers, one request, and the right answer was not the request. That happens often enough that the request count on its own should never be your trigger to build.
Nine requests, three situations
What a request is actually evidence of
- That something got in their way recently enough that they bothered to write to you. That part is real and worth taking seriously.
- That they believe your product is the right place to solve it, which is a compliment and also a constraint on their imagination.
- That their mental model of your product produced this particular shape of answer. Useful information about your product's model, not about the solution.
- It is not evidence of how many other people have the same situation, nor of how much it is worth, nor of whether this is the best answer.
Treating the request as the spec
- Build the dropdown.
- Count requests, build what has the most.
- The loudest and best connected customers set the roadmap.
- The product accumulates one narrow control per request.
Treating the request as a clue
- Ask what they were doing the last time they needed it.
- Group requests by underlying situation, then count situations.
- Customers who never write in get represented too.
- One change can retire five requests at once.
That last row is the practical payoff. When you work at the level of the situation rather than the request, a single well chosen change often kills a whole cluster of tickets. When you work at the level of the request, you get a settings page with forty checkboxes and customers who still write in.
Three questions to ask when a request arrives
- What were you doing when you needed this?
- Pushes them from the abstract feature back to the concrete episode. The episode is the data. Ask for the most recent time, not the typical time.
- What do you do about it today?
- Every real problem has a workaround. The workaround tells you how bad it is and often suggests a cheaper solution than the one requested.
- What happens if this stays as it is?
- Separates irritation from cost. 'It is annoying' and 'we do an extra two hours of manual reconciliation every Friday' are very different tickets, and only one of them should move up the list.
These three questions take about ten minutes on a call, and you can ask them by email if you have to. The trap is asking them and then building the request anyway because the answers were inconvenient. If you are going to do that, save everyone the call.
There are times when you should just build the request. If the ask is small, sits inside the shape of what already exists, and the cost of investigating exceeds the cost of building, do it and move on. Adding a column to an export, supporting a date format, letting someone rename a field. Investigation has a price, and spending a week of discovery on a two hour change is its own kind of waste. Save the questions for anything that adds a new surface or a new concept to the product.
There is also a political version of this problem. Sometimes the request comes with a renewal attached and the answer is going to be yes regardless of what you learn. Fine. Ask the three questions anyway, quickly, because even when the decision is made, knowing the underlying situation changes how you build it, and it tells you what else is coming from that account next quarter.
The skill here is holding two things at once: taking the customer completely seriously, and not taking their solution literally. People sometimes hear the second part as arrogance. It is the opposite. It is assuming they had a real reason, and caring enough to go find out what it was.
Quick check
Four customers request the same feature. What is the strongest reason not to treat that as a build decision?
The takeaway
Build for the situation that produced the request, not for the request, and group requests by situation before you count them.
Try this tomorrow
Take the three most recent feature requests in your queue and reply to each asking one question: what were you doing the last time you needed this? Group the answers by situation rather than by requested feature and see how many collapse together.
Answer the check above, then bank the day.
Where this comes from
- The Mom Test, Rob Fitzpatrick
- Inspired, second edition, Marty Cagan
- Continuous Discovery Habits, Teresa Torres
Product Thinking is one of six tracks. These lessons summarise and build on the work above, they do not reproduce it. Buy the books, they are better.