Those who have worked in the software industry for a while have likely witnessed a project that went off the rails. Lack of vision, changing requirements, or an out-of-sync team is a surefire path to a fraught development process. Although there have been advances in approaches to project management within the industry, things still go awry more often than they should.
A key benefit of Agile is its rapid pace and adaptability; however, this often comes with an allure to move too quickly, dive into a project without thinking, and start coding straight away while making decisions on the fly. Although it lets teams instantly feel productive, this kind of approach is often to a project’s detriment. Meanwhile, the more traditional Waterfall model can be too rigid for modern development teams to remain competitive and serve their customer’s needs. Now I’m a proponent of Agile, but I think that introducing some initial thoughtfulness into the process makes it a more powerful tool and makes a project more likely to succeed. That’s why I believe there’s a “middle ground” approach to starting a project and running a development team.
Enter the Product Requirements Document (PRD), a simple framework to help software projects get started on the right foot.
What is a Product Requirements Document?
The simple explanation is that a Product Requirements Document is a document that outlines the purpose, use cases, and functionality of an intended product at a high level. It’s the starting point for planning and designing a piece of software to be completed before the developers start hitting their keyboards.
The less-simple explanation is that a PRD is not just a document, but also an exercise in thoughtfulness undertaken by a product owner or set of stakeholders. The process of creating a PRD is as valuable as it’s output (if not more). The resulting document helps guide the start of a software project while also acting as a reference once design and development have begun.
What’s the purpose of the Product Requirements Document’s process?
Primarily, it helps build an understanding and unified vision of what the team is setting out to create. A PRD doesn’t only include functionality, it also defines goals and gets people thinking from the user’s perspective – among other things. It outlines the general shape and objectives of a project to make sure everyone is on the same page once things get started. Ultimately, it’s about providing a clear direction to help teams get moving quickly and in the right direction.
Why does your software project need one?
If I ask you to build me a car, you should have some follow-up questions: How many seats should it have? How many doors? How fast does it need to go, or how efficient should it be? Do you want an SUV, crossover, or sedan? What color do you want it painted? If you simply built me a car without getting more information, you and I would have very different pictures in our minds of what was being built, and I’d likely end up with something I wasn’t expecting.
Being clear about a project’s direction from the start makes sure the end result is what’s desired. It allows you to maintain control over your project, and ensure that everyone is on the same page with what’s being built. As with many things in life, clear communication is key. A PRD acts as an anchor for expectations and direction to share with and unify the team.
The process of creating the document is also beneficial in the sense that it gets you thinking holistically about what you’re setting out to build, and may cause you to consider details or user perspectives that have been overlooked. Using a structured PRD Tool can help prompt considerations along these lines. Doing this work at the start helps prevent surprises later on in the process.
There are financial benefits to completing a PRD as well. First, it allows for the production of a more accurate cost estimate for the project by outlining the core deliverables and considerations. Second, having the requirements in order and the team on the same page from the start also means less time is spent having to redo things because someone had a different understanding of the work needing to be done.
Simply put, a PRD makes your project more likely to succeed, run smoothly, and take less time (and thus cost less) along the way through the creation of a clear and thoughtful plan.
Why don’t more people write Product Requirements Documents?
I think there are many reasons for this:
- Lack of previous experience as a product owner: Those who haven’t been responsible for many development projects may not have experienced the pain points that can happen along the way. As previously discussed, projects become challenged when expectations and direction are unclear. Getting bogged down in planning meetings late in the game acts as a lesson on the importance of deciding on a plan early and following that vision, which illustrates the power of the PRD process.
- Too much experience as a product owner: Converse to the previous point, experienced product owners may have the impression that the PRD process is too laborious or not worthwhile. Especially to those coming from the Waterfall school of project management, the thought of endless meetings and the production of complicated ER diagrams and extensive documentation may turn someone off to an initial planning process completely. The allure of Agile can trick people into thinking they can dive right in – to their future peril.
- Uncertainty about the process: There’s no consensus on how a PRD should be done. Ultimately it’s a blank canvas and can involve as much or as little work as desired. This open-endedness can be overwhelming – with no clear starting point – and scare people away from the process entirely.
Whatever the reason, those who aren’t taking the time to produce one are risking the future of their project, or at least potentially making their lives more difficult.
Is there a better way to approach the Product Requirements Document?
Personally, I think starting from a structured framework that focuses on the core aspects of an intended product is the way to go. The process doesn’t have to be overwhelming when its scope is clearly defined. That’s why we’ve produced a guided Product Requirements Document tool to help organize the exercise in a tractable way, whether you’re a seasoned professional or a first-timer when it comes to creating software.
To ease the process, there are a few things to keep in mind. Limit your focus (to start) to a Minimum Viable Product (MVP) version of what you intend to build. Concentrate on the essential aspects of the product and don’t get distracted by bells and whistles. It’s okay to take note of ideas worth revisiting in the future, but they shouldn’t distract from the process early on.
Planning for an MVP is useful to constrain the discussion, but you should also be sure to not miss any important details. Get out of your head and think from the user’s perspective. Practicing User-Centered Design (UCD) can help mitigate blind spots during the planning process. Specifically, the use of User Personas can facilitate this and drive the process of defining functional requirements for your product.
And finally, recognize when it’s time to move forward and get started on the project. Remember that the PRD process is about finding a balance between too much planning and not enough. PRDs can be written sufficiently in a day or two in many cases. Once your document is comprehensive and there’s a clear vision of what you’re intending to build amongst your team, you’re ready to go. You can always look to revise the document in the future, or simply move on to using a more permanent and iterative project management process such as Scrum or Kanban.
Final thoughts
Product Requirements Documents don’t need to be difficult, and they require a relatively small amount of time and effort when compared to the lifespan of a project. Given the value they create – both in terms of the actual output and for catalyzing thoughtfulness – they’re something product owners should be doing out of habit when starting a new initiative.
If you’d like to read more about PRDs, we’ve written a guide specifically on how to write an effective one (you may be able to skim the first couple paragraphs now that you’re familiar with the subject matter.) You can also dive right into creating one of your own or take a look at a completed example for reference.