WTF?! No-BS PM -- Product Strategy: Turn Your Vision into an Action Plan

Doing the right things is more important than doing things right.

The success of every organization depends in large part on how well senior managers are able to integrate mission, vision, values, and strategy into a project portfolio that meets the requirements of the marketplace. Although it seems obvious when stated, managers sometimes forget that it does no good to accelerate projects that were ill chosen in the first place. The only result such actions achieve is a more rapid failure!

Strategy is the overall approach that the company takes to achieve its mission.

Tactics are those steps taken to implement strategy.

As we have emphasized so strongly, the first question that must be asked by any organization-whether for-profit or not-for-profit-is, What is our business?. All too often, in their zeal to succeed, man agers forget this fundamental question. They try to be every thing to everyone, and end up confusing their customers. In books on branding, experts provides examples of successful companies that forgot who they were and lost their way. It remains to be seen if this will be true of Amazon.com. They were highly successful in establishing them selves as an online bookseller. Now they sell CDs, apparel, and electronics, trying to redefine themselves as a highly efficient online store where you can buy almost anything you want.

It’s outside the scope of this guide to go into de tail about defining a mission and vision for your organization, but until you can express it in concise, clear language, you are not ready to start accelerating your projects. Thus the following overview.

MISSION, VISION, AND STRATEGY

In over 30 years of working with organizations on their performance issues, we have found that many managers are not clear about the differences between mission, vision, strategy, tactics, and logistics, so be fore we go any further, let's clarify these terms. A company's vision can be thought of as its self-image. Your personal self-image is how you see yourself, and how you think others see you. It’s often a surprise to individuals to learn that others don’t see them the same way that they see themselves. E.g., you may think of yourself as warm and friendly, and learn that others see you as cold and impersonal. As another example, we are fairly strong introverts, but people who attend my seminars don't believe this. They can't comprehend that so outgoing an individual in the seminar room can become a very quiet, re served person outside of it.

A company's vision can be thought of as its self-image.

It does no good to accelerate projects that are ill conceived in the first place!

In any case, let's say that a company's vision is what management wants the company to be, and how they want customers to see it. The mission of the organization is to achieve that vision-to take steps that will cause customers to see the company in the desired way.

Strategy is the overall approach that the company takes to achieve its mission. A couple of examples may help clarify this. Consider a company that aspires to be very large, because management believes this is necessary for its success.

Growth can be accomplished a number of ways. One is to be very aggressive in developing new products that meet market needs, based on very good information about market requirements. Another way is to grow by acquiring other companies that fit within the family of products produced by the company.

One growth strategy that we have observed we have dubbed the predatory approach. For instance, a large drug chain goes into a market and either buys up existing small pharmacies or prices their own products so low that local stores are forced out of business. In another case, a very large camera store chain moved into an area, then approached a quite successful local store with the ultimatum that they could either sell their four locations to the chain or be run out of business. The local store sold out. (I don't approve of this strategy-I am simply describing it as an example.) Tactics are steps taken to implement strategy. As an ex ample, if you decide to grow by acquisition, you must arrange for financing your purchases, unless you have access to a lot of cash. Logistics has to do with supplying your employees with materials, equipment, and an adequate work environment so that they can perform as required. This is an area sometimes overlooked by managers. Let's see how all of these fit together in managing a product-development project.

AN EFFECTIVE METHOD FOR MANAGING PROJECTS

In order to make it easy for everyone to understand the steps involved in managing a project, I have developed a flow chart that shows the steps and the sequence in which they are taken. ( You can download a free, color version of the chart) The chart is shown.

As is shown by the chart, there are five processes involved in a project. These are initiation, planning, execution, control, and closeout. In the model you will see that planning is subdivided into planning strategy and implementation planning. Also, as part of final closeout, a lessons-learned re view is held to aid improvement of future projects.

Initiation

The most critical process is definition. It’s here that the seeds of failure are sown in perhaps 80 percent of all projects. As a former NASA program manager has written, "The seeds of problems are laid down early. Initial planning is the most vital part of a project. The review of most failed projects or project problems indicates the disasters were well planned to happen from the start". As stated earlier in this section, it does no good to accelerate a project that is heading in the wrong direction. We will return to this theme later in the section. For now, we want to give a high-level overview of each process.

In the definition step, a project team must be very clear on exactly what they are going to do. If developing a product, exactly what kind of product? What are the specifications?

There must be a shared understanding of project vision, or problems will result.

Who are the customers for the product, and what do they expect of it? These questions help the team clarify the vision-their mental picture of what the final result will look like, how it will perform, and so on.

Unless there is a shared understanding of the vision among all team members, senior managers, marketing, and other stakeholders, you can be sure that problems will result.

The mission of any project is always to achieve the vision, so a clear vision is the starting point. Once these two have been worked out-and only then-the team can turn to step three of the Lewis Method and discuss strategy.

Planning Project Strategy

This part of project planning is often overlooked. It’s assumed that the team knows how to go about the job without paying much attention to strategy. Or they simply fall back on a strategy that has been used in the past and been found to work. However, the old way is not necessarily the best way, so all possible strategies should be examined and the best one chosen for this particular project. We'll discuss how this is done later on.

Implementation Planning

Once a project strategy has been chosen, tactics and logistics must be worked out. Exactly what steps must be taken to execute strategy? What kind of materials and equipment must everyone have in order to do their work? How long will each task take, in what order are they completed, and who will do them? How much will they cost? These kind of questions must be answered in this step.

Execution and Control

Once a proper plan has been developed, work can begin. As the work is done, progress is monitored and compared to the plan. Are we where we are supposed to be? Are we on schedule, on budget? Is the performance of components under development acceptable? At any point where there is a deviation from plan, steps should be taken to get back on track. This is how control is exercised.

Learning and Closeout

Once all work in the project has been completed, a les sons-learned review should be conducted by asking two questions. One is "What did we do well?" The second is, "What do we want to do better next time?" Notice that we don't ask, "What did we do wrong?" The reason is two-fold-first, there is a possibility that nothing was done wrong, but we know that we can always do better next time.

Secondly, people get defensive when you ask what they did wrong, and they tend to hide their mistakes. You can't learn from errors you don't know about, so it’s a good idea to avoid any suggestion that people may be blamed or punished for errors they made.

THE MODEL IN MORE DETAIL

Now that you have a general understanding of the model, we will move on to some more detailed comments.

As stated earlier, this is actually the stage where many projects fail. Everyone assumes that they all understand and agree on project definition, vision, and mission, and this assumption simply proves to be incorrect.

I worked once with a team that had been given the job of cost-reducing a component used in an appliance. For nearly 10 years they had repeatedly refined the component, taking out 5 cents here and 25 cents there, until there was virtually no room left for further cost reduction. As we discussed the problem, it became clear that what was needed was a totally new concept for producing the component-not a rehash of the old design. They had already worked on the job for a couple of months before this realization occurred, and had struggled because no one could agree on exactly what they were trying to do. Yet they had begun the job believing that they were all in agreement.

This is so common that many stories exist about the failure of groups to manage agreement and disagreement. It’s called the "false consensus" effect-the belief that everyone in a group agrees, when this is not true.

The important thing is to spend sufficient time discussing a project so that everyone can be certain that a true consensus exists. Note that not everyone needs to completely agree with the majority on the issue, but every member of the team must be able to say, "While I don't totally agree with all of you, I'm 100 percent willing to support the majority position." This is as close as you are likely to get to true consensus.

One point about mission statements. The mission of a team is always to achieve the vision. So vision must come first. What exactly is it that we are trying to produce? Once this question has been answered to everyone's satisfaction, the mission statement answers two questions:

1. What are we doing?

2. For whom are we doing it? Answering "for whom" forces the team to think about the customer. Of course, there is some circularity in all of this because you can't define what you are doing unless you know your customer, so the mission statement simply reiterates what you already know.

PROJECT STRATEGY

Note that this section is on product strategy, while this section is on project strategy. It’s important that everyone understand the difference between these. Product strategy is the development of an approach to produce a mix of products that customers want and that gives the company a competitive advantage in the marketplace. Projects are conducted to develop products, and project strategy is the overall approach or game plan that will be employed to develop that product. We will discuss product strategy later in this section.

There are two possible kinds of strategies in a product development project. One is the overall project strategy. The second is the technical strategy. For simplicity, let's say that you must feed a group of people one evening. Asking your self how you can do this, you arrive at the following possibilities:

1. Cook the food myself.

2. Take everyone to a restaurant.

3. Have the food prepared by a professional caterer.

4. Have a "pot luck" meal at which all guests bring a dish of some kind and share.

From this list of possible project strategies, the one that appeals to you is to cook the food at your home. You then consider how you will actually go about this, and five approaches seem possible:

1. Cook using a conventional range.

2. Have a backyard barbeque.

3. Microwave the food.

4. Have a fondue party.

5. Have a Chinese-style "hotpot" dinner.

From this list, you decide on a backyard barbeque. It will be fun. People can stand around the grill, even participate, and the weather is expected to be nice.

Then, the afternoon of the dinner, you get out your grill.

The last time you used it was last fall; it’s now May. To your dismay, the grill has developed rust, rendering it unusable, and you have no time to shop for a new one. What to do? Perhaps cook the food on the range? No, that won't be any fun. Fondue? No. Hotpot dinner? No. Microwave? Absolutely not.

This leaves no room for doing it yourself. There is no time for a caterer, and it’s too late to tell people to bring their own food, so you are left with only one alternative-take everyone to a restaurant.

This example illustrates the fact that project and technical strategy interact. In product development, it may be that you want to employ a certain kind of technology, but you have no internal capability for it. You must either develop that capability or contract out that part of the project-or possibly abandon that particular technology.

An example of a change in technical strategy was the way in which Boeing designed the 777 aircraft. Previous de signs were drawings done on paper. However, this two-dimensional approach almost always resulted in components inside the wing ( E.g.) bumping into each other because they were located in the same place. This kind of interference is almost impossible to catch before a prototype is built, and then it’s very expensive to correct.

The 777 was designed using three-dimensional computer modeling, so that such interferences could be seen on screen before any hardware was built; and, naturally, corrections could be made as well. Without a doubt, this saved Boeing a lot of money. It also saved time, because redesign eats away at a schedule.

It’s important that a strategy (or combination of strategies) be chosen because it’s the best one for this particular project, not just be cause "it represents how we have al ways done our projects." So in step three of the Lewis Method, you brain storm a list of possible strategies, then pick one in step four. As notice, you must ask several questions in step four.

A strategy should be chosen because it’s the best one for the project, not just because it represents how the work has always been done.

Implementation Planning

Once you have selected a strategy, you must develop a de tailed plan on how to execute it. This plan will consist of a list of all tasks to be performed (called a work breakdown structure), a schedule showing task durations and sequencing, resource assignments, and a project budget. In most projects, the deadline is dictated. Your schedule must show how you will meet that deadline, or alternatively, what it’s possible to do in the event that you have too few resources to meet the original target. Every project has four constraints-performance, cost, time, and scope (PCTS)-and because they are interrelated, trade offs must be made.

Three of them can have values as signed, but the fourth must be al lowed to vary. In fact, one of the dozen or so most common causes of project failure is that the project sponsor dictates all four constraints.

One rule must be strictly followed in developing an implementation plan: The people who must do the work should prepare that part of the plan! This rule yields a double benefit. One is a realistic plan. The people doing the work have the best idea how long things will take and the order in which they must be done. The second benefit results from the first-because people put together their own plan, they are committed to it.

Implementation planning can take a lot of time, and one trap is for people to say, "We don't have time to plan-we must get the job done." This is actually counterintuitive. The more critical the time frame, the more important the plan be comes. It’s when you have forever to get something done that the plan is unimportant.

The people who will do the work should plan it!

Execution and Control

If you have no plan, you have no control.

Development tasks should have durations not exceeding one to three weeks.

Once work gets underway, control is exercised by comparing where you are to where the plan says you should be, and taking action to correct deviations that will inevitably occur.

Since your plan tells you where you are supposed to be, it follows that if you have no plan, you have no control. This means that planning is not merely an option if you want to actually control your projects.

Another essential aspect of control is that you can't have control if you don't know where you are. This is no trivial matter, especially in knowledge work. Attempting to mea sure progress in engineering, programming, science projects, or other knowledge work is virtually impossible if you try to do so using a continuous scale. That is, we can measure feet or meters on a continuous scale. We can measure time or volume on a continuous scale as well. But we can't measure work progress that way.

The best approach is to break knowledge work down into increments of one to three weeks' duration and measure two events-start and finish. It makes no sense to say a task is 60 percent complete, because you can't tell. In fact, you can't even be certain that some work is actually complete, but you are often forced to pretend that you can tell. Otherwise, you struggle forever at tempting the impossible. Furthermore, by insisting that large tasks be divided into small ones with one- to three-week durations avoids the common problem in which a designer gets about 80 percent of the work done and then takes forever to complete the remaining 20 percent. The progress curve for such work is shown in ill. 2, and it’s a universal curve.

Learning and Closeout

One of the common mistakes teams make in projects is failing to do the lessons-learned review. Doing so most certainly means that mistakes made in one project will be repeated.

Furthermore, the "good" things learned are not captured, so they cannot be employed in subsequent projects. Regular les sons-learned reviews should be part of every organization's culture, but not just at the project's end. The rule should be that these are conducted at major project milestones or every three months, whichever comes first. The reason for the three-month rule is that this is the limit of what people can reliably remember. The major milestone rule allows les sons-learned to be done on very short-duration projects be fore they are finished. The idea is to learn as you go, not just when the job is finished. The best examples of this being done correctly are in sports, where lessons-learned reviews are conducted after every game, and in the U.S. army, where such reviews are conducted after every simulation and every major battle.

Dividing one guess by another to get a magical thing called ROI is just a modern-day method of divining the future by reading the entrails of a chicken. It's just less messy!

THE PROJECT PORTFOLIO

Developing products is always a gamble. You never know if you will sell enough to recover your investment, much less make a profit. The decision to develop a product is always based on guesswork. How much will it cost to manufacture? What will it cost to develop? How many units can we sell? What will customers pay for it? There's a lot of witchcraft involved in answering these questions. In some companies you would be as well off examining the entrails of a dead chicken as you would believing the market forecasts or the estimates of development costs. In fact, I am almost convinced that this is how some companies do it. In one of my seminars I stated that many companies require a certain return on investment (ROI) before they will develop a product, and an engineer asked, "How do the marketing people deter mine how much it will cost to develop the product? They don't ask us engineers." I agreed with him. "In fact," I said, "they use sleight of hand. They begin with the ROI imposed on them by the company, and they forecast sales. Then they plug this into the equation and find out what the development cost must be to yield that ROI, and that is the number they use." We had a good laugh, and I know that not all marketing departments do this, but I have seen so many that do that it makes me wonder.

The fact is, in any case, that the market forecast is the best guess marketing has about sales, and even if engineering estimates development costs, that too is a guess! I know, I know: we would like to feel that there is some kind of precision in all this, but dividing one guess by another to deter mine a magical thing called ROI is just a modern-day method of divining the future by reading the entrails of a chicken. It's just less messy.

All estimating and forecasting is guessing!

Probability

In other words, all of this is probabilistic, not deterministic.

There is a certain probability that you can sell the product.

There is another probability that you can develop it for a certain cost, and another that it will cost a certain amount to manufacture. There are three important variables in product development, which I call the three Ps: performance, producibility, and profitability. The product must perform according to requirements. It must be producible in quantity. And it must be sold at a profit.

It’s interesting that product developers often only understand one of these, performance. So long as they can make a product do what it’s supposed to do, that's all they care about. It doesn't occur to them that it’s unhelpful that they have made one unit work in the lab. They forget that the item must be made in quantity to be of value to the company. And of course, why make it in quantity if you can't sell it at a profit? If all of this leaves you with a queasy stomach, it should.

As we've said, this is a messy business; essentially, it's gambling.

The best thing you can do is to build a portfolio of products in which some are low-probability, high-payback; some are high-probability, moderate payback; and so on. Like investing in stocks, you need a proper mix for safety.