I thought about this discussion all weekend because, after many years (6+) of running Agile Development across several organizations, and being both a CIO and CTO (going on 15 years) with product development experience, I have rarely (but not never) seen a Product Manager or Product Owner drive for the simple flux capacitor. Somewhere, in the mix of developing the market opportunity, looking at the competitive landscape, gathering feedback from stakeholders, and ultimately, defining a product vision that delivers business value, the principals of simplicity and speed to market get compromised.
Thinking "Agile" - The Why, Not the Why Not or How
Agile development defines "how" product owners and technologists can deliver incremental value to customers. Break features to stories that deliver business value, prioritize the stories that deliver the most value, insure that your sprint delivery hits "done" criteria so you have a theoretically shippable product at the end of every sprint.
The problem of course is the "why" - why deliver a smaller feature set? Why is it better to add components incrementally?
The difficulty for many organizations is that they better relate to the "why not". I can't easily prioritize feedback from customers or sales, so to maximize the opportunity to sell this product I need almost everything. I can't easily develop marketing material against a competitor if I can't match up feature to feature. I'm not sure if there will be sufficient funding available for ongoing development. I don't know how to work with a designer to build up the user experience iteratively. I need to develop the big strategy to gain organizational momentum and secure funding, but don't know how to sell the baby steps. I don't have an easy mechanism to survey customers incrementally. ...
Why a Minimal Marketable Feature Set
The answer to "why" a minimal marketable feature set and why incremental comes down to some very basic principles.
- Selling a product is most often "better" than having no product - What is your target demo to close ratio? Assume that you will achieve a smaller percentage of target in the first several months after the product has it's initial release. Run the numbers. Do you really want to write off this revenue?
- Incremental is the organizational "steady state" - Engineering teams are not the only ones who better respond to incremental product deliveries. Sales, marketing, customer support all have to absorb the new offering and must develop processes, train individuals, establish metrics, etc. in managing the new product. Guess what - customers exhibit the same behavior! They can't easily absorb everything at once especially for products that roll out to lots of users. Think back to the first time you used a word processor - did you learn all its features before you started using it, or did you learn how to type, spell check, print, and save before diving into formatting, layouts, styles, embedding media, etc.?
- We are all just not that smart - Why is it that 64% of features never or rarely get used? How many people in the organization can be effectively tapped into product definition and review? How strong is our customer survey methodology? How capable are your teams at developing superb user experiences? We can be smarter through feedback, and the best feedback is what customers tell us about the product in market. Why couldn't we get a demo? Why did they pass after demo? What features are they actually using? Why aren't they using the others? This real quantitative and qualitative feedback around and better decision making and prioritization around it is what makes us smarter.
Where does that net us? The simple answer is, one must challenge, challenge again, and challenge again the definition of minimal marketable feature set. Think flux capacitor. Remember the death star was destroyed by one critical defect.