Understanding the Shelf-Life of Your Product Requirements

As a team lead, product manager, or anyone heavily involved in roadmap planning and resource discussions, it pays to be mindful of when and how much you invest in writing detailed product requirements.

The idea of ‘missing the market’ is well understood. As a visionary product strategist, you might ship a product that would be wildly successful if only your customers were ready for it. Alternatively, you could be late to the market, delivering a me-too product that has become table-stakes in your increasingly competitive product landscape.

As much as timing matters for launching your product, it also matters when you gather and specify the requirements to prepare for development. Too late and your engineers are working without a vision. Too early and your requirements could quickly go stale.

Different levels of requirement fidelity

Requirements can range from conceptual user stories to highly prescriptive “shovel ready” product specs. As you get closer to the build phase of a project, you need to increase your requirement fidelity so that you’re providing the team with a solid foundation from which they can begin the agile development process. However, with increased fidelity comes increased overhead. It’s not easy to produce a shovel-ready product spec — and you certainly can’t do it alone — so it’s a real bummer if you let that effort go to waste.

Varying degrees of product requirement specificity and when they’re needed most.

The requirements document is one of a few deliverables that a product manager owns. We invest significant energy in research, analysis, and design to be sure the specified requirements will address a customer need and ultimately succeed in the market. As a good product manager, your requirements document will be clear and concise; it will also be delivered on time.

But what if your plans change? What if something happens that could not have been anticipated by even the best of good product managers: there’s a change in priorities (gasp!), and your project is put on the back-burner.

For the following weeks, maybe even months, your project remains in the backlog. To satisfy a restless salesforce, your project might be labeled as “on deck for Q2.” Eventually, it moves to the more ambiguous but still optimistic “H2 roadmap.”

The thing about the back burner metaphor is this: it’s a big fat lie. Even if the project is still likely to happen in the relatively near future, those requirements aren’t being ‘kept warm’; they’re not top of mind for a team of dedicated engineers and product marketers. Nay. Your expertly crafted requirements are likely collecting dust on the shelf.

When H2 rolls around, and you finally get the nod to begin development, you might discover your requirements now read like alternative facts. Misleading at best. Key customers may have found viable workarounds or changed processes. Your partners may have updated their offerings. Technical assumptions may have changed. Each of these variables could affect your product spec in different ways, even if your business case is still strong.

Be careful. If you write requirements too far ahead of development in a fast moving industry, you should later re-confirm they’re still valid or be prepared for significant rework. Product requirements are a perishable good; they have a shelf-life, and the expiration date might be earlier than you think.

Your requirements increase in fidelity as you approach development. Wait too long and they begin to decay.

A lean product team should ideally only invest in detailed requirements for products they fully expect to be delivered in the near term. For planning purposes, however, your engineering counterparts will likely ask for more detail upfront, increasing the accuracy of their estimates and safeguarding their commitments. Finding an appropriate balance — likely unique to your particular team — can make for a happier product org.

Given the need for compromise, below are some good habits for helping extend the shelf-life of your requirements. Preservatives, if you will. While these could be considered best practice for any product artifact, I’ve found them to be especially important for helping maintain the fidelity of my requirements.

1. Document your assumptions, and expect them to change. Identify the key assumptions that shaped your requirements and watch closely for how these age with time. What are the assumed technical dependencies, market conditions, or industry trends that pushed you towards one solution vs another? What are the key bets you’re making about the user and how they’ll interact with your product? Which assumptions, if proven false, would be most damaging to your design choices? A focus on assumptions will help you quickly identify areas for revision when you dust off your requirements in the future. Return to these first.
2. Habitually cite your sources. It can be very difficult to revisit your assumptions if you don’t remember where the data came from initially. Why didn’t users understand a proposed workflow within the prototype? Which customers (or sellers) were most heavily weighted in your revenue projections? How did you arrive on one side of a feature trade-off versus the other? These details often come in the form of anecdotes, whiteboard footnotes, or water cooler decisions; and they can be easily lost without discipline. If you document these key decision points — like research breadcrumbs — you can more easily retrace your steps to validate that your original assumptions, hypotheses, and data remain true.
3. Focus on the vision. Your product vision is central to the requirements, painting a picture of not only the existing market conditions, but also the expected trajectory. With the right team, a well articulated vision can also help lessen the engineer’s demand for requirement fidelity: by providing additional market context around your requirements and including measurable hypotheses about the future, your team will be more empowered to collaborate around the problem and help you better evaluate key assumptions.

These product management habits can be especially effective when trying to increase the longevity and sustained relevance of your requirements research. They can also be invaluable for stewardship if you ever need to handoff product ownership to a colleague — else they’ll be forced to choose between trusting your specs and starting from scratch.