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.














Use of music?

Many people casually use music on websites because “it’s not for pay” so they think there’s no need for a license and no risk for them.

The simple answer is  – get a legal opinion. Reading “terms and conditions” and the law is a good start but is not the whole story. The best way to use music is to subscribe to a service that clears the music that they provide – OR – as another person suggests, have a bit done specifically for you with all rights.

One *might* be able to “get away” with marginal use of another’s work but with greater risk. Remember the BIG fines levy against folks who copied a single movie or album? Tens of thousands of dollars in legal fees and then much more in fines.

Why subject yourself, your family and your business to that type of lawsuit?

Firing a PITA client/customer

Firing a PITA client can be a liberating thing – if done well. But there’s risk associated with cutting off a client besides loss of income from them.

Just as good news travels between like-minded people, bad news (being fired by a supplier) travels even faster. And that news is colored by the client’s spin even if you’re in the right.

Unfortunately even more folks hear of the bad news than ever hear of the good news. Some of the “bad news” is repeated by the offended party (the PITA client) to their close friends. Even more can make the underground circuit in no time flat, but with a spin against you as the supplier. Unfortunately, there’s precious little that one can do as a supplier in these circumstances. Start the “he said – she said” game and your business will likely suffer beyond the single firing.

How much can this underground network hurt or help? When email first started being used by businesses, I was responsible for a new product line that was a year late when I took on the job. ONE complaint about the project from a customer waiting for the parts was copied to twice as many people as had designed in the part. Careful, thoughtful, transparent communications kept all 683 customers satisfied while we worked through the problems. Done wrong, and the bad news would have propagated to several times theb number of people – and we would never have the chance to fix the problem.

Caveat amet