The Case for User Feedback Gets Stronger When the Stakes Get Higher

A reader responded to In Practice: Why We Push Back with something worth addressing directly. His point was that the companies I described — ones building features nobody asked for, ignoring users in favor of internal assumptions — often aren't doing it out of arrogance. They're doing it out of desperation. A pivot company operating on fumes, with legacy obligations, sporadic revenue, and a business model still in motion, doesn't have the luxury of doing things right. They do them good enough and build a backlog.

He's not wrong about the conditions. But the conclusion I'd draw from them is the opposite of the one implied.

When you can't afford to make mistakes, you can't afford to build the wrong thing. The constraints don't weaken the case for user feedback. They make it the only rational path.

On money — or the absence of it

No reserve. Sporadic revenue. Not enough sustained funding to do it right. Vendor obligations. Investor commitments.

These are the conditions under which most of the founders I've worked with are actually operating. Not the well-capitalized startup with a clean runway and a product roadmap. The self-funded founder who burned through their savings on a first attempt. The founder running on a grant or a friends-and-family round — where the people who believed in them early are watching, and where failure costs more than money. The legacy firm pivoting on whatever's left after keeping the lights on.

Under these conditions, building just to build is the most expensive thing you can do. Every sprint that produces something nobody uses is money that could have gone toward something that moves the needle. The tools that make user research fast and cheap — AI-assisted design, prototype testing, a feedback button and a sprint review — exist precisely so that resource-constrained teams don't have to gamble on intuition. There is no budget argument against a Loom recording and a fifteen-minute call with three users. There is a very strong budget argument against a six-week build that lands with silence.

On vendor and investor obligations specifically: these stakeholders have expectations about what gets delivered. The answer isn't to exclude them from the feedback loop — it's to include them in it. Bring them in the room. Treat them as customers with a seat at the table. Their expectations become part of the data set, not a force acting against it. The stakes of getting it wrong with an investor or a key vendor are higher than getting it wrong with a new user. That's a reason to be more rigorous about what you build for them, not less.

On strategic uncertainty

A business model still in motion. A team copying features from competitors or from systems they used in a previous life. A shotgun blast approach to revenue — any opportunity is a good opportunity.

The fastest path to revenue under these conditions is a direct question to the people already in your ecosystem: what in this product is a dealbreaker, and what would you actually pay for? Everything else is noise. Competitors' features were built for their customers, with their context and their data. They are not a roadmap for your product. They are an observation.

The business model itself is part of the experiment. If customers aren't engaging the way the model requires, that's a signal — not a mandate to push harder in the same direction, but an invitation to test assumptions the same way you'd test a feature. Can customers sustain what you're asking of them? Is the model legible to the people it's supposed to serve? These are answerable questions. Hoping the market will accept a business model that hasn't been tested is the same error as hoping they'll use a feature that hasn't been validated.

Legacy clients are not a distraction from this — they're part of the answer. Existing relationships are cashflow and signal simultaneously. These are people who already chose you. They have opinions about what they need next that they haven't been asked for. Maintaining what they value and asking what they'd want beyond it is not a detour from growth. It's the most direct route to finding where the product can expand without losing the core.

On systems and teams

Legacy systems that aren't being used by actual customers are dead weight. They look like assets on paper. They are operational drag in practice. The right lens is lean: upgrade when there's usage, cut when there isn't. That post described features that were built and went unused for months — the same principle applies to inherited systems. If real users aren't touching it and potential users aren't asking for it, it's technical debt dressed up as infrastructure.

On teams without clear roles or ownership: the build-measure-learn loop doesn't require an org chart. Anyone can participate in it. What it does require is that the people closest to the product stop assuming they understand what users want because they've seen similar problems in other contexts, and start creating a direct line to the people actually using the thing. A feedback mechanism — a button in the product, a form, a quarterly call — costs almost nothing to set up and almost nothing to run with an AI agent triaging requests by frequency and backing. The operators of the business should be operating the business. The job of figuring out what users want should not be assigned to the same people who are already wearing five hats. Offload it to a system. Build it early. It becomes cheaper to make decisions the longer it runs.

The companies in this position — pivoting under constraint, without reserve, with obligations pulling in every direction — need these tools more than anyone. Not less. When there's no margin for error, the only rational move is to derisk the build process as much as possible before a dollar of development is committed. A few conversations, a prototype, a feedback loop wired into the product from day one — these are not luxuries. For a company in that position, they're the difference between a pivot that finds its footing and one that exhausts the runway on the wrong thing.

The lean methodology is called lean for a reason. It was designed for exactly these conditions.