Deliver These Eight for an Exceptional Product Requirements Document

What does highly useful PRD look like?  It will be…

1 – Verifiable. The requirements are measurable, not subjective. You can test their validity.

2 – Clear and Concise. No rambling. No cleverness, just a clear and easily understood explanation that can only be interpreted one way.

3 – Complete. The document does not require the reader to fill in gaps. All the information is there in black and white. It covers the entire scope of the product or enhancement.

4 – Consistent. Requirements are aligned. They do not conflict. You do not duplicate requirements. You define terms and maintain a consistent use of those terms throughout.

5 – Traceable. Every requirement can be traced back to a market need it is fulfilling. The document is organized with a numbering or annotation system covering individual requirements. There is a hierarchical structure that breaks requirements into smaller units while also allowing them to be traced back to the higher requirement.  The PRD must track versions so that changes in requirements can be followed.

6 – Viable. Can the requirements actually be met? Are they feasible? The PRD must lay out a plan that can be delivered with existing technology, skills, and capabilities. It must adhere to a set schedule and budget.

7 – Necessary. If the product requirements were removed, there would be a noticeable deficiency in the system. Delivery on this item can lead to prioritization discussions.

8 – Free of Implementation. The requirements should define “what” not “how”. The how the requirements will be implemented should fall to the designers. The one exception to this is when the market insists that the product meet set standards.

When you’ve developed a PRD that can successfully deliver on these eight items, you can be confident your team will have what it needs to move forward.

Advancing the Profession of Product Management
website I consulting I training I toolkits I books I blog I twitter

The post The Exceptional Product Requirements Document appeared first on Actuation Consulting.

In this week’s post, I’m going to discuss the nuts and bolts of the PRD (Product Requirements Document). Next week I’ll complete this discussion by covering some of the specifics that will be part of a good PRD.

What is a Product Requirements Document?

A PRD is a document that serves the development team. It provides details about features, functionality, and capabilities required to build the product. Obviously, if the product is a new one, the level of detail will be much greater than what’s needed for an enhancement to an existing product.

A well-crafted PRD clearly defines both the breadth and depth of the product. Done right, the PRD will move the development team beyond considering what to build to how to build. Supporting groups (packaging, creators of user manuals etc.) should understand what needs to be delivered with the product. All should understand what the customer experience should be when using the new capabilities. Finally, product requirements must be aligned with your company’s business objectives.

Four Questions Your PRD Should Answer

1. Who will use the product?

In answering this question, you should address the need the product will meet. Also cover the characteristics of the end user and how end users will actually use the product.

      2.   What will the end users do with the product?

This question covers the functional requirements the product must meet. This could be something simple like buttons to press or as complicated as a computer display. In some cases, you may need to provide a process flow for the various activities an end user will need to perform. Flow diagrams, data diagrams, sets of use cases, or content, and entity relationship diagrams can also be part of the functional requirements explanation.

      3.   What are the product’s performance requirements and design constraints?

Often called the non-functional requirements, these items define how well or how much the product needs to perform against measureable criteria. Product constraints can take many forms. They are often industry-specific. Typical considerations are environmental legal, physical, support of other products, etc.

      4.     What must accompany or support the product?

Support items are not related to the specific operation of the product. However, they are vital to supporting a smooth end-to-end user experience. Supports include such items as documentation, accessories, shipping, packaging, installation, replacement parts, and maintenance. The answer to this question can extend to cover how customer service will handle calls about the product.

Advancing the Profession of Product Management
website I consulting I training I toolkits I books I blog I twitter

The post Developing a PRD appeared first on Actuation Consulting.

When you begin developing your product roadmap, you start to envision how your product strategy will actually be accomplished. You tangibly define the phases or activities required to reach your aspiration goals. These set of activities will typically cover multiple product development cycles and define high-level deliverables. The form your roadmap takes is largely dependent upon the expectations of your organization. This can range from PowerPoint to more automated tools.

Purpose of the Product Roadmap

So what do you want to accomplish? Are you trying to attain internal and external alignment around a set of envisioned activities? Or are you also attempting to ensure an appropriate allocation of supporting resources so that your team can achieve its goals? Your organization likely has goals of its own. Organizations commonly use roadmap deliverables as a visible measure of how efficient your product team is. Make sure you not only understand what you and your team want to accomplish – but also what the organization’s expectations are. A disconnect between these two sets of expectations can spell trouble.

5 Things Normally Included

Every product roadmap needs to cover these items:

• A timeline aligned with customer purchasing behaviors or business cycles.
• Outline the market drivers that will drive deliverables on the roadmap. For instance, tradeshows, high sales seasons, or expected legislation that could impact the market, etc.
• Define the business objectives or product themes that divide the overarching timeline into phases that align with the overall product strategy and support the long-term product vision.
• Capture the high-level features being targeted for delivery in each phase.
• Optionally, include an aligned technology roadmap that reveals specific technology platforms that will be impacted by each major phase and feature list. This can be a big help in proactively aligning product and technology groups.

Four Characteristics of a Top-Notch Product Roadmap

It should:

• Be crafted in such a way that it can guide each of the planned phases and project priorities.
• Align with your product vision and strategy and provide a plan for delivering on what these documents promise.
• Include a plan around resource requirements that the executive team supports.
• Is not so set in stone that it cannot be updated along the way as market changes occur and progress is made.

Advancing the Profession of Product Management
website I consulting I training I toolkits I books I blog I twitter

The post What is a Product Roadmap? appeared first on Actuation Consulting.