The Root Cause of Product Failure

This is a summary of Marty Cagan's talk "The root cause of product failure" at USI

https://www.youtube.com/watch?v=jVbVEdF75PE

The issue is how you work not a matter of talent. This is for companies working on tech and you depend on consistent product innovation. Many companies that hire and build technology, are companies that were from before the internet era. The way they work consistently fails when it comes to tech products. How most companies work in the old way work (Bank, Telco, Insurance)

1.) Ideas

• Mostly come from executives.
• Sometimes from bigger customers

Marketing driven products are so bad a.) customers and executives don't know what's (technically) possible vast majority of great product innovations-> the customers pain can inspire not the solution -> the solution comes from the technology Consistently the best sources are not from customers or executives. If you have to pick one of the many good sources of product ideas -> consistently the best source are your engineers. b.) Biggest mistake is to not invite your engineers in the discussions about coming up roadmaps. This is a huge huge handicap. Why are engineers so critical? Engineers are in the best possible position to know what's just now possible with your technology as they use it every day. They are your single best source.

Not enough to just include engineers, but it starts with engineers.

2.) Business Case (Fallacy)

Need to prioritize to make sure you are working on the most important things first.

Management is asking questions because they want to prioritize the roadmap. This is also called Level of effort. This is basically estimating things. a.) How much money do think we are going to make b.) How much does do we think it's going to cost what we build

But at this stage you have no idea how much money you'll make, because it depends on how good the solution is. AWS for example thought they are going to make between 1 million and 1 billion $. Now this became a 8 billion $ business.

Estimating things at this stage e.g. with t shirt sizes is a compromise. Marty Cagan also calls this business silliness.

When you do tech products the most important thing what for you to remember is to have to know what you can't know and the truth is in tech products one of the things what we can't know is what the solution is going to need to be and we can't know how much it s gonna cost, because we don't know the solution yet.

The real issue is the roadmap.

3.) Roadmap

Prioritized list of features and projects, those things the business thinks they need.

Management wants to plan (What’s going to happen) and predict some level of what's going to happen in each quarters. Typically companies have a 3-month roadmap, some do have a 1-year roadmap which is really bad.

Two inconvenient truth about product a.) At least half of your items are never going to work with your customers.( We are excited but customers are not) -> Most of the time companies meet their objectives 20% of a time b.) The other half that could be great will take several iterations before they actually make money (usually 3,4,5,6 or more iterations)

Many organizations consider a roadmap as commitment.

Be stubborn on your vision and flexible on the details Jeff Bezos

• -> Roadmaps are the opposite of flexible
• -> Roadmaps are all details

Roadmaps are the root of so much evil.

4.) Requirements

Gather requirements, stage where you decide the idea on the roadmap might be integrated paypal, But what does that mean? For what do you need that? If the product manager is the person gathering requirements this is the opposite of a modern product roll. Modern product managers don’t want to work in roadmap/waterfall environments.

Reasons why?

• PM -> believes that roadmap is the wrong items, they don't feel ownership.
• Design -> Designer believes that this is the wrong solution, and is then only making the lipstick pig design
• Engineers -> are building something which they don't believe in

We need teams of missionaries instead of teams of mercenaries John Doerr

• Missionary -> Teams have to believe in the product
• Mercenary -> Teams are just there to implement someone else's idea

If you use engineers only to code you’re getting only half the value. We need engineers and designers to play a much more central role.

5.) Design

UX-Design -> Workflows and visual design

6.) Build

We build something, typically in an agile way, in sprints.

7.) Test

Make sure it works as it's supposed to work-> typically in hardening sprints

8.) Deploy

Launch your product to the customers

Roadmap is a list of output instead of business results

Example Integrate Paypal is not a goal it’s a tactic, that may or may not work Increase the number of customers is a reasonable goal. -> Paypal might be the solution to achieve that, the product team has to figure out if that’s the right approach.

This is a waterfall process. If you are doing it in this way, your company is anything but agile. If this is how you are working and are not getting the real beneftis of agile, its the fault of leadership not of the engineers.

You don't know nothing until you are live and put it in front of real customers. Slowest most expensive way to find out if something works out with customers.

• -> It's the opposite of lean startup tactics.
• -> In a real startup you would probably run out of money

Biggest problem is the cost of opportunity.

Continuous Discovery and Delivery (dual track agile)

• -> Lean Startup is one of the most famous set of techniques to do product discovery
• -> The purpose is to separate quickly the good from the bad ideas
• -> Once there is a good idea, we build product quality implementation (something that is scalable, accurate, secure and fast performant.)
• -> You need a strong product team -> outsourcing to india is not a product team -> you have already failed.
• -> Each team needs the big picture -> a compelling product vision and outcome based performance management system
• ->objectives and key results -> used by google facebook and linkedin
• -> Alternative to roadmaps -> prioritize business outcomes

When you are building a Minimum Viable Product, this basically is not a product but more rather an experiment, usually a prototype.

• Google Fake it before you make it
• AirBnb Build things that don't scale
• Facebook Move fast but don’t break things ( Marty Cagan may accidentally said this wrong, Searching the internet gives the facebook motto Move fast and break things)

To make you product market fit, you'll first need good answers to following questions

1. Would the user buy it or choose to use it?
2. Could the user figure out how to use it?
3. Can we actually build it with the skill set, time and the tech we have?
4. Can the different stakeholders (legal, finance, marketing) in your company support your solution?

You have to get good at this if you are truly a tech power product company or it’s just a matter of time...