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.

Just look at what the Project Charter should cover…

• Project scope
• Project objectives
• Deliverables
• Schedule
• Required resources
• Communications plan
• Risk management
• Project monitoring
• Controlling procedures for the project

Anyway you look at it, that’s a lot to cover in one concise document!

A Few Things the Project Charter Should Accomplish

After reading the project charter there should be no doubt who is in charge of the project. It should be clear who has authority. Just making this fact clear is extremely important if the organization has a matrix environment.

When you’ve read the project charter, you should know:

• The purpose of the project
• It’s benefits and objectives
• What project success will look like
• Name of the project sponsor
• Stakeholders
• Budget
• A description of the product and deliverables

Points Typically Included in a Strong Project Charter

When the charter has been put together, you should be able to look at it and understand why the project was undertaken. You should know any objections and constraints that are on the project. Main stakeholders should be identified along with target benefits of the project. There should be a clear description of in-scope and out-of-scope items along with a high-level risk management plan and high-level communication plan. Finally, there must be a high-level budget and arrangements for spending authority.

How Can We Know We Have a Top-Notch Project Charter?

There are four signs that you’ve crafted a project charter that can heft the weight of your undertaking:

• Project stakeholders not only approve the charter, but also assign the resources you need to begin.
• The project charter can be used, referenced, and evaluated by even a new executive in your organization.
• Clear decisions are made about who owns the budget and who is managing it.
• The executive team has agreed to be accountable for certain measurable and achievable objectives.

With the rise of Agile practices some may question the value of project managers. However, project managers have had to redefine their role to address changing business needs, often moving upstream to the enterprise level. Project charters remain an important tool to ensure the effective coordination of complex projects and work efforts.

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

The post Crafting A Project Charter appeared first on Actuation Consulting.

Defining a Product Vision Document

The Product Vision document looks into the future. It presents a 30,000-foot view of what you plan for the product to be in the future and its anticipated value.

The Role of the Product Strategy Document

Your Product Strategy document explains what high-level actions will need to take place in order for your product to live up to the anticipated deliverables in the Product Vision document. Just as important, the Product Strategy document sets boundaries for activities that should not be pursued.

It’s easy to understand why these two vital documents are often presented together.

Three Things Product Vision and Strategy Should Provide

A well conceived Product Vision and Strategy will:

• Present a statement about what you envision the product will be in the future and how it will benefit its market.
• Cover high-level actions that must be taken in order to fulfill the promise presented in your document.
• Outline measurable objectives that include both short and long-term goals as they relate to the product.

Characteristics Specific to a Well Developed Product Vision

• Present a clear view of where you see the product in one year or perhaps many years, depending on the product lifecycle.
• Define your target customers and how the product will help them solve challenges. Clarify the value to be derived from the product.
• Set a high bar that pushes product team innovation.
• Make sure that the level you set is high enough that it won’t change every time there’s a shift in market dynamics.

Characteristics of an Excellent Product Strategy

A well thought out product strategy can set the stage for your product roadmap. Your Product Strategy needs to offer clearly defined phases that lead up to meeting the Product Vision. It should include the key activities your product team will undertake toward meeting the Product Vision. Your Product Vision acts as your north star guiding your decisions. However, your Product Strategy will evolve over time in response to changing market conditions.

Your Product Strategy should also be centered on objective time lines associated to business metrics related to customers, the competition, the market, or financials. You also need to include shorter-term milestones with specific deliverables. Make it clear all along the way what the next steps should be.

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

The post Developing A Product Vision and Strategy appeared first on Actuation Consulting.

What Does an MRD Look Like?

Your MRD can take many forms. It can be a simple document, a wiki, a spreadsheet, a unique software tool, or something else you devise to fulfill this important step in your process. The potential of the project will dictate the form your MRD should take.

The Core of the Market Requirements Document

There are essentially two things at the core of your MRD:

1 – A clear definition of your target market. This is basically a vivid picture of your potential buyer and user profiles. What are the key reasons someone would use the product?

2 – Defined problem scenarios – What are the main challenges your users face that will cause them to turn to your product. These likely will vary between buyers and end users. You’ll want to develop problem scenarios for each.

Functional and Non-Functional Requirements

Requirements that must be dealt with in the Market Requirements Document fall into two categories: function and non-functional. Here’s the difference.

Functional requirements cover capabilities that have interactivity with the user. They deal with specific high-level functions a user may want to perform.

Non-functional requirements are concerned with design restrictions and performance factors involved with the product. Performance factors cover how well a product must perform. Design restrictions revolve around how much a product must support.

Common Non-Functional Requirement Categories

There are many different categories of non-functional requirements including many that are industry specific. Here are some of the most common categories:

• Physical requirement – Maximum and minimum dimensions, weight, packaging, sturdiness, etc.
• Environmental requirements – the environment in which a product must be operated or stored.
• Performance requirements – This category can include such things as expected speed for specific operations, what are the lifetime expectations for use, etc.
• International requirements – where the product will be sold and used. What are the language, currency, power supply, and specific localized needs?
• Compatibility Requirements – How does the product need to work with other products?
• Documentation requirements – What are the types, formats, and delivery methods for documentation?
• Support requirements – What must be available to customers to help them with installation, repairs, operation, payments, maintenance, and disposal of the product?
• Legal, Regulatory, and Compliance requirements – What laws, rules, and government or agency-related requirements impact the product?
• Distribution and Packaging – What is required to distribute the product and how does it need to be packaged?

What to Include in a Successful MRD

There are essentially six key elements of a successful MRD.

1. As mentioned above: You must include a definition of your target market, a vivid picture of your potential buyer and user profiles.
2. A comprehensive list of market requirements the solution will need to fulfill.
3. Suggested quantitative measures of success for each requirement.
4. A prioritized list of requirements from your market’s point of view.
5. A clear focus on the market problem you are trying to solve, not on your planned solution.
6. A timeframe for product introduction and a supporting rationale.

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

The post What is a Market Requirements Document (MRD)? appeared first on Actuation Consulting.

Before we drill down into Storyboarding and Flow Diagrams, let’s take a moment to think about the purpose of the problem scenario.

Purpose of the Problem Scenario in Product Concept Investigation

All problem scenarios must illustrate challenges faced by users while attempting to reach a specific goal. This includes exposing the limitations of current solutions in the marketplace.

An effective problem scenario promotes:

• Clear understanding of the situation a user faces in trying to reach a goal
• An accurate definition of the goal the user is seeking to achieve
• A strong understanding of how consumers are currently reaching this goal
• The frustrations felt by customers using current solutions
• A revelation of the opportunity you have to flush out new ideas to reduce or eliminate frustrations with current solutions
• A wide open path for the presentation of bold, fresh ideas that could dramatically improve the customer’s experience

Storyboarding as a Method of Product Concept Investigation

One of the great strengths of Storyboarding is its ability to make an idea instantly understandable to your team. In contrast, the simple story method of product concept investigation requires the audience to read through the whole written description. Only when the reading is complete will the team understand where you are going and what you are suggesting.

Storyboarding combines illustrations (ala comic books or cartoons) with individual written steps to deliver your concept. Your audience can quickly grasp where you are taking them with the storyboarding methodology. The one danger is that you can over simplify your ideas and therefore leave out critical details that would be clear in a fully written out concept (simple story).

Now, let’s consider another approach to the Problem Scenario, Flow Diagramming.

Flow Diagramming

If collaboration between individuals or departments is vital, the Flow Diagram is an excellent tool for sharing your ideas.

The Flow Diagram essentially shows how a solution would flow through your company’s various departments on its way to completion. Each handoff point and step will be clearly shown on the diagram so everyone can see exactly where their department fits into the overall sequence.

Looking Forward

Next week we’ll move away from the Problem Scenario approach to product concept investigation. We will take a close look at the Competitive Analysis Matrix and its uses, advantages, and disadvantages in the product development process.

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

The post Storyboarding and Flow Diagrams appeared first on Actuation Consulting.

Problem scenarios are a good way to take a high level look at what an ordinary customer might encounter, the problems they need to solve, and the challenges they face in doing so.

A mother may need to provide a nutritious but easy to prepare meal for her busy family.  They need a quick meal, but not just any fast-food pickup. It needs to be healthy, quick to prepare within tight time constraints, and tasty.

Problem Scenarios – Different Types

A problem scenario can take different forms depending on the product concept under consideration and the level of detail you want captured in the scenario.

The first type of problem scenario is the Simple Story. This can include a few paragraphs or a few key bullets. Key elements to include in a Simple Story are:

• Who is the primary persona in the scenario? Usually there is one, but sometimes there can be several, depending on the product.
• What are the location and timeframe for the scenario? Does it occur at home, in the office, or somewhere else?
• What is the goal of the persona? What is the high-level objective the persona is trying to achieve. For example: Provide a quick to prepare, tasty, and healthy meal, hear music on a patio, etc.
• What are the common steps taken to achieve the goal? What are the most basic tasks a person will need to undertake to reach the goal? These should illustrate the challenges and frustrations the persona encounters in the quest. These also should encompass how the persona would proceed using current solutions and products available in the market. The result of this step will be a complete start-to-finish set of activities. It will give a bird’s eye view of the situation.
• What major decisions must the persona make during the workflow? If the product is complex, such as software or services, there may be several paths that can be taken depending on decisions made. For example, let’s consider a product team attempting to create an online order form. Decisions the persona would need to make might include which credit card to use, do they want gift wrap, where will the item be sent, how much does the persona need to purchase in order to get free shipping, and that’s just the start of the possible decisions.

Looking Ahead

Next week we’ll take a look at another type of problem scenario you can use in your product concept investigation: Story Boarding.

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

The post Problem Scenarios as a Device appeared first on Actuation Consulting.

Choosing the Best Product Ideas and Features to Advance

Today, we’re going to look at a tool many organizations find useful in helping them determine how to proceed. This tool, the Prioritization Matrix helps product teams score the various product concept ideas under consideration so they can make well-reasoned decisions.

When myriad product ideas are floating around, this systematic matrix approach will help ideas with the most potential rise to the top so they can receive further study.

You can use this same Matrix approach to consider various features you may want to add to a product. The Prioritization Matrix pulls the cream of the ideas to the top and lets the sludge sink to the bottom and ultimately disappear.

Choosing Matrix Criteria

Your Prioritization Matrix can include any criteria that align with your organization’s goals and objectives. Some commonly used criteria are:

• Is the market attractive?
• Can you be competitive?
• Is it a good time to enter the market?
• What’s the market’s potential value?
• Can you differentiate your product from others out there?
• Is there a strong projected return on investment within a set period?
• Does the proposed product align with your company’s goals and objectives?
• How does the estimated cost of development compare to the size of the
  opportunity?

Here’s a virtual example of what a Prioritization Matrix might look like:

Using the scoring scale, each of the criteria earns a score of 1,2,or 3. For clarity and to avoid individual subjectivity, it’s smart to specifically define each measure. For example for Market Attractiveness high would equal market growth of greater than 5% along with a market size of over 2M potential customers. Once you’ve defined your ranking scale numbers, your team should rate each criteria and total up the scores for each idea under consideration.

Naturally, at this point the scoring will be fairly subjective. That’s ok because you are not at the point of constructing a financial forecast. You are simply considering which ideas are the most deserving of additional consideration.

Building in Automatic Stops

You need to build some automatic stops into your Matrix. For instance, if an idea does not strategically align with your company’s strategy or objectives, it must be dropped from further consideration. Additionally, at the outset you should agree that products that do not garner a predetermined minimum total points will be discarded.

The systematic Prioritization Matrix approach is an excellent way to increase effective use of your resources. Don’t become discouraged if a majority of ideas don’t measure up on the Matrix. This is a common occurrence that can often lead to a positive: your valuable resources not being wasted on lackluster ideas.

Looking Forward

Next week will take a look closer look at Product Concept Investigations, beginning with Personas.

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

The post Pursuing the Right Product Ideas or Features appeared first on Actuation Consulting.

The GE-McKinsey Matrix

The GE-McKinsey Matrix simply gives your organization more nuanced options for how products are categorized. Instead of just four boxes, the grid now includes nine. By replacing Market Growth (used on the BCG Growth-Share Matrix) with Industry Attractiveness, you have the option of weighting your decision based on such factors as:

• Size of the Market
  • Intensity of the Competition
  • Market Growth

The result often is a clearer view at your product mix and opportunities.

The GE-McKinsey Matrix Horizontal Axis

As with the vertical axis, the relabeling of the horizontal axis from Market Share to Competitive Position opens up new ways to examine your market. Now, you can factor in other corporate strengths such as:

• Brand Equity
• Your Company’s Core Competencies
• Distribution Strength

Nine Boxes Vs Four

With the GE-McKinsey grid, you have nine possible options of how to view products. Your alternatives now range from clear winners to invest and grow to products you need to phase out and cut loose.

Elements of a Good Product Portfolio Management Process

No matter which analysis method you choose, you need to be sure it includes the following:

• Allocation of resources that aligns with your corporate goals across multiple product activities
• A balance of product activities with diversity across products you currently have and what you’ll need to develop as tomorrow’s winners; current and future markets; and short-term versus long-term revenue sources

Upcoming Post

Next week my post will take a look at the SWOT Analysis and how it will help you gain a clearer view of your product’s current and prospective standing.

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

The post The Value of the GE-McKinsey Matrix appeared first on Actuation Consulting.

This post discusses the sixth and final key finding gathered from the analysis of the latest Global Study of Product Team Performance.

#6 Key Performance Indicator

Product Teams that Believe Their Effectiveness Would Be Improved by the Use of Product Tools and Automation Are Likely to Be High Performance Teams in Companies that Achieve Their Financial Goals and Objectives.

Just over 50% of our survey respondents are members of technology development teams. For this reason, this finding is particularly meaningful to technology development organizations.

Desire to Improve Tools and Increase Automation

The sixth indicator of high performance is essentially possessing the desire for improved tools and increased automation. Organizations that have implemented effective team processes often seek out ways to further improve efficiency.

This indicator points to the rapid uptake of DevOps and the Extreme Programming (XP) practices that underpin it.

This particularly points to:

• Test automation of every kind starting from the practice of test driven development
• Refactoring (and tools that automate refactoring)
  • Continuous integration, continuous delivery, and continuous deployment (and
  the automated build tools and application release tools that support these
  practices)

The up swell of enthusiasm for test-and-build automation has driven strong tool development and rapid tool advancement. This includes having check-ins kick off build scripts that not only compile binaries, but also generate documentation, tests, and statistics. They also kick off test automation, plus generate and deploy distribution media, website pages, and program logic to servers.

In addition, on the operations side, tooling like continuous configuration automation enables automated rollout of both physical and virtual infrastructure. The result is that teams with effective team processes find themselves continuously looking with longing for the latest – and the latest is rapidly evolving.

Next Post: Wrapping It All Up

For several weeks now we have delved into the responses and analysis of the latest Global Study of Product Team Performance. Next week, we reach the conclusion when I will share a few final thoughts on this interesting survey and its outcomes.

Recap of the Six Key Performance Indicators:

1. High performing teams have a clear definition of “done”.
2. Respondents unable to associate a product development methodology with product profitability are unlikely to be on a high performing team.
3. Respondents who believe using Agile/Scrum leads to high product profitability tend to be in organizations that meet or exceed their financial goals.
4. Teams that consider development cost as a criterion for requirements prioritization are more likely to under-perform (i.e., negatively correlated).
5. There is a strong correlation between an effectively prioritized backlog and high product team performance
6. Product teams that believe their effectiveness would be improved by the use of product tools and automation are likely to be high performance teams in companies that achieve their financial goals and objectives.

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

The post Product Tools and Automation appeared first on Actuation Consulting.