From Problem to Solution: How Fyle's Product Managers Collaborate with Customers
Learn how customer interactions shape our product strategy and success!
Hello, this is Pradyumna Dinni, a Product Manager at Fyle. I’ve been working in Product for three years, and it has been almost two years at Fyle. In these two years, I’ve had instances where I spoke to our customers and prospects to understand their requirements.
We mean it when we say we build the product for our customers. How can we understand the problem we should solve without talking to the users?
In this blog, I'll talk about the customer interactions at Fyle and the different stages at which we speak to customers to involve them in our product development cycle.
"Innovate with ears open; you're not Jobs or Ford. To know what people want, you must first listen.”
Abhishek Jain
We speak to them for various reasons, from understanding their problems, getting their validation, feedback, onboarding to a new feature, or hearing them out when they don’t find the product useful and decide to churn.
We have amazing Sales and Customer Success teams who actively engage in customer interactions and help us with facilitating customer calls when required.
Let’s get started with each stage.
Problem Exploration
Objective: Listen to them, don’t jump to conclusions. Ask, ask, ask!
We call each roadmap item an initiative, and every quarter we have multiple initiatives running in parallel. We plan our roadmap and start working on the initiatives every quarter.
We get customer requests via the Customer Success team and Sales team, among other sources.
Soon after we start working on an initiative, we write the problem statement and the background in the document. At times, we are not clear about the problem. We have a vague idea of the problem, so we reach out to the users to understand their pain points in detail.
We drive the call by keeping the agenda simple - hear the problems they face that can help us solve them.
Not always do the customers communicate their problems. Sometimes it’s about how your product offers the same solution differently. It’s always better to listen to them and ask the right questions until we are clear about what they want to achieve with our product.
Validating the Solution
Objective: Offer the solution approaches. Take note of the feedback to incorporate and improve.
As we proceed with ideation of how the approach to solving the problem should be, we brainstorm and decide on an approach. If it is straightforward, we proceed to start working on designs.
At times, we have multiple ways of solving the problem, and after all brainstorming sessions, we reach out to customers to seek their feedback on the approach(es) we have thought about.
This helps us avoid building something that doesn't meet our users' needs. By testing the ideas with users, we identify any issues early on and make changes before it's too late.
While we validate the approaches with our customers, it’s equally important to use our judgment to decide the solution.
Design Feedback
Objective: Design something that is obvious, and users shouldn’t think how to use it! Observe carefully and ask questions. Incorporate feedback.
After we ideate and decide on the approach to solving the problem, we proceed to start working on designs. Although our design team starts working on the screens then, we ensure the team is in the loop from Day-1, depending on the kind of problem we are solving.
Our design team offers help to us in coming up with solutions ground up for a couple of initiatives, and they have done a great job so far!
Once we have the designs ready, we reach out to the users who are facing the problem that could potentially be solved with the solution.
We don’t make them see all the Figma screens but work on a prototype and ask them to finish a task by navigating on their own while we are watching them. We observe their behaviour and ask them questions about why they performed the task the way they did, seeking their feedback.
At times, we have multiple versions of the designs when we are unable to decide. While the users are on the design feedback call, we gauge their usage and feedback to decide which version makes sense for them.
We get their feedback on the usability and overall experience. This feedback helps us improve and ensure the final product is user-friendly. By incorporating user feedback into the design, we create a product that is easy to use and meets the needs of our users.
Post-Release Feedback
Objective: Collect feedback and add improvements to the product backlog.
After the release, we need to take the feedback and improve the product further. This feedback helps us make improvements and prioritize new features. By listening to the users, we can change our product to improve its overall performance and user satisfaction.
It reinstates that we care about our users and incorporate their feedback in product development. You can read about an initiative (Automatic Expense Report Submission) that we improved after releasing the basic version here.
Not every time we ask the user for their time to hear their feedback. We let them share their feedback by any means they are comfortable with. Here’s a sample screenshot of one feedback we received over email.
Since we will be working on multiple initiatives at a given time, we interact with our customers for one or multiple reasons while working on the problems. While the stages mentioned above can be part of a product development cycle, we also speak to the customers in other instances, like dealing with churn warnings. Also, for the ones that won’t make it to initiatives, we have requests where we have to say NO to the customers.
Saying "No"
Not every request from users can be accommodated in our product. As a product manager, it's important to say "no" when a request doesn't align with the overall direction of the product. By saying "no" to certain user requests, we maintain the focus of our product and ensure that it meets the needs of our target market.
"Innovation isn't about saying 'yes' to everything. It's about knowing when to say 'no.' A great product isn't the result of indiscriminate 'yes's but the resolve to say 'no' a thousand times.”
Abhishek Jain
During these calls, it’s important to politely put forward your thoughts with the users and help them understand what your product is built for.
Sometimes the users are used to using a product in a certain way and find it difficult to use our product in the way we built it. If it is a problem that we need to address, we pick them up. Else, we politely say no.
Dealing with Churn Warnings
Objective: Hear them out. Think about ways in which you can make them successful. If you feel the product does not fit their requirements, let them know then and there.
There are instances when the users can come up with requests or problems and mention that they won’t use the product or churn unless that is built.
Usually, such instances are rare but happen for B2B products. While that customer is important to our business, it’s equally important to judge whether their request makes sense for the business.
We talk to them to understand why. If the problems are valid and value addition for the business, we pick them up and see how to build them. We reprioritize the roadmap items and incorporate this request as it unblocks the customers to use Fyle or prevents churn.
If the request isn’t something of value addition for the business, we let them know, and the Customer Success team expedites the off-boarding process.
Is this it?
While we need to get relevant answers from the customers at every interaction, it’s necessary to understand we are talking to humans and not ChatGPT to get the responses we always expect with some prompts. Not every call can go fruitful, and it’s okay.
We try to make the users comfortable at the beginning of the call so that we can have a conversation instead of a Q&A session.
The instances mentioned above are not exhaustive. We speak to customers on multiple occasions, and I tried to address a couple of scenarios here. By the way, we document every customer call by following a template on Notion. Every Product Manager at Fyle follows this practice to ensure we all pass on complete information to empower us for decision-making.
Our vision at Fyle is to ensure that “Not a second is spent on expenses." Hence, we continue to work on solving our customers' problems and making their lives easier by always keeping them in the loop and making them collaborators!
It's all about building the product together with our customers to ensure their needs are met.
For the design feedback what's the split like between using something like Maze (maze.co) and observing over live calls with the user? Or when to use which?