The feature that was really a support problem

Six weeks of engineering went into the most-requested feature. Usage was under 2%, and the underlying complaint had nothing to do with it.

This is an anonymised composite, not a report about a named company. The situation and numbers are typical rather than reported.

Where they were

A scheduling product for small clinics, $30k MRR, one product engineer and two founders.

The problem

'Bulk reschedule' was comfortably the most requested feature — 34 requests in a quarter, more than double the next item.

The decision

Whether request volume was enough to justify six weeks of their only engineer.

What was on the table

• Build it
  For: It was the clear top request, by a wide margin, from paying customers.
  Against: Request counts measure how easy something is to ask for, not how much it is worth.
• Call ten of the requesters first
  For: Two days to understand what sits behind the request.
  Against: Delays the most-wanted feature, and the answer felt obvious.
• Ship a crude version and measure
  For: Fastest route to real usage data.
  Against: Even a crude version was three weeks.

What they chose

They built it. Six weeks, polished, well tested. The reasoning was that thirty-four paying customers asking for the same thing is about as clear as product signal gets.

What happened

Usage settled under 2% of accounts in the first month and never rose.

When they finally called the requesters, the pattern was immediate: nearly all of them were rescheduling in bulk because a clinician had called in sick, and what they actually wanted was for the system to notify the affected patients. The rescheduling was the workaround, not the need. They had built the workaround, faster.

The notification feature took nine days and is now used by roughly 60% of accounts.

What transfers

• A feature request is a customer's proposed solution. The job is to find the problem behind it, which is often a different feature entirely.
• Request volume measures how easy something is to articulate, not how valuable it is.
• Ten phone calls cost two days and would have saved five weeks.
• When a request is a workaround for something your product does not do, building the workaround well makes it permanent.

More case studies