If your business operates in a competitive environment, it is vital that you develop products and services based on customer feedback. As an alternative, you can play visionary and assume that you know their needs better than customers. But this is quite risky, as you can overestimate your visionary abilities. Therefore, feedback (or feedback) from customers is the most important information for your business.
Where to get it on a regular basis? How to work with it and how not to become a product where functions are implemented at the MVP level? Let's talk about this.
Each market has its own approach.
The question arises: how to get this very “feedback”, or rather, how to organize a systematic receipt of feedback from customers? In our opinion, the choice of feedback method depends on the size of your market (in pieces of potential customers).
For example, when you are engaged in a product for a large business and federal authorities (the co-founders of our startup have such an aggregate experience of ~ 25 years), the number of potential customers in the market is measured in several hundred. Each client is important and brings a lot of money. Several people from the company should maintain contact with each of them - an account manager, project manager, product and system analysts ... In other words, there should be a physical opportunity to talk with all the client’s employees involved in the project. And given the cost of projects, all this, of course, is supported by financial feasibility.
At the other “pole” are products whose market is measured by tens (and hundreds) of thousands of potential customers. There is no physical opportunity to communicate closely with a significant number of consumers. It is possible to “overpower” interviews of several dozen during the year, but this is a fraction of a percent of the entire market, so this approach will not give an objective picture.
But tens and hundreds of thousands of customers are a great base for statistical methods. You can define and measure product metrics, conduct A \ B tests, and use other features that provide "big data." Physical communication with several dozens of clients will also be helpful, but only as a way to reinforce (or, conversely, weaken) those assumptions that you received from statistics.
There are products in the middle of the scale described. Our Okdesk, a cloud-based Helpdesk for automating after-sales service in service companies, falls into this category. The number of potential customers is measured in thousands (but not hundreds of thousands). There are too many of them to get an objective feedback only through personal communication, but too few for statistical methods. How to live?
Why develop a product?
Before answering the question "how to remove feedback for product development?", You need to answer another - but why do you need to develop the product ? The superficial answer is obvious - for business growth. But is it?
If your business is a cloud service (and software for small and medium-sized businesses is distributed mainly according to the "cloud" model today), then business growth is associated with two key aspects:
- getting new customers;
- preservation of existing (reduction of outflow).
In the first case, you need to identify "features" that potential customers need, but which are not yet in your product. In the second case, it is necessary to catch on time the growing needs of existing customers and realize them in the product faster than the consumer realizes his “pain” and tries to move to more quick competitors.
A client who is no longer satisfied with the use of your solution is not the only problem affecting the business. There is still the cost of technical support. When customers do not find the function they need or cannot solve their problem, they turn to technical support with questions. The more such questions, the more time technical support spends on their processing.
Customer support calls are a good indicator of the situation. If customers apply for existing functionality or for advice on its use, then it is poorly implemented. And the sooner the problems are found and resolved, the faster the technical support will get rid of the same type of requests.
In addition, customers can contact technical support with business requirements that are not yet implemented. To process such applications, it is advisable to attract more qualified specialists - product analysts who find out the details of business requirements, try to find a workaround and write a diplomatic answer so that the client is confident in the further development of the product in accordance with its needs. Ultimately, the more functions that are really needed by the client, the less requests for technical support, the less often it is necessary to attract highly qualified specialists to answer and, as a result, the lower the cost of technical support :)
IMPORTANT! Product development in the name of reducing the load of technical support almost always corresponds to product development in the name of preserving the customer base.
So, we summarize. Product development is necessary for:
- getting new customers;
- reduction of outflow of existing customers;
- reduce the load on technical support.
How do we get market feedback for our product?
Keeping in mind the goals - getting new customers, reducing churn and reducing the load on technical support - we analyze four relevant sources of information:
- sales failures;
- reasons for customers leaving;
- NPS survey reviews
- requests for technical support;
Sales failure analysis
The number of targeted and matured customers for Okdesk is limited, so we cannot afford automatic sales.
We cannot sell sales to “trigger mailings.”
A manager responds to each client, identifies needs, conducts a demonstration, if necessary, etc. ... Ie with each "incoming" client, we try to establish contact by collecting the maximum requirements and tasks. All this information is recorded in the transaction card in the CRM system .
If a deal is closed without a sale and the reason “indicate a competitor” or “not enough functionality” is indicated in CRM, and the potential client refers to our target industries (the industry is also fixed in the deal), a task for the product manager is automatically created in CRM for a detailed analysis of the causes of failure. Further, information useful for product development is extracted from the transaction, and sometimes from an additional call to the failed customer.
Customer Reason Analysis
It is sad, but some customers leave. Someone is in search of a “better share”, someone continues to work without automation, while someone closes the business. We analyze the reasons for the loss of each client in detail at the level of sales manager and product manager. This is the same systematic activity as the analysis of the causes of failure.
Fortunately, the outflow in our case is small, measured in pieces. The main reasons in our case are the following (in decreasing order of popularity):
- The company has closed or is experiencing serious financial difficulties - this is not the time for Helpdesk. If there are no clients, then there is no one to serve :(
- Did not start - did not start to fully use the product during the first paid period. This is an important signal for the product - if there are customers who cannot "start up", then the product is too complicated for them. They cannot get tangible benefits with minimal costs on their part. There are other reasons that cannot be influenced by one product - organizational problems and the resistance of employees within the organization. Here are 13 main causes of failures when implementing Help Desk or CRM systems.
- Did not see the value - the fact that the client did not see the value for themselves in the basic advantages that systems of this class carry. This mainly happens when the company does not have many customers and the owners are willing to be content with the small ones. But this is not a reason to relax - it is necessary to seek and implement functions that carry values for this group of customers.
- Not satisfied with the possibilities - the case when the client switches to a competitor's decision (this mainly happens when the initial requirements for the Help Desk system were very superficial, as a result, Okdesk was chosen instead of a system for b2c service or instead of an ITIL-oriented product ), a substitute or decides to develop an independent solution (yes, the latter also happens).
- In our case, the first two reasons are the main ones, and the last one is a good (though not the main) source of new ideas. We study each outflow case in detail; as a result, about a third of former customers who were not satisfied with the lack of certain functionality return a few months later.
Analysis of responses as part of the NPS measurement
The consumer loyalty index is, on the one hand, a very controversial metric (perhaps this should be written in a separate article), and on the other, it is so universal and generally accepted that it has average industry values (benchmarking), including SaaS, obtained on the basis of thousands of companies from all over the world .
We use this survey among our customers to track “dissatisfaction” with the product and proactively respond to a possible outflow. Sometimes through this survey we get very clearly formulated wishes for the current “shortcomings” and wishes for development.
By the way, our average is much higher than the “average” for SaaS (and we believe this because we follow the rules described in this note):
Analysis of requests for technical support
Analysis of requests for technical support, in our opinion, is the best source of information, since these requests come from people who use the product daily. When analyzing failed transactions or the reasons for customers to leave, the requirements are visible with “large strokes”, without details. Analysis of technical support calls, on the contrary, sheds light on the inconvenience of the system and the nuances. Customers who work with your product daily formulate more informed business needs. They are more loyal to you and more enthusiastic about talking about their automation needs. Those. In addition to the inconvenience that customers encounter at work, you will preventively learn about growing needs and implement them faster in the product - thereby you can prevent future outflows.
For customer support we use our own product Okdesk (all of a sudden!). All applications upon the decision are marked with tags that are associated with the functional blocks of the product for subsequent analysis. In addition, if the client’s business need cannot be implemented in Okdesk, the product manager is connected to the solution of the request. If necessary, he calls up with the client and details the requirements.
In conclusion
So, if you are developing a product for the “medium” market, then the sources of product requirements are:
- analysis of failed transactions for the sale of the product to new customers;
- analysis of the causes of the outflow;
- analysis of technical support calls.
No magic techniques and magic, no confused services that "guarantee the reduction of outflows to zero." Just systematic work that helps make the product a little better day by day. And this systematic work helps us from year to year to make Okdesk even more functional, more convenient, even better. And our Help Desk itself has already become a de facto (~ 500 active clients on a subscription and attempts to copy) standard of use in the service industry.
And it's not just words. This is how the distribution of hundreds of respondents (our clients and guests of the webinar) looks like to the question about the satisfaction of our development in 2018 and 2019.
We thank each of our customers and those who have not yet become our customers;) Thanks to you, “daily improvements” and “the most active development in the market” have become yet another of our competitive advantages!
How do you develop a product and how do you collect requirements? Share in the comments!