As you might know, PRD stands for a product requirement document, which is used to communicate with each team member to share purpose, user experience, assumptions, constraints, target values and so on.
Many people wrote and published useful PRD templates and explained about elements that we should write in PRD.
I also wrote an article about what PM should think when writing PRD.
Many product managers who learned about these knowledge have succeeded to lead their team better. But some product managers didn't succeed although they spent a long time making their PRD.
I was wondering what the differences are between them. So, I found three key differences and I will introduce them. If you want to change jobs from engineer to product manager, I would like you to know these three keys.
Create a PRD as an order for engineers and designers.
First, product managers should write PRD to express their ideas of new products or features, and then they should brush it up with team members.
Therefore, stakeholders including engineers, designers, marketer, and management team can understand the background of the product idea well.
They are on the same page, and it makes them ready to discuss.
Through the discussion with them, the product manager should gather opinions on each different perspective and keep their PRD updated daily.
We must not force engineers and designers to make products follow the PRD.
I think people who have experienced large waterfall projects tend to do so.
Too long PRD
PRD should be concise. Stakeholders can read and understand it easily. If it has many pages, most people can’t understand it. Even though the first PRD is concise, after a lot of discussions, it tends to grow into a large document.
I suggest you divide PRD and some spec documents. For example, about UI design, we describe only User Experience in the PRD, and we make the UI specification document to explain details of UI design.
Most designers might want to discuss the details of UI design, but marketers don’t need to know about it.
Product managers have to keep PRD simple, as which can be browsed within 15 minutes.
Focus on mainly what and how we develop
I think PRD should answer these questions below.
Why do we create the product? What problems do we solve? How do we measure our success? What user experience and features do we provide?
The balance of three points of view is important. I often find the third item occupies a large part of PRD. It might become the reason for the previous two problems.
Especially product managers with experience as an engineer or designer had better take care of this balance.
Wrap-up
There are three keys for writing effective PRDs. It might seem easy, but Without my actual noticing, you might make these mistakes as your project goes on.
I would appreciate it if you send your feedback as comments in this article.