I came into the software world at the crossroads of the change from waterfall to agile. Most of my older colleagues had spent their careers in waterfall: writing detailed requirements, building comprehensive designs, writing code that adhered closely to the designs and requirements, and then going through long testing and verification cycles before shipping their products. Releases in those days were unpredictable, and it was common for a product to take 18-24 months from concept to release. I was fortunate to land post-college on a team that was doing things differently - a cross-functional team, driving short / iterative releases, using customer-driven development, and holding daily standups. This team would of course later be known as the “first scrum team.”

That early experience was formative in how I approached building software: first as a software engineer, and later as a development lead, architect, and engineering manager. As the years passed and the industry moved further from waterfall, multi-year development cycles shifted to rapid MVPs; long serialized phases were replaced by short sprints; long and elaborate designs became one page story-driven HLDs; testing and verification became integrated into sprints; and detailed requirements were replaced with epics and stories.

While I embraced these changes, I always struggled with the loss of requirements. The long form narrative of requirements - complete with the analysis of the market, competition, product vision, and more - always seemed to be a powerful technique that never found its full equivalency in stories. As a result, I never stopped writing requirements, and over time just found ways to adapt them into my agile processes.

So here are the top 7 reasons I always writing requirements before stories:

#1: Define the WHY

If you want teams to do their best work, you need to start with the WHY. The WHY provides a team their inspiration: the reason behind the investment, the value it brings to customers, the reasons it matters to your business & market, and how you plan to do things differently. Too many product managers skip over the WHY to go straight to the easiest thing to communicate: the WHAT. But in my experience, great software professionals have more in common with artists than engineers, and thus their best work comes from inspiration instead of direction. Requirements provide a great opportunity to leverage the long form narrative to clearly articulate and get buy-in for the WHY behind your proposed investment.

#2: Impart customer & market knowledge

My requirements always start with an overview of the business problem: who the customer is, what problem they are confronting, how they are solving the problem today, and the impact a solution would have on them. I also take the time to provide an overview of the market and competition. Good teams will make numerous decisions a day, many in the absence of a product manager / owner. The more you can help your teams step back and see the forest through the trees, the more frequently these teams will get these decisions right. They will also be able to make decisions faster with less friction. This information can also be highly valuable to other functions in your business - e.g. marketing, sales, customer success, support.

#3: Put investment in context of strategy / vision

All product investments should be made in the context of a multi-year vision and strategy. While strategy often gets imparted through other means - e.g. company presentations, strategy documents - summarizing the relevant parts in requirements makes it more digestible for a broader audience, and enables teams to look ahead to the longer term plan.

#4: Improve & refine the WHAT

There is no point in writing great requirements if you are not always willing to subject them to rigorous reviews. The best product managers realize their greatest value is not in defining the WHAT, but in harnessing the collective customer IQ of an organization to get to the right WHAT. Attendance in requirement reviews varies by organization, but I find the most effective reviews include the broadest stakeholders. In the earliest phases of my last startup, it was common to have sales people, marketing managers, software developers, and members of our executive team working side by side in a review to ensure we got it right. My sacred rule was that we subsumed all opinions at the altar of the customer - i.e. we can have differing opinions, but the right one is always the one that advantages our customers the most. I also found two reviews are almost always better than one: the first done when opinions were loosely held and the author is fully open to brainstorming (strawman); and a second when the group had converged its thinking and was nearing a final proposal (steelman).

#5: Define release phasing

One of the improvements I added to my requirements over time was the addition of phasing. I break my requirements into 3-5 releases, each building upon the previous one, and each representing standalone, usable value to customers. There are several reasons for doing this. First, it allows you to define and get feedback on the MVF - the Minimum Viable Feature. Second, it lets teams look ahead to what might come next, ensuring design and implementation can be future proofed as desired. And finally it provides a product owner a roadmap for how to efficiently manage a storyboard to bring a successful feature or product to market.

I should confess: I always treat the phases after the first as subject to change based on the feedback received after launch. Everything in my world is subject to a Build-Measure-Learn loop.

#6: Converge team thinking

The requirements represent the last chance to make major changes to a proposed product or feature with almost no cost. Stories have not been written, designs are not yet defined, and no one has put fingers to keyboard to produce code. A major change at this phase requires only the modification of words in a document. Now is the time to let everyone get their ideas on the table, and to discuss, debate, and argue over a white board. A healthy debate now almost always saves time and friction in getting a quality product to market.

#7: Written documentation for future

The last reason I write requirements is they provide a fully standalone document defining everything an organization was thinking when it decided to make an investment. They are in effect a time capsule that can help in defining future releases, in documenting products, and disseminating knowledge across the cross-functional organization. A collection of well written requirments can also over time represent a mulch pile for future innovation and product releases.