Chapter 11 Developing a Plan: Market Needs, Product Description, and Road Maps Product Management

IN THIS CHAPTER

• Getting some basic terminology straight
• Nailing down your market needs statement
• Building product descriptions with the development team
• Looking ahead with road maps

Transforming a customer’s need into a product is the basis of product management. It’s an exciting process that offers great rewards. Along the way you can encounter
breakthroughs and challenges. In this chapter , you discover how to successfully document your market needs, work with product development to translate a need into a product description, and lay out the future of the product with a road map.

Uncovering Market Need and Creating
Product Feature Descriptions

Any tension between product management and engineering is often traced to whether the discussion is taking place in the problem space (where product managers focus) or the solution space (which engineers and many others find to be more comfortable). The terms used to describe issues changes depending on what the focus of the conversation and discussion is. Here is a clarification of the terminology and how it can help your team work more effectively simply by choosing the right words.

The problem space

A market need is a customer-oriented and clearly articulated understanding of the problem a customer needs to solve. It’s also often referred to as a customer need or customer requirement and market requirement. For the purposes of this chapter , we will use the term market need to mean all four terms.

The solution space

A product feature description is an explanation of a feature or features in your product
that will address one or more of the market needs. Again, the following terms are often
used interchangeably: feature, product feature, and product requirement . For this
chapter , we will use the term product feature to describe something that is part of the
solution space.

The issue with the word requirement is that it can be used in both the problem and
solution space. If your company uses the term requirement, use either
customer/market requirement or product requirement . In addition, the term feature
is often used instead of product feature . This can sometimes lead to features being
confused with what the customer wants. Select words that specifically indicate that
you are in either the problem or the solution space and insist that others in your team
follow the same convention.

Comparing market needs and product features

To clarify market needs versus product features, here is an example:

A salesperson has a need to quickly and easily be able to dial the top three
people in a major account she manages. She calls them all several times per
week, often from the car or while on the move. She doesn’t want to have to look
them up in the contacts in her smartphone.

The market need is “call the three most important people in my major account easily .”
Giving the product development department a well-constructed market need rather than a product feature is very important. Y our engineers often come up with something that is far more creative than what they’d create if you just offered up a product feature such as “have the top three contacts at a major account on speed dial.”
Some product features that may meet this need include the following:

• Show a list of favorites, including people she calls frequently , so she can tap once to see the list and then tap once on the person’s name to dial the call.
• Allow her to add the three people from the major account easily to her speed dial list so she can use speed dial.
• Have the smartphone suggest creating a new speed dial group with these three people after she’s called them a certain number of times.

By stating market needs rather than communicating product features, you gain lots of
benefits as a product manager:

• Harnessing the creativity and brilliance of your engineers
• Fostering more of a team spirit with your engineers
• Ensuring that people understand the importance of their roles and feel valued in what they contribute
• Coming up with better solutions for your customers
• Being perceived as a product leader who can influence without formal authority without having to come across as being dictatorial

In some engineering teams, delivering only market needs isn’t an effective
strategy . If a group doesn’t have a sense of teamwork with product management, or
your company has a culture of engineers not wanting to take ownership for deciding
product features or simply believing that features should be delivered by product
managers, you may have to define specific features for them. In this case, expect to
provide the product features and even write a detailed product description to support
each feature.

One approach for helping foster creativity while providing guidance is to state the
market need and then provide one or two potential product feature descriptions that
would solve the problem. With these as guidelines, you can challenge your team to
come up with something even better that will meet the market need. This way , you’re
giving them more guidance but aren’t coming across as telling them exactly what they
must do.

For any particular product, a market need and a product feature don’t necessarily
correlate one to one. The relationship is closer to that in Figure 11-1 . Market needs 1 and 3 are resolved by feature 2. Market need 3 also needs product feature 4 to be complete.
Don’t expect to have one market need be solved neatly by one product feature.

Keeping discussions clear

In the world of market needs and product features, clear terminology can make sure that you and your team are on the same page. It’s a relief to know that simply agreeing what certain words refer to can solve so many problems.

One of the frequent statements that the 280 Group hears from organizations is
“We don’t know how to write effective requirements.” Usually , the underlying problem
isn’t that they can’t write down what’s needed but that until the language itself is
untangled and closely defined, resolving the requirements-writing issue is tough.
Sometimes, they forget that words are a poor substitute for images and, more
critically , discussions.

In Figure 11-2 , you see the effect of poorly defined and poorly understood requirements —both customer and product. The longer the misunderstanding continues, the higher the probability that the possible solution delivered won’t meet market needs.

AVOIDING ERRORS WITH AGILE

The possibility that the end solution doesn’t match the market need is one reason that Agile development methodology is becoming so popular . Agile specifies a meeting to check and discuss everyone’s understanding of product features before they’re built. Then a small increment is developed and the team checks in again. The emphasis on conversation and frequent inspection and feedback makes it lot harder for the wrong product to be built over time.

Documenting Market Needs

Documenting market needs is the first step in communication and negotiations with
product development. If you skip this step, you’re at a significant disadvantage when
working with product development. The documentation of market needs keeps you on
track, providing a road map of where the product begins and ends. Then you’ll be able to
tell if you’ve gone off route sooner rather than later .

Questioning why “why ” is so important

Simon Sinek writes and talks about leadership and management. One of his great ideas is keep to the reason “why” you are doing something top of mind at all times. Figure 11-3 illustrates this simple, powerful concept.

Here’s a breakdown of how starting with “why” translates to product management:

• Why: The core of what motivates people is the purpose, the central belief , and the reason your organization exists. For a product manager , the “why” translates into the real driving vision — the reason the customer will find the product offering and solution so compelling.
• How: Around that core belief and meaning is the “how .” What’s the special way your company and your product can deliver value?
• What: And then you have exactly “what” (the products and services) you deliver .

Companies that have a strong “why” often have much better stock market valuations and an easier time of making decisions on a meaningful basis. Their product strategies and long-term success are often far greater than their competitors. And everyone on the team is more likely to be on the same page.
Your understanding of market needs protects you from wavering from solving the actual
problems that your customer has. It’s your guiding light that gives you direction in the
middle of the day-to-day discussions that may otherwise consume all your energy and
cause you to lose focus on your original purpose. What is your why? What is your
company’s why?

GETTING THE SKINNY ON MRDS AND PRDS

The market needs document is also known as the market requirements document (MRD). The MRD has historically been used in waterfall and phase-gate development processes rather than Agile and is designed to capture a deep description of the market needs that customers have. In many Agile cases, a
short MRD is an effective way to capture and understand the market needs before diving into writing user stories and cranking out features in the product backlog as fast as possible.
The MRD is accompanied by the product requirements document (PRD). Oftentimes, the company is so excited and pressured to create the product rapidly that many organizations do away with the MRD and jump right to the PRD (or , in the case of Agile, simply put together a list of product features as a backlog, write user stories, and start developing the product without discussions or a deep
understanding). The PRD includes a section to explain why the customer needs the product. If you aren’t going to produce an MRD or a PRD, make sure that you at least have an in-depth discussion and get agreement with your team about the “why” of the product, what the true market needs are, and
how the product features will solve that need. You’ll have much greater product and career success as a result.

Gathering the necessary information

Developing a market need involves collecting information that gives the context of the
problem, who experiences it and when the experience occurs. Four key components that you need to understand thoroughly in terms of market needs are

• Personas
• Problem scenarios
• Customer journey/workflow
• Market needs statements

Creating personas

The idea is to begin with the customer in mind, and the most common method is to define the personas that your product interacts with. Check out Chapter 5 for a full discussion of personas. For the purposes of this chapter , you just need to know that personas are archetypes of people that share similar characteristics. T able 11-1 shows how to define a persona. Figure 11-4 includes a completed user persona.

TABLE 11-1 Information Needed for Creating Personas

Persona attribute	Attribute explanation	Example
Name	Name each persona.	Fred
Role	What is the persona’s role in the product purchase decision?	User , buyer , influencer
Goal	What problem is the persona trying to solve that your product provides some or all resolution to?	Enter data for manager to track work
Background	What is the persona’s background that informs how it reacts to your product?	Earns $/year , college educated
Attitude	What is the persona’s attitude toward the product or actions that you’re asking it to take?	Intimidated by new technology
Behavior	What is the persona’s observable behavior with respect to your product offering?	Reluctantly uses iPhone; scared of Android phones
Insight	Do you have any other insights into the persona’s reaction to your product that hasn’t been covered elsewhere?	Feels stressed when out of control

Problem scenarios or problem statement

When you’ve defined all the personas associated with your products (as we discuss in the preceding section), you need to create the problem scenarios that cause them to need your product. The product should be the “ Aha, you fixed my problem!” solution to the problem.
Problem scenarios contain the following information:

• Primary goal: What is the primary goal of the customer in this particular situation?
• Persona(s): Who has this problem and is trying to reach this particular goal?
• Background: What is the background situation regarding why the customer want to achieve the goal? Think of the difference between a person trying to park on a wide-open street with few cars on a sunny day versus someone parking at night in a crowded muddy lot during a rainstorm. The background is important.
• Frequency: How often does this problem happen? Every day? Once a year?
• Trigger: What causes this problem to arise?
• Description: What if any other details do you have that describe the problem in its entirety?

Here’s a very quick example:

You decide to make potato salad. Y ou buy potatoes, and now they need to be
peeled. You can use a knife. The downside is that you’re frustrated by how much
potato comes off with the peel. Y our market need is to peel potatoes without
removing anything but the skin. Aha! A potato peeler is just the product to
resolve your problem. It shaves off only the potato peel, leaving the potato flesh
behind. And you can push down hard on your potato peeler to give you more
control over the peeling process for different results.

If the definition of the customer and persona who has the problem changes, another
solution may arise. For example, think about a new persona — an older person, Suzanne,
with arthritis. The problem definition changes, and the market need does as well. Now , you need to add in an aspect of comfort in using the peeler while still being able to retain
control and apply pressure. That’s why a company named Oxo makes a range of kitchen
implements with soft, comfortable grips. Oxo extended the problem space to account for this different persona.
Problem statements and problem scenarios are two similar-sounding terms. A problem
statement is a short version of a problem scenario. In the potato peeler problem, because the problem as written is quite short, it’s closer to a problem statement. Here is the same information written as a problem scenario with more context and color:

A grandmother , Suzanne, decides to peel potatoes for the Sunday family lunch.
Ten people are coming over to eat, and she wants to make mashed potatoes
because it’s a family favorite. She doesn’t believe in waste and prefers to peel off
as little potato skin as possible. She knows that the vitamins are in the outside of
the potato and wants to feed her family well without peeling away these
nutrients. Recently , her arthritis has really been bothering her , and when she
uses her standard metal peeler , her hands hurt. It feels like either the potato or
the peeler will slip and she’ll injure herself .

This problem scenario has much more detail, both qualitative and quantitative, about the actual situation that the persona faces before the product solution is developed. This
approach helps the group developing the product imagine more easily all the challenges
the grandmother faces and create a wonderful solution. Though you wouldn’t want to write up a problem scenario for each little detail of the customer problem, there is a strong case for creating at least one or two key problem scenarios that can guide your product development team.

Customer journeys and workflows

Customer problems aren’t always a single-point situation. In many instances, particularly in a sequence of software interactions, an overall goal is achieved by resolving a series of problems along the way . The sequence is either defined from the customer’s perspective using a customer journey or the sequence of tasks that the software needs to help different users navigate from start to finish. The more technical the sequence and the more people involved at each step, the more likely that a workflow point of view works better . The more generic the process is for any customer , the more likely that a customer journey is useful.
The most common and generic of the two is a customer journey , so we’ll describe the
process of creating one here.
Start by defining a customer journey using two pieces. Define the overall goal of the
customer and then the specific problem points along the path to problem resolution. At
each stage of the journey , identify the following from the customers’ viewpoint:

• What action do they need to take to get to the next step?
• What is their motivation (or lack thereof) in moving to the next step?
• What questions do they have at this point in their journey?
• What barriers are in the way of them completing this particular step?

For an example, consider navigating paying a tax bill online with the IRS. Given the level of tax jargon, navigating the IRS site is likely going to be confusing for customers. They have little positive motivation, other than to pay their taxes and avoid a penalty . Each user has many questions along the way and, when faced with a barrier more complex than providing a name, address, and social security number , may simply give up and pick up the phone to call instead of using the website.
By mapping out the customer journey and workflow , the IRS can get a deeper sense of how the customer is going to interact with the website. It can anticipate what the questions and barriers may be and then build a solution that minimizes challenges and makes it far more intuitive for the user . And in the end, it can save a significant amount of money because users will be able to accomplish what they need to by using a self -service website rather than the IRS having to pay an agent to answer the phone.

One way to map out a customer journey is to pull out some old favorite tools: sticky
notes in different colors and marker pens. Write down each step along the way on
larger sticky notes and put them in sequence at the top of your workspace (such as a
whiteboard, wall, or flip chart paper). Then fill in the actions, motivations, questions,
and barriers along the way . Workflow situations vary tremendously , but with a little
thinking, you can experiment and discover the key components that need to be solved
at each step. Document the sequence for your team using drawing software to show
the overall story and then break the story down into each separate step. A personal
favorite is simply to draw it out in PowerPoint and then share it with the team.

Market needs statement?

When you’ve sorted out your personas, worked out what problem you’re trying to solve for each particular persona, and determined where they are in their journey toward solving their problem, your market need becomes much easier to write. Various useful formats can make the process easier .
The simplest format is this one:

The [Persona role], [Persona name], must be able to [achieve a result] OR [solve
a problem].

Consider Suzanne, the arthritic, potato-peeling grandmother from the preceding section,
as an example:

The user , Suzanne, must be able to remove the skin of six 3-inch-diameter
potatoes without experiencing pain or losing the nutrients in the outer part of the
potato just below the skin.

Detailing your market needs document

Documenting your market needs uses a simple format based on the data you collect.
Remember that the market needs and product feature descriptions are intricately linked.
As you work to resolve the differences between the two points of view — that of the
product manager and that of the product development organization — remain flexible.
Here are the parts of the market needs document; the following sections explain them in
more detail.

• Executive summary
• Personas
• Problem scenarios
• Market needs
• Success criteria
• Assumptions, open issues, exhibits, and appendices

Executive summary

Complete this section after completing all other sections, even though it comes first in the document. It describes the three to five main problems to solve and the personas who have these problems and lays out the main problem scenarios in two or three sentences. The executive summary should ideally be just one page — certainly no more than two. You can treat it as a standalone document.

Personas

One or two personas should always be the primary focus for the design even though you
may have five to seven personas total. Describe the personas representing the different
user types within the targeted markets.

• Buyer personas: This section describes the buyers, made up of the financial and technical decision makers. These people are often found at businesses (B2B) and are distinct from the users who directly interact with the product. Buyer personas are often very concerned with aspects of the whole product offering as described in Chapter 1 .

Financial decision maker (CFO) persona(s): These are the personas that determine
whether to buy the product or not. They may not have a great understanding of why
the product is so important to the user .
Technical decision maker (CIO) persona(s): These personas worry about the
technical standards used and support for the product. They are concerned how the
product fits with the rest of work done at the company .

• User personas: These are the personas who interact with the product. They allow the development team to live and breathe the user’s world. By always asking, “Would Jim (or whichever persona) use this?” the team can avoid the trap of building what users ask for or what the company may think is cool rather than what customers will actually buy and use. Constantly evaluate designs against the personas and resolve disagreements over design decisions by looking back to the personas.

Problem scenarios

This section describes various scenarios related to the market need(s), relative to the
personas’ goals. Problem scenarios describe the current state, not the solution state (also known as a use case).

Market needs

In this section, you describe the customer needs, the solution to which an architect or
designer later documents as product features. Market needs are described from the
customer’s perspective and use the voice of the customer; they’re never about product
capabilities. Use the INVEST criteria for creating great market needs. INVEST is described in Chapter 12 .
For each need in the next sections, give the following information:

• ID number: Assign the need an identifying number .
• A description: “ As a [persona] I want to [do something] so that I can [derive a benefit]”.
• Acceptance criteria: What are the high-level criteria that measurably determine the success of this need? Use the “given, when, then” format as follows: “Given [condition], when [event], then [testable outcome].”
• Objectives: What is the value or overall benefit provided to the customer with this ability?
• Personas: Who are the personas who have this need?
• Problem scenarios: Which problem scenarios are involved with this need?
• Priority: What priority is this need? Check out the sidebar “Different ways of saying ‘maybe’ ” for optional market needs.

In addition to the following sections, you can also add customer journey and/or
customer workflows sections depending on your industry and solution.

FUNCTIONAL

What is the functionality the customers seek? What do users need to do to achieve their
goal? Most of your market needs end up here.

COMPATIBILITY

What are the platforms and systems the solution must be compatible with (for example,
browser version X and above or Windows version Y and later)? Do customers require
interaction with other systems using APIs or certain programming languages? APIs are
application program interfaces which specify how your program shares information with
other software. What document formats do customers need? If this is a new version of an existing product, what compatibility needs do customers have?

SECURITY

What are customers’ security needs? Do customers require the data to be encrypted? What type of standards do they need to comply with? If a legal or some external requirement mandates this customer need, describe it in the legal, regulatory , and compliance section.

PERFORMANCE

Many times, the market requires, or expects, performance needs. Don’t use this section to describe how the solution may be designed. If industry standards exist, name the
specification instead of describing its details. Don’t make up criteria. It must be based on market research.

USABILITY

Include ergonomic and accessibility needs. Is the product to be used by the elderly , people with poor eyesight, or those with difficulty lifting? Ergonomic and accessibility needs should be based on known user experience standards (for example, a progress bar will be shown for any operation taking more than x seconds). Wherever possible, simply reference the company’s user interface (UI) standards instead of describing them here.

OPERATIONAL

For hardware products, this section includes manufacturability and serviceability needs. It may include environmental issues such as “operating at temperatures up to 120 degrees Fahrenheit.” The performance of many electronic parts degrades (officially the term is derate ) at certain temperatures and start to behave erratically or even stop working. For example, clothes dryers use electronics, so knowing the upper temperature of operation is an important design factor . Does the product need to conform to environmental needs, such as disposal or recycling programs? Does the solution need to include data capture and reporting on usage (analytics or other diagnostic criteria)?
Do customers depend on the company’s internal operations — for example, a software
service that needs to be maintained by internal operations? Does the customer need for
service occur during business hours or 24/7?

INTERNATIONALIZATION

In what languages and countries will the proposed product be used?

DOCUMENTATION

What forms and types of documentation are needed? (This is documentation for product
usage. Y ou capture marketing materials in the market strategy and marketing plan
documents.) Documents may include a user manual in printed or online format and/or a
one-page quick-start guide. Include the needs of the channel, partners, and resellers.

SUPPORT

What are the needs placed on the support organization? What do customers expect from
support: hardware replacement, return and repair , email responses, phone calls?

LEGAL, REGULATORY , AND COMPLIANCE

Define all of the legal and regulatory requirements customers need. This information may be security for the military or privacy data for a financial company . It may be accessibility requirements as defined by Section 508 of the Rehabilitation Act of 1973.

DISTRIBUTION AND PACKAGING

What are customers’ distribution and packaging needs? Do they require overnight
delivery? Is the product sold at retail stores; if so, what are the needs of those resellers?

MISCELLANEOUS AND ADDITIONAL TOPICS

Describe any other market needs not defined previously .

Success criteria

Describe what success is for customers. How do customers measure success — an
improvement in productivity , a reduction in errors, or elimination of eliminating a manual process (just to name a few)? Are there specific and measurable tests of success?

Assumptions, open issues, exhibits, and appendices

Writing about a future product is all about prediction. Y ou’ve made a number of
assumptions while writing the market needs document. Record your assumptions here and be prepared to defend them.
Track any open issues during the creation of this document. When the issue is resolved,
record it. Any unresolved issues should be assigned to a responsible party . Y ou’ll likely
have a number of open issues, which tend to get resolved as the project proceeds. Identify where in the process these issues need to be resolved.
For other data that isn’t easily included in this document, cite the references to the
external documents.

Prioritizing detailed features and market needs

Be sure to include detailed information on prioritization in your market needs
document. Prioritization is a way to pare down ideas into what will work to eventually
solve the market need and what won’t. For a large software project, feature requests
and ideas can reach into the thousands. If you work in Agile, the list of user stories
grows too, and having prioritization tools and methods will help you be efficient at
making the right choice about what to build next. The prioritization matrix in Chapter
7 is especially useful given the large number of trade-offs you need to make. Check
out other prioritization tools while you’re there.

In this section, the term feature has crept back into use because it’s the common
terminology for this type of work and using these tools. The same tools and
techniques work with market needs.

DIFFERENT WAYS OF SAYING “MAYBE”

Prioritizing features, needs, and requirements is possibly one of the hardest decisions that a product manager has to face. What absolutely needs to be part of the product, and what is optional? If something is optional, how optional?
Here are a couple of common methods that teams use to assign the relative importance to a feature:

• A simple but effective method is to allocate each optional feature into three buckets.

High: Highly desirable in this release
Medium: Nice to have in this release
Low: Can defer to the next release

• The MoSCoW prioritization includes prioritization for features that both have to be included as well as three decreasing distinctions for less important features.

Must: Requirement must be satisfied.
Should: High priority item that should be included if it’s possible. Critical requirement, but can be satisfied in other ways.
Could: Considered desirable, but not necessary . Include if time and resources permit.
Won’t: Will not be implemented in a given release, but may be considered for the future.

Whipping Up a Product Feature
Description

You’ve come a long way . You know your customers, their problem, and when and why they have it. You’ve documented or communicated this information to your development team members, so now it’s time to turn the work over to them.
Figure 11-5 shows you how the who and why become the what and how and points out two important considerations for you to think about:

• The line between product management and product development is porous. Your conversations about what your customers need and what product development proposes as a solution is a discussion. During this discussion, you as a team come to the best possible solution. In fact, the discussion is critical to any relationship between product management and product development in order to ship great products.
• The “how” part of the product development isn’t the product manager’s responsibility . As a product manager , it isn’t up to you to be involved with the guts of how a product is actually made. Your development team determines what development tools, programming languages, and processes to use to build the product. You as a product manager simply don’t have that expertise (and if you do, it still isn’t your responsibility), just like your engineers don’t have the business background and expertise to create the product strategy or business plan.

A small caveat to this discussion: Product managers are smart to learn as much as
possible about their products. For example, are some plastics prohibited for
regulatory reasons? You want to know that. Do you need to know what the actual
formulation of the offending plastic is? No. But you do need enough technical and
product knowledge to know whether the decisions being made are sound.

USE CASES?

In many companies, product managers create or assist in creating use cases. These aren’t the same as problem scenarios because use cases contain design-level details and are focused on the solution space.
Use cases also don’t have the holistic vision that customer journeys, workflows and story mapping (see Chapter 12 ) give the development team. The major difference is that a use case includes a description about what the system will do (typically a sequence of steps) as the user interacts with the proposed solution.
Unfortunately , you can’t find a standard formulation of a use case. It’s usually a mix of product and customer information that makes it slightly easier for developers to understand how to solve the problem. The downside is that this mix of information can overwhelm or shut out the customer need.
The 280 Group recommends avoiding use cases, but you may not have much choice if your team uses them. As you develop a use case, clearly identify which parts are oriented towards the problem space and which turn the focus to the solution space. Guard against changes to the problem space topics because those are where the market need shines through.

Outlining the product description

A best practice is to have your product development folks create the product description as a response to your market needs document. Then you can have a team discussion to
determine what is achievable. Here’s a basic outline of the product description; the
following section breaks these parts down in more detail:

• Executive summary: This rundown includes the product vision, objectives, scope, and risks.
• Product features: This detailed section defines the following list of product features. In Agile, this section will be at the level you know today . Agile accommodates change later on in the process. Add to the list if needed and delete what isn’t applicable:

1. Release planning
2. Functional
3. Compatibility
4. Security
5. Performance
6. Usability
7. Operational
8. Internationalization
9. Documentation
10. Support
11. Legal, regulatory , and compliance
12. Distribution and packaging
13. Miscellaneous

• Architectural vision: What is the structure of the entire development project? What tools and processes will be used to create the entire product?
• High-level scope: This section outlines the needed resources, tools, dates, and milestones.
• Risk analysis, assumptions, and open issues: As with all documents, provide a risk analysis and note your assumptions and open issues.
• Conclusions and recommendations: What is your conclusion and recommendation?
• Exhibits and appendices: Any supporting documents and further details are placed here.

Completing the product description document

The product description document is where the product itself appears. As you or your
development team creates the document, use the market needs document as a constant check to make sure that all needs have been accounted for , even at a high level for those who work with Agile. It isn’t the length of the document, but the quality of the thinking that counts.

Executive summary

Complete this section after completing all other sections. This section should be just one
page; you can even treat it as a standalone document. Explain the why , what, where, who, and when of the product.

PRODUCT VISION

Briefly describe the highest-level description of the product and the overall goal of building the solution. What are the three to five key features designed to be in this release of the product? What is the long-term vision of the product? This section provides the directional statements to help guide detailed product and design specifications. Even if your engineers are creating the product description document, this is the one section which is directly guided by product management.

OBJECTIVES, SCOPE, AND RISKS

Who are the features designed for , and what key problems, as described in the market
needs document, do they solve for the customer?
What are the required resources? What is the time frame for the release? How will this
impact the development team and other groups? What was identified in the market needs document that is out of scope for this release? You can use a product description document for multiple releases or add short versions of new documents for future releases. If items are out of scope are they documented in a road map? Out of scope here means features that unable to be developed in this release.
What are the main areas of risk and what are the associated mitigation plans?

Product features

Describe each of the features with the associated costs necessary for product management to make the trade-offs on the basis of the value-based priorities. These have been identified in the market needs document. This section also informs marketing team members what the solution will provide so they can create the appropriate market strategies. The format of a mandatory functional product feature in waterfall is:
The product MUST be able to perform or provide or have Check out the sidebar “Different ways of saying ‘maybe’ ” for optional product features. Use the INVEST criteria for creating great product features. INVEST is described in Chapter 12 .

RELEASE PLANNING

The purpose of release planning is to establish a plan and goals that the development
teams and the rest of the organization can align to for the project. Release planning
answers the questions, “How can we turn the vision into a winning product in the best
possible way? How can we meet or exceed the desired customer satisfaction and return on investment?” It also establishes a probable delivery date and cost that should hold if
nothing changes.
What is the goal of this release? What are the major risks and the overall features and
functionality? For each feature, define the following: a unique ID, the description, the
acceptance criteria and the cost in engineering terms. Use high, medium, or low or the
point system that your Agile team uses to determine how much effort a feature is to
develop. Agile point systems are often eclectic and use relative values of , for example, t-shirt sizes (S, M, L, XL).

FUNCTIONAL

What functionality does the product provide? How will this functionality help customers
achieve their goals?

COMPATIBILITY

What are the compatibility features of the product? Does the feature need to be compatible with another product or system?

SECURITY

What are the security features of the product?

PERFORMANCE

What are the performance capabilities of the product?

USABILITY

What are the usability features of the product? If needed, put wireframes (sketches of what the user will see on the screen) and other drawings in here.

OPERATIONAL

What are the product’s operational capabilities? What operational requirements does it
place on the company? For example, the product may have data center , application
servers, and/or website implications.

INTERNATIONALIZATION

What languages will the product support? Does it need to meet any other legal or
regulatory compliance to deliver product in particular countries or regions? Note them
here and under the legal, regulatory , and compliance section, if necessary .

DOCUMENTATION

What form of documentation will be included?

SUPPORT

What support capabilities will be provided?

LEGAL, REGULATORY , AND COMPLIANCE

What legal, regulatory , or compliance requirements are going to be supported?

DISTRIBUTION AND PACKAGING

How will the product be packaged and distributed?

MISCELLANEOUS

Describe how the other customer needs will be met via the product features.

Architectural vision

Briefly describe the long-term objectives of the product. What architectural issues exist?
Are new technologies or tools needed, and, if so, do they need to be obtained? Is the
company likely to build, buy , or partner? What engineering is necessary during the
product’s future set of releases that needs to be addressed now? Can technologies be
reused or created for reuse? What would the technical road map look like? Is this project
part of a platform or portfolio of products, and how do they integrate? If this project is a
platform, how will it develop over time? How do the new capabilities of this project support the business objectives and vision of the company?

High-level scope

This section gives scoping estimates to communicate to the key stakeholders (upper
management, product management, product marketing, and engineering). These are initial (rough) estimates. You determine more specific details during the project’s planning that takes place between engineering and finance.

RESOURCES

What are the resources needed to complete this release?

TOOLS

If new tools are necessary , how long will it take to have them available and integrated into the development process?

EXPECTED RELEASE DATE AND MILESTONES

What is your best estimate, given all the features and needed resources described in this
document, for the product’s release? What are the key milestones for the project, such as a prototype that can be tested or a beta version for customers to install? When can the project start?

Risk analysis, assumptions, and open issues

Identify the key barriers that may impede the processes and/or services provided by the
project. How will you overcome these barriers? How may the following affect your
company? You may simply flag the probability as low , medium, or high. Keep your answers brief . Also identify the risks to the company of not doing the product and the product development risks like technology hurdles that need to be overcome.
Record your assumptions here and be prepared to defend them. Keep tabs on any open
issues and document them as they’re resolved. Assign unresolved issues to a responsible party and identify where in the process these issues need to be settled.

Conclusions and recommendations

State your conclusion and the justification of your recommendation. This section should
include the likely effect of developing the product in the specific way outlined in the
document. Describe alternative product development options. What are the pros and cons?

Exhibits and appendices

Include larger detailed analysis, which may best be shown in table or possibly graph form.
For other data that isn’t easily included in this document, cite the references to the
external documents. Make sure all appendices are items the main document text mentions.

Plotting Your Product’s Path to
Success with a Product Road Map

Products evolve over time. Road maps are a great way to document planned changes for
product strategy , direction, and features. Chapter 21 has a lot more detail on different
types of road maps that you may find useful.

Documenting your plan to deliver product features over time is critical for getting
management buy-in, project funding, and customers who agree to buy it ahead of
production. This document is called a product road map, and it shows what you’ll
deliver and when and how the product features will support your strategy and achieve
your long-term vision.

Product road maps are a core deliverable for product managers. Here is a simple eight-step process to make sure that you don’t miss a step.

1. Decide the detail level and amount of time to spend depending on your
   audience and the purpose of the road map. Should this be a “quick and
   dirty” road map that you create in half an hour , or is it something that warrants
   you spending many hours on? How much detail do you want to include? Does it
   need to include details on all of the features in each release or can it be more
   high-level?
2. Assess the competitive moves, market, and tech trends that are the
   background into which you are developing your product. This will help
   you as you plan your product strategy and determine what a winning road map
   will look like.
3. Gather and prioritize your requirements. See Chapter 7 for prioritization
   tools.
4. Decide on the appropriate timeframe. Will your road map be short-term
   and just show three, six, or twelve months? Or is it a longer-term road map
   that is one, three, or five years?
5. Choose an organizing strategy . Use themes, golden features, timed-release,
   or other ways of organizing the releases on your road map. Refer to Chapter 21
   for details on themes, golden features, and timed-releases.
6. Build an internal road map. This should include enough details to help
   educate your team and others about where the product is headed and what to
   expect in the future in terms of product releases.
7. Get buy-in and finalize your road map. Share the road map with your team
   and executives as you are developing it. Make sure they understand your logic
   and thinking using the organizing strategy and other data. Once you have a
   final draft, get sign-off from the main stakeholders.
8. Create an external road map. Use the internal road map as a basis and then
   remove the appropriate level of detail and specifics so that it can be shared
   more widely outside of your company to give major customers, the press, and
   industry analysts an idea of how you will achieve your vision.

Eight steps seem so simple. In practice each step may involve a lot more in-depth thought.