The demo went well. That is the part that still stings.

Twelve people in a conference room at a mid-size industrial distributor, watching a quote-builder prototype glide through a sample order. Clean UI, real data, a total that calculated itself. The sales manager said, out loud, this is exactly what we need. Two weeks later I pulled the usage dashboard and the number was best described as a flatline. Zero sessions. Not low adoption. Zero.

This story is a composite of a few builds I watched die the same way, names and industries shuffled. The failed software prototype lessons it carries are worth more than most success stories, because success stories hide their luck. Failures itemize it.

Here is the autopsy, so you do not have to fund your own.

The short version: the prototype died because discovery interviewed the person who felt the pain loudest instead of the people who lived it daily. The real bottleneck was pricing-exception approvals, not quote formatting, and one day of shadowing a rep would have shown it on day one. Everything below is what we paid ten working days to learn, so you can learn it in ten minutes.

What We Built and Why

Say you are a distributor with 40 sales reps and a quoting process that lives in a creaking ERP module from 2009. The sales manager's complaint, delivered with feeling in week one: my reps spend two hours a day formatting quotes, customers cannot read them, we look amateur.

That sounded like a brief. We built the obvious thing: a quote tool with templates, product lookups, margin guardrails, and PDF output that did not make customers squint. Ten working days, roughly like this:

Notice what is missing from that list. It is the part where anyone watches a rep actually work.

The Discovery Mistake

The sales manager was not wrong about his pain. He was wrong about whose pain mattered. He experiences quotes as documents that arrive on his desk for review, so formatting is what he sees. Reps experience quotes as a scavenger hunt: the ERP price is stale, so they check a spreadsheet, and anything over a 22% discount needs a director's blessing, which means an email, which means waiting a day and a half while the customer goes quiet.

We learned this in week two, when a rep I will call Dana finally told us the tool was pretty, but the price was still wrong and she still could not send anything over her discount limit without waiting on Greg. The two hours a day was never formatting. Most of it was waiting. Our beautiful formatter attacked maybe twenty minutes of it.

One shadow-shift on day one would have caught all of this. We saved a day and spent ten.

The Failed Software Prototype Lessons, Itemized

Run the five whys and it gets uncomfortable fast:

  1. Why did nobody use it? It did not remove the bottleneck reps actually felt.
  2. Why did we build for the wrong bottleneck? Requirements came from one interview with a manager.
  3. Why one interview? The timeline had no discovery budget; we treated the brief as fact.
  4. Why no discovery budget? We assumed the pain was obvious and quoting meant formatting.
  5. Why assume? Nobody wrote the assumptions down, so nobody had to defend them.

That last why is the one worth tattooing on a roadmap. Do the calendar math: one day of shadowing costs eight hours and would have killed the wrong build on day two. Instead we spent roughly 62% of the two weeks building features nobody used, 18% in meetings, 12% on rework, and 8% on anything resembling discovery. The chart above is that ratio, and it is ugly.

The Assumption List We Should Have Written

Steal this template. Before a single wireframe, list every belief the build depends on, each with a cheap test and an owner:

Half your assumptions dying in discovery is a good week. It is only embarrassing when they die in production.

What We Did Instead

Once Dana said the quiet part out loud, the pivot took about two days of scoping. The actual bottleneck was the discount-approval loop, so we built the dumbest possible thing: a chat bot. The rep types the quote number and requested discount, the director gets a one-tap approve or deny with the customer context attached, and the decision writes back to a shared sheet. Three days to build, live by Friday.

Approval turnaround went from a day and a half to about forty minutes. Reps adopted it in a week without training, because it removed waiting instead of adding a tool. The prototype's corpse did donate one organ: the product-lookup component, which we bolted into the bot so price checks happened in the same thread.

Total recovery cost was four days; total cost of skipping discovery was ten. The pattern shows up everywhere. The full 90-day logistics engagement story only worked because the first two weeks were mostly watching, and the invoice automation that returned 40 hours a week started at a bookkeeper's screen, not in a stakeholder deck.

Rules for Not Dying in Week Two

If you are about to greenlight a build, three rules from the morgue:

Prototypes are supposed to be cheap ways to be wrong. They only get expensive when you skip the part where you find out you are wrong. The spreadsheet empire teardown is the same lesson at a longer timescale: the system you can see is rarely the system doing the damage.

Build the shadow day into the budget. Your future self, staring at a flatlined dashboard, will thank you.