Tuesday, February 27, 2007

Chapter 4. Creating and Growing a Winning Product

- Isaac Bashevis Singer

How many babies will you take across the river?

Deciding what goes into a particular product version (or model) is more often a question of what you don’t include rather than what you do include. From rivets to dropdown list boxes, every tiny addition to a product costs money, but a feature that is of questionable value to a customer will cost more than average because a customer will spend a disproportionate amount of time trying to figure out the feature. This results in more service calls, more engineering cycles, and more distractions from the real value of your product.

There is a fable about a boatman transporting babies across a river. In addition to the weight of his own body, his boat can carry four babies. If he loads more than four babies into the boat, he increases the risk of sinking and drowning everyone. Wolves will quickly devour anyone who remains, including himself if he dallies long enough, so he can make only a single trip.

He is faced with a choice of (a) staying, in which case he and all of the babies perish, (b) taking all or most of the babies, which is just as calamitous, or (c) taking four babies across the river, leaving many behind to die.

Clearly, (c) is the only viable option in this, thankfully, theoretical set of options.

The fable illustrates the need to make a tough decision when one needs to. The boatman must look at those sweet little babies and decide which to leave behind. And there is the pressure of time.

The Product Manager as boatman

Let me offer an adjusted model of the boatman’s dilemma to make it a more applicable metaphor for the challenge facing the Product Manager:

You can make repeated visits across the river, and there are no wolves. Your competitors face the same challenge. The winner is the boatman who gets the most babies, alive of course, across the river within the time allotted.

There is still plenty of time pressure, but there is clearly an optimal path available: Transport four babies at a time across the river, making as many trips as necessary; paddle as fast as is safe, without burning up too much energy too early.

The inexperienced Product Manager will often yield to the pressure to “take many babies.” The boatman, at least, knew that four babies was his absolute limit. For the Product Manager, it is a little murkier; it is difficult to determine how many, and which, additions, a particular product version (or model) can support. Add too many, and the version may become unstable; add too few, valuable time and opportunity are lost. Features tend to be less valuable than believed, and more costly than predicted. As obvious as this might sound, a core objective of the Product Manager is to pick just those right product additions, but not too many, to include in a given version or model, and to hope and pray that the competitors’ Product Managers make poor choices.

  • Features are less valuable, more costly and take more time to create than predicted.

Sorry, sir. That was the demo model

Many of life’s experiences turn out to be less exciting than they appear in the brochure. Additions to a product are no different. You thought a feature was going to “send the competition running for cover,” but when did it ever turn out that way? It was also more difficult to add the feature to the product and it took longer than expected. Consequently, it cost more to make.

It’s all in the trade-offs

Let us do another thought experiment. Picture a Product Manager looking at the list of additions he is considering for a product release. The list has twelve different additions ranking in value from most valuable to least valuable. He does not yet know how many of the twelve he will add. It almost certainly will not be twelve, nor is it likely to be one.

Figure 9 – Product additions are usually less valuable than believed

The chart in Figure 9 contrasts what someone might believe the value of an addition to the product to be with what the actual value turns out to be.

The Product Manager also knows that the more he adds to the release, the more costly the production will be; there is good sense in biting off only enough to minimize production risk. For the same reason, if he does not add enough, the product release may fail because there is not enough return on investment, or not enough quality to support the feature additions; there is a different risk in adding too little. All obvious stuff, you might say, but most Product Managers get this wrong.

For each of the twelve additions, he associates an incrementally larger risk to represent the geometric increase in risk for each subsequent addition. He also wants to represent the increased risk of adding too little; hence, there is a higher risk associated with the first few additions.

Figure 10 – additions to a product are more costly than predicted

The chart in Figure 10 contrasts the believed costs of the same twelve additions (illustrated in Figure 9) to the product with their actual costs. Consider each column, or point, to represent an addition to the product. The first addition or two have high costs associated with them because (a) a “light” product release may cost more to market and (b) there are fixed costs with every release no matter how little you include. Beyond the first couple of additions, each incremental addition to the product release adds increasingly more cost. In other words, as you pile more and more into a given product release, the more expensive, and at a certain point, prohibitively expensive, the release becomes. Everything costs more than we thought it would cost because, well, c’est la vie.

Big deal”, you might say, “so it costs a bit more than we thought it would. It’s still great stuff to add to the product so we should add it anyway.”

For a given product release (or model), the value of an addition to the product must exceed the cost of that addition, or we should not make the addition. Note the cut-off point in the next two figures: As long as costs remain below value for a given addition, it makes sense to add it to the release.

The mind that is wise mourns less for what age takes away; than what it leaves behind.

- William Wordsworth

Figure 11 – Optimistic scenario – we invest in 50% of our candidates

In Figure 11, we look at the top twelve most valuable candidates for inclusion in the next year’s model of our product. (Addition 1, on the x-axis, offers the most return while addition number 12 offers the least return.) We compare the expected return to the expected cost. The costs climb with each addition to a product release. The more we add to the product in a single release, the more complex the release becomes which adds cost in the form of risk and management beyond the addition itself. In other words, when you double the size of the release, you more than double the cost. The size of the release is sometimes referred to as “project scope”, and experienced engineers and managers will tell you that costs increase geometrically with project scope.

From the chart in Figure 11 we might assume that the top six additions are worthwhile, because they cost less than the expected return; thus we decide to invest in six (50%) of them in the next release of our product.

However, when we discount for optimism and compare actual return with actual cost, we see a different result. Only the first two or three additions are worthwhile.

Figure 12 – A more realistic scenario – we invest in only 25% of our candidates

Figure 12 illustrates the notion that when value and cost estimates are slightly discounted, the data suggests significantly fewer additions be included in the product release. Addition 1 (on the x-axis) is considered the most valuable and addition 12, the least valuable.

Therefore, the optimal number of additions to make in our theoretical release should be three, not six. This 25% investment promises about 50% of the return from all twelve candidates.

ë When we are conservative about return-on-investment and its associated costs, we make significantly different decisions about how much to include in a product release.

If we were to include six additions in the product release, as suggested by the optimistic scenario in Figure 11, the benefits from the first three additions may be wiped out by the next three less worthwhile additions.

The lazy man’s load

My mother points out that a lazy person will overload their basket in an effort to minimize the number of runs they will take. A diligent worker knows that there is an optimal amount they can carry in a single run, and that amount is considerably less than what they are theoretically capable of. They pace themselves, and save a little wear and tear on their body in doing so, avoiding backache on the later runs.

The lazy man’s load might also be described as the young person’s load or the inexperienced person’s load.

The hare and the tortoise

In 1994, I took it upon myself to walk the Wonderland Trail that circumscribes Mount Rainier in Washington. It is almost one hundred miles long, and comprises of mostly inclines and declines the whole way round. At least, that is how it seemed. Before I started, I checked in with the park ranger to pick up my permit. As I stepped out of the ranger’s cabin, a group of perhaps six young hikers was stepping in to the ranger’s station to pick up their own permits. I had perhaps a five-minute lead on them. An hour or so later along the trail, I heard them approach from the rear, getting closer and closer until they reached me. I stepped aside for them to pass, as they were moving considerable faster than I was. They were full of excitement and youthful energy. They had the latest professional hiking gear from the best hiking stores in town and they were not going to waste time by going at the old man’s pace. They quickly disappeared into the distance ahead of me on the trail.

Another hour passed as I inched my way along the trail. I turned a corner to see my six fellow hikers stopped on the side of the trail. A full three of them were nursing blisters. Two hours into a 50-plus-hour hike, they were in pain.

Just as there is an optimal amount of gear to take with you on a hike, there is also an optimal speed. Getting it right means keeping your strength and power for the long haul ahead of you.

In product management, there are no short hikes of any real interest or value.

Remember, there is always another release. If you get the right amount included in a given release, you can provide a satisfactory return and kept costs and risks at an optimal level. In addition, you are less likely to exhaust a future release by spending resources making repairs from its preceding release. From your experiences of the just-released product, you will have an updated and expanded list of candidates for the next release, and in time, you can slice another 25% off the top of that list in the same way.

The cumulative effect of several solid, timely releases in a row can put your product far ahead of the competition. It is better to ship a solid improvement every year than an ambitious release every two years.

  • The longer you wait to ship a model or a version, the higher the bar your customers expect you to jump over.

Often, companies try to stuff too much into a given release, or go to the opposite extreme, adding little that is new to a release, opting for “perfect product quality” in an attempt to protect what they have already achieved.

Boring as this sounds, the Product Manager should be playing a wait for the other guy to get this wrong competition, rather than an I will add something brilliant to steal the market competition. In my experience, strokes of brilliance are rarer than hens’ teeth, but getting five optimal product releases out in a row is doable and gives you a real chance to make your product a success.

Everything for the long term

I

It’s rarely do-or-die in a single release. I have heard variations of the doomsday scenario where, if we “Don’t stuff such-and-such…” into a given release, the competition will wipe us out. If that truly is the case with your product, I suggest you invest your life energy elsewhere. Real products with real futures and possibilities support many releases over a decade or more. A Product Category with a lifespan measured in decades is infinitely more valuable than one measured in years. Long-life Product Categories reflect pervasive, persistent and reoccurring problems that customers need to solve repeatedly. When you invest money and time in solving these problems, you will be rewarded repeatedly for your efforts. Only long-life Product Categories can provide such a return. Continue to invest as long as you can foresee at least ten more years of sales.

  • Invest only in Product Categories you expect will last for at least another ten years.

1 comment:

limeade said...

This chapter is the most powerful, in my opinion. It also implicitly celebrates shorter development cycles. We have monthly releases, and every month I am sad that we are only doing 5-10% of what I know we need to do to kick butt. But that is a very good thing, and forces a calibration with market needs every month.