Contain and Control Risk

In 1981 I, together with two other founders, started the first Computer Aided Software Engineering company aimed at improving the workflow for IBM mainframe programmers. The opportunity was huge, and the potential payoffs for us and our prospective customers were equally huge.

My original idea was to develop a series of programming tools in a staged fashion. The approach I’d been using for several years was a forerunner of Lean business and Agile Development. The ultimate end goal was to offer a workstation that provided closely integrated editor, syntax checker, compiler, runtime emulation of the behavior of the IBM mainframe Cobol environment, testing tools, and full code analysis.  The original plan was to quickly develop the editor and syntax checker and put that into customer hands for feedback.

Enter the Venture Capitalists. And a required change in the development plan. Rather than initially offer the editor/syntax checker as a first product, the VCs (who then dominated our Board of Directors) , insisted that we only offer the fully capable final visionary product. We gave up the ability to get early feedback for our approach. Now we had stepped up the risk factor several times. We delayed customer feedback, increased the company spend rate, multiplied the software that needed to be completed by several times, and suffered the usual delays in delivering a working “product.”   We had to scale up our training staff, documentation staff, and field applications engineering staff.

The company eventually failed for many reasons, but I believe that the chief reason was rooted in the need to acquiesce to board members who were disconnected from our prospects. By circumventing the opportunity to gain early feedback (through design  of experiments) we delayed validating our product ideas. Every delay of validation increases risk – sometimes disproportionately.

I’ve seen and experienced this general sequence many times in my career and taken away one fundamental guiding principle: design the product so that early testing of an essential product can begin early. This is a risk containment and control strategy. You’ll see this technique used in Agile development methodology, Alex Osterwalder’s Canvas business generation system, and other enlightened business and product planning approaches.

I’ve adopted a personal approach to product development that focuses on risk mitigation. I can’t, and shouldn’t, eliminate risk but I do want to contain the effects of risk discovery and control how we react to the new facts of risk. That business philosophy, practiced over close to thirty years, has been codified by Alex Osterwalder in “Business Model Generation” and Ash Maury in his “Lean Stack” system.

Bottom line: don’t be that person who falls in love so hard with the product or company idea that you can’t/don’t see the risks and opportunities to mitigate risk.