Extended Review of Market and Product Requirements
Introduction
Requirements are a robust and proven technique for representing different levels of information required for product delivery.
This review lays out the boundaries of using requirements according to the Blackblot Procedural Requirements™ model and the principles of the Blackblot PMTK Methodology™.
Product Delivery Process
Product delivery is a staged process of bringing a product to market.
Product delivery describes how a company goes through several internal stages, resulting in a product being offered to customers.
The Blackblot Product Delivery Process is comprised of three stages:
1. Product Planning — describe the market problem.
2. Product Definition — describe the solution and how to build it.
3. Product Development — build the solution.
Types of Requirements
Different types of requirements represent each stage in the Blackblot Product Delivery Process.
1. Market Requirements — describe the market problem in the product planning stage.
2. Product Requirements — describe the solution in the product definition stage.
3. Technical Requirements — describe the solution’s technical implementation in the product development stage.
Roles and Deliverables
Each stage in the Blackblot Product Delivery Process is owned and managed by one role that produces a deliverable with specific requirements representing information particular to that stage.
1. Product Managers create market requirements in a Market Requirements Document (MRD) in the product planning stage.
2. Product Architects create market requirements in a Product Requirements Document (PRD) in the product planning stage.
3. Engineers prepare technical requirements in technical documents, collectively named Technical Specifications (Tech. Specs.) in the product development stage.
The Market Requirements Document (MRD)
The MRD expresses the market problem in a way that allows developers to offer a solution.
The MRD contains a description of the market opportunity, market problem, and the resulting market requirements.
The most significant component of the MRD is the market requirements which detail the functionality sought by the collective users to address their market problem.
A market requirement is an aggregate unit of information that represents with sufficient detail the functionality that the user seeks to address a specific facet of a particular market problem.
For the most part, market requirements stand the test of time, and the need they express fundamentally does not change over time.
MRD and Requirements Clarifications
The MRD is not a process; it is a deliverable.
The MRD is not a tool explicitly confined to software development or any other technology product.
The MRD and the Blackblot Procedural Requirements™ model for preparing market requirements can be used to plan any business or consumer product or service.
Market requirements are the only type of requirements in an MRD.
Market requirements do not describe the product’s features, physical attributes, or technology.
It’s important to note that the expression of market requirements does not change or expire when the technology or the solution evolves.
User, customer, business, and marketing requirements have different meanings, some more ambiguous than others, and are not synonymous with market requirements.
The MRD does not contain marketing, business, or product assessments and information that are part of a Product Requirements Document (PRD), Business Case, or Market Plan.
Voice of the Customer (VOC) is a process for eliciting needs from customers. The VOC is performed in preparation for creating an MRD.
The Benefits of Using MRD
The Market Requirements Document (MRD) is based on prior and continuous market research; therefore, it encapsulates established market knowledge and represents a true understanding of customers and their needs.
Developing a product without an MRD will result in “Research-oriented Development”, a condition where the product development effort begins while there are incomplete, ambiguous, or missing market requirements.
This forces further learning of the market and cause occasional readjustments to the product’s feature set while the product is being developed as more market knowledge is gained.
Although possible to reach the same product feature set with or without an MRD, it is the general opinion that with an MRD, the effort required and the time duration needed to deliver a product are less than those without an MRD.
Less time and effort support the notion of cost-savings when using an MRD as opposed to not using an MRD.
MRD Quality Metrics
Writing a Market Requirements Document (MRD) is akin to telling the story of a particular market problem that customers have, yet doing so in a formal language that product developers understand and can work with to offer a solution to that market problem.
There is no universal, mechanical, and measurable way to determine the quality of an expressive work as an MRD.
There are no quality metrics to measure or grade a market requirement’s articulation level.
Finally, although it is possible to logically verify the existence of traceability between a market requirement and the related product requirement(s), there is no qualitative way to measure the suitability that the assigned product requirement(s) provide to the demands posed by the market requirement.
So when writing requirements of any kind, the quality of work will always come down to the competency levels and judgment calls made by proficient and knowledgeable product planners and product architects.
Requirements Misconceptions
Misconceptions exist regarding requirements documents, particularly the Market Requirements Document (MRD) and the Product Requirements Document (PRD).
The MRD and PRD are tools that manifest a specific technique and represent information levels.
The MRD and PRD can be efficiently employed in a sequential or iterative product development environment and successfully applied to goods and services in B2B or B2C, high-tech or traditional industries.
Arguments that requirements documents are inherently outdated or voluminous are incorrect and likely based on working with the wrong template or skewed workplace experience.
It is noted that Scrum’s product backlog and the popular Product Backlog Item (PBI) of user stories are not by any measure a substitute to requirements documents.
In Agile/Scrum, a User Story and Acceptance Criteria combination is essentially the same as the classic Use Case.
Agile is a product development framework, and Scrum is a product development method — both unrelated to product management.
The MRD is a flexible and dynamic deliverable that allows software development in either heavyweight or lightweight software development modes.
Moreover, the MRD can embody a rigidity or agility mindset, regardless of the product type and the development method used by the product development team.
Requirements Management in PMTK and Lightweight Software Development (Agile)
The principles of product management according to the Blackblot PMTK Methodology™ are universal.
Universality allows PMTK to quickly adapt to linear, iterative, or continuous product development, whether software or any other product or service type.
With the introduction of Agile to the company, the relationship between product management and product development now hinges upon the Agile team receiving market requirements from the product planner, a primary role in PMTK responsible for identifying and articulating market problems.
PMTK employs an efficient and robust method to create a Market Requirements Document (MRD), effectively a written understanding of the market problem.
PMTK does not enforce the idea of a singular, complete, and voluminous MRD.
PMTK processes work well with mini-MRDs or an MRD that constantly grow while relaying small sets of market requirements to the product development team.
Depending on their chosen software development method, the product developers can do what they wish with the MRD information sets.
They can create user stories, product requirements, use cases, build a product backlog, etc.
So it is possible to implement PMTK requirements management with any Agile method.
A PMTK/Agile alignment is powerful because it enables a combined product/development team to run a continuous delivery process that would start with identifying customer needs through releasing the product to market to capture feedback from the actual product use.
This approach enables activities to start in the solution space before product management activities with extended lead times are fully completed.
And this Agile-aligned process, employing a PMTK/Agile combination, would likely serve companies far better with a supported and efficient implementation of a market-driven product management methodology.
The Product Requirements Document (PRD)
In the product delivery process, the Product Requirements Document (PRD) is the next deliverable that follows the MRD.
Prepared by the Product Architect, the PRD is a high-level description of the solution, its intended use, and the features the solution provides that address the market problem and satisfy needs.
Similar to the MRD, the PRD manifests a methodology of expressing product features.
Although perceived by the product delivery process, a PRD is not mandated to follow the MRD.
When dealing with software development, the developers in Engineering (solution space) can use a PRD or Product-Backlog or anything else they want and work according to any software development method, but this does not affect the MRD or product management practices (problem space).
Product Architect and The Product Requirements Document (PRD)
According to the Blackblot Product Manager’s Toolkit® (PMTK) methodology, the Product Architect role is part of the Blackblot Product Definition Team Model and responsible for creating the Product Requirements Document (PRD).
Through the PRD, the Product Architect articulates the product’s architectural and technical vision and structure and specifies the product’s components and interfaces, creating the features that the market requirements prescribe.
The product’s architectural and technical vision may change as technologies evolve and improve.
Technical changes that only affect the PRD, but do not involve the MRD, are for example the replacement of rotary hard drives with solid-state disks (SSD); or the integration of the new IPv6 internet protocol to replace the aging IPv4 internet protocol.
Accordingly, in the same manner that the Product Manager regularly maintains the Market Requirements Document (MRD) to reflect the ongoing changes in customers’ needs, the Product Architect will modify the product’s technologies over time to create a more fitting and better solution.
All Product Definition Team members (including the Product Manager and the Product Architect) continue making individual decisions and contributions throughout the product delivery process and the product’s lifecycle.
The inclusion of a Product Requirements Document (PRD) template in the Blackblot Product Manager’s Toolkit® (PMTK) is to provide evidence of process continuity and to show the relationship between a Market Requirements Document (MRD) and a Product Requirements Document (PRD).
Summary
Requirements are a robust and proven technique for representing different levels of information required for product delivery.
After uncovering the market problem, crafting requirements are arguably the most critical part of the product delivery process.
Well-defined requirements encapsulate market knowledge and a true understanding of the market and its needs, which is required for a smooth development process and marketplace success.