As a product manager (PM) your principal job is to get the right product built and delivered to your customers in a manner that meets their needs. The outcome of getting that right means customers buy, adopt, or expand the use of the product you got built. Get it wrong and these things don’t happen. Maybe they don’t buy, don’t grow, or outright reject your product for a competitor. That is not a good outcome for the company.

There is a lot you can say about the many demands on a PM, but one that is critically important is the generation of product requirements documentation for engineering. Requirements docs may be the most important thing you do as a PM. The purpose of requirements is simple, but the way you document them can come in a couple different forms. The PRD is the culmination of your research, customer interviews and discovery, conviction, and direction to engineering on behalf of your customers. The purpose of requirements is to convey to engineering the customer problem to solve. That sounds simple, but there are a set of rules around this. I’m tempted to call it an art, but it’s not an art at all. It’s a craft that when done well, can result in getting what customers need delivered to them effectively.

SOFTWARE DEVELOPMENT METHODOLOGIES

Before launching into what the requirements formats do, let’s first talk about the two big ways to build software. This is not about writing code. It’s about the choice the company makes for the building process. It’s important to PMs because it has a material impact on how you document your requirements.

THE AGILE FAMILY

Just over a decade ago in 2011, Eric Ries wrote a popular book called The Lean Startup which made much more popular a set of concepts also associated with Agile product development. Agile as a concept has gone by many names, each slightly different, including Kanban, Scrum, Scaled Agile, and many more. As a result, in the 2010s many startups and companies pivoted their software development processes to embrace concepts of MVPs (minimum viable products), stand-ups, sprints, and user stories, etc. You’ve probably heard of several of these.

In an over-simplified summary, the Agile/Scrum framework designed for rapid build and rapid release to production (i.e. the live product in customers’ hands). It was a convenient fit for online products like web sites, SaaS products, and phone apps. These are all things that can get updated with or without your personal involvement as a consumer. For example, how often does your Google Maps phone app or Amazon.com update? Do you even notice? This model worked well because these updates don’t need your intervention as a consumer. If the updates have bugs, the app creator can just update it again the same hour or day if needed.

Some products, however, are more complicated and do require your involvement to update. Non-SaaS enterprise products often fall into this category. Operating systems, system software, and firmware, for example, require you the consumer to download and install the software update. The challenge for software companies is this: What if you never do that? What if you do it incorrectly and render it unusable? There is no guarantee that you will ever upgrade the software on something you have to manage yourself. E.g. Have you ever upgraded the software on your microwave? Your car radio or TV? In many cases, you’re not expected to. Enterprise software products are complicated and do require updates to resolve bugs, issues, and critical vulnerabilities (CVEs). In time there will be new features as well which a customer may want to install. Another important motivator is the closing of a support window for a software release. Businesses don’t let enterprise software run without support from the vendor.

WATERFALL

Since enterprise products run your business and other solutions that manage mission-critical applications, the software development process needs to match to ensure uptime and reliability. Here’s why it matters. Let’s say you have a product that manages half the air control towers in your country. Or a software package that monitors post-surgery human vitals in a hospital. Or all the subway system control systems in New York City. The cost of them going offline and breaking is very high. At worst, the cost could be human life. Knowing that it may be a long time before anyone upgrades these systems, as a software vendor you need to ensure to the highest possible degree that your product won’t break. A software development model that fits mission-critical applications is called Waterfall. In short, you sequence the software activities of requirements, analysis, design, coding, testing, and operations. Whatever you build has to be of extremely high quality, and you test the hell out of it over multiple iterations before you release it to ensure it has no severe or high-impact bugs. Following the tsunami of popularity for Agile and MVPs, you might guess that Waterfall isn’t used much anymore. That is not the case. It is very much still around.

SIX SIGMA

Development methodologies, like blue jeans and hairstyles, also have fads and trends that come in waves given enough time. 20 years ago, some software companies were passionately embracing Six Sigma. This was a methodology created for physical manufacturing which employed continuous improvement to endlessly improve quality. In the 2000s, some companies tried to bend Six Sigma to help software development. In 2003 I was at Sun Microsystems who was passionately doing this in their software division. Not to be out-branded, they changed the name to Sun Sigma. Go figure. Overall it was fine, but I did find it pretty heavyweight and definitely not light on process. I think the lean startup trend was a response to that in some ways.

CHOOSING YOUR MODEL

As a PM, you won’t choose the software development model. Your business software needs and your engineering leaders will choose the model. The company should choose the one that is best for customers and the company, in that order. As time has marched on, I don’t see Six Sigma anymore but I’m sure it still exists in hardware manufacturing. Agile and Waterfall are still very common. In many cases, a company chooses one or the other, but even Waterfall has adopted some Agile components like the two week sprint. There’s nothing wrong with that in my view. If you are a Waterfall company, you will still ensure you test the whole thing rigorously before release. This component adoption simply allows for chunk-sized development within the Waterfall framework. By the way, I often ask PM candidates if they know the difference between Agile and Waterfall in interviews. I’m surprised that many don’t know, and can’t even describe Agile in any detail. As PM training courses and degrees increase in popularity, perhaps more will learn these topics.

ANATOMY OF REQUIREMENTS

A requirement is the concise, atomic description of what needs to be accomplished in the product. It states only what needs to be done in order to solve a problem. It does not say more. For example, the coding language to build it is not given. The color of the UI is not given. Why you need it is not given (not here anyway). I say “atomic” because each requirement must stand on its own and ask for only one thing. That prevents confusion and allows engineering to know exactly what to build with exactly which priority. Each atomic requirement must have a priority assigned to it. A requirements document may have many individual, atomic needs defined.

The PRD is the culmination of your research, customer interviews and discovery, conviction, and direction to engineering on behalf of your customers.

REQUIREMENT PRIORITIES

Some needs are more important than others. Smart PMs know the difference and only ask engineering to build what is essential. By assigning priorities per atomic requirement, you are telling engineering what must absolutely ship, what should ship, and what is nice to have. You will build trust with engineering by being honest and ruthless as to what is required, wanted, and nice to have. For what it’s worth, I have included nice-to-have P2 items but I ensure they are described with the right priority. When push comes to shove (figuratively) on time to release, scope, or cost, nice-to-have items get cut, followed by should-ship items.

Most companies I have worked for use the following shorthand:

• P0 (priority zero) = Must ship. I.e. This software cannot leave the building until this item is present. I will stand in the way of the door to make sure this happens.
• P1 (priority one) = Should ship. I.e. This software should really have this feature, but if we must ship with only the P0s I can live with that. P1s sometimes land in the follow-up release, if ever you get that opportunity. If your customers truly can’t live without a P1, it’s actually a P0.
• P2 (priority two) = Nice to have. I.e. If you can include this I would really like it for my customers. Thanks in advance. I understand if you ignore this one. Do you prefer chocolate or vanilla ice cream? I’ll drop it by your desk after lunch.
• NOTE: You can define more, but they won’t get built so don’t bother. Your P2s might not get built either.

Caution: A pitfall some early PMs occasionally fall into is building in release schedules into requirements docs. This is a bad idea. How long it takes to build and release something will matter to you, but you are not the project manager. Don’t down-categorize requirements to get something released faster because you’re effectively saying you have a bunch of unimportant requirements that shouldn’t be built. If you mislabel needs that get delayed or not built, you’re doing a disservice to your product and customers. The requirements are the requirements. You may be asked to negotiate phases or scope which you can do, but a P0 requirement is still a P0 if it gets put in a second release. Even if phased, you’re crystal clear on what customers require in your requirements documentation.

THE MRD (Marketing Requirements Doc)

Though the name of this exists, most PMs I have worked with don’t write MRDs as separate documents. For what it’s worth, I have never seen this section written by someone in a marketing team as the name implies. They include this content as the preamble to the product requirements in a single document. To be as concise as possible, the MRD explains the ‘Why’. I.e. Why are you writing up these requirements and presenting them to your business and engineering teams? What is the justification that is relevant to the business outcomes for your product? E.g. How much additional revenue (market) can you win may be your success objective. If the total market is $1B, and the Available market is $100M, perhaps you can claim with data and research that your Obtainable market is $25M over 3 years. See TAM, SAM, SOM as a framework for sizing the market you can actually obtain. Your goal might be revenue, adoption, usage, etc. depending on the key metric you’re driving.

The MRD also describes the customer problem. I like to include sections for background, goals, target use cases, assumptions, and customer user profiles. This sets the stage to describe and defend why the requirements matter to the customer and the business for the reader. Some even include success metrics.

MRDs fit well for net new project initiatives. That could be a whole product or significant new functionality. A minor enhancement to an existing product feature might not need a MRD. In that case, a minor enhancement might just be a JIRA ticket. Minor might include something small enough to be accomplished by one team. E.g. Show more rows in a table before paginating a web page result. That might not need any API work, no new UX, no net new UI development, etc. A dev team might just change the default size of a JSON payload.

If you can’t explain the ‘why’, you will get challenged by engineering and leadership. Failure to understand and convey a meaningful why may result in your feature not getting built. This is an important section.

THE PRD (Product Requirements Doc)

The PRD describes the ‘What’ to build. The PRD is a requirements format closely associated with waterfall development. As it is the start of a full product development cycle, it is intended to be a complete document. It is often a multi page affair including a MRD, a complete set detailed requirements across multiple topics, and related information for an entire product or feature. I.e. Everything you need from a PM perspective to create the product. In theory, you could send this to engineering and get what you want back in a few months. In reality, nothing is ever that simple.

As described, individual product requirements are concise and separately prioritized. You may have many individual requirements to satisfy the product outcome you need. Some PMs stop here, but I strongly advise my teams to include a range of topics relevant to enterprise products which are also important. I like to employ a template to ensure these are captured. These should also use atomic requirements. These sections include:

• Platform Requirements. If the functionality of other teams or other product vendors is built on top of your product, you have a platform. Do they have needs to include that you need to add?
• Limits and Maximums. Are there minimum or maximum scale considerations? E.g. If you’re making a vehicle, do you need 0, 1, 2, 4, or more seats for people? Is this a race car or a school bus?
• Performance. When everything works great this is easy to forget. Does your car need to drive at a maximum speed of 76MPH or 200MPH? How quickly does it need to get to 60MPH? This is easy to think about for a car. How fast do your product API responses need to be? How many concurrent, successful API calls are enough? How much latency is acceptable?
• Scalability. Just how much can you use it? My dining room table most often seats two people, but it can scale to eight if needed. Is that enough?
• Role-based Access Control. AKA RBAC. Who gets to use this product? When they use it, how much can they see and touch? Some people get everything. Others can just look. The car driver can do nearly everything in a car where the passenger cannot. In both cases they can change the station on the car radio if they are sitting in the front.
• Security. This has wide implications. Are you locking your product down preventing customization or changes? Are you ensuring updates? What is needed?
• Upgradability. In my world, this is universal. No feature can render a product unable to be upgraded. There can be exceptions however for other products. If you need an exception for an enterprise product, be prepared to defend the reason.
• Troubleshooting. This sometimes falls into a topic area of serviceability. Is a user or a support person able to get details on what went wrong? Do they have access to logs? Warnings? Back doors? Troubleshooting shell access?
• Guardrails. Are you building in safety measures to prevent customers from creating dangerous conditions? To what extent do you want to go? I.e. Some cars don’t allow you to go over a certain speed limit for your safety. However, no cars prevent you from driving into a lake.
• UI/UX. I said earlier that you don’t own the UX but you are still a stakeholder. What do you need? Do you need your product to work well on a computer, a tablet, a phone, and a Tesla car dashboard?
• Auditing. I can’t track who uses my microwave. Software with multiple users however do often need to track who is logged in, what they do, when they did it, and what changed. The only thing you truly can’t audit is intent. Did you know that the majority of reported product errors come from user misconfiguration?
• Instrumentation/Telemetry. 15-20 years ago companies really debated the customer viability of collecting user details. These days, customers of online solutions know their data at large is collected. Many support systems provide their best service by having access to product inventory and logs. As a PM, what data do you need to include in ‘phone home’ data? This can be the difference between tracking your customer KPIs versus having zero post sale visibility.

With these elements your enterprise product PRD is nearly complete. If sections don’t apply to you, mark them ’N/A’. I prefer to do this versus delete them because it tells the reader that you did consider this topic and didn’t forget it. Lastly, there are some additional topics I recommend my team to include. These are useful because they collect user evidence and trends. Evidence of the customers’ voices and needs are a very useful set of supporting data.

• Deals or Customers at risk. Is the lack of a feature causing customers to consider not buying or using your product? Worse, are they considering leaving your product for a competitor? Which customers? How large is that exposure?
• Opportunities. How many customer sales opportunities are backlogged on this feature? E.g. Do you have 15 customers each willing to spend over $1M in extra billings based on a need of theirs?
• Customer feedback. Sometimes there isn’t money directly on the line but you have heard from influential customers. This provides context you can include.
• Support cases. Your support teams use ticketing systems for customer cases. They probably keep track of case counts for unsupported features, or workarounds for missing or weakly supported features. This can be a valuable source of data which connects needs to named customers.
• Reference docs. Finally, links to reference docs are useful. After years in large companies that always seem to have at least four competing document systems (Google Docs, Word, Sharepoint, Confluence, Sheets, PowerPoint, wiki, etc.) it can be impossible to find something a year or two later. A link goes a long way. Search doesn’t always work.

USER STORIES

The Lean Startup and Agile wave shaped the documentation of requirements differently than the traditional PRD. In this format, user stories like PRDs also describe the ‘What’ to build. Since Agile uses short sprints for development and release, the way that requirements get written are terse and focused on who wants something, what it is, and why it helps them. Agile dispensed with the idea of a PRD entirely. Requirements, therefore, are written only in the scope of the next sprint, which will get delivered in short order to customers. That process will happen over and over. The idea is that the product is always evolving and you can more deftly respond to needs in short bursts versus waiting several months for the current iteration to ship and for customers to try it. Agile is much more responsive and rapid. An engineering sprint may only have a handful of requirements in them. The format of requirements in this development model is called a User Story. Similar to PRD requirements, these are short and atomic in nature.

The format of a user story follows this convention:

As a <role> I can/want <capability>, so that <receive benefit>

E.g. As a car driver, I want to indicate which lane I’m turning into, so that other cars don’t hit me.

You’ll notice this example doesn’t tell engineering how to solve this. A blinker may be the answer. Maybe a siren or a big red directional arrow in your rear window could have solved it too. There can be multiple solutions. Fast iteration can help you explore this.

I have wondered if some Agile products started with a PRD to get the first iteration out, then converted to Agile. If they didn’t, the first version may have started with a vision statement. I’m not arguing a PRD is required but they can be helpful depending on the overall size and scope of the desired product. Agile can certainly be the only development mode used and well. Each model has trade-offs.

THE AMAZON 6-PAGER

Amazon has their own form of a narrative document used to convey product ideas from PMs to engineering and the rest of the business. This is referred to as the ‘6 Pager’. You the PM have six pages to crisply define the narrative important for you tell the audience the story. What used to be, what is, the direction to be taken, and what the future may look like. Charts and data go in the appendix. How you structure the document is up to you.

If you are accustomed to using a PRD format and slides, you may be surprised at how challenging a six page limit can be. When presented, everyone in the room is silent and reads the entire document before any discussion. Everyone as a result, has the same information to start the discussion from. No exec overrides and derailing tangents after slide 3 of 30. I can’t even give you a number of the number of meetings I’ve attended that never completed the intended slide deck. What I’ve heard is that at Amazon, the audience is very astute and will mark up your printed document and challenge you on individual phrases to precision and clarity.

Amazon has been around a long time and their PMs have migrated over time to many other companies. Often they recommend this format on arrival. I have found that getting everyone is a room to read first silently and fully adopt the process requires executive commitment across the company. This is because this format represents a real change to company culture.

What I don’t see in the various 6-pager summaries I’ve found is what happens on day two. Somehow this narrative needs to get captured in a format engineering can execute against. To be fair, PRDs have this same problem. User stories tend to get written directly into the ticket tool of choice so it has that advantage.

LIBERALLY APPLY FEEDBACK

Perfect is the enemy of the good (even great). Your requirements might never be perfect because you will always learn more when your documented requirements and your product make contact with reality. I say this to save you time. You will spend plenty of time talking to customers, reading, evaluating, and crafting your requirements. Let’s say that, among other things you’ll do as a PM, you took a couple of months to frame out a first PRD for a new initiative. Don’t waste another month or two polishing it next. Get it in front of reviewers and let them comment. They will add lots of comments and this is a great outcome. If you’re new to PM, you may feel attacked. This isn’t the case. The problem is getting attacked so that the result is better overall.

Your reviewers should be your immediate PM peers in the same related area, your manager, engineering leads, architects, support team leads, and passionate sales engineers. SEs are a great resource by the way. They work with customers directly when things go well, and especially when things go badly. They feel customer needs intimately. Reviewers will challenge your assumptions, point out holes, and sometimes outright tell you it’s a bad idea. You should embrace all this because it will help you distill even better requirements and sharper thinking. Update your document as a result.

GREEN FLAG GO

Once your requirements are written, and engineering accepts them, they will get put into the queue for building. The size of your company and the number of products you have may influence how quickly it gets built. As work starts and progresses, you will be very involved working with engineering to ensure clarity of purpose, answer follow-up questions, provide clarifications, and ensure what is built meets the needs of the customers. Good luck!

BONUS 1: THE ERD (ENGINEERING RESPONSE DOCUMENT) aka DESIGN DOC

This document isn’t for you the PM per se, but it does represent the understanding of the lead engineer who is translating your requirements from business language into engineering language with some amount of detail. It may include decisions and trade-offs.

This is a very useful document for PMs to read and ensure you agree with the lead engineer’s understanding of your requirements. If using a collaborative document tool like Google Docs, you should add comments and meet with the lead engineer to ensure you agree on it, or resolve any points of contention including omissions. This is not an opportunity for you to debate their choice of programming language, API design, modularity, etc. You’re not in engineering. I don’t care if you used to be an engineer either. Your job is to ensure the requirements are met and nothing is missing.

BONUS 2: TECHNICAL SPECIFICATION

This one isn’t for you at all; it’s for other engineers who will implement the solution. I wouldn’t bother reading it. It conveys in deep technical detail how the solution will be built on an engineer to engineer level. For the non-engineer, it may not even resemble English. It’s also not important to you. Of course you care that your solution gets built well, is supportable, and meets the requirements. This, however, is not your domain. I include it for completeness. After this comes the actual code, which you will also not read. If your company has a tool like OpenGrok, you could look at the code in a safe, read-only mode, but this is really not a good use of your time. I’m sure you will be busy working with engineering to get your product built, and working on the next set of research and requirements for what comes next.

ABOUT LUKE

Luke Congdon is a career product manager living and working in Silicon Valley since 2000. His areas of focus include enterprise software, virtualization, and cloud computing. He has built and brought numerous products to market including start-up MVPs and billion-dollar product lines. Luke currently lives in San Francisco. To contact, connect via luke@lukecongdon.com or https://www.linkedin.com/in/lukecongdon/.