Old-timers like me remember when the philosophy behind product development was that you only got one shot, so you needed to get it exactly right. That was the era of "waterfall" development: First, you completely specified the product with all the features that you thought customers were looking for, then you built it, tested it and delivered it. Waterfall development came of age when product development cost a lot and took a long time. Committing to the project at all meant spending a lot of money and committing a year or two to product development, so you'd better get it right the first time. The problem, of course, is that very few teams got it right the first time, or even bothered to talk with potential customers before the product was 90% completed, so the vast majority of new products failed.
Waterfall development has now been replaced in most cases with agile development. Products, especially software and online services, can be developed in a tiny fraction of the time and at a tiny fraction of the cost required when I first entered the business. The new goal is to develop a Minimum Viable Product--a product or service with the least amount of features and capabilities necessary in order to be considered usable--and then modify the product and add functionality on the basis of customer feedback.
However, there's a very important part that's often left out of consideration, and that's what's going on in the heads of customers. Both waterfall and agile development processes are driven by the amount of time needed for development: Waterfall takes a long time, so you have to offer a "complete" product when you go to market; agile can deliver something that works in weeks, so you get "something" out quickly and iterate. Customers, however, neither know nor care how long it takes to develop a product. They don't care about whether the product was developed using waterfall or agile techniques. All they care about is what the product does for them. Does it solve a real problem? Does it make their lives easier? And, most importantly, is what the product does valuable enough for them to pay for it?
There's an old saying: "You never get a second chance to make a first impression." Most of the time, the Minimum Viable Product that a development team shows to potential customers has what the team thinks are the minimum necessary set of features and benefits, but what if they're not? Agile product development and customer development practice says that you iterate--make some changes to the product--and try again. In the worst case, you pivot and make major changes to the product, target market or distribution. However, those potential customers who you pitched your original MVP to already formed an impression about you and your product, and some of them are unlikely to give you another chance.
That's not a big problem if your market is big and you have lots of customers, but if you've got a market with a relatively small number of large customers, losing even a few of them could easily add a year to your sales cycle, if it doesn't kill your product altogether. So, the real question is, when is it 11:30?
The one hard-and-fast rule is that the only people who can tell you if your Minimum Viable Product is truly viable are your customers, and if you wait to start talking to them until you've got what you believe to be a MVP, you may already be too late. The time to get "out the door" and start talking to customers is as early in the product development process as possible. This is especially true if no one on your development team has deep knowledge and experience in the market you're addressing.
In the world of agile development, your customers are the timekeepers. They're the ones who'll tell you when it's 11:30.
No comments:
Post a Comment