Build First: Why Slides and Spreadsheets Delay Product Development
Every hardware programme I have watched slow down had the same early symptom. Not a technical blocker, not a supplier delay, but a room full of people polishing slides and spreadsheets while the bench sat empty. The plan looked beautiful. The product did not exist.
The comfort of artifacts
PowerPoint and Excel are comfortable because they give the feeling of progress without the risk of being wrong. A roadmap slide can be perfect. A cost model can balance to the last cent. Nothing on them has met reality yet, so nothing can fail. That comfort is exactly the problem. In embedded and hardware work, the important unknowns do not live in the plan. They live in the timing of an interrupt, the noise on a sensor line, the datasheet that quietly disagrees with the silicon, and the integration seam where two modules marked "done" meet for the first time.
Prototypes tell the truth
A prototype is uncomfortable for the same reason a slide is comfortable: it can be wrong, and it will tell you so immediately. You wire up the sensor, and the bus does not enumerate. You run the loop, and the jitter is three times your budget. You bring up the board, and the regulator you specified cannot hold the rail. None of this shows up in a spreadsheet. All of it shows up in an afternoon on the bench. Every hour spent building buys you information that no amount of planning can produce.
A spreadsheet reduces anxiety. A prototype reduces risk. Only one of those ships a product.
Slides and spreadsheets are outputs, not the work
This is not an argument against documentation. Roadmaps, cost models and review decks matter; they are how a team aligns and how a programme is governed. The mistake is treating them as the work instead of as a byproduct of the work. The best plans I have worked with were written after a prototype, not before. Once you have measured the real timing, held the real board, and seen the real failure mode, the plan almost writes itself, and it is a plan you can trust. Build first, then document what you learned.
The prototype mindset
The mindset is simple to state and hard to hold: at every step, build the smallest thing that removes the biggest unknown. Not the whole product. Not a polished demo. The one crude experiment that answers the scariest open question. Can this microcontroller meet the control-loop deadline? Wire up a timer and measure it. Will this sensor fuse cleanly? Feed real data through the filter on a laptop. Does the FPGA path close timing? Synthesise the block instead of arguing about it in a meeting. Each answer collapses a branch of risk and makes the next slide honest.
Why it actually saves time
It feels slower to build early and faster to plan on paper. The opposite is true. Planning defers the discovery of every hard problem to the moment it is most expensive to fix: late, integrated, and on the critical path. Prototyping pulls those discoveries forward to when they are cheap. A programme that finds its ugly surprises in week three on a breadboard finishes ahead of one that finds them in month nine on the integration rig. Delay is not caused by moving fast early. It is caused by moving carefully on paper while the real risks wait, untouched, for later.
So my rule, after enough programmes to know better: respect the slide, respect the spreadsheet, but do not let them stand in for the bench. If a decision can be settled by building something small this week, build it. The plan you write afterwards will be shorter, truer, and far more likely to ship.