One of the toughest concepts in product building is deciding and documenting exactly what you’re setting out to build. From experience, I’ve learned that it only takes one cycle using a “wing it” approach to product development before most folks swear to never do that again. They all conclude that if they’re going to set out for a destination they’ve never been to before, they’re going to want a map.
But the pendulum can swing too far the other way as well, resulting in a thick, unwieldy requirements document that describes almost everything about the product except what it’s actually supposed to do — and what the product accomplishes for the business.
Do you document requirements for your product and upgrades? If so, how? And have you already stopped reading this post in anticipation of being lulled to sleep by a requirements discussion?
I understand the reflexive hesitancy. When I’m advising startup and product leaders, requirements documentation is one of those areas where it’s like pulling teeth to get folks to stay with me and understand why the concept is so important. It’s boring. “It’s busywork,” they say. “Let’s just wing that shit.”
I’m going to accept that challenge. I’m going to put forth an actionable post on product requirements without boring you to death.
3 Things a Product Requirements Document Must Do
In almost every case where a dedicated requirements discovery and documentation process sucks, it’s because that process is being done wrong. We tend to put a lot of formality and pomp and circumstance into a requirements document. It’s a job that is tasked to someone to cover someone else’s behind.
When you take the requirements process out of CYA mode, the process itself becomes startlingly simple: The reason the requirements exist is money.
Yes. Money. Dollars. As in making them. That’s what’s going to make this discussion interesting. I’m not going to tell you how to document your requirements, I’m going to tell you why.
You need to be able to answer the question, “What defines ‘success’ for our product?”
You need to make a plan to produce a greater benefit for a lower cost. As business, product, and technical leaders struggle over the hows and the whats of what they’re building, they’ll need to keep referring back to that plan.
The fact is, how you document your requirements is immaterial. You just have to accomplish three things:
3 Things a Product Requirements Document Must Do
- Business requirements must define and justify the business needs.
- Functional requirements must describe a solution that elegantly fills those needs.
- Technical requirements must be step-by-step instructions to build that solution.
All three entities are completely independent, but are also critically intertwined. In other words, the technical owner doesn’t need to care why the business has a certain need, but at the same time, the technical owner should be aware of the need and why it exists. This helps the technician understand why they’re building what they’re building, and when viewed through the prism of the functional solution, will inform the technician how to best and most efficiently fill that business need and functional solution with their technical tool set.
On the other end of the spectrum, the business owner’s only concern should be the parameters of the business need. They should never try to suggest the functional or technical solution, as this will only limit flexibility and options down the chain. At the same time, the business owner should have an understanding of the product’s function and its foundational tech, so they know what is possible, what is viable, and even when a problem can be solved without building a new technical solution to solve it.
Writing Requirements Is Rarely a Job for One Person
Unless the person actually executing the requirements process and documentation is a combination of a company executive, business analyst, product engineer, data scientist, technician (software, hardware, or whatever), and marketing professional, the requirements process is a team effort that usually touches all facets of a company.
But most requirements initiatives are usually left to one person, most of the time that person is not all of those things, and most of the time the necessary business, functional, and technical requirements are obtained and documented in a vacuum.
That’s how terrible, expensive products and features get built.
Everything Starts and Ends With Dollars
The requirements process should always start with the business owner, who should constantly be asking why the business need exists, and the answer they document should always directly relate to dollars.
The functional owner starts with those justified business needs and injects elegance into a solution that maximizes the dollars earned while spending as few dollars as possible to get there. They do this while also avoiding technical debt and customer friction.
The technical owner then turns that solution into something tangible — something that doesn’t break, can be built quickly, and maximizes the benefits of the technical architecture at its core.
When in doubt, or if a critical decision needs to be made, the technical owner should be able to go backwards to the solution, or back even further to the business need, to understand the context of their build.
There are always a million business, functional, and technical solutions for every problem. The solutions your product builds on should be those that deliver the most value for the lowest cost. Getting there doesn’t have to be a slog. You just need to focus on the ultimate goal.
