🎯 Standards for internal vs external releases

It is natural to think of internal releases as "low stakes" - if it crashes and burns, no big deal. It's just an experiment, right? Near production release, we'll toss it over the wall to QA/Manufacturing and find all the issues.

This is partly true, and partly false. While it is true a product should get better over the development cycle, it is helpful to apply the same standards for internal releases as external for the following reasons:

• It forces an emphasis on quality early.
• It results in automated testing.
• There will be fewer surprises late in the development cycle.
• Integration with other groups happens earlier (Quality, Sales, Manufacturing, Customers).
• It is much easier to build prototypes when quality is high.

This does not mean the entire product needs to be perfect on day one - that is impossible, as the product is not done - just the work already completed, however small that may be. Is this tiny bit of work done to high standards? Is it testable, manufacturable, etc.? Is it useful to someone?

Here's the thing - it is much easier to apply high standards to small bits of work as you go, than retroactively fix it late in the game. It is not a waste of time, rather it is only way that works in developing modern systems.

If internal releases are not at the same standard as external releases, they are not releases, they are something else.