How Razorpay is building great products by avoiding traditional PRD approach

Introduction

Razorpay has been innovating at the top of the financial ecosystem and providing solutions to businesses since 2015. From our neobanking product – RazorpayX, to the recently launched product – Payment Buttons – all of these products have seen significant traction. Month on month, increment in the organic growth of businesses that sign up to use Razorpay, is a testimony that our products have been solving some of the key problems that were until now ignored.

In order to make sure that we always strive to continue building such solid products, there are definitely many factors that go into it. However, as a product manager, one of the most crucial elements to our success can be attributed to our Product Requirement Document (PRD).

In this article, I will take you through behind the scenes of how Razorpay has been able to conceptualize and consistently launch exceptionally high performing products. If you are into product management, you’ll definitely love this!

What is a Product Requirement Document and why is it important to have one?

A Product Manager (PM) is often called the CEO of a product or a customer’s advocate. Whether there’s a customer pain point to be solved or a business case to be implemented or just a fun feature to develop – all of these can be molded into simple ‘requirements’.  A collection of these requirements for any product is called a PRD.

A PRD helps in easy collaboration across cross-functional teams like Design, Analytics, Engineering, Dev Ops, QA, Marketing, and Sales.

At Razorpay, the challenge is huge in trying to solve problems and at the same time ensure compliance with regulatory bodies such as the Reserve Bank of India.

Given the large number of people involved in making a particular product successful, it becomes important to document everything relevant so as to create a common understanding of the product. A PRD hence also acts as a communication tool between the Product Manager, cross-functional teams as well as other stakeholders.

Without ironing out the details and setting the right expectations in the PRD, it is very likely that what is in the mind of the Product Manager compared to what finally gets launched could be very different.

To avoid such mistakes a PM needs to ensure that they clearly explain requirements in a way that is easy to consume by the readers. Flowcharts and wireframes always aid in explaining complex requirements much better

Challenges with traditional PRDs

A traditional PRD will be a lengthy document that is focused purely on elaborating the solution in form of requirements. The solution is thought based upon the feature list that has been finalized by the PM. Many of the times, it happens that the ideation of the product is based upon what has worked upon in the past and if the same can be modified a bit for a newer set of customers. A walkthrough of the same is provided to different stakeholders, which is further broken down into the Jira tasks based upon the features and the specifications.

Traditional PRD doesn’t sell the vision of the product and fails to excite the team in terms of: 

Why is this product important? 

Who are the customers? 

How is it going to solve the problem of the customers? 

What benefit will the organization get post this product launch? 

Hence it continues to be the voice of a PM rather than the voice of the customers.

Being a PM, If you don’t go deep into the problem statement and don’t understand your customers then you will never be able to build solid products, the same applies to the reviewers of your PRD. If the reviewers of the PRD are not aware of the problems faced by the customers, they would never be able to provide meaningful feedback on solving the problem in a different way, and they end up being readers rather than reviewers. 

How is a PRD at Razorpay different from others?

At Razorpay, we not just emphasize on ‘What’ but also on the ‘Why’ part of the product requirements. So the deal is like – Why does this product need to be built and what problem is it going to solve? A few questions to be answered are:

• Do we know about the customer’s pain point?
• Do we have the right customers for this product?
• Is this the right time to build this product?
• Is this inline with the vision of Razorpay?

One of the most common mistakes made by PMs is to directly jump to provide a solution without completely defining the problem statement. In order to avoid such situations, we have divided the PRD into two parts – a Concept Note and User Stories.

A concept note is supposed to elaborate on the purpose of the product and get an internal buy-in on the concept – problem statement, customers, impact, and a high-level overview of the proposed solution.

Think of a concept note as an executive summary of a business plan or a VC pitch. This concept note can come in from any stakeholder and having this handy helps a PM prioritize a particular requirement among the many others in the product backlog. A PM can then introduce wireframes, workflow diagrams etc to explain the above points in the concept note. It’s not necessary that all concept notes written will see the light of the day as post writing a concept note, one could have a better insight on the “Why” part.

User Stories on the other hand are specifications that act as input for other members of a cross-functional team. These are further broken down into Epics and Stories, based upon the granularity required for the product. Each story is focused towards providing a deliverable feature to the end customer. It is always important that these stories be as granular as possible because it would help in getting realistic estimates in planning for a sprint.

Key Sections in a Concept Note

• Project Summary – A project summary is meant to inform the reader about the idea and key highlights of the product. The project summary is one of the most important parts of the proposal. It is likely to be the first thing a reviewer will read and this is your best chance to grab their attention, have them show their interest, and probably convince them of the importance of the product before they even read the entire document.
• Goal and Success Criteria – This section carries the exact goal that we would achieve post launching of the product. Success Criteria should be well defined, as every stakeholder would want to keep an eye on this metric to see the value add that this is going to bring to the organization. Post-launch this becomes more critical for stakeholders as it helps to measure the success or failure of a product.
• Objective and Key Results (OKR) mapping – Another key line item that we add to this section is “OKR Mapping ” which helps the PM to understand that whatever they are building is aligned to and shall impact the organization’s OKR. This is a topic of an article in itself if you haven’t already started using this technique to help prioritize.
• Problem Statement – Current problem faced by the customers in the absence of the proposed product. A good problem statement not just contains a description but is also backed by data. Data helps in highlighting how big the problem is. Most of the PMs make the mistake of defining a problem statement with just descriptive text, assuming that the stakeholders are already aware of the problem statement. Sometimes you may not find the right data for your product. In those cases, it is very important to start doing customer research or user interviews to understand how big the problem is. A well-defined problem statement is the core of building the right product for the right customer.
• Customer Persona – Razorpay has a Customer-first philosophy that emphasizes a lot on defining the personas. Who are you building this product for? What are the key pain points of these sets of users? There are multiple scenarios where you will find that there are different sets of customers and each set has a unique behavior. Do NOT make the mistake of putting all your customers into a single bucket! This way your product will never be able to find a market fit. Either you are very very sure of the segment for which you are solving a problem or you pick your segment for whom you would be solving that problem.
• Current Alternate – We are working in an era where technology is evolving every day and product improvisation is born to happen. There are high chances that your team or stakeholders aren’t aware of how customers are currently working in the absence of the problem to be solved. When you uncover this portion you may encounter, more areas of customer pain points, you could get more clarity of thought on what to build and what not to build.
• Assumptions – This is an optional section, but it is recommended to add all the assumptions you have taken towards conceptualizing the product. This helps all the stakeholders to be on the same page and leaves no room for misunderstanding.
• Recoverable / Reversible in case of failure without impacting Customer experience – Disaster management, something that most of us might have heard of, is least likely to be implemented when we are building a product. There is no silver bullet in software engineering and there could be a scenario where your product might be dead on arrival or it might have severe impact on other modules that could impact overall customer experience. This section would cover the solution we are proposing is reversible/recoverable in terms of failure and steps to mitigate the same. This would help the team to shut down the feature in terms of failure.
• Unknown/Future similar problem – Zoom out and think of, what could be the similar problems that might arrive in the future, list those downs to get a fair idea on, how proposed solutions can be leveraged to incoming future solve the problem that doesn’t exist as of now.
• Solution consideration – As I mentioned earlier, a typical mistake which is made by PMs is to come up with a solution and not elaborate on the problem statement enough  This has also led to thinking of just one way of solving a problem and in most of the cases, PMs might have already thought of a solution. Do not do a rookie mistake over here – open your mind and think of at least 3 ways to solve a problem. These solutions could be very lame and may look hackish but still jot down every solution with pros and cons. This would give you a clear picture of your own thoughts and you would be able to surprise yourself too on what the mind can achieve when put to think before acting. At Razorpay, PMs are able to propose a minimum of 3 different approaches to solve a problem, each approach having its pros and cons. This helps the stakeholders to evaluate the solutions and also provide a view of why a solution is being proposed like this.
• Solution Summary – Once you have the different approaches listed down with their pros and cons, you are now clear with what approach could be chosen to solve the said problem. Mention a high-level summary of your proposed solution so that the reader gets a sense of the bigger picture of the solution before going deep into it.
• Happy Flows – Maybe a wireframe or workflow diagram, use your preferred way to explain the happy flow of the proposed solution. How customers interact with the system, end to end? It will make the readers comfortable and they can visualize how you are proposing to solve the problem.
• Un-Happy Flows – Similarly like Happy Flow, you need to explain all the edge cases in form of wireframe or workflow diagram, these are very important and do not ignore even if you are building a smaller feature as well. If you are not defining this section very well, you are surely going to miss some of the system behaviors and these would be voided during the implementation, and eventually, it might lead to poor customer experience.
• Detailed Solution – By the time you reach this section, you have already uncovered all the possibilities in terms of the problem and it’s solution, your mind can now focus on elaborating each and every moving piece that would be required to build the product. Uncover each component and blocks, layer by layer, and explain your solution. The easiest way to do this, jot down all the blocks of the solutions and within blocks, capture the component interaction of the system. After reading this section, readers should be well aware of the proposed solution and different pieces that would be required to build this product. Most teams should be able to provide rough estimates based upon this section.
• Impact assessment and Metrics – Define the metrics that you would use post-launch, to measure the impact of the product and ensure its success or failure. This section should be in line with the Goals and Success Criteria mentioned in the starting of the concept note.
• Internal Dependencies (optional) – Optional section to help you collate all the internal dependencies you might have for executing the product implementation, it could be as small as getting additional data from someone or maybe it could highlight cross-functional team dependency.
• External Dependencies (optional) – Differentiating external dependencies with internal one so as the team has clarity of thought on whom to approach for what. It could be something like a UAT testing environment or sandbox environment. Any blocker you feel you might have from an external party, mention about the same here.
• Competitive landscape (optional) – Every business has its own competition, make sure you have done enough research on how they are solving this problem statement and highlight the same. It need not be in detail, just the summary with few external reference links will give a fair idea of how soon this problem should be addressed.
• Risk assessment (optional) – The solution which you are proposing, will it impact other modules or cannibalise any other product or it might cause drop off in the user base? If yes, then assess the risk associated with the same and highlight it in this section, so that stakeholders are aware of the risk associated with building this product.
• Release strategy and milestones – Callout your phase-wise release strategy on how you are going to take this product to the market and roll out the feature/product slowly. For bigger projects, I would recommend carving out a separate Go to Market (GTM) plan. Your strategy should start from Production testing → Alpha Release(1 customer) → Beta Release(4-5 Customers) → Phased wise release. Every phase will have the release criteria based upon which you would be increasing the rollout.
• Future scope – High chances are that you are not building a full-fledged product and focused towards building in a phased wise approach. Carve the future scope of this product into a summary paragraph.

Building a concept note will help you get the buy-in from your business and tech stakeholders, but still the same can’t be used for the implementation. The next piece is to break down the proposed solution into requirements so that it can be consumed by various teams for implementation.

User Story is broken down further into EPIC and Stories. A single EPIC can have multiple stories and a product can have multiple EPICs.

• EPIC – An epic is a large user story that cannot be delivered as defined in a single sprint or single iteration. This typically contains the key components of the product which needs to be developed by implementing smaller stories inside it. While writing EPIC, please ensure you write down the project summary along with relevant links to the reference documents like – Concept Note, Mocks, Integration Docs etc. EPIC should also contain the benefit, the end-user will get post-go-live of the project.
• User Stories – Set of features that you would have planned to have in your product. Each feature to be explained in such depth that developers should be able to understand user interaction with the system. Below is the framework that we had implemented at Razorpay, to carve out the user stories.
  • Summary of the story – 1-2 liner explaining the feature that is being addressed with this story.
  • Benefit – End customer impact that it will have post-development of this story. Teams who would be picking this story for implementation will be well aware of the impact that this is going to happen post-launch.
  • Acceptance Criteria – The expected outcome for a user for the corresponding solution being proposed. A good user story contains acceptance criteria at the Product solution level and stays away from drafting Engineering and Design solutions towards the proposed product solution.
  • Analytics Requirement – Metrics that you must have planned to track post-go-live, may not even exist, hence every story should be backed by the analytics requirement, these could be in the form of events or data points that you would like to capture.

Tip: User Story format is compatible with Jira importer, post writing your stories in the excel, you can upload the same on Jira, it would create all the stories in no time. You can also add as new columns as per your project configuration and it will work flawlessly. 

As you can see from the above sections, we at Razorpay document, every minute details and moving pieces of a product.  The objective is pretty simple – easy collaboration and informed decision making across cross-functional teams. Beautiful ideas are often badly executed due to a lack of clarity or wrong expectations which in turn result in disastrous products.

Do try out writing a concept note next time with your user stories, here is the handy template of Concept Note and User Story, that will help you to get started right away.

We would love to hear other best practices around writing better product requirement specifications.