Milestone driven product development

One of the cautionary tales Steve Blank discusses in The Four Steps to the Epiphany is that of Webvan. Webvan was notorious for planning their scaling based on their business plan forecasts and not their actual growth.

Lots of companies focus their development cycle around these assumptions that are made prior to anycustomer contact. This is often a fatal mistake, as was the case with Webvan’s business plan. Webvan’s strategy arguably set the market for online grocery delivery back 5 to 10 years. Services like Instacart and others are proving that there is a clear demand for grocery delivery, yet for years investors were scared away from the concept. Webvan had this immutable roadmap laid out before ever interacting with their customers or learning how they were even planning on using the service. They plowed ahead with building warehouses and tons of infrastructure well before they understood their customers’ behavior patterns. By burning through their cash because thats what their plan had entailed, they failed to recognize the potential underlying pivots to their business model that could have saved them. For all we know Webvan could have survived simply by moving slower. Remember, no business plan survives first customer contact. Webvan’s business model made enormous assumptions of consumer demand and buying patterns, that drove them to build in anticipation of demand rather than in response to it.

One of the concepts I’ve been advocating lately with several of the startups I advise is to abandon the traditional waterfall method of product development and shift to a milestone triggered product development methodology. I don’t have a catchy name for it yet (I’m open to suggestions, or someone else probably has come up with one already), perhaps its a growth point product development process. The idea is simple, break up your ideal product vision into segments, starting with your mvp, and mapped out through a few versions. Each subsequent phase of development is not, and I repeat NOT, pegged to an arbitrary date; each subsequent phase of development is tied to a specific business milestone being reached, either a predetermined number of users, or better yet, a certain amount of revenue being reached. By tying your development to your revenue milestones you can also put more emphasis on refining your product at each phase as well as factor in the cost of development of each feature set into your budget and base it on your income.

There is a misconception that adding features will help improve your product or earn you more money. We falsely assume that the end customer has a perfect view of the options or entrants into your marketplace. I would wager that the average customer rarely does the kind of marketplace analysis you do, and likely cannot compare efficiently the few different options in the marketplace that they are aware of their pricing.

Many entrepreneurs (myself included) falsely assume that customers care or pay enough attention to your product and are sitting there chomping at the bit waiting for your next feature to buy your product. By and large your average customer is not waiting around for your product development roadmap to catch up to their dreams; they are looking for instant gratification. If they can’t find MOST of what they want in your product now, then they move on to your competitors, or buy now, and assume they won’t be getting that specific feature they are hoping for.

This theory drives a wedge into the idea that you should publish a calendar based product roadmap on your site publicly. You can, and maybe should, post your product development feature list, or roadmap on your site, but never attach hard dates to any of the features as that ties you to those deadlines. By tying your roadmap to an internal metric based schedule, you can more easily quantify investment of money and budget for each new feature. If you understand how much each customer is generating for you, and that each new feature will cost you $xx,xxx to develop, you can more profitably factor in your dev cost as part of your ongoing budget planning.

You might be screaming “But Brian, if we don’t release new features every so often, we won’t have anything to get buzz or press about.” I hear ya, but the amount of press you get for adding an incremental feature is minimal at best. Unless you are adding a groundbreaking new feature with each release, you’re likely going to get lost in the crowd of TechCrunch news anyway. So save your energy for focusing on improving your existing product, or optimizing your funnels, or refining your current product to maximize revenue in each cycle. Squeezing more money out of your existing products will likely result in a much better BUSINESS than constantly chasing an arbitrary date for new features that you declared before even launching your product.

Remember, your business plan won’t survive your first customer, so its better to be agile and learn from your customers and figure out what THEY really want or need and adapt to that, rather than set your milestones based on the cycles of the moon.

Image credit