The restaurant tech industry is highly competitive. Every company with a restaurant tech software wants to understand what their customers are looking for in order to create a comprehensive tech solution. More often than not, customers ask for more than what your product offers. These are called product feature requests.
What are feature requests?
Any incoming request pertaining to the product from existing clients is termed feature requests. They are generally associated with the specific business goals of each client. In the B2B realm, it is vital to consider these feature requests as they drive product development and help in customer retainment.
When a product company addresses the business goals of its customers, it increases customer loyalty. It is important to keep your customers involved in product development- a product evolving based on customer feedback is more likely to be successful in the market.
In such cases, especially in the B2B product market, it is imperative to establish a feedback loop. Of course, the customer is the main stakeholder along with the business itself. Every decision taken with respect to feature requests and general critique is going to affect the quality of the product and, in turn, the business.
How does a feedback loop work?
The protocol of the feedback loop differs from company to company. This depends on various factors like the organization size (small-scale, mid-scale, or large-scale), nature of the company (startups or corporates), business goals, bandwidth, and most importantly, the product.
EagleOwl has been successful in putting a feedback loop in place. It is a collective effort by the CSM, engineering, and product teams. EagleOwl’s protocol dictates a standing meeting every morning to discuss new and old feature requests from customers. These are raised as tickets in a project management tool.
There is a priority list for these feature requests. This is based on a number of factors like bandwidth, time, the extent of benefits, financials, client profile, need analysis, and compliance with the roadmap.
In this context, we connected with the main players within our company- the tech team, customer support (CSM), and the product owner. This is a report on their views and opinions about their experience with the feedback loop.
Handling feature requests: The tech perspective
In a startup environment, everyone juggles different roles. It is only tech whose responsibilities are somewhat streamlined. They are responsible for the overall functioning of the product. This is a huge responsibility- you cannot build a product without tech. Without the product, your business has no value.
In larger corporations with considerably bigger team sizes and possibly multiple teams on multiple projects, it may not be possible to involve everyone in customer-facing situations. However, in smaller setups, this can be easily done.
Exposing the engineers to raw customer feedback provides them with a deeper insight into the customers’ thought-process. According to our tech lead, Nithin Jose, getting involved in the feedback loop meetings has helped the team understand the customers’ mindset at a deeper level.
Does this affect their decision-making with respect to prioritizing feature requests?
Nithin suggests that there is a great advantage behind direct exposure to customer feedback. At the same time, unless tickets are prioritized at the business (CSM and product owner) level, the focus on tech shakes to a certain extent. Decision-making from the point of view of tech is governed by stakes different from the business side. These stakes include bandwidth, available technology, and time.
As a solution to this, Nithin feels that giving the onus of prioritizing tickets to the business side of the company helps them churn out better quality features and gives them the space required to focus only on tech. However, since the customer is the main stakeholder, if an issue raised by them is affecting their daily operations, that ticket always goes to the top of the priority list.
Intra-team dynamics
Every tech team has engineers from different backgrounds, with different levels of experience. This dictates their skill sets and strengths. Depending on these factors, engineers are assigned tickets to resolve.
When asked about his protocol on delegation, Nithin had a very simple answer. ‘The higher the urgency of a ticket, the more the level of seniority of the assigned engineer’. The senior engineers are well-versed with the product and codebase. Therefore they require less time to resolve most issues.
Low priority tickets are assigned to junior engineers. But at times tickets pertaining to the product structure or function are also assigned to junior engineers with the intention of rendering them an opportunity to learn more about the product.
Tools involved
There are different project management softwares available in the market. Yet, most tech teams prefer Gitlab. So does EagleOwl.
Gitlab is a tech-focused project management tool that renders an effortless user experience, especially for engineers. It is designed in a way that in addition to hosting its codebase, Gitlab also directly links tickets to corresponding parts of the code. This makes it easy for engineers to manage their workflow.
A change made in the codebase will automatically reflect in the ticket status. Additionally, Gitlab enables the engineers to easily revisit specific parts of the code without having to go through the entire codebase.
Dependency on the leader (Product Owner)
In startups, the product owner (in this case, our CEO), is generally the main stakeholder from the business side. They are also the team leader and in most cases, the primary employer. Even so, Nithin believes that the customer’s needs are above the business goals, as they directly influence the health of the product.
As mentioned earlier, at EagleOwl, the CSM team is responsible for most of the ticket prioritization. The tech follows suit. Only in cases where there arises a disagreement between CSM and tech does the product owner steps in.
The product owner also consults the CSM team in case a ticket potentially heavily affect the business. This dynamic is favorable for the team because it helps build mutual trust, evenly distributes the pressure of decision-making, and thus improves the quality of those decisions.
Fostering customer relationships
In most cases, the chain between tech and customers includes various levels of customer support and sales entities. However, in companies as small as EagleOwl (10-30 employees), it is inevitable to avoid personal relationships, even friendships with the customers. Nithin has fostered such close relationships with some of our customers.
Does building relationships directly with customers affect the quality of critique that you receive from them?
In Nithin’s experience, personal relationships give way to more open critique. Many of our customers bypass the CSM team and approach Nithin with issues and feature requests. When the process is organic as such, it helps create space for more candid customer feedback. The tech team then consults the CSM team and Product Owner before considering any of this feedback.
At the same time, Nithin believes that if the feedback loop is too process-oriented it discourages the customers from coming forth with their critiques, requests, or feedback. If the customer has to go through multiple steps to finally reach a concerned entity, they could feel frustrated and step out. Inflexible companies often suffer from loss of customers due to this reason.
Next, let’s look at the experience of the CSM team with respect to managing product feature requests.
Handling feature requests: The CSM perspective
Onboarding is the first and the most crucial part of a customer’s journey. It can make or break a customer relationship. Therefore, it is imperative for the onboarding (sales) team to be as transparent, clear, and informative as possible to increase the customer’s confidence. At the same time, their onboarding experience needs to be as effortless as possible.
After the sign-up process is complete, a customer becomes the responsibility of the CSM team. The CSM personnel then carry out their training in the product. According to our customer support team head, Varun Vijayan, this step is very important. It gives the CSM team a clear idea about the customer’s sensibilities, as well as it equips the customer with the knowledge to operate the product.
All of EagleOwl’s training sessions are pre-recorded so the customer can revisit them whenever needed. This gives them a feeling of “being in control”. The training sessions as part of the onboarding experience constitute the very first interaction between the CSM team and the customer. Varun feels that if these go well, they earn a trusted critique for good.
CSM and the customer – a bond of friendship
As mentioned earlier, establishing a good relationship with the customer at the onboarding stage itself is pivotal in determining whether the company gains a dependable user. Varun states that it is important to keep these customers happy.
Why is that?
Once the company develops a good rapport with the customer, the customer finds it comfortable to provide honest feedback and openly voice their grievances about the product.
In the beginning, it is imperative to approach the customer (at least once a week to 6-7 times a month) in order to help them attain that level of comfort. Once they have been with the company for a substantial amount of time, they usually initiate conversations with the CSM team.
The feedback from these customers is often key to product development and improvement.
Setting boundaries with the customer
Establishing a strong bond with the customer is highly beneficial for the product. At the same time, it is also important to know where to set boundaries with them. Varun recalls one such customer who got so at ease with the EagleOwl team that they stopped giving constructive critique. Instead, when approached to borrow their expertise, they began complaining about feature requests that were not taken up by EagleOwl.
Prioritizing feature requests is governed by certain factors, the most important being how many customers it is benefitting. It is not affordable to take up a feature request which is useful for only one customer. For that level of personalization, the company has to have a large bandwidth.
Ways to gain feedback/feature requests: Proactive or Passive?
When asked about their process to receive customer feedback, Varun spoke about a simple yet meticulous routine followed by EagleOwl.
When a customer has signed up, they need to be trained in product operations. Here, all sessions are recorded for the benefit of the customer, so that they can revisit any part of the training process in the future. This is the first step toward customer loyalty.
– Varun Vijayan
Once their training is complete, the CSM moves the customers to normal support mode. In the initial 3 to 6 months, our CSM team proactively contacts them to learn about their experience with the product. This second step is significant in establishing a good rapport with the customer. As mentioned earlier, this stage can make or break the relationship.
The third and perpetual step is transferring the customer to full support mode with assistance as requested by them. By this stage, the customer should be feeling secure with the company. This enables them to open up about their experience and feedback with respect to the product. Such customers form the most vital part of stakeholders for the company.
Prioritization of requests
As mentioned above, the CSM team plays the lead role in prioritizing feature requests. Being the customer-facing department, they have gained the trust of most of the customers. Therefore, it is easier for the customers to ‘confide’ in them regarding their pain points in the product.
The CSM team receives feature requests from the customers, lists them in order of priority, and then hands them over to the tech team. Various factors like bandwidth, time, the extent of benefits, financials, client profile, need analysis and fitting within the roadmap influence these decisions.
Varun confidently states that the CSM team alone takes decisions about most of these feature requests. Bugs in the software are always a top priority. These are followed by functional/UI-related feedback, and so on. The CSM taking the lead in this respect offloads a huge responsibility from the shoulders of the product owner.
There are times when Varun feels that it is important to run their decisions by the product owner. This usually happens in conflicting cases. For eg. when the feature request is advantageous for the product, but the company currently lacks the bandwidth for that. Another case is when the customer is old and trusted, but their feature request is too personalized. In such situations, the product owner takes up the onus of decision-making.
So now let’s explore the perspective of the product owner.
Handling feature requests: The PO’s perspective
Being the founder of EagleOwl, Vinodh Rajaraman, by default, became the product owner (PO) as well. Following is a report on his views and opinions about his experience with the feedback loop.
Significance of PO as the final decision-maker
Being one constant connection between tech, design, and CSM, the product owner(PO) becomes the arbitrator between these three teams. Additionally, if the product owner is the CEO as well, that means that they are closely in touch with existing and new potential customers. This makes them a node where all the above mentioned stakeholders converge.
This is exactly what happens at EagleOwl.
Vinodh, the de facto product owner, is the person whom everyone in the company reports to. Although the CSM team and/or tech team take most of the decisions, there are instances when they require the PO to intervene.
Moreover, he is in close contact and on cordial terms with our customers, which renders him scope to demonstrate more empathy while taking decisions on feature requests. Having spent close to a year in the restaurant backend, he has deep domain knowledge.
Dependency of decisions on bandwidth
In small-to-midsize companies like EagleOwl, even if the expertise exists, decisions about product development also heavily depend on the bandwidth as the team size is small. The bandwidth of the team basically decides upon the time taken and the expertise required to complete tasks.
Depending on the nature and size of the team, a tech company takes up certain feature requests before others. The reason being the team is well-equipped to address them. Even so, in some situations, the time required for a particular task gets miscalculated. This can lead to a substantial loss of time, and as a result, money.
Dependency on customer relations
EagleOwl, like every other company, is ultimately a business. Their ultimate goal is to acquire more and more customers by the day and reach as far as they can. Thus, pleasing the customers is an important marketing move that helps in increasing customer loyalty, with reach and positive word-of-mouth references.
Despite that, Vinodh believes that appeasement does not fit into the philosophy of EagleOwl. Every customer is equally important regardless of their organization size or the business they bring. Therefore, the feature requests that are adopted are seldom the result of whom they come from.
The main deciding factors are their role in the product roadmap and the number of customers that will benefit from these new features.
– Vinodh Rajaraman
In general, customizations are not encouraged. While this is true, there are exceptional cases to this. However, the features developed because of these “exceptional cases” are definitely not limited to that one customer. All of EagleOwl’s customers can use it to their advantage.
ROI on adopted feature requests
Feature requests get translated to active product features that primarily benefit the customers. As a result, they contribute to increasing customer loyalty, reach, and business gains. This process is ultimately profitable for the company. Therefore, it is very important to gauge the returns on investment (ROI) from feature requests.
ROI is not just limited to financial gains; there are more facets to its definition. For young startups like EagleOwl, visibility and reach are equally important. Thus, features that would benefit maximum customers and attract potential customers take a higher position on the priority list.
At the same time, the product portfolio is also extremely important in order to catch the attention of potential customers. In this respect, the features should also contribute optimally to product development. If these two factors are taken care of, financial gains follow.
EagleOwl’s protocol on the feedback loop
As the PO, Vinodh believes strongly in the daily-standup call routine that EagleOwl follows to keep their feedback loop active. He feels that it helps them take quicker and faster decisions and keeps them on their toes. It is also easier to quickly evaluate the feature request in question on the existing product and market status.
More often than not, the discussions also revolve around how a particular feature needs to be implemented. This is very critical. As the CEO, Vinodh thinks that this protocol helps him track the work status and progress of all the teams without having to intrude into their space. Frequent discussions and consistent brainstorming keep the momentum high to deliver faster and better.
Dealing with customer reactions
Vinodh has been in constant contact with existing customers. He is also one of the first faces that new and potential customers come across at EagleOwl. With his extroverted yet grounded personality, he manages to step on the good side of most of their customers. He has established strong and long-lasting bonds with many-a-customers of EagleOwl.
Even when that is true, not all of their feature requests are taken up. Yet, Vinodh believes that it is the relationships that he has with the customers and the performance of EagleOwl as a product to make them profitable, that make them trust him and the company.
Most customers are reasonable. They do not react negatively to their feature requests not being implemented. In Vinodh’s experience, more than 90% of EagleOwl’s customers do not consider this as the basis for them to keep using EagleOwl. There are loyal customers who have been waiting for one request for more than two years. This only comes to show that customers are capable of understanding EagelOwl’s business goals and trust the product direction.
Final thoughts
As evident from the above perspectives, establishing a feedback loop for accepting/rejecting feature requests is very important in the realm of B2B SaaS. At the same time, what makes it successful in contributing to the product and business growth is the protocol being followed to address it.
EagleOwl’s feedback loop and the protocol to drive it are extremely advantageous in two ways. Firstly, it keeps the teams well-informed about one another’s responsibilities. Secondly, it enables the company to give due attention to incoming and existing feature requests, thus making the customers feel heard and cared for. Both of these scenarios are ultimately advantageous for the business.