Stop making useless PRDs
This is how we revamped our PRD template in 48h at Feedzai (powered by UX)
At Feedzai, Product Requirement Documents (PRDs) are used to detail the requirements a product needs to perform successfully. This is a living document that records the evolution of the product until the end result of a project as planned in the roadmap.
It’s the ultimate source of truth for the various team members who will contribute to the project. This includes stakeholders, product managers, UX designers, engineering teams, etc. The PRD provides context, requirements, issues, dependencies, and guides the team’s work to deliver the best possible solution. In a nutshell, having a well-designed PRD is half the battle for delivering a robust solution.
In order for teams to work in a consistent manner and have a similar way of organizing and consuming the project information, a PRD template was developed to aid product managers (PRD creators) assembling high amounts of complex information into a readable and easy-to-understand document. Since the first creation of the PRD template, the product’s needs have drastically shifted and teams have grown rapidly. The product team has grown to include UX designers, technical writers, etc. The initial template was no longer sufficient to provide the requirements for each team member.
We realized it was time to do something about the elephant in the room and then… Glitch Day came along!
There was a Glitch needed to be fixed!
One of the best things about working in an environment where the pace and expectations are always high, is there are thousands of ideas being generated at the same time. Sadly, (and realistically), there is never enough time to execute all ideas. This is why at Feedzai we have dedicated events that enable Feedzaians to explore and execute some of these promising ideas. On the Glitch Day, Feedzaians were given two days to assemble a team and work on a specific “glitch,” — something that affects either our team or our clients in a deep way, but was never considered for the product roadmap.
This seemed like the perfect event to explore how we could revamp our PRD structure to improve our team’s productivity and alignment. We gathered team members with different roles and expertises that could contribute to this new project through different angles: our platform director, a recently onboarded group project manager, a technical writer, and two UX designers.
The clock started ticking and we had 48h to come up with a solution that would match our team’s PRD needs.
Our goal was to design a new PRD template that supports the needs of the different team members’ expertise that contribute to the profiles that make our product. This includes engineers, product managers, technical writers, directors, UX designers, and subject matter experts (SMEs).
How we tackled the problem
Our glitch team gathered information and came up with an execution plan.
Phase 1: Dig Deep and Collect
The first phase was to dig deep into the problems we faced with the existing PRD and understand it as a whole. We decided the best way to do so would be to involve our colleagues across the product department. We quickly drafted a survey that was sent to team members in order to understand their pain points with the current PRD template. We wanted to collect direct insights into what could be improved rather than going based on our own assumptions.
We identified two different PRD personas as fundamental from our survey sample.
- Creators: users who actively drive or participate in the PRD creations;
- Consumers: users who would make use of the information described to complete and execute their work.
The survey results had to be informative and have qualitative data that would support the team in designing the new template. We asked questions that would provide more insight on current challenges of the PRD such as:
- In your opinion, what should be the main goal of a PRD?
- Please describe in what way the PRD is helpful when performing those tasks?
- When reading a PRD, what pains are you currently experiencing with the current structure and content?
- If applicable, when you create a PRD which section(s) do you find the most difficult to write? Why? Add examples when possible.
- What would you wish you could see in a PRD that is currently missing?
- Can you specify why the shared PRD example is a good or bad example?
- What other references/artefacts do you use besides the PRD as a source of information during the development of a feature?
We also included quantitative questions to provide us with metrics we could measure through the PRD experience over time:
- Please indicate to us your role at Feedzai
- Who should be contributing to the PRD?
- How much does the current PRD structure help you execute your daily tasks? (on a scale of 1–7)
- How often do you view the PRD of a project? (ex., at the beginning of the quarter vs. all the time it’s the ultimate source reference, my single source of truth)
- According to your experience, are the PRD’s up to date during the entire project? (on a scale of 1–7)
- How well do you think this PRD represents what you need for your work? (on a scale of 1–7)
We included a fresh perspective to our research as our survey results are based on our internal experience of team members who have been using the PRD for quite some time.
We were in luck! One of our team members on the Glitch team was one week fresh to the company. He was tasked with reading through 2–3 PRDs developed in the previous quarter to provide an unbiased perspective and identify any issues and challenges he noted as a PRD consumer.
Phase 2: Analyze and Redesign
In combination with all our research around what a good PRD is we also referenced various articles related to PRD to design a new template that would solve for many identified problems at Feedzai.
Here are some changes we did to improve our PRD structure:
- A structure that matches the entire project life cycle: PRD consumers felt the PRD did not reflect all the steps the project needed to take during its execution. Following the same guidelines as our UX process (Discovery — Problem Space | Definition — User needs and Requirements | Deliver & Metrify — Adoption/GMT Space), we created new sections that would follow a similar approach.
We created each stage of the project lifecycle as a category and subcategories, to compliment the required information needed in order for each stage to be completed.
Feedzai PRD Template Structure:
- Project Team Members
— PROBLEM SPACE —
- Project Overview
- Strategic Fit
- Use Case(s) and Journey(s)
- Assumptions
- Open Questions
— SOLUTION SPACE —
- User stories
- UX Design
- User Flows
- Detailed Use-Cases/Scenarios
- Wireframes
- High-fidelity mockups (if applicable)
— ADOPTION / GTM SPACE —
- Adoption plan
- Related Documents
Appendixes
How to write a good PRD?
The goal was to create a structure that would enable anyone at the company, even if they did not belong to a product team, to understand the feature journey. This structure helps ensure that the PRD was fully completed by the creator and that all necessary information was provided to the consumer.
- Connecting the Dots: Another example of a simple but impactful improvement was to add a section called “Related Documents” placed at the end of the document. This section would help users link any documents related to the initiative that before could be easily forgotten to be linked, like for example the Technical Design Document.
- Guidelines to help PRD creators provide expected information: Interviewed PRD creators mentioned the old structure was not providing much guidance on the expected outcomes. To provide better guidance in this area the team split the various subsections of the PRD according to members’ areas of expertise. Next, we created guidelines to display what information should be included and, more importantly, what information is considered the most relevant for PRD consumers.
- Writing Style: We provided instructions on writing style to provide direction in communication. The purpose of this is to help create standardised content that could be understood by any Feedzaian. We provided examples on “How to Write a Good PRD.”
- Actionable Sections: Some users pointed out they felt it was not completely clear how to structure a considerable amount of information. To solve this pain point we created actionable tables that guide users when filling out the document. The hope is to have the PRD delivered in a consistent manner to get the ball rolling on the project.
Sharing is caring!
At Feedzai we believe teams should help and learn from each other not only inside the organization, but communicate those ideas with the rest of the product community that’s out there. After going through this whole process and seeing how it is already producing impactful change and results, we decided to share our template with you guys! You can download the full template here.
Additionally, we encourage you to share and comment on any suggestions on how to write good PRDs by leaving us a comment. :)
Iterate, iterate, iterate…
Although our project was done during the glitch event, we can proudly say our team has solved for more than one glitch. We solved a problem that was affecting multiple personas and profiles in different ways. Currently the new PRD template is being piloted with some projects in the first quarter of 2021 and its positive impact is already becoming visible, but… we want more! Besides testing it out, we compiled a second feedback survey to learn about the good and the bad of the experiment. The next step will be gathering the glitch team again, analysing and comparing the survey results, and iterating based on the new user feedback.
We feel confident this process will take us to the next level!
