Pascal and the Lesson of the Minimum Viable Product

Start-ups are faced with a daunting task. They must develop their technology or their discovery into a product that people can use. Often the technology and the product are two very different things. It is easy to fall into the trap of wanting your product to be everything to all people, solve all problems, have all features. The perils of this attitude are that although the attempt is valiant, these extra features can be complicated to develop and have glitches that don’t work.  This causes the whole product to fail or creates delays that miss the window for product launch. The hard part is separating the product’s essence from the extra desired features. 

I learned this lesson the hard way, which is the way I seem to learn things best. It was 1987, and while an aspiring design student at Carnegie Mellon, I had to take a required course in Pascal programming. Questionable requirement for design students. In 1987. But nevertheless I persisted, embraced it even. It was a challenge for my right-brained way of thinking to adjust to the specifics and precision of the language. Once I got the basics though I was off and running and able to create small routines that produced the desired result. I even started tutoring fellow students. This fed my burgeoning self esteem until it grew into over confidence. 

The final exam came- the test of my mastery of this new skill. The exam was structured in tiers of features for certain grades, so you could choose to write your program to an A that solved the problem and had all features with bells and whistles working correctly, or you could take on less features and write it to a B, C, or D. Since I imagined myself as a newly minted Pascal expert, I naturally chose to write the program to an A. This required the basic functionality and the escalating tier of extra features to be all exactly error free or else none of it would work and I would fail. 

After many hours of creative soul searching and technical syntax, I had developed my solution and chose to weave in all the extra features. Triumphantly I ran the program and was horrified that it failed. It failed on one of the extra features that had very little to do with the execution of the basic function, but this failure took the whole thing down with it and nothing worked. The clock ran out and I had to turn it in. I got a D. For disaster. 

Now since I was an A student, my grade for the year was a C, but this was still a devastating event to my self inflated ego. 

30 years later I still recall this event when seeing the desires of start-ups to attach bells and whistles to their initial product. At Stream we counsel them to keep it simple and separate the extra features from the minimum viable product. Achieve greatness with your core competency that is well executed. Future iterations can include extra features, but you have isolated the variables and are building on a foundation that is firm and functional. Then you give yourself the ability to learn from user interactions with your prototype and incorporate their feedback. Failure is your friend, but only early in the process so you can learn from it and improve, not when steel has been cut for injection molding tooling. Incremental improvements will get you to the A because you have iterated, learned, and improved.