The Five Key Mistakes in Product Management

The Five Key Mistakes in Product Management

This post is also available in: Español (Spanish)

There are five key mistakes most product organizations make which prevent them from achieving their growth goals and leading their market. These failures significantly reduce the probability of delivering products with a good acceptance in the market.

We know that between 40% – 50% of products fail to achieve sufficient market acceptance.

Let’ take a look at those errors …

1 – Organizational Design

First reason why many companies fail in building products is their organizational design. They are not organized around value but around silos or egos.

There exist three basic organizational design patterns, two of which are dysfunctional and prevent your business from delivering awesome experiences to your customers fast and sustainably, growing and leading your market.

Organizational Pattern #1 – Proxy Product Managers

In this scenario you have the Business Units asking Product Managers to deliver on an already approved Business Case. So, basically Product Managers manage the high-level delivery roadmap whilst Product Owners and their team administer the detailed backlog.

Even if you are doing Agile in the teams this is pure waterfall, with silos, hand-offs, division of responsibility and wishful thinking. Many companies claim they are agile just because teams are doing Scrum or delivering software iteratively and incrementally every few weeks.

Organizational Pattern #2 – Proxy Product Owners

This is an evolution (for the better) of the previous approach; however, instead of having separate roles in delivery functions, you just have one, typically the Product Owner. But, still a delivery role.

Organizational Pattern #3 – Product Organization

In this setup we have Product Managers with total responsibility for the development of a product or product line. The Product Manager leads a small, dedicated team that creates the product concept, develops the business case, leads the technical design of the product, manages the development process, coordinates with production engineering and sales/marketing, and takes the product into production.

If you are in patterns #1 or #2 you have a great problem. You are usually delivering late stuff nobody wants, with a lot of drama and friction.

2 – Cognitive Biases

There are about 150 cognitive biases that make us take irrational decisions due to some automatisms in our brain.

The only way to prevent those biases from impacting our product development process is to iterate, implement short feedback loops in contact with customers and the usage of data to inform our decisions.

Many cognitive biases have a negative impact in how companies define their strategy and think about new ideas and implement them. But, probably the most important ones are Innovator Bias and Confirmation Bias. Which can easily be avoided by adopting the right processes.

Innovator Bias

Falling in love with your idea or your solution without validating what problem will it solve. It is typical of new technologies or inventions finding a problem to solve. But, a great idea that pops up while having a shower doesn’t necessarily translate into a new growth area for your business, there are many interconnected variables that need to be solved.

Your idea might be great, and I agree that customers don’t know what they want. As Henry Ford or Steve Jobs would. But, even in those situations, when you have a great idea, take a step back and see what problems and underserved needs it is addressing, make sure there is a market big enough to build a business model upon it, and try to clearly differentiate from current solutions and competitors with a unique value proposition.

All this you have to do iteratively and incrementally by adopting the scientific method and testing your riskiest assumptions continuously until you can demonstrate market traction.

Confirmation Bias

This is the tendency people have, to seek, interpret and remember information that confirms their beliefs and opinions.

A confirmation bias happens when people give more weight to evidence that confirms their hypothesis and undervalue evidence that could disprove it.

3 – Putting the Cart Before the Horse

This is the most usual mistake traditional companies make: scaling before having objective evidence that you have built something people want and there exists a reasonable market for your product (Product-Market Fit).

Usually, there is a goal, project or idea. Then, companies create a business model out of the blue, fund the whole thing based on estimates and guesses on the future, put the whole infrastructure, resources and people together upfront, and then they start building like crazy.

When working with traditional businesses we ask our clients to approach product development the same way we do for innovation or startups. Management should act as Venture Capitalists using innovation accounting to measure progress until Product-Market Fit is reached, and then drive growth.

  • You don’t need 15 developers if you haven’t yet validated product-market fit, you will find something better to do for them.
  • You don’t need the budget for the year assigned to projects and products from day one.
  • You don’t even need a scalable architecture from day one either. Your infrastructure needs to grow alongside your customer base, otherwise you will be burning cash like crazy.

Some entrepreneurs also make the same mistake of jumping into scale phase before achieving product-market fit. This is a huge mistake because scaling sucks cash like hell and if you don’t have product-market fit you are doomed.

The way traditional business operate, assign budget and resources and incentivize management prevent them from working this way, which is in turn the cause of their decline and ultimately becoming irrelevant.

4 – Just because you can build it …

This is the well-known pattern of waterfall and still today, of many so-called Agile companies. They basically start building without understanding what problems they are trying to solve beforehand, for whom, and if there is a market big enough out there willing to pay for it. 

Here, the problem is a mindset of delivery. A mindset of output over outcome.

The measure of success and productivity is working software to production, regardless if that is solving a problem or providing any business benefit at all. Like a feature factory.

In this scenario, you don’t know if there is a problem worth solving and if your solution fixes that problem, but you are already building software.

Bear in mind, building software is the most expensive thing you will do, so try to reduce it as much as possible. Here, the agile principle of “working software is the primary measure of progress” doesn’t work, the only measure of progress is validated learning.

Many companies make the mistake of deciding whether to make an investment or implement something just based on the cost. Which is actually the less significant of all the variables in a business model. Typically, the most significant variables are the size of the market and the rate of adoption. So, instead of asking how much is it going to cost, ask how much are we going to sell and how fast.

Just because you can build something doesn’t mean you have to. Ask yourself questions such us:

  • What problem is this solving?
  • For whom? How many people?
  • What is the alternative in the market?
  • What does the price have to be in order to be profitable?
  • Is our target customer willing to pay that price?
  • What are the technology and operational implications of that price?
  • Etc, Etc, Etc, …

5 – Wishful Thinking

Wishful thinking means making decisions without data or operating blindly. This is a widespread disease of all sorts of companies and at all sorts of layers in the company. From strategy to operations.

Investment decisions are made based upon 50-page business cases full of lies and assumptions. There isn’t a framework for deciding which projects get funding or which are decommissioned and the HIPPO has the final call.

Product Owners and Product Managers schedule work based on who shouts louder, artificial urgencies or opinions.

Our Approach

What we suggest in Lean Product Management is that you should think of a Product Owner as a Product Manager with modern skills like Lean Startup, Behavioral Economics, Customer Development, Analytics and Innovation.

Once you organize around products, what you have to do is put in charge a competent Product Owner that can drive business growth. But, getting such experience in the market is difficult, time consuming and very expensive. So, we have designed a program that will enable you to grow great Product Owners in your own company with the help of our expert product coaches and consultants, saving you time, money and headaches.