[beckingz]

Except that requirements cost time to develop, so perfect requirements have significantly more cost than good enough requirements.

Also, requirements tend to evolve as customers grow, so requirements will change over time and become less perfect, causing that investment to depreciate.

[tonyarkles]

I agree completely. In the physical goods world, though, it’s not a continuous function. At points along the way, there is a very clear cost step response. Requirements evolving is totally fine and expected, but you need to periodically say “The current set is good enough, let’s build it and ship it”. Trying to do continuous delivery on manufactured items is the road to madness.

My general approach to this is to try to reasonably anticipate things that could be coming down the pipe and, if possible, do the bare minimum to cheaply support the next prototype. As an example, if the product has a GPS receiver and a microcontroller and could conceivably need to do dual-receiver down the road, I’ll have a quick look for spare Tx/Rx pins on the microcontroller and just route those out to blank pads. Two benefits:

- when product management asks, we have a way to build a prototype using existing parts

- if there aren’t any spare pins to break out like that, I can raise it as a potential design red flag early. It’s not necessarily a show stopper, but it contributes situational awareness for when the next big step cost might show up down the road.

[firewolf34]

I love when you guys do that. Then when I'm hacking around w/ your machine, I can get ahold of those spare pads :)