Product Documentation | Part 2 — RFC
Why does a PO discuss technical documentation?
First, I don’t believe POs/PMs need to learn programming. However, by becoming familiar with the Request for Comments (RFC) document, I have broadened my perspective on how the technical aspects relate to my deliveries as a product.
The essence of the product is to communicate and clarify. I realized that the RFC is about gaining perspective on technical feasibility and understanding the details of the development.
That’s why I want to delve into the details of how the RFC impacted my experience as a Product Owner of a technical team.
What is an RFC
RFC stands for Request for Comments, and its main purpose is to collect contributions from the entire technical team, including from mobile and data. It is a document to assist multidisciplinary development teams in constructing a technical solution.
Once approved, the RFC serves as a point of reference for the entire team when implementation begins.
Importance for product area
Just as the Product Requirement Documentation (PRD — article about this documentation here) can be seen as the consolidation of the discovery and the proposed solution to be implemented in the product, the RFC would be its technical complement. The PRD fulfills the function of informing the business side, while the RFC is the technical team’s reference for what will be done.
This document guides POs and developers to adopt a more holistic mindset, including expected milestones and important considerations, ensuring well-founded and well-evaluated decisions.
Experiences
I learned that together, the RFC and PRD greatly increase the efficiency of the team.
Why it was useful for my context:
- Prevention of mistakes — I learned that the best path for feature/product development is to map out from the beginning the feasibility and risks of the infrastructure and technology that the product already uses. As we were in the midst of a platform migration, the scenario was not just about the technical feasibility of our product but also about what needed to be integrated into the technology of another platform. In addition to giving the developers much more clarity from the start, I could understand closely the backstage of the development.
- Clarity on details — more than once, the RFC brought to light the need to change a route or the behavior of a button because the technical part compromised what the Product Designer and I had envisioned at first. Discovering this before starting development prevented rework and frustration.
- Anticipation of necessary changes — Usually, our new features required some code refactoring or a CRUD, the Tech Lead would define in the RFC how and on what infrastructure this would be done, which directly influenced the sprints (size, weight, and impact of tasks + prioritization); It is important to follow this process in case significant changes need to be made.
(“Create, Read, Update, Delete” is an acronym for ways one can operate on stored data. […] CRUD typically refers to operations performed in a database or datastore, but it can also apply to higher level functions of an application such as soft deletes where data is not actually deleted but marked as deleted via a status”, according to mdn web docs);
One of the impacts I felt with the use of RFC was having the description of how to perform a rollback to a previous version of the code if necessary.
Despite all the care with development and testing, it’s common for something to fail and need to be undone quickly to avoid impacting users. Therefore, it is important that everything developed can be reversed and what can be done in different scenarios.
Having this information in the RFC and knowing that we were covered in case of an emergency, from the beginning of the development, gave security to the team and to me as the manager of that product.
Success Case
In one particular project, the phase of building the RFC coincided with the vacation of the technical leadership of my team. To avoid delays in development, we took the initiative to have senior frontend and backend developers take on this task.
We created a document for each part, but there was excellent collaboration between them and the outcome was very positive.
Because they are close to the code on a daily basis, I felt that the delivery was more pragmatic, less complex, and straightforward. Another positive point was that the developers were very committed to mapping part of the work that they themselves had built.
Highlights
- Detailed correlation of the database;
- Suggestions for the utilization of existing frontend components;
- Suggestions for refactoring and adapting frontend components;
Challenging Case
A somewhat more complex experience occurred when the team was without an assigned Tech Lead and the developers did not have seniority in the product.
We had the support of other developers who worked in other squads, but there was a lack of vision of the infrastructure of the part in which we were operating in the product.
Highlights
- The RFC was based only on the PRD’s proposal and did not delve into the technical specifics;
- There was no participation from other developers, which resulted in a biased document since the responsible party was only involved in backend (some frontend interactions impacted the creation of a new database);
The product delivery phase was affected by rework in development, testing, and documentation. Consequently, there were delays, constant scope changes, and team frustration.
What I have learned
Of course, the idea of creating another document implies the use of precious time from a developer, in addition to the energy that the team will need to invest in studying this material.
However, this argument can be easily countered if we think about how many times we face misalignments in communication between backend and frontend or realize too late that new problems have arisen due to the use of an inappropriate solution for a technology decision.
Based on the experiences I’ve had so far as a PO, I find myself fully embracing the culture of creating various product documentations, including the RFC.
Certainly, we’re discussing different contexts and needs. In my previous experience, at a large company with significant technical complexity, this document was indispensable.
However, I have spoken with technical leaders from startups who informed me that the speed required for delivering certain features did not allow for the proper use of RFCs.
Besides the time spent writing the document, there is also the maintenance as things change. Therefore, startups usually do not use them.
I didn’t create any RFCs, of course, but GitHub has various templates that can be followed. I will leave an example that I found here.Nubank has created a public document explaining their use of this documentation, which you can consult here.
What do you think? Share with me if you create this documentation and how your team uses it 🙂
