How should product managers write requirements?

A requirement is a short statement of the problem.
Everyone has different ways to write requirements.  Products are becoming more focused on customer experience and who can get them to market the fastest, and companies who have the most effective requirements help get those products to market faster and with fewer defects.  The key to writing good requirements is collaboration with your team, and iterative development.

The product manager needs to define the problem.  "As a product owner I want to..." (sometimes this can be "As a marketing manager, business owner, sales manager, etc.").  Remember, you're writing the requirements so that the person reading them understands what they're trying to accomplish or fix.  This shouldn't be a long statement, but rather should be a short statement of the problem.

Once you've identified the problem, you can write detailed specifications around how the problem should be solved.  Typically this should be reviewed with the developer(s) in charge of the solution and should include.  Below is a high level outline of what to include in your product requirements (driven by the product manager).  Each project/product will have a different level of detail associated with these, but in general all of these aspects should be covered.

  • Summary / Problem 
    • a detailed explanation of the problem from the perspective of the business (marketing, product, customer, etc.)
  • Goal / Acceptance Criteria
    • the desired outcome once the problem has been solved; a defined solution to the problem described
  • Expected Workflow / Wireframes
    • a chart of the workflow; these can be extremely useful for defining use cases and suggested data that is recorded; these can also be useful for the development team
    • wireframes typically help define what is on the screen or product that the customer is using
  • Data
    • any data that should be collected or provided regarding expected outcomes or business intelligence (reporting, etc.)
  • Use Cases
    • a list of steps, typically defining interactions between a user and the system
    • user persona's should be previously defined and used to help move this forward.
What are your processes for writing requirements?  Do you follow the same process each time?  I tend to include wireframes in my requirements and don't include as much text.  What do all of you use? As always, I love hearing from you! 

Here are some resources that might help you along the way:


  1. I contend that the problem and acceptance criteria represent the requirements. The rest of the information is interaction design. According to this definition of "requirement", requirements specify the least stringent conditions that must hold to solve our avoid prospect problems. Nothing more, nothing less :-)

    1. Love this short definition Roger. I particularly like that a solution and problem are presented in the requirements. Thanks for the link to your blog - I've enjoyed the posts I've read!

  2. Software can make computers do a lot of different things, like letting me type this comment. Earlier I was playing a game, simulating WW2 in Europe. Today at work I worked on use cases for bank employees to use with clients to select the best products for them. So it depends on domain; I play games but don't knowing what requirements for them would look like that a developer would actually use. Most of us reading this probably work in information systems, for which process and data is crucial. So methods that capture that is what we use. Use cases seem to have emerged as the dominant method, but I still don't see a lot of data modeling going on. In the end, requirements are (1) what the business agrees captures their needs, and (2) developers agree that they can deliver the solution to,meet the needs. If your method does not do both, then it is not going to work for you.

    1. Thanks David! I agree- requirements need to capture what the BUSINESS agrees captures their needs. Thanks for the feedback!

  3. Good read Cait and indeed a very important topic. Authoring requirement is a very critical aspect of Product Manager's job. How well requirements are authored directly impacts the effectiveness of entire team. There 3 aspects as I see;
    1. Understand market drivers and source
    2. Knowing the expected outcome / what to expect
    3. Authoring them to precision

    will leave some links for further reading around this.


    1. Writing Good PRD ( )
    2. Knowing your requirements ( )

    1. Hi Abhay! Thanks for commenting. The links you've posted are very helpful and I love that you noted the expected outcomes. Stop by again soon!

  4. Good post and good comments all. I'll just add something on artifacts we use. Each new feature of any appreciable size gets a spec consisting of a summary, user stories ("as a _user type_ I want to do _something_ so that I can _business objective_"), and use cases. The use cases derive from the user stories and outline the broad strokes of UX. We use Google Docs spreadsheets for everything except really technical specifications, which get a document. Yep, pretty basic, but this method has really enhanced the way we develop products.

    I think this goes beyond Roger's definition, but we focus on capturing (a) what engineers need to get started on a project in an agile environment, while keeping in mind (b) what other stakeholders need from these documents—namely, longer-term reference material as to how things were intended to work from inception.

  5. I agree with the statement that you added. Typically I will add something like 'As a product owner, as a marketing manager, etc. ' I love that you reminded me to add that! Thanks for commenting and I hope we can collaborate in the near future!

  6. I like Roger's narrow description of a requirement as a condition that must be present to alleviate a problem. That eliminates a good bit of the ambiguity.

    In the distant past, I've suggested that user flows are one of the four deliverables required to define a commercial product. I don't think, however, that those are requirements because they're malleable. The discovery of a way to achieve the same result with fewer steps will likely lead to the replacement of that workflow; therefore, it couldn't have been a "requirement."

    Perhaps thinking about "user goals that must be met within constraints" is a better paradigm than "requirements"?


Note: Only a member of this blog may post a comment.