Prototypes of various forms have been around for as long as we’ve been doing software, since the famous Fred Brooks quote: “plan to throw one away, you will anyway.” However, many things have changed. Not the least of which is that the tools and techniques we have for developing prototypes and testing them have developed dramatically. Of all the different MVP techniques, prototypes are among my favorites.
In earlier articles I’ve discussed various aspects of Minimum Viable Product (which I like to refer to as MVP Tests to avoid any confusion with an actual product). In this article I’d like to say more about the critical concept of Product Market Fit.
Much has been written about waste at startups. I started writing about this as far back as 2005 (see Startup Product Management), and this concept is at the core of the Lean Startup movement.
Much has been written about how to do product discovery in startups, by me and many other people. There are many challenges for startups, most importantly, survival. But one of the real advantages from a product point of view is that there’s no legacy to drag along, there’s no revenue to preserve, and there’s no reputation to safeguard. This allows us to move very quickly and take significant risks without much downside.
When I start working with product teams, one of the first things I try to do is to get them to stop thinking of their job as one of gathering and documenting requirements. In fact, I try to get them to stop thinking in terms of requirements at all. Most requirements are not actually requirements, and the rest are better thought of as constraints.
One of the things I like about a Lean Canvas is it helps to quickly highlight the key assumptions and major risks facing a startup or a significant new product in an existing business. This is a good thing. The idea is to tackle the biggest risks first. That's the theory at least.
Our job in the product organization is to create products that can sustain a business. Make no mistake about it: everything depends on strong products.
I should have written this article many years ago.
Starting around 2004 and 2005 I began seeing an increasing number of teams moving to Agile, and of course the first thing they needed was training and often some coaching.
However, more often than not, I had to go into these companies after the training and try to clean up the mess that the trainer left behind.
This article is a little bit different, but if you make it to the last paragraph, I'm hoping it will help better explain where I'm coming from.
I'm always badgering teams about moving faster. Yet I continue to meet people and teams that not only move very slow, they don't understand the relationship between speed and innovation, or speed and quality. In fact, many people still think those goals are at odds. I attribute this mainly to a deeply rooted Waterfall mindset.