Starting early

In our experience with client after client, the most common problem with the way many companies create products is that they view the process as serial rather than parallel. In reality, as Figure 8-1 shows, product development often starts early and continues at the same time as the ongoing work of understanding how the product will best be brought to market, positioned for a market, and sold.

The most important thing about planning is to make sure that you start early. In fact, you should always start much earlier than you think you need to in order to determine both the product and the marketing parts of the product delivery equation. As you investigate an idea in the conceive phase, plan ahead to what it will take to actually get funding for a project.

While you’re in the conceive phase — as you examine and then quickly reject or accept many options — completing the product, problem and business model canvases helps creates an outline of what you will need in the plan phase. Head to Chapters 4 and 7 for details on the conceive phase.

Including your team

Here’s an interesting phrase: “PM as a GM.” It means that a product manager should think about his work much as a general manager does. No, most product managers don’t have the scope of full financial responsibility that a real general manager does. However, the concept of a product manager acting as an executive overseeing all aspects of the plan and execution is very valid.

Products are best brought to market by an integrated team, including members from all parts of the organization. In our consulting work, where we find organizations that are struggling to reach their potential, we often hear of siloed functions that aren’t working together or communicating. Siloed functions happen when information isn’t shared between departments or where each department only looks after its own interests or charter without adjusting to other departments. The result is disjointed and inefficient transitions between internal groups who don’t see themselves as part of a cross-company team. As you get started, bring your integrated team together and share your vision. Have each member contribute to the vision so that everyone has a stake in it. This is one secret to great products: great teamwork.

Treating your plan as a living document

Remember: Information changes. Each document you create for your project needs to have version controls so that you’re clear on what the latest version is and you can keep adapting the document. Arrange for some time each week or month to update the document that you’re developing. At some point, you may not be the product manager for this product anymore, so make sure others who follow in your footsteps can understand the changes you made and why. Table 8-1 shows a simple addition and revision history of a change. Changing the version number can also help readers easily identify whether they have the latest copy. Online documentation such as shared wikis often include planning information using change logs and allowing readers to subscribe to a document so that they receive alerts when a document is changed.

Comparing Lean versus in-depth planning

The two popular methods of planning are Lean and in-depth. We further discuss both later in this chapter, but here we give a brief comparison of the two types. The term Lean has become very popular in the world of product, product management, product development, and even plain old management. At its core, the Lean method of planning is built on two core concepts:

• Respect for people: Focus on the customer and empowering the individuals doing the work.
• Continuous Improvement: Focus on repeated changes to the product based on a consistent method of dealing with uncertainty. One great Lean tool is the Discovery, Hypothesis, Test, Learn loop (shown in Figure 8-2). Using this learning loop, the team working to solve problems starts by discovering new information, developing a hypothesis to test against, and then learning from the tests. Once new information is acquired, the team feeds it into the next round of learning. The best teams don’t adopt any new idea until it has been tested and proven to be better.

Unlike in-depth planning methodology, where you develop extensive plans upfront and don’t expect them to change much, Lean methodologies build in learning and change as you go.

In-depth planning is predicated on getting to the right answer. There are versions of the answer, but after everyone agrees on it, backtracking or adding in new learning is really hard. The process isn’t fast enough to accommodate new learning and adjust the plan. That’s why many teams file their completed annual plans and don’t look at them again. When the planning cycle comes around again, they dust off the previous year’s plan, and everyone may read it and adjust it with the learning that has happened in between. But a year is a long time. Given the fast-changing nature of many markets, industries, and products, incorporating aspects of Lean thought processes and planning typically improve business results.

Completing the types of new products and services grid

In Chapter 7, we introduce the product-market fit quadrant to determine what kind of product and problem space — defined or undefined — you’re working with during the conceive phase. In this chapter on planning, your focus is adding an additional dimension of business viability. You need to know that you have a business model that generates profits given the problem that you are solving and the product that you develop to solve the problem.

Take a close look at Figure 8-3. If you’re investigating a Type I product, where you know both what product solution you have and what problem it solves, then you have a lot less work to do in determining financial viability. The example shown is for Microsoft Word 10. If you have sold Word successfully for many years, then there is not much financial uncertainty. Recently Microsoft has moved some of its products to a subscription model, which increased financial uncertainty. The focus of the Word product manager is then to discover what impact a change in the pricing model would have on overall revenue. The product and the problem it solved remained unchanged as they had already been successfully defined.

If, on the contrary, you identify that you’re working on a Type IV product, where you’re simultaneously working on defining what the customer problem is while defining which product may solve that problem, your planning should be much more cautious and use a disciplined empirical process like the learning loop discussed earlier in the chapter. Empirical process means one that is driven by evidence.

Start with undefined factors, the product management equivalent of the medieval map label “there be dragons” for unknown territory. Tread carefully. Examine every assumption. Validate constantly, and be ready to accept that throwing it all out and starting over or switching directions (pivoting, in the Lean start-up terminology) is the right thing to do. For those factors that are defined, make sure to document them very carefully in customer-oriented language.

Finding the right level of planning for your company’s culture

Only you know your company’s culture well enough to decide what level of planning is expected and necessary. Here your focus is on balance and balance can be lost as one or another department takes over the planning process. Organizations are typically driven more in one of the following directions than another as shown in Figure 8-4:

• Financially: Every decision is run through a strict financial lens. This approach can work for the next version of an existing product. For cutting-edge products or products that deliver softer benefits like happier customers or long-term strategic position in the market, driving decisions on a financial basis can be challenging. And with your finance department in the driver’s seat, understanding real customer value buried under the numbers becomes a challenge. The planning process is drawn out, detailed, and complicated.
• Sales: In this environment, the focus is on making the customer (perhaps several customers or just one demanding customer) happy at all costs in the short-term to complete the sale. You have to be careful here because there are a few common traps of sales-driven planning:
  • Different versions: Doing different versions of a product for each customer produces multiple custom versions of your product. This may cripple the product delivery and support organization as they struggle to support many flavors of one product.

  • Understanding customer wants: Sales may not have really understood what the customer asked for. If you are unable to validate the request because sales rushes the product change through, you could easily develop the wrong product. Make sure you validate and clarify the needs and requests before committing resources to build anything.

    One big caveat applies in sales-driven planning. Some companies serve very few customers. Virtually every product that they produce is custom. In this scenario it is best to create an underlying product platform that suits most of what customers want and proactively create a boundary above which the product is customized.

• Product: This method is also known as the bright, shiny object scenario. Someone, typically high in management or in the product organization, thinks that this cool new product idea or feature is just what the market needs. An organization like this one may feel no need to do detailed market and customer analysis. It instead is driven by someone’s gut feel and hopes everything will work out fine. This approach is very common in the founders of start-ups. Planning can be short circuited or revised often as the next shiny object to be developed is pushed to the top of the development list.
• Customer or market: This scenario is commonly believed to be the right orientation for successful organizations. By focusing on customer needs, your planning process is delivered at the right level of details and balances finances, sales buy-in, and product differentiation.

If you’re serious about helping your company become a more customer driven organization, preplanning is critical. Organize product investments under a coherent strategy, and you get a clearer idea when the product, sales, or financial decisions may be jeopardizing the longer-term goal.

Considering your executives’ expectations

Key executives drive most organizations. They have expectations of what your work will look like, and the kind and amount of information they need before they make a decision. Consider the following list of questions about your executives as you begin planning:

• Are the executives involved or hands off?
• How do they like to take in information? Should you speak to them while using visuals; submit a written document/presentation and talk them through it later; give them the information well in advance and have them come back with questions; or give them the information shortly before the deadline (knowing that they won’t look at it until the last possible moment)?
• Do they use particular language when they accept or reject an idea? Can you use this language when speaking with them to tilt the conversation in your favor?
• How analytical are they?
• Do they empathize with actual customer issues, or are they mercenary in taking advantage of customers in any way they can?
• Do they really know what being a customer is like, or are they just guessing? When they really know what customers need, do they have the courage to make changes that improve customer experiences?
• How much information do you need to (gently) educate your executives?
• Are their communication styles direct or indirect? Will you know when they’ve said yes or no?
• How decisive are they? Do they make a clear decision and stick with it, or do they push decisions off?

When you’ve analyzed their usual behavior patterns, create a communications plan to get your point across. Tie the outcome that your product delivers to the executive goals for the company. Don’t leave any crucial parties out of the equation. Getting executive buy-in is critical.

Evaluating investment risk

Investment risk is all about balancing out company resources. For start-ups, the focus is getting to self-sustaining revenue, or growing and achieving market domination as quickly as possible. What many new product managers struggle to understand is how the investment process is perceived at the corporate level. For larger companies with existing products and the opportunity to develop new ones (either follow on products or completely new ones), each project is evaluated differently. Many companies divide their development budgets into two or three categories, as shown in Figure 8-5.

• Ongoing product support: This category is also known as continuing engineering. It’s allocated to fix bugs and sometimes to enable minor enhancements. Investment risk in this area is low.
• New products: The bulk of what product development spends is here. Typically, many more products want funding than can actually be funded, and prioritization should be strategic. Companies usually decide to balance their investment risk by selecting some projects from the product-market fit Type I category and then a few from Type II or Type III categories. You may find a Type IV category product in here. (See Chapter 7 and Figure 8-3 for more information on these categories.) Again, the idea is that you don’t put all your eggs in one basket.
• Advanced products: New technologies fall into this basket. This high-risk category is the “cool new stuff” category. Most of it won’t work, but sometimes it will. For example, the touch-screen technology for iPhones came out of Apple’s advanced technology group. That said, you can consider most products in this category Type III: technology looking for a market and problem to solve.

If you aren’t careful to prune your product line, the ongoing product support category may grow too large over time until getting funding for new products is hard. Chapter 16 gives you an idea of the best way to retire products and have more funds to develop new products.

Understanding the Lean approach

The goal in Lean thinking for product management is to decrease the time to market and project cost without sacrificing the focus on customer value. At the same time, the project has to achieve product-market fit. (See Chapter 7.) In Lean, you investigate the entire system by using a learning cycle. Here are a couple of learning models:

• Discover Hypothesis Test Learn works well in early stage fluid situations and pairs well with Agile.
• A/B testing works out which of two chosen options is most effective.

These models are deliberate investigations of the system you originally used to create product and deliver value. With the results of testing, you alter aspects of the system to improve the whole. If, for example, you reduce cost by delivering software faster but the code has so many bugs that fixing it increases time to market, the system isn’t optimized. You’d be better off to slow down the coding and have better-working and maintainable code at the end.

With the idea of Lean product management in mind, the next sections cover the product management aspects that need to be in place for Lean to deliver on its promise: more value for less cost and time.

What numbers are you looking at?

Incorporating Lean into the planning process means being honest with yourself. Part of that honesty revolves around the numbers you look at. In today’s digital marketing world, you can look at any number of numbers (pun intended). With a product moving through planning, you’re developing and testing — and probably selling at some level. Track each step of the process to see, for example, how many people sign on to the service, use it, keep using it, and then pay for it. Look for the big decrease in customers moving from awareness to commitment.

In Table 8-2, 100,000 people became aware of the product; 10,000 showed interest; 1,000 evaluated the product; and 1 person committed. This decrease in customers as they move through each and every step of the sales decision process is huge and needs urgent investigation into all aspects of this product’s value proposition. By using Lean thinking, you can run a test like this one and then, in association with an Agile development team, make changes rapidly to correct the situation.

Beware of looking at numbers that seem to show success (in this case, the high rate of customer awareness and interest) when you know that something isn’t right. This approach is called focusing on vanity metrics. Instead, start looking for the numbers that will help you find the problems (in this case, the low commitment rate), and then you can start solving problems one by one.

Taking a look at a popular business model canvas

Figure 8-6 is the popular business model canvas. You use it in place of a business plan when you’re working in a Lean method with high uncertainty — so not typically for known (Type I) products. As you explore ideas and want to adapt to new information, the business canvas keeps everyone in the loop as to the current thinking, which could easily change tomorrow.

The sections are of a business canvas are in the following list. Turn to Chapter 7 for details on creating business canvases:

• Key partners
• Key activities
• Key resources
• Value propositions
• Customer relationships
• Channels
• Customer segments
• Cost structure
• Revenue streams

Where do you start? With whatever part you believe to be true. You may start with the value proposition that you want to deliver with your product. You can also start with unserved customer segments that you want to target. Then keep filling in the missing parts. If the whole scheme falls apart early on due to an inconsistency or a part of the business puzzle that you can’t validate, you’ve lost only the time spent — not millions of dollars that you may have invested building a product through more traditional planning methods.

Being prepared to rapidly change and pivot

Lean incorporates the idea of checking and change as part of the process. To implement Lean, it helps to think of the axes on which you can change or pivot your offering, market, price, or communications. These axes may include the following:

• Problem: If you find that customers still aren’t interested after you solve a defined customer problem, maybe you need to revisit the problem and make sure that you really understood the underlying need.
• Customer segment: Are you addressing the wrong customer segment or group of customers? Careful analysis may show that a different customer segment would be more receptive to your offering. Use Chapter 5 to help you with customer segment creation and analysis.
• Product: Maybe your customers are using only part of your product. To pivot, you would refocus and expand on the part of the product that is working and de-emphasize or delete the rest. This is what happened with Groupon. It pivoted toward the part of the product that customers were using: deals on products and services.
• Marketing: You may pivot and decide to reposition your product in the market. For example, in one company, the win-loss analysis showed that the product sold more successfully when it was combined with another product. The marketing was then changed to address this target market, and sales efforts were more successful.
• Price: Pricing structure can influence how customers receive and perceive a product. Interestingly, if the offering is positioned as a premium product and brand, one option may be to increase the price so customers understand the value of the offering.

Pivots are a key part of the Lean process. As such, plan to review numbers regularly (on a monthly basis is a good cadence) and decide whether a pivot may be appropriate. Then think along each of the pivot options to see which one or two may offer a change that puts you on the road to success.

Deciding whether to document

Though running an entire project from a business case using only a canvas on the wall may be nice, the reality is that the level of documentation depends on a variety of conditions:

• Do you develop using Agile methodology or waterfall? Throughout Parts 2 and 3, the right documentation for each is specified.
• What is the underlying nature of the project you want to document? If it’s a large-scale change in the product, then documenting the market need and corresponding product description in detail is appropriate. If the focus is on changing or adding target markets, then spending more time on the market strategy documents is in order.
• What are you trying to create documentation for? A bug fix or other minor change should be very easy to document and proceed with. But if you’re planning to spend $100 million, you’d likely want a detailed and thorough plan that executives are required to read and sign off on. Expect to carefully consider every aspect of the project. Table 8-3 gives you a way of classifying the type of change or project and the corresponding type of documentation needed.

Using key documents and corresponding questions

Chapter 3 discusses documents you use throughout the entire product life cycle. We cover the details of how to think about and create the contents of each of strategic documents in more detail in Chapters 9, 10, and 11. In the planning stage, team members should complete the following strategic documents for a large scale project:

• Business case: Captures the reasoning for initiating a project and determines whether the effort should proceed based on profitability and strategic fit. The target audience for this document is management who decide whether a project moves forward.
• Market needs: Description of the business or consumer challenges to be solved through an analysis of market needs, user personas (head to Chapter 5), and usage scenarios. The audience is product development and quality assurance organizations.

• Product description: A description of the completed solution’s feature set, expected usage, and the technology and delivery requirements. Includes initial scoping of product and project costs. Product development typically creates this document, and the target audience is product management, which confirms that the document meets the customer needs as outlined in the market needs document. In some cases, quality assurance uses the document to make sure that all parts of the product are completed.

  Product development is typically unhappy about having to create a product description document. They don’t want to take responsibility in case they forgot something or the project doesn’t go well because it was described incorrectly. Workarounds include selecting one engineer and, for software, one UX person to work closely with you. Have this work specifically assigned to them through the engineering organization. You can then collaborate with them on the details of the document. Another alternative is to create a version on your own, give it to one person or a small team in product development, and then change it based on what they tell you is wrong. Since this document drives the nuts and bolts of what your product will do, product managers do whatever it takes to complete this document no matter what type of development team they work with.

• Road map: Description of a set of sequential product releases based on scoping, strategy, and objectives. Road maps are used for many internal audiences to explain the longer term direction of a product. A modified and simplified version is used for external audiences. See Chapter 20 for caveats on using road maps with external audiences.

When working with Agile teams, product managers often skip an in-depth planning activity. Teams can confuse the planning of a product in the plan stage of the product management life cycle with the scrum planning activities. Both instances use the word plan, but the work done is actually very different. To hold the long term vision and strategy in focus, product managers need to have well-thought-out strategic documentation in place at all times. This documentation is quite detailed so the Agile team members are better served by a concise product vision developed on the basis of the strategic documentation which provides a guiding light through the entire project.

Because no development process is truly 100 percent Agile or 100 percent waterfall, many organizations create hybrid processes that retain the flexibility and adaptability of Agile and have the elements of early and deep thought and planning that are waterfall. In Table 8-4, you see that the hybrid method looks a lot like Agile, with Agile requirements (called epics) taking the place of large market needs and product descriptions documents. (We discuss waterfall and how it compares to Agile in Chapter 12.)

Estimating your time investment

Writing coherently and thoughtfully to clarify your own thoughts and then using the content to influence others takes time, and your time as a product manager is precious. Each page of a document that you write can easily take you an hour or two simply because as you start writing, you realize that you forgot to nail down some of the details and have to go to figure them out. Even a well-written and complete email can eat up an hour.

You won’t likely have the free time to create each of these documents in one sitting. Rather approach the work like a term paper, plan to spend some time each day when you won’t be interrupted. Don’t be afraid to rotate effort among different documents. In particular, the market needs and market strategy documents are intertwined, and you’ll bounce from one to the other. (Check out Chapters 10 and 11 for a more detailed look at these documents’ contents.) The most important thing is that you think about all the critical questions that these documents pose well in advance of the project and then update your thinking and assumptions as you go.

One recommendation is to create a very rough draft and then ask everyone’s opinion. In that way, you don’t spend a lot of time crafting a message only to find that particular issues are still not clarified.

For a detailed project, the time from start to finish for extensive planning may be two to three months as you home in on a solution that works with all internal and external stakeholders. The actual time you spend writing will be much, much shorter than that. But if you’re going to be advocating that your company spend a large amount of money developing, launching, and marketing a product, the time you take to answer critical questions upfront and build a solid plan will be well spent.