I sympathize with Marty Cagan’s article about product fail. My world of product development is not as perfect as I want it to be. Therefore I suffer. From Marty’s article, two questions remain: first, why do all people involved behave the way they do, producing sub-optimal results? Second, what can I do better? Personally. Concretely.

Recap: the causes Marty Cagan sees for product failures

Let’s start with a quick recap of the root causes Marty sees for product failure. He singles out his top 10 causes that can be generalized in 4:

• Working (too long) on the wrong problems. Stakeholders pick the wrong ideas in the first place, validation of customer value happens too late, no agility in the first part of the process. As a consequence better opportunities for the ressources at hand are foregone.
• Picking the wrong indicators for creating certainty and measurement of achievement. A business plan upfront with unjustifiable sales & cost, roadmaps with output (features) instead of outcome, project management (controlling of input and milestones) instead of product management (user value and outcome)
• Not accepting trial and error as part of product developmemt. The majority of ideas/feature produce no significant results and getting products right takes more iterations than one hopes.
• Treating product teams as mercenaries. They are just told what to do rather than leveraged earlier on in the process.

It is tragic. All people have good intentions. They share the common goal of building successful products. Nobody wants to be unsuccessful. Still too often, it doesn’t work out. Why?

Going one level deeper: why do these causes occur?

Let’s try to understand the behaviour of executives and staff with respect to product management.

Looking at executives

One part of an executive’s job is to give direction. In product development, giving direction causes trouble if the executive is not aware of two facts: first, he has to find the right level of abstraction in defining the WHAT for the team. The WHAT are definitely not features, but more problems-to-solve or business areas. Secondly, it is even more important that the teams understand WHY they should do something. The job of the executive is not only to tell the WHY, but to watch out that the teams connect to it. This is a subtle, yet important difference.

Even if an executive is aware of those two facts, it takes continuous practice not to do the work of your directs and being understood on your intent. Some executives miss the humbleness that they, too, have to practice every day.

Executives do understand that uncertainty and complexity have been increasing. And rationally, they want to be be more adaptive and flexible.

Still, deep in their heart, they often have the urge to control things. They feel responsible! So they want to make sure that everything is on track. They want to base decisions as much as possible on analysis and want to have plans to identify deviations. There is a tendency to look on stuff that can be measured. This is also the reason for the fact that quantifiable results are higher valued than more illusive learning results.

Next to the personal longing for certainty, there are also some very concrete drivers to push for control. Executives are (rightfully) measured to deliver results in terms of revenues and profits. And they are expected to deliver fast. Therefore, there is an incentive to push towards quick wins instead of building up a long term value preposition towards the user.

Looking at staff

The largest issue arises when a team don’t understand the context they are working in. A product manager, for example, is not in the business of self-fulfillment through his product. He has to find the best way how the product serves its role in the broader context of the company serving the customer. Teams should work autonomously, but must not confuse self-organization with self-direction.

If teams are united behind their mission, they can move mountains. I have seen that myself. If not, performance will suffer. Lacking commitment and ownership leads to mediocracy.

Doing product development is for pros, not amateurs. It takes a lot of experience. Being agile and applying lean methods is even more difficult. Many teams want to do it, but don’t know how. Valuable tools become ideology where teams play to the book rather than live up to the core of the tools.

Lack of skills and experience is sometimes not openly appreciated and worked on. As a consequence, executives give teams less responsibility then the team expect, but don’t communicate it properly. This creates frustration with the teams rather than productive learning.

The table below summarizes the reasons I see why the issues in the product development process occur:

Now what?

So what do I try at XING to overcome those issues?

I don’t have a perfect solution. Far from it, I am aware that becoming better as an organization in product management takes time and perseverance. I am grateful to work with very talented people in an organization that practices modern forms of product management. What follows are the things that I try to focus on in my daily thinking and doing.

Continue making business plans

Planning is everything, the plan is nothing. Dwight D. Eisenhower.

It is very important to think systematically before you start anything.
Business plans are a way to write down your thinking.
This comes before you start product development in the narrower sense. Still, I would not call it a waterfall approach like Marty does. At XING, we think in three horizons, depending on the maturity of the product. If a product is well established with proven KPIs, you are able and should define targets for those KPIs on a regular basis. The degree of uncertainty is limited, Steve Blank would call this scaling a proven business model. You look at revenues and profits.
Products in the second horizon have the potential to create relevant revenues in 2 to 3 years. But you don’t know yet. From a financial perspective, you allocate cost in a portfolio of initiatives and should define milestones for defined customer validations. In order to decide which product initiatives to pursue, you do have to think about a revenue potential, estimate an order of magnitude for profit margins, and have an idea if there is an user problem worth solving. Therefore you do market research, look at competitors, and conduct early user insights research. And then you have to decide.
For the third horizon, the mental model is research. You have to watch out for new trends and think about how the world might look in 5-7 years. Anything you do in this area should be accounted as recurring cost. Still, you have to decide upfront which trends you want to look at.
It is important that everybody does understand the different degree of certainty of the business plans in order to use them effectively.

Create clarity of intent upfront

As we have seen above, for products in horizon 1 and 2, management and teams need a mutual clarity of intent upfront. That means providing context by defining the WHAT (which problem to solve) and the WHY (the reason for solving this problem and the right of our company to do it). This is a collabarative and iterative process between management and the product team. Only if the managements approves and the team commits the intent will we have a good enough chance to be successful. It is only through this alignment upfront that the team is enabled to find the HOW in an autonomous way, reacting to all the unforseen things that will happen. And to find meaning in what they are doing.
At XING we started to use a template called Auftragsklärung (assignment clarification exercise – it happens rarely that the Germans have the shorter word). Be aware: this is much more about the process and precise thinking than the final piece of paper. Remember Eisenhower.

Increase insight productivity

I think of insight productivity as insights per time and resources used. It means getting as much traction as possible towards your defined intent. I try to help my teams getting this traction with a couple of basic tools. This is my way to secure good results as much as possible.
First, I ask for simply putting inputs (resources to be used, analysis to be conducted, concepts to be defined), outputs (anything shipped in front of a user) and outcomes (indicator of user behavior and ambition level of change) on one sheet of paper. People get more focus on outcomes and become aware of the tendency to talk about input and output (only).
Secondly, I try to educate people about the nature of a good definition of outcome. A quantifiable indicator with an ambitious target is not something teams should avoid, but happily embrace.
The intent of a product is always a complex phenomenen that is described in more qualitive terms. Teams cannot operate and measure progress at this level, thus cannot celebrate achievements. Picking a few indicators that are measurable helps in this respect. One has to be aware though that an indicator is always a simplification. It may very well be that the team has to change focus and select another indicator later on. For the chosen indicator, you then have to define an ambition level. The ambition level serves two purposes: define the order of magnitude how you want to think about the solution. For example, reducucing a web loading time from 6 to 3 seconds is a different task than going from 6 seconds to 0.6 seconds. In addition, the ambition level has to be high enough that it justifies the use of the planned resources.
Thirdly, I push teams on thinking and testing. They should always generate a broad enough set of options, use analysis to prioritize, identify critical assumptions, and user test those assumptions.

Increase capabilities

A company and its leadership have to make sure that individual learning occurs. As a first prerequisite, the leaders have to give its staff clarity where they stand. Based on this joined understanding, task have to be allocated such that everybody operates out of the comfort zone, but not in the panic zone. And the company should offer training programs and build a community of practice within the company.

Lastly, everybody should seek to strengthen the capacity for (self-)reflection. It is only when we are aware what is happening that we are able to change.

Increasing capabilities is maybe the most difficult task as it forces everybody to get out their ‘social’ comfort zone and do things on top of the regular tasks. Long term, however, it is the most important one.

---

I hope that this article helps people to understand some patterns that might occur in their product development. And then change it for the better.

Marty Cagan: Product Fail