Product management teams have traditionally been responsible for delivering documents full of requirements. Market Requirements Documents (MRDs) define problems experienced by some segment(s) of the market as defined in an Opportunity Assessment, and Product Requirements Documents (PRDs) define the solution to be built.
Traditional software efforts–driven by project thinking rather than product thinking–have been notoriously unsuccessful. Many of the software efforts surveyed were internal technology projects, but commercial software products haven’t had a dramatically different outcome.
The truth is that requirements are often emergent; traditional teams go to great effort to project costs and timeline, only to see those projections vary wildly when requirements are discovered well into development. The agile manifesto was an engineering-driven reaction to this and other issues with traditional software development. This development approach pairs nicely with agile product management.
Is the idea of “software requirement” still relevant?
For agile teams, there are still requirements that must be met. Here are just three examples:
- Any product that implements an API must comply with the contract that goes with that API, which then becomes a product requirement impacting future functionality.
- A product may be developed for a market who already use specific software; compatibility with that software illustrates a market requirement.
- Once a file export is created to deliver data to your system and used by customers, modifying the data type of a field demands a corresponding change on the client’s side. In the enterprise, that demand results in frustrated clients, because those clients often need to request data feed modification from an already overtaxed IT group. This is a constraint on future development and also affects future development.
Marty Cagan echoes many in modern software product companies in discouraging the use of the concept of requirements:
When I start working with product teams, one of the first things I try to do is to get them to stop thinking of their job as one of gathering and documenting requirements. In fact, I try to get them to stop thinking in terms of requirements at all. Most requirements are not actually requirements, and the rest are better thought of as constraints.
Enterprise buyers are frequently very demanding in terms of non-functional requirements (or constraints) covering areas including accessibility, data security, uptime, reporting and export capabilities, as well as software functionality. There are other business constraints as well, in particular related to marketing and legal concerns.
The minimum viable product in the enterprise is often much more robust than a consumer MVP, because enterprise buyers
At the end of the day, “requirements gathering” is an outdated concept.
Multiple Types of Requirements
One of the areas that drives a lot of confusion among product managers is the very word, “requirement.” There are a number of different types which emerge in different ways, and need to be captured and treated differently. Here are the main ones that product managers need to concern themselves with:
1) Customer / Market requirements – This category covers the needs of the customer or segment(s) of customers for whom the solution is being built. These represent the problems that the solution is intended to solve. For example, a digital camera might have a core requirement related to image quality: “The camera must capture images of professional quality with high resolution for printing and digital manipulation.” A camera that can’t capture high resolution images won’t satisfy market needs and wouldn’t be a good fit for that purpose.
2) Functional requirements – This category represents requirements from the perspective of the system, that serve to meet the customer / market requirements the system is being built to meet. In the digital camera example, the functional requirement derived from the high-resolution requirement might state the lens must capture up to 20MP. And because printing and digital manipulation is part of that market requirement, an additional functional requirement related to export of the image to an external device might be derived as well.
3) Non-functional requirements – This category represents the “unwritten” rules of the system. These are often the hardest to pin down for a new software system because they are abstract. For example, in exactly how many seconds should the next screen of a web application display? Requirements in this category are related to security, performance, compliance, backup capabilities, disaster recovery, quality and a number of other factors (see more here).
Note: Requirements analysts and business analysts may find benefit from drilling down further into the additional types of requirements, but this should be enough to identify the characteristics for product people.
Describing Requirements Through User Stories
Most software requirements — including non-functional — can be described for agile teams in the format of user stories. The story describes the actor, the needed ability, and the purpose–providing the necessary condition that must be met and why, without specifying the implementation.
Many things appear to be requirements, but aren’t. They’re opinions about the way a problem must be solved. They may be related to an unstated problem, which would be better addressed if it were identified as a separate and distinct problem. Identifying the problem separately allows for all possible solutions to be considered.
Often times, requirements related to a particular capability are expressed as acceptance criteria on the user story. This encourages the requirements to be expressed as constraints, while remaining design free.
Give a Moose a Muffin
In the story If You Give a Moose a Muffin by Numeroff and Bond, the moose given a muffin immediately has a new need: jam, to go on the muffin. He may want a napkin to clean his hooves, a knife to cut the muffin with, and so on.
Once those needs are met, others will follow. You can’t possibly know (or build!) all the items your customers will need–so focus on identifying only the items required to solve the core problem.
Your Job is Not to “Gather Requirements” — It’s to Communicate
Requirements aren’t hidden in obscure locations like easter eggs, waiting to be collected by your child. Requirements are emergent, and are often only elicited by showing a client a potential solution. It’s much more productive to build a prototype of a proposed solution, and get feedback based upon that. Keeping real users involved is the secret to success.
Modern agile teams act with the assumption that user stories will be brought to the team to represent all requirements, that acceptance criteria will be included where constraints are necessary, and that over time, new requirements will be discovered. It’s your job as a product manager to ensure all those things happen.
It’s also your job to communicate to stakeholders what’s there, and what isn’t there. Use your judgment when communicating what’s not present, so that stakeholders know the use cases they care about which aren’t addressed. Communicating with real users at every possible opportunity helps to ensure no requirements are missed, and that emergent requirements are captured and prioritized.