Marty Cagan gave this very inspiring talk called Great Engineering, Failed Product at the Craft 2015 conference. The talk is about the huge difference there is in how the best companies produces products compared to how most companies produces products.
The root causes of failure (the process used in most companies):
1. Ideas: comes from two sources: Customers or sales
2. “Biz Case”: informal or formal
– how much money are you gonna make
– how much money is it gonna cost
3. Roadmap: comes from focus on higher value and desire for predictability
4. Requirements: – someone is responsible for gather requirements and document them for engineering
5. Design: user experience design
6. Build: enter engineers, this often the very first appearance of the agile implementation
7. Test: some companies even use “hardening” phases where all bugs are fixed. Having testing sprints being different than development sprints is madness.
8. Deploy: the final step
The above is anything of agile, this is basic waterfall!
What’s wrong with this process?
1. The source of ideas – the best source of idea is not included in the process. The customer and the executives of the company don’t have the knowledge of what’s possible with the technology. Also none of us knows what we really want with a technology product before we have had a chance to play with it. Consistently the best source of new ideas are the developers! The reason for that is that the developers work with technology every single day and know exactly what is now possible to build. The chrime in most companies way of working is that the developers aren’t even invited to the party where they need to be. Another great source for ideas are collected data. Platforms enables our customers to use our products in ways we didn’t imagine, and this is one the best selling points for public APIs. (For more see the article The Power of Customer Misbehavior or the book with the same name). At eBay the best innovation came from creating an environment where the customers could use eBay in ways no one had anticipated and then observing the customers being creative.
If you’re only using your developers to code, you are only getting half the value.
2. Business Case Fallacy
Business cases if you them right are actually useful. Unfortunately most companies to them to create roadmaps. They are supposed to answer the two questions how much money will we make and how much money will it cost. The problem is that you have no clue at this stage in the process since we just have ideas and they could be good, but probably not. It’s also at this stage when a product or project manager comes to the developers and says we are concidering doing this feature, how long would that take you. The smart answer here is: GO AWAY! This is where story points or t-shirt sizes came from, which in this case is a stupid compromise since we really don’t have enough information to estimate either cost or revenue.
3. The Roadmap
This is the biggest difference between the best companies and the others. Most companies thinks their job is to follow the roadmap and do the things in order of the roadmap. The best companies knows that it’s not. The problem with a roadmap are the two inconvenient trueth with a product: 1) at least half of the ideas that we build and deploy to our customers are not giving our customers any business value or the product is not usable, 2) the ideas that actually are good might take a long time to get to work inte product, might take several iterations to get the details right. Time to market is meaningless, time to deliver real value is really what we are after. A roadmap only helps us with time to market. Companies using roadmaps sees them as commitments and does not know how to handle the actual case of ideas beeing bad and not working or good ideas taking longer than expected to deliver value. A roadmap is actually dooming your team to get items out in your product that most of them don’t work or need more attention to get to work.
4. The Role of Product owner
Good product owner or product manager should have very deep knowledge of your customers and their users, they also have to have a good understanding of the data of your product, they need to understand your business, they need to understand the constraints of your product. In a modern team a product owner or manager is not the one who goes and writes requirements. User stories really aren’t very meaningful.
5. The Role of User Experience Design
Most organizations don’t staff the user experience design they need to. Most companies use some external agencies that give you mockups and wireframes. Companies like Amazon, Netflix and Google hires user experience design as fast as possible.
We need a team of missionaries and not a team of mercenaries. In the process described above, no one in the process get’s to add any ideas to the product development. Definition of insanity is doing the same thing over and over again and expecting different result, and the above process is insanity!
When Agile started to take form in early 2000 there seemed to be hope that developers demanded the insanity to stop and for them to get more involved in the process. But now it seems like the business people has outsmarted most of the developers by allowing them to have their standups etc. as long as you follow the roadmap🙂
The most important thing to change is to invite the developers to the ideation phase, not once every quarter, but every day! In good organizations, product owners, user experience people and engineers sit side by side and solves problems. That is what being Agile really means.
The problem is that most organizations talk about projects and not products. They optimze for a process leading to a final deployment with a party. You don’t wanna think in terms of projects with issues that should be resolved. You wanna think in terms of results. Outcome and not output. An outcome would example be: decrease the time it takes for a new customer to actually go live from 10 days to 10 minutes. A good team is given objectives like that and are expected to figure out how to solve it.
The process above is the slowest most expensive way of validating an idea as opposed to Lean startup that is the fastest cheapest way to validate an idea. Two most is not fast evaluate a Minimum Viable Product (MVP).
Continuous Discovery and Delivery
Lean startup is about separating the good ideas from the bad, but not in months but hours or days. This is what Product Discovery is all about and the output is validated ideas. The four questions we want answered during product discovery are: 1) will the customer actually buy this (or will they choose to use it), 2) can they figure out how to use it, 3) can we actually build it with the time and skillset that we have and 4) can our stakeholders support it (does it work in the market with regards to law etc.).
Instead of roadmaps use product visions that states where you intend to take the product in the next 2-3 years. From the vision use objectives (OKR – Objectives Key Result) and the whole idea is to drive the team from results. Visions applies to the whole company and objectives to a specific team. The purpose of discovery is to run a number of rapid MVP tests. An MVP is a missunderstood concept but the real meaning is an experiment that gives you insights on your ideas, it is not a product. If you treat your MVP as a product you are wasting valuable time to get your ideas validated quickly. Use the terms MVP test or MVP experiment to underline that it is not a product that you are developing. A good time will do 10-20 MVP experiments each week. The ideas that are good, those are the ones that actually makes it to the product backlog. It’s from the product backlog that the real software is delivered from with all the engineering aspects needed for a product. The purpose with the MVP experiments is to get a Produc/Market Fit.