Skip to main content

Product failed? Blame your company process before development


Agile. Agile is here to save your world. Do Agile and your product would never fail. Right? Wrong! Why? Agile can help with your delivery, but most product failures decided much earlier than delivery.


Think how your company makes product decisions. Now draw it. Now think again. Where is your delivery in the entire process? Where your devs, UX, and designers come in? Towards the bottom, right? By the time product concept goes into delivery it could already be a failure.

Some time ago I was writing about common problems resulted in product or company failure. It was mainly applicable for startups but surprisingly even big and stable companies experience very similar issues.

For every "Google Maps" there is a "Google Wave". For every "Apple Keynote" there is an "iTunes Ping". Why even in a big, resource-limitless companies those failures happen?

Hear Marty Cagan, product management veteran, speaker and author talks on this topic.


  • Big difference between how most companies and teams work and how best companies and teams work
  • Everything starts with ideas
  • 2 main sources: stakeholders and customers
  • For ideas to get on a roadmap they need to have some kind of business case
  • Why business case important for C-level? To have some kind of predictability in the business. To make sure the most important things are on the top
  • Business case = potential revenue vs costs
  • PMs\POs describe what needs to be done
  • Design provides an "experience"
  • Only then it reaches development. Plus tests and finally we deploy
  • What is this process? Waterfall , classical.

10 reasons why waterfall business process is doomed to failure

Source of ideas

Stakeholders and customers are two least valuable sources of ideas. Most valuable source = engineers. They work with technology every day and they are in the best position to know what is possible today.  Another source: data. But usually, data is not in the hands of people who provide ideas. Customers are not good in providing ideas for a product. They don't know what is possible, they don't know what they want until they see it.
Remark here; customers might not be a great source of ideas, but they definitely the key source of problems. For which we need to figure out solutions.

Business case

How much money are you gonna make? You have no clue. You can guess, but you never know! We don't know how much it gonna cost either. You can estimate, but still, you never know for sure!

Roadmap 

Execs want predictability.
2 inconvenient truths about product:

  1. Half of items on a roadmap never gonna work with customers
  2. For the half that could work, it will take several iterations before it makes money 

Because the process takes so long: startups run out of time, big companies run out of execs patience.
Roadmaps are details, not a vision.
Items on a roadmap = commitment. Half will not deliver any value.

Requirements

Is not a job of PMs. Product managers often asked to be project managers. This process requires a project manager, not a product.

Design 

As a designer, you receive something where lot's of bad decisions are already made.
This process is a mercenaries process.
A designer that receives wireframes = unhappy visual-only designer.

Development

If you only use devs to code - you lose at least 50% of their value. Dev is coming way too late in this process. And only here ... only that late ... Agile comes in. Only in a delivery. Which is probably only 10% of the Agile value.

It's a project based process. Where what we measure is output, not an outcome.
This process is about output. About effort. Not about the outcome. Not about the result.
Biggest issue: opportunity cost. The process is long, expensive and you can't have those resources back.

How best teams work 

  • Continuous discovery and delivery
  • Ideas (more sources) > discovery (lean, customer development) - PM work > Delivery.  
  • Best teams try out much more ideas than most teams. 
  • Vision and OKR (objectives and key results). 
  • No roadmaps - problems to solve instead. 
  • MVP tests. Experiments. 
  • Discovery: valuable, usable, feasible. 
  • Delivery: product-market fit. 
  • All about learning. 


So how do we prevent product failures? How shall we build our processes to minimize chances of doing wasteful work? 

Listen to Rich Mironov, who was doing product management before electricity was invented, great speaker and author. Rich talks only concrete, that come from the years of experience. 


Software law of gravity

  • Software profits are all about scale
  • No company ever has enough development capacity 
  • You can't outsource your strategy
  • Segmentation is strategic art of choosing customers who want the same solution

The causes of product failures, shortlist

  • Wrong problem - wrong solution
  • Marketing / Sales / Channels failures 
  • Undifferentiated or poorly positioned
  • Delivery problems (quality, late to market) 
Engineers cannot fix that with better coding. 

"Most of the success / failure of a product  is determined before we pick our first developer or fill out our first story card" Rich Mironov
  • Users understand problems but misdesign solutions 
  • Watch for confirmation bias
  • Validate BEFORE development
  • Business value error bars >> engineering error bars
  • Business value estimation is as vague if not more than engineering estimations 
Tech debt. As a PM I know I need to invest in it. I don't know how much and what benefits I am gonna have in the future. 

Portfolio budget is like a household budget.
Key: opportunity cost

Ask a sales rep why we closed the deal? Coz I am a great sales rep. Why we didn't? Coz features or price. Sales care about closing deals, not corporate goals.

Prioritization 

Hard to prioritize unlike items. A feature, quality, tech debt, customization for key customers. Pick the most important... Instead, group similar items. Assign the budget to groups.

Product portfolios

Try BCG matrix for product portfolios. 
Questions to ask when prioritizing portfolios
  • How many products\projects we can fund?
  • Major opportunity gets the new business unit?
  • Our Investment horizons? 
  • Do we need platforms? 

Wrap up

  • Watch out for your process before delivery
  • Business cases are promises not an insurance
  • Roadmaps are details not a vision
  • Continous discovery and delivery
  • Can't outsource product strategy
  • Validate before development
  • Set product\portfolio-level spending allocation
  • Deeply agile development is still critical 

Learn more

Comments

Popular posts from this blog

Fogg Behavior Model

Have you ever wondered why you do certain things? Why are some behaviors easy and joy to do while other not so? And your customers - have you ever struggled to understand their behavior?
BJ Fogg, from Stanford University, has created simple and powerful behavioral model for persuasive product design.


Product Vision: an elevator pitch for your product

On this blog, I write a lot about making data-driven decisions. But what if you just starting to think about your product? You have a vague idea and nothing more. No point to go for prototyping or even talking to customers as you don't know yet who to talk to and what to talk about. In such situation - start from creating a product vision.

2017: Less of How, more of What, and a little bit of Why

Focusing less on how (methodologies, frameworks, processes). For me, that was the most important product management trend in 2017. Surely, "Agile" talks are bottomless. Yet, I noticed a certain tiredness and dare I say, boredom among product community with regards to this topic.
- Maybe that's enough? Haven't we discussed that like thousand times? Shouldn't we all have that figured by now?