Building Products | Requirements & Roadmap planning
Building Products | Requirements & Roadmap planning
Hey there, thanks for dropping by! I’m Pradyumna, working in the Product team at Fyle. It’s been two quarters at Fyle and two years of building products in my career, both in B2C and B2B combined.
Disclaimer: There is already a lot written on Product Management, and I am no expert in setting guidelines on how PMs should function. This reflects how we work at Fyle to build products that our customers love!
We really are obsessed with solving our customers' problems, and we walk the talk in doing so. This blog post will help you understand how we gather the requirements, coordinate internally, prioritise, and add them to the roadmap.
Gathering requirements:
We gather the user requirements and feature requests from these sources:
Support tickets: Our Customer Success team has Customer Success Managers who manage the user accounts, and Customer Support executives interact with the users over the chatbot present on the product.Since this team interacts with users on a regular basis, we get the requests faced by the users through this team. Our Customer Success team creates tickets on Clickup with relevant details like the customer name, the number of users, and screenshots, and we sync up to understand the user requests in depth. We use tags to identify similar tickets and bring these tickets during the roadmap planning.
In-product reviews: This is the prominent source of understanding user problems. We have NPS surveys inside the product prompted after the users complete an action on the product. Usually, the users mention the ratings, we follow up with them to understand what was helpful and what went wrong for them.
Customer interviews: As mentioned, we follow up with the users for a quick call to understand their experience with using our product and ask them about the problems they faced and what they would like to have. To understand their requirement better, we ask how they are solving it without the feature, what functionality they need (not exactly what feature they want), and how is it going to help the users (in reducing manual effort or customising their org needs).
Many times while we are interacting with the customers, they bring up the requests they have on the whole product, outside of the agenda of the call we intended to have.
We compile the notes of these calls and post them in internal slack channels, reach out to other stakeholders working on the respective areas, and consider them to understand and build.
Internal Slack channel: We are our customers too! We use Fyle to claim expenses incurred on WiFi, Work from home setup, and other expenses. Since our team uses Fyle, we post the requirements in a Slack channel called #feature_wishlist. We keep tracking the features and be transparent in letting know the team how we go about deciding what we’d take up in the upcoming quarter.
We gather the requirements from the existing customers and internal teams from the above-mentioned sources. Do you think we heard the voice of all people to build the products?
What about the prospects who didn’t convert? Is there any way to understand the reasons for the deals we lost?
Yes! We have an awesome sales team that shares the information about the lost deals due to missing features on the product. You see, it’s non-negotiable for us to build features for our customers, but also important to consider the requests of the prospects who didn’t choose Fyle for any missing features.
So, we interact with our sales team regularly and understand the reasons for the lost deals.
With the requirements present on our backlog, let’s discuss picking them up to serve the customers.
Quarterly Roadmap
At Fyle, we plan quarterly to build and ship products. We interact with the key stakeholders involving the leadership to align the roadmap with the business goals.
We have the OKRs set for the company in a quarter and pick the requirements from the backlog based on them to discuss and prioritise them in the roadmap.
Our quarters follow the calendar months, with the first quarter (Q1) starting from January 1st and the last quarter ending on December 31st (Q4).
Roadmap planning
After collecting the requests in the backlog, we schedule a couple of internal meetings (within the Product team, including the leadership) 30 days before the commencement of the upcoming quarter (for Q3 2022, we start the discussion at the end of May).
We call each roadmap item an initiative and have different teams working on different initiatives. Since we have two roles on the product, we divide the initiatives catering to the needs of these two roles:
Admin: Administrator who is an Accountant or Finance person of the organization, responsible for configuring the settings and coordinating with their employees to report their expenses. Typically there are one or two admins for an organization using Fyle. The scope also covers the Accounting integrations with Fyle since the accountants export the expenses to Accounting software like NetSuite and Sage Intacct from Fyle.
Spender: All users of Fyle who report the expenses and get their accounts settled.
It is in our best interest to divide the teams based on the role so that the teams are focused on providing a better experience to the users. For example, I work on initiatives impacting the Admins.
Prioritizing the initiatives
We always have a lot to build in the backlog, and I believe this is a good problem to have! We prioritize based on how well we could solve customers’ problems, what would be the impact on our KRs, and the ones which would impact the company’s metrics are easy to pick.
We try to get answers to these questions to prioritize the initiatives:
Why is it needed? We ask why the requirement is needed for the customers. We try to understand whether it’s a blocker for them and whether any workarounds can help them achieve their goal.
What is the impact it is going to make? Is it a deal-breaker? Did we lose any customers due to the absence of the functionality? Is it going to add more customers to Fyle?
What is the value addition to the customers? Is it going to help them by reducing the manual effort? Is it going to customise according to their needs? Does it help them in reducing errors while reporting expenses?
Since it’s not practically possible to ship all the features present in the backlog within a quarter, we set the expected stages at the end of the quarter for the initiatives.
Research: Owned by the PM. The objective is to understand the problem, and the outcome is to align the stakeholders, validate the problem with the customers, and explore various solutions. Then handed to the Design team.
Design: Owned by the designers. The objective is to explore the designs for various solutions, take feedback from the customer, and be expected to be ready with the final designs of one solution.
Release: Owned by the PM. Activities like release planning to the customers, communication, discoverability of the product, validating the solution, and evaluating the OKRs until closing the initiative.
We set any of the above three expected stages for each initiative based on the team's bandwidth. It’s important for us to give importance to roadmap planning, and hence we spend a considerable amount of time here.
After multiple sessions of healthy debates with the stakeholders from the Design and Engineering teams, we publish the roadmap. Believe me, the whole process is as exciting as SharkTank! We share the roadmap across the organization by posting on Slack.
While this gives you an idea of how we gather requirements and prioritise them, there’s still a lot to be covered on how we pick an initiative and ship it. We will get back with the details of it in upcoming blog posts, promise!
As mentioned at the beginning of the blog, I have an experience of two years, and I’m glad I decided to join a fast-paced startup, Fyle, at the early stages of my career. If you had asked me about doing the things mentioned in the blog, I’d have not believed.
With the friendly team and approachable leadership, I’m learning a lot by practice, by applying the principles of Product Management every day at work.
Talking to the customers, actively interacting with the teams, and shipping products has been a great experience so far, and I’ll continue to learn and grow. I am hopeful that this is the beginning of something big and great 🙂
