Creating a Good PRD

Creating a Good PRD Tellme

Angus Davis <angus@tellme.com>

Last updated June 18, 2001

Tellme Confidential

Summary
Good product managers plan and manage their products using a product requirements document, or PRD. The PRD is the nexus point of all
product planning, serving as the consistent point of truth on any project or product development effort for a wide range of audiences. Few
things are more critical to a product's success or to a product manager's effectiveness than the PRD.

Creating a PRD involves much more than just writing. Product managers must gather requirements from the
market, understand our own product capablities, and balance these two needs against available knowledge of
competitive offerings. These three forces pull our product planning efforts in different directions. The
challenge in creating a PRD is to balance the tradeoffs between these forces and set a direction for the product.

The PRD is the heart of a project; it pumps life into all other documents, plans, and efforts. QA test plans,
operational deployment plans, marketing launch plans, documentation plans and financial plans are all based in
large part on the contents of the PRD. Questions ranging from an engineer's "What do I build?" to a public
relations manager's "What do I announce" are answered by the contents of the PRD. The PRD is not simply a creation challenge, it is a
management challenge. Good product managers drive their projects from the PRD, continually updating and improving it while keeping the
project on course.

While designed primarily for product managers who want to adopt best practices, this doucment is also useful for anyone interested in the
importance of PRDs or the role of product mangement. It is organized as follows:

I. Stating the Mission

II. The Whole Product
III. Setting the Goals
IV. Identifying the Team
V. Planning the Milestones

1 of 10
Creating a Good PRD

VI. Explaining the Requirements

VII. Highlighting Issues & Risks
VIII. PRD Template

Stating the Mission

Good PRDs must answer the question, "Why are we doing this? What is the purpose of this?" To do that, they should clearly articulate a
mission for the project. For example:

"Convert call center integration from a liability into a competitive weapon." (Tellme CTI Connect)

"Build the most scalable, interoperable, available, manageable messaging system in the world, bar none -- and beat Lotus Notes'
run rate in deployed seats" (Microsoft Exchange 5.5)

"Get to 30% browser share in 12 months." (Microsoft Internet Explorer 3.0)

"Faster, smaller, better." (Microsoft Internet Explorer 5.0)

An effective mission statement is:

A bedrock foundation for goals. The mission serves as the bedrock foundation for goals, which in turn serve as the foundation for
everything else in the PRD.
Understood by all. Everyone involved with a project, from technical support to marketing to engineering, should be able to understand
the mission.
Built to last. Accomplishing a mission requires a sustained, intense effort. It is better to have an unchanging mission driving goals that
adapt over time with progress than the other way around.
Give purpose to team. The mission serves as a rallying cry for the team and should give every contributor a sense of purpose.

The product manager is the CEO of the product, and in this leadership capacity, he or she must set and communicate the
high level direction. The mission is a key part of this. Good PRDs should state the mission for the product clearly, at the
beginning of the document. Some tips on crafting the mission:

Ask around. Ask customers why and contributors they think we should offer a new product, and synthesize these.
Ask employees, influencers, customers, partners. It is critical to include feedback from the field and from customers.
Identify the source. Are we doing this because customers need it? Want it? Because we're in pain and this will help? Because
management said so?

2 of 10
Creating a Good PRD

Envision the goals. As you begin to synthesize an understanding of the mission or purpose for this product, imagine what the goals
would be, and how they would relate back to an overarching mission.
Know what's good for them. Customers don't always realize they need something, but once presented with the idea, they want it. Just
be sure to test the idea out on them before implementing it.
Beware of technology missions. Beware of missions based purely on a technology interest, and not a market one. Consider Netscape's
mission to build a Java-version of the browser, nicknamed "Javagator." The mission was to build a Java-based browser. It had lower
quality, lower performance, fewer features and higher total cost of ownership than the incumbent product. Ick. No wonder it never
shipped.
Motivate with the mission. If part of the mission is to kick Lotus' ass, then that's good, because it envigorates the team. Teams are
motivated by a strong mission and sense of purpose.

Although this section has not been given adequate thought or input, potential missions for products underway at Tellme may include things
like:

"Enable the creation of voice services in North America and Europe that fundamentally improve the caller experience while
integrating with telecommuncations networks and the Internet at the highest levels of reliability, resulting in lower costs and more
satisfied callers." (Voice Application Platform)"

The Whole Product

Reading Crossing the Chasm will give you a brief overview of the "whole product model" concept
introduced in Ted Levitt's The Marketing Imagination -- the concept that a product really has four
perceptions:

1. Generic product: This is what ships "in the box" and is covered by the generic contract. For
example, Tellme's Voice Application Platform.
2. Expected product: This is the minimum configuration of products and services necessary to
have any chance of achieving the buying objective. For example, the platform (generic
product) plus the associated network infrastructure, operations service, and toll-free telephone
number.
3. Augmented product: This is the product fleshed out ot provide the maximum chance of
achieving the buying objective. For example, the expected product described above plus
Tellme CTI Connect and readily accessible integration partners.
4. Potential product: This represents the product's room for growth through follow-on offerings and customer-specific enhancements
made by the likes of professional services, systems integrators, resellers, etc.

3 of 10
Creating a Good PRD

Even when considering the "Generic Product" only, product management frequently overlooks key componments that are critical to the
success of a product, and should be addressed in a good PRD:

Account Management. Should account management sell this new product to existing customers? Do they need to communicate any
changes to these customers?
Business Development. Do we need to partner with a supplier or distributor? Does our product open up a new type of sales
opportunity?
Channel. Should the channel sell this new product? How will we tell them about its availability or include them in the planning
process?
Documentation. Do we need written documentation in the form of a technical manual, how-to guide, administrators guide, etc.?
Field Marketing. How will we price the product? Should we update our standard sales presentation to include any information about
it?
Finance. Do we need to buy anything? Will we ever bill customers for this product?
Legal. Do we need to license anything? Do we need to ammend our enterprise sales agreement or service level agreement?
Operations. Will we have to deploy any new infrastructure or make any changes to existing infrastructure? Will we monitor for
reliability?
Professional Services. Can professional services use our new product to build solutions for customers?
Provisioning. Do we need to order and install any new networking infrastructure?
Public Relations. Can we announce our new product in a press release, demo it at a conference, or talk about it on an analyst tour?
Product Marketing. Should we create a data sheet or customer FAQ for this product? Can we put them on our Web site?
Sales. Have we included feedback from sales in our planning? Can we train the sales force on how to sell this product? Do we need to
incent the sales team to sell our product differently through the compensation plan?
Sales Consulting. Should we train the sales consulting team on the technology behind our new product?
Standards. Is there any opportunity to improve our standards leadership with the new product?
Support. Will customers or partners ever ask questions about how to use this product? Should we train support to answer those
questions?
Testing. How will the QA team test our new product? Is there a test plan?

In Moore's book, he offers a simplified view of the whole product model (see page 115), which helps explain why this concept is so
important, especially in the context of a PRD. The book was written in 1991, but the point sticks: PRDs need to describe the whole product
requirements, not just the feature list for the generic piece that, while critical, must be surrounded by other pieces in order to be successful. In
addition to nailing the "Generic Product," strong product managers must consider the other pieces of the puzzle. Below is an example of the
simplified whole product model alongside a version customized for Merrill Lynch's purchase of Tellme CTI Connect, which is itself only an
"Additional Software" component of Tellme's total solution offering:

4 of 10
Creating a Good PRD

Simplified Whole Product Model ... ... for ML's CTI Connect Purchase

The trick in applying this example to a good PRD is in looking at what "additional stuff" is required for a customer to be truly successful with
the new product. For example, Tellme's Voice Application Platform requires a Web server ("Other Hardware", "Other Software") with a
connection to the Internet, perhaps one with more bandwidth than whatever the customer has today ("Cables"), etc.

Product managers may want to devote a section of the PRD to list all the pieces a customer needs in addition to the "Generic Product" to get
the more complete "Expected", "Augmented", or "Potential" products. The may also want to call out relevant areas from the list above, such
as PR, marketing, sales training, etc.

Setting the Goals

Goals serve as specific objectives that drive all sorts of subsequent decisions -- they act as guideposts in both planning the work and in
working the plan. People that write books about goals like to preach the SMART gospel, making all goals:

Specific. Instead of saying "The extranet should be secure" it would be better to say "The extranet meets the demanding security needs
of financial institutions."
Measurable. Instead of "Massively scalable" or "Most scalable" say "Scales to 1000 transactions/second."
Attainable. Is "scaling to 1000 transactions/second" actually attainable? Would 750 be more realistic? Speak now or forever hold your

5 of 10
Creating a Good PRD

peace...
Relevant. Do we really need to "scale to 1000 transactions/second" or would that represent massive over-engineering given that we
don't expect to perform more than 180 transactions/second in the next 12 months?
Time-bound. It is best to tie a set of goals to a particular time frame, e.g. "Q4" or to break down goals by time frame, e.g. "99.00
extranet availaiblity monthly average (Q2) going to 99.5% in Q3."

This is a good start. Other things to consider when setting goals in a PRD:

Comprehensive. Can every feature or decision in the product planning effort relate back to a specific goal? If not, we should cut the
feature or more clearly articulate the goals.
Understood by all. Everyone from engineering to marketing to sales to support will be working on some aspect of the product at some
time. If they don't understand the goals behind our effort, they will not be able to effectively execute against those goals.
Agreed-to. Product management requires management by influence -- even the best product managers cannot "impose" the goals. Work
carefully and quickly to build support in the organization behind the goals in the PRD, leveraging other managers wherever possible.
Understand trade-offs behind goals. For example, if the company were to exit a key customer vertical, such as financial services,
would security still be a goal? If the answers to any questions like these are yes, make sure we note that, so the company understands
the cost of pursuing different market strategies.
Be specific about specifics. If a goal says, "Meet all contract commitments for reporting," the PRD should somewhere list exactly what
those commitments are, or include links to documents that contain that information.
PRIORITIZE. Few things are as important as prioritizing the goals. Later, making the right feature trade-offs will depend on having
made the right goals prioritization. Make sure to check the prioritization with key advisors, such as customers, SCs, sales directors,
managers, etc.

Obviously the greatest challenge in goal-setting is picking the goals, not communicating them. To do this for a product targeted at large
enterprise customers, good product managers must pick goals based on intense consultation with the market. Identify several outside advisors
in a given market, and bounce ideas and questions off them. In addition to understanding what the market wants, figure out what the
competition has to offer. Here is a simple task list to follow when setting goals:

1. Talk with the market. At the very least, talk with regional sales directors, sales consultants and account managers to get their input on
whether the goals are on target. Preferably, talk directly with customers. The desired result is a goal that, when achieved, allows the
product to meet or exceed customer expectations.
2. Research competition. Get sneaky -- use every resource from DiOrio to Google. If planning a reliability goal, get their SLAs; if
planning a speech platform goal, get their SDK, etc. The purpose of this effort is to be sure that achieving our goals will result in a
product that is competitive.
3. Put it all in context. Make sure goals leverage our own internal strengths and core competencies. For example, if speech recognition is
a key competency, find a way to leverage that advantage in the goals.

6 of 10
Creating a Good PRD

Identifying the Team

The Summary tells readers why we're doing it, and the goals explain how we'll achieve the mission. The "Team" section of a PRD is a small
but important answer to the question of who is accountable for achieving the goals. Although it seems relatively simple to list the contributors
on a project, it is important to remember a few things when crafting this section of the PRD:

Motivate with inclusivity. If contributors aren't listed here, how can they feel like an important resource in accomplishing the mission?
Make people feel important by listing them -- because they are.
Advertise accountability. Few things are as effective at getting contributors to be accountable and responsible for "doing their part"
than broad public knowledge of the important role they play and the expectations the team has of them. Write down who is accountable
for what.
Make it clear who's leading. Many people reading the PRD won't be on the team. For them, it is critical to know who to contact if they
have a question. Put leaders (product manager, dev lead, etc.) at the top of the list to make it clear who is managing the effort.
Remind readers of product management. It is worth mentioning in the team section that any questions about the product features,
schedule, strategy, etc. should be directed to the product manager.
Include contact information. Provide a link to appropriate email addresses or directory entries for each contact.
Include extended team members. This could be a good place to list key customer contacts, advisors, partner contacts, etc.
Don't over-do it. The team section doesn't need to read like an Academy Awards acceptence speech. Keep it simple and short, and
don't let your ego get carried away.

Planning the Milestones

Milestones answer the "When?" question, and all good PRDs should list the high-level project milestones. Note that the PRD is not meant to
be a detailed engineering schedule that looks like output from Microsoft Project or some such beast. Suggestions on defining milestones:

Be specific. If "queuing support" really means "queuing support prototype in the labs," call this out so readers don't assume the
milestone refers to production-readiness of a particular feature.
Give it a name. Whether it's something generic like "M1, M2, M3, Beta, GA, etc." or something creative like "Jack'o'Lantern, Solstice,
etc." (for milestones occurring in late October and mid-December), milestone names facilitate communication.
Show some progress. Milestones should allow the team to demonstrate its progress towards the goals.
Less is not more. Milestones every 2-6 weeks let the team celebrate success early and often to build momentum and morale. But it
doesn't make sense to have "too many" (i.e. 15) milestones.
Jingle Bells. Don't forget holidays, maternity leaves, etc. when setting milestones. A good time for a milestone is right before
traditional holidays/vacations.
Anchor milestones to something solid. Milestones set arbitrarily in time are more likely to slip, then, say, milestones tied to a keynote

7 of 10
Creating a Good PRD

demo at Comdex where the CEO will demo the newly polished product before 50,000 people (note the "Advertise accountability"
suggestion above).

Explaining the Requirements

When most people think of a PRD, they think of a list of a requirements (a/k/a "features"). The majority of a PRD is
about setting the right high-level direction, not picking individual features. Before explaining requirements, a good
PRD should state the mission, set the goals, identify the team and lay out milestones for progress towards those
goals. Throughout this process, it is critical to plan the whole product, as described earlier.

The first step a good PRD takes in listing requirements is identifying the "buckets." For example, here are some
buckets for two Tellme products and a car:

Tellme Voice Tellme CTI 4-Door

Application Platform Connect Sedan
Engine
Speech input
Routing Transmission
Telephony
Reporting Interior
Audio output
Queuing Audio System
Notifications
etc. Exterior
etc.
etc.

Buckets should cover all aspects of the product needed to be successful. For example, we discovered relatively late
in the development of our platform product that "Notifications" would be necessary to achieve our goals. Similarly,
we discovered we needed a platform-only billing solution to satisfy the needs of our reseller partners. These sorts of
mistakes are costly and painful. Ask yourself whether the buckets identified in the PRD will really enable us to
achieve all the goals.

This is a place to remember the whole product, and ask whether we need any documentation, operations support, training, etc. It is fine to link
to other plans here; for example, a bucket called "Testing" could simply link to a QA Test Plan. However, it is imperative to list every
requirement for the product to be successful.

Prioritization is one of the most critical jobs a good product manager performs. Once the buckets are identified, prioritize them as follows:

8 of 10
Creating a Good PRD

Prioritize against the goals. If exceeding certain reliability targets is a higher priority goal than delivering the most feature-rich
environment, it probably makes sense to prioritize the reliability-related feature bucket above the feature-rich environment-related
feature bucket. In short, line up requirements priorities against goal priorities.
Check prioritization with advisors. Good product managers are not paid to be omniscient. To the contrary, the best product managers
are those who can effectively measure and synthesize outside expert opinions to make prioritization decisions. Once you've made the
prioritization call, check it with customers, SCs, sales directors, managers, etc.
Communicate the prioritization clearly. Once the prioritization decisions are made, clearly communicate them in the PRD and
elsewhere. This allows everyone to more effectively balance their time and resource allocation to line up against the most important
work.

With the buckets identified and prioritized, the PRD should list individual requirements in sections split by bucket. The "bucket" process
yields a high-level summary of the requirements. The purpose, then, of the individual requirement details is to be specific. If there is any
possibility that two people could interpret the PRD's description of a requirement differently, that description is not detailed enough.
Remember that the PRD's audience contains technical and non-technical contributors, so choose wording carefully and include additional
explanations where necessary. Order the list by priority. Each requirement on the list should contain the following information:

Description. What it entails -- as specific and detailed and measurable as possible.

Milestone. When it will be available to customers as described. (Unless the description specifically says "prototype in the labs," or
"beta," or some other qualifier. By default, all milestones are assumed to be customer-facing)
Owner. Who is accountable for implementing it (could be several people).
Priority. What the relative priority is.
Goal. Why we are doing this -- just reference one of the goals already listed, perhaps offering a more specific explanation if
appropriate.

Highlighting Issues & Risks

Imagine for some reason, in a few months, the product is a complete failure, or has slipped terribly, or some other very bad thing has
happened. All the fingers are pointing to you, the product manager. Yikes! Now take a moment to be glad that this is just your imagination,
but think seriously about what could have led up to that point. Are there any risks or issues that could potentially block the success of this
product? This is the section of the PRD to list them.

Just as important as identifying and communicating the risks is to be proactive about heading them off. Thus, when listing the issues, be sure
to include mention of what steps you or other contributors are taking to mitigate the risk or eliminate it altogether.

PRD Template

9 of 10
Creating a Good PRD

Formatting style and syntax will not make or break a good PRD. However, good PRDs should answer the following questions when
considering the whole product:

1. Why are we doing this?

2. What are the prioritized goals?
3. Who is accountable?
4. When are the milestones?
5. What are the prioritized requirements, both at summary and detailed levels?
6. Are there any risks?

Answering those questions effectively will yield a good PRD. Maybe even a great one. Some frequently made mistakes are:

1. Minimal or no regard for "the other stuff" that makes a whole product successful (i.e. documentation, marketing, integration partners,
etc.)
2. Decisions made in a bubble -- inadequate checking w/ outside advisors (customers, etc.)
3. Lack of prioritization of goals, features, etc.
4. PRD is almost all "marketing fluff" and reflects lack of engineering consideration
5. PRD reads like an engineering functional spec and reflects lack of market focus

10 of 10