IN THIS CHAPTER
- Understanding basic planning guidelines
- Looking at planning under Lean, Agile, and waterfall
- Figuring out how much and what kind of documentation is appropriate
In this chapter , we discuss all the variables that affect how you decide to plan a new
product or new addition to a product. This chapter ensures you understand the lay of the
land in your specific situation and shows you why changing the way you plan to achieve
better outcomes can be valuable.
Adopting Planning Best Practices
The key benefit that a well-functioning product management organization can bring to a
company’s success is making sure that the products developed actually deliver valuable
solutions to customers and that the product is profitable for the company . The planning
phase is where you do the detailed work to make sure that you are focusing the
organization on a valid problem to solve and that solving this problem will actually
translate into company revenue, profits, and any other goals that you’ve set for the
product. Planning to plan may sound odd, but the planning process has so many variables to look at that the safe and sane way to proceed is to plan carefully .
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 . T able 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.
TABLE 8-1 Change- T racking in a Living Document
|Date||Description of Change||Change|
|Added “shipping” as additional target market with associated positioning statements||Julie Harris|
Deciding on the Right Amount of
Different products require different amounts of planning. For one project, imagine that
you’re developing an app to help customers keep track of gas mileage. For a second
project, imagine that you need to track all the different kinds of propulsion types and their current statuses on a manned rocket headed for Mars. In both instances, you’re checking to see how much farther you can travel. The differences in the projects — who the client is, the risks involved with the project, the overall cost of the investment — contribute to how much planning needs to happen.
Here is a list of items that would indicate that you’re going to have to do a lot more
- Your industry and line of products are highly regulated.
- Development times are very long.
- Development costs or the cost of change during a project very high.
- The team working in the project is very large.
- What you’re working on is only part of a much larger solution, and you need to be closely integrated with the other parts of the solution.
- Y our company or organization is very risk averse and needs many levels of approval in order to proceed.
After you know what your planning scope will be, you can align your time and effort
accordingly . In general, the more clearly written your material is with a compelling story
driving the narrative, the less work bringing the rest of the company along will be.
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, T est, 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
Remember 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
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
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
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.
ANALYTICS AND THE FEAR OF RISK
Making sure you base all decisions on hard facts and clear analysis is tempting because having the numbers support every decision you make can be comforting. The underlying assumption is that each decision you make can have an absolutely correct answer that clearly excludes other options. The only solution to the problem 2 + 2 is 4. This kind of thinking and problem space is often called well defined.
Unfortunately , the product management problem space is one in which the problem being worked on (customer , product, and so on) and therefore the solution may be ill defined . You simply have too many variables you can’t define and put numbers around with an exceptional level of accuracy . Overanalyzing may lead to paralysis by analysis. By recognizing which problem space you’re in, you may be able to
determine key guideposts and then use Lean methods to pivot or shift the project in a different direction as you explore the problem further .
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
Streamlining the Planning Process
with Lean and Simple Planning
Using a Lean approach to planning in product management means not defining all details upfront. It means accepting — and even welcoming — that change will happen and be part of the development process.
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 T est 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 T able 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.
TABLE 8-2 Analysis of Sell- Through
|Number of people||100,000||10,000||1,000||1|
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. Y ou 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
- Customer segments
- Cost structure
- Revenue streams
Where do you start? With whatever part you believe to be true. Y ou may start with the
value proposition that you want to deliver with your product. Y ou 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
Being prepared to rapidly change and pivot
Lean incorporates the idea of checking and change as part of the process. T o 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.
Taking a More Thorough Approach: In-Depth Planning
If you’re proposing to spend a lot of money on developing a brand-new idea, be prepared to spend a lot of time justifying the investment. Y our executives and company may need deep planning and justification, so your planning documents will likely be long and complex.
In many companies, the trend has been toward using presentations rather than
written documents as a form of documentation. Although presentations are faster to
create, the deep thinking that goes into a written document creates a more thorough
understanding of the issues. Think of a presentation as a movie and a written
document as a book. When a writer adapts a book into a movie, she has more
extensive background material to choose from; even though she simplifies the book’s
story in the long run, the final product is still richer because of all that preexisting
content. But a tie-in book based on a movie is often very shallow because the writer
has far less material to work with. Even if all you are asked to create is a movie
(presentation), spend time writing out the book (documents). You’d be surprised at
how much thinking you still need to do in order to complete the documents that you
didn’t have to do to complete the presentations.
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. T able 8-3 gives you a way of classifying the type of change or project and the corresponding type of documentation needed.
TABLE 8-3 Comparing Documentation Levels
|Content||Type of Change or Project||Sign-Off|
|Light||Few or no written documents. All critical issues considered in person.|
Summary email advised to document decision.
|Bug fix, minor user interface|
even just an
|Medium||Some or all documents written in short form. Level of detail kept as minimal as possible.||Small-to-medium next revision|
of an existing product.
just have direct
|Heavy||Complete documents delivered for all phases with extensive detail.||Large and/or new product area, solutions that cover multiple products as part of the offering.||All stakeholders|
sign off and agree to all documents.
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.
Warning 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 T able 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 .)
TABLE 8-4 Comparing Agile, Hybrid, and Waterfall Documents
|Plan Phase Documents|
|Agile||Business planning/business case|
Prioritized high-level user stories
|Hybrid (Agile and waterfall)||Business planning/business case|
In-depth epics with more direction so that other areas can be sure of achieving certain
goals for customers
Market needs document (in some cases) to think through the personas, pain points, and customer problems at a more in-depth scale over a longer term
|Waterfall||Business planning/business case|
Market needs document
Product description document
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.