Digging Beneath Feature Requests – The Unbiased Founder #3

Welcome back to the 3rd article of The Unbiased Founder series!

In Post #1 and Post #2, we learned how to avoid leading questions and how to deflect the "fool's gold" of polite compliments by anchoring on past behaviors.

Once you start having real conversations about a customer's workflow, something exciting happens: they stop giving you generic praise and start pitching you concrete feature requests.

"You know what you guys really need? A custom CSV/Excel export builder with macro templates!" "If you add a real-time Slack bot with custom slash-commands, we’d definitely consider switching." "Can you make the dashboard configurable with drag-and-drop widgets?"

As engineers, our natural instinct when someone hands us a concrete technical specification is to smile, open Jira or Trello, create a ticket, and start estimating story points. Happy days...

After all, isn't "listening to the customer" what good product teams are supposed to do?

Not quite... Listening to customers does not mean taking orders like a restaurant waiter.

Today, we’ll cover what to do when customers start designing your product for you, why blindly implementing feature requests is a fast lane to feature creep, and how to perform root-cause analysis to uncover what they actually need.

The Problem with Feature Requests: Product by Committee

Here is one of the most important mental models in product engineering:

Customers are world-class experts at knowing what their problems are, but they are terrible at designing the software architecture to solve them.

Think of it like visiting a doctor:

• As the patient, you are the undisputed authority on your symptoms: "My lower back hurts every time I sit at my desk for more than two hours."
• Imagine if you walked into the clinic and instead of describing your symptoms, you handed the surgeon a sticky note saying: "Please prescribe me 400mg of Medication X and perform a L4-L5 spinal fusion this afternoon."

A good doctor doesn't blindly obey a patient's self-prescribed surgery! They ask diagnostic questions to find the root cause (maybe you just need physical therapy or an ergonomic chair).

When founders blindly write down every feature request a prospect mentions and add it to the roadmap, they end up building a Frankenstein Product by Committee:

Even worse: you spend three weeks building the exact feature a customer asked for, come back to show them, and they say, *"Oh, neat! We still can't really use it yet, as our remaining system isn't working properly!

The Classic Case Study: The "Excel Export" Trap

Let’s look at a classic real-world example that almost every B2B founder encounters.

A customer tells you: "We need a one-click Excel export button on every analytics screen."

If you take that request literally, you spend a week building an .xlsx serializer, handling multi-sheet formatting, column widths, and date-time timezone conversions.

What happens if, instead of saying "Sure, I'll add that to the sprint!", you pause and dig beneath the request?

Customer: "Does your platform have a customizable Excel export?"

Founder:  "Not right now. Out of curiosity, what do you do with the Excel 
          file once you export it from your current system?"

Customer: "Well, every Friday afternoon, I export the CSV, open it in Excel, 
          delete columns D through K, and email it to our CFO."

Founder:  "Got it! Why does the CFO need that file every Friday?"

Customer: "Oh, she just wants to check if any single vendor invoice went 
          over 10,000€ before approving the weekly wire batch."

Read that again!

The customer does not love Excel.
They don't want to spend their Friday afternoon deleting columns D through K in a spreadsheet! They asked for an Excel export because that is the only mental model they know from their legacy tools to deal with a completely different problem: giving the CFO visibility into invoices over 10k €.

If you understand the root motivation, you don't build a bloated spreadsheet exporter. You build a simple automated Friday Slack/email digest for the CFO: "Here are the 3 invoices over \10k€ awaiting approval—click [Approve]."

You just turned a painful 30-minute manual Friday chore into a zero-click automated workflow—all because you refused to take the feature request at face value.

Finding the Root Cause: The Diagnostic Digging Loop

Whenever a customer requests a feature—or exhibits a strong emotional signal (like frustration, anger, or sudden excitement about a workflow)—treat it as the start of an investigation, not the end.

Compare the surface reaction with the root-cause digging approach:

The 4 Go-To Digging Questions

Keep these four questions in your back pocket whenever someone pitches you a feature:

1. The Motivation Probe: "Why do you want that? What would having that allow you to do that you can't do today?"
2. The Coping Probe: "How are you coping without it right now?" (Remember from Post #1: if they say "Oh, we don't really do anything, it's just a nice-to-have," you immediately know it’s not a critical blocker!).
3. The Priority Probe: "If we built that today, would you be ready to switch immediately, or are there bigger blockers in the way?"
4. The Emotional Follow-Up: When someone sighs, rolls their eyes, or lights up and says "That part drives me crazy," never move on to the next question on your list! Stop and say: "Wait—tell me more about why that part drives you crazy."

Feeling Like an Annoying Five-Year-Old ?

At this point, a very natural concern usually pops up: "Carlos, if I keep asking 'Why do you want that?' and 'Why do you do it that way?', won't I sound like an annoying five-year-old interrogating them?"

If you literally repeat the word "Why?" five times in a robotic monotone, yes, it will feel weird! :D

The secret is framing your curiosity around their expertise. People love talking about their craft and explaining the nuances of their job to someone who genuinely wants to understand it.

Instead of a blunt "Why?", use conversational bridges:

• "Wait, help me understand the backstory there—what happens downstream if that report isn't sent?"
• "I'm not super familiar with how finance teams audit that step—walk me through why that column matters?"
• "That sounds super tedious! How did that process come to be?"

You aren't challenging their intelligence. You are asking them to teach you their domain. In my experience, most domain experts will happily talk for 20 minutes straight once they realize you are actually listening to the messy details of their day.

And in the real Word, how to log feature requests without "Polluting Your Roadmap"

In software architecture, we often use the Command Query Responsibility Segregation (CQRS) pattern or separate raw event logs from materialized views. You should do the exact same thing with your product backlog!

Never log a customer's literal feature request directly into your engineering sprint board. Instead, log a Problem-Solution Pair:

❌ BAD BACKLOG TICKET:
- [FEAT-104] Build customizable Excel (.xlsx) export button on Invoice page.

✅ GOOD DISCOVERY LOG:
- [PAIN-104] Context: Every Friday, Accounting exports CSV and manually filters 
  invoices > $10k in Excel to email the CFO before wire approvals.
- Literally Asked For: "Custom Excel export."
- Root Job-to-be-Done: CFO needs pre-wire sign-off on high-value invoices (> $10k).
- Coping Mechanism: 30 mins/week of manual Excel editing.

When you log the Root Job-to-be-Done alongside the literal request, you start seeing patterns across 10 or 15 customers. Five customers might ask for five completely different features (an Excel export, a Slack webhook, a custom PDF report, an email alert, a mobile view)—all to solve the exact same underlying problem.

Solve that one underlying root cause cleanly, and you satisfy all five customers without turning your codebase into a bloated spaghetti monster.

Wrap-Up & What's Next

When customers start designing your software for you, resist the urge to just take orders:

• Separate symptoms from prescriptions: Customers own the problem; you own the solution architecture.
• Dig beneath every feature request: Ask "What do you do with that once you have it?" and "How are you coping without it today?"
• Follow emotional signals: Whenever you hear frustration, anger, or excitement, stop and dig deeper.

So far in this series, we’ve covered how to ask unbiased questions, how to deflect compliments, and how to dig beneath feature requests.

But what happens when you are following all these rules, having pleasant, insightful conversations about workflows—while subconsciously tip-toeing around the one massive question that could prove your entire startup is dead on arrival?

In the next article, Embracing the Terrifying Questions – The Unbiased Founder #4, we’ll confront the scariest questions in your business and learn why seeking out bad news early is a founder’s ultimate superpower.

Stay tuned! Cheers 🙂