Before I start, I want to make a confession. The documentation is very boring and I hate writing PRDs. I had found a hundred excuses not to write a PRD.
Call the developer and explain the wireframe. Create a process flow and tell developers to build on top of it. Print out the design and scribble my acceptance criteria on it.
All of the above activities are good to do, but they don’t replace the primary goal of creating a PRD. I recently learned this from a colleague. A colleague did an amazing job explaining the main reason for creating a product requirements document. In this article, I’ll share what he taught me and how it helped me write a better PRD.
why:
-
There are many articles in the media highlighting the many benefits of creating a PRD (uniform communication, reference documentation, knowledge transfer, etc.). All this is good, but it doesn’t motivate me to do this. But what I’ve learned is that PRD is for me, not for other stakeholders. When that thought hit my head, I stopped writing crappy PRDs. The only goal I would say when writing a PRD is to clear your mind and be completely clear on why you are building this product/feature, what you are doing, and how you are doing it. is to I dismissed the idea that he was writing a PRD to help a developer create a specific feature. I am writing to know what I wanted to create. everything else is secondary. period!
how:
-
I’m using Confluence to create her PRD and I haven’t found a way to change it. Confluence comes with a default “Product Request” template, which we use with a few modifications.
Let’s start with the PRD teardown!!
We cover the following topics: set goals correctly
Know your success metrics
Think like a customer
How will my customers receive me?
lay out your thoughts
design before code
set goals correctly
Confluence Product Requirements Template
“Why did you start this project in the first place? There should be only one core goal.”
The goals you set for your product/feature should be clear. There may be multiple purposes for creating this feature, but pick just one that is the most important. This is important because it helps you focus sharply on one thing. With so many goals, it can get confusing to track your progress. So find a solid reason to build this first and foremost.
1. Know your success metrics
As the saying goes, “You can’t improve what you can’t measure.” I don’t think you can even prove it’s worth doing. Once a goal is set, I need to know how I will demonstrate the success of this initiative.I need to know what the best metric is to measure it. Let’s say you are creating an “order detail page” and your main goal is to improve the customer experience. Unless we know what the current customer experience is like, we can’t know if the intervention had a positive impact. You can now track multiple metrics. for example. :
- Number of issues per 100 orders, change in CSAT score, etc. Don’t start developing a product if you don’t know your current metrics. These indicators are also very simple. If you can’t ask your customers for feedback, do some research with your operations and support team. But make sure you know the metric and its current location.
2. Put yourself in the customer’s shoes
Before you start writing this, talk to a few customers, or potential customers, who have used your product in this way. Don’t tell them what you’re building and need their opinion. You need to map the user journey. Below are some questions that need answers. How did users find this feature/product?
Is the problem you are trying to solve supported by customer feedback?
How will users interact with the new features you want to create?
How do competitors solve this problem?
In my opinion, this is the product manager’s most important task. To act, think and act like your customer, you have to know your customer well.
One of the tools he uses for user/process flow mapping is Draw.io. There are various other tools such as Miro and Whimsical, but draw.io is very comfortable because it works with Google Drive. This is one such process flow view we created for our order management system.
Process Flow — Order Management System
Once the process flow is in place, each user needs to write out her story in detail. This is necessary to know each use case. A user story is something about how a user behaves with the product. You can follow this structure:
Requirements:
Details on the order list page
User history:
Assuming I’m the customer (assume you’re the customer and see how he reacts)
I am on the order list page (the position he is in)
And I have placed some orders before (he has done so in the past)
You can then see all your past orders along with order date, order amount, and brand. (I want it as a result)
PRD Template Snippets — Confluence
Similarly, I made separate notes for each actionable step. This may seem repetitive and redundant, but it helps cover all the nuances and details.
3. How will my customers receive me?
Acceptance Criteria (AC) are the conditions that a software product must meet for customer acceptance. They are unique to each user her story and define functional behavior from the end user’s perspective.
Make the function more detailed.
AC defines the boundaries of user stories. Provide precise feature details to help your team understand if the story is complete and working as expected. Please describe the negative scenario:
AC sometimes needs the system to detect an insecure password entry and prevent the user from continuing. An invalid password format is an example of a so-called negative scenario where a user enters invalid input or behaves unexpectedly. AC defines these scenarios and describes how the system should react to them.
Acceptance criteria can be written in a variety of formats. That is:
scenario-oriented (given/when/then template);
Rule-based (checklist template).
You can search in detail. Let’s take an example to understand this.
4. Giving a Layout to your Thoughts
Wireframe: A wireframe is a layout of a web page that demonstrates what interface elements will exist on key pages. It is a critical part of the interaction design process.
The aim of a wireframe is to provide a visual understanding of a page early in a project to get stakeholder and project team approval before the creative phase gets underway. Wireframes can also be used to create global and secondary navigation to ensure the terminology and structure used for the site meets user expectations.
I use Balsamiq and Whimsical to make wireframes. But there is no hard tick on the tool selection until you are able to convince your thoughts in design. There are many who makes wireframes on drawing sheet which is also absolutely fine.
Sample wireframe — Order Listing Page
5. Design Before the Code
Finally, when you have done so much, you now need to sit with UX/UI designer and walk him through the complete PRD. Your role ends here. But just make sure, you don’t submit the PRD to your stakeholder unless your design is ready. Here are a couple of things you need to check the design for:
- Go with the theme of the overall product
- Don’t overwhelm the user with many click options and data points
- There should be a design for a website, mobile view, Tablet (or any other screen size)
- The design should cover all use cases.
This might look a bit overwhelming for someone who is new to product management. But having a skillset to write detailed PRD sets you apart. Do reach out if you wish to discuss this topic in detail.