Val Yonchev

It should NOT! Adoption is the job of everyone in the company and the ultimate owners of the adoption KPIs would be the business owners (CEO, BU leaders). We succeed together and we fail together. If a customer isn't successful it doesn't really make a difference if your team/department has done the job in an excellent way. We still have failed as an organization on our purpose and that is what everyone should be focused on. Adoption KPIs are in general lagging indicators, which make it less useful and interesting to split them. What you should strive instead is to analyze what are the key capabilities and key factors driving adoption for your customers and identify leading indicators for each of those. This way, you can see where in the organization there is more work required to level up and increase our ability to influence the adoption of customers. Those leading indicators should cover the full journey of the customer as adoption starts even before the sale is made. For example: Sales and Sales Engineering/Solution Architecture are the first to create a baseline for adoption. They do so through the expectations created in the sales cycle about the value of the product - available use cases, measurable success from other customers, capabilities that can be created towards customer's ambitions and strategic objectives. Customer Success takes over those expectations and promises in order to further elaborate them and convert them to shared and committed action plans including everyone in the organization as well as the customer stakeholders who drive the adoption on their side. Think about what key leading indicators point to opportunities/deals which grow faster and better in terms of adoption and use those for defining the different functions' OKRs.

As your products scale in popularity, it is inevitable that you will see more and more customers adopt your product without the support of your orgnization or the partners in your eco-system. I have found two good practice to address potential issues with ease at scale: A) Build in Health-checks into your products B) Reference architectures Let me expand on what I mean by build in a Health check: 1) It should part of the price of your product or in other words not required for the customer to pay extra to get at least the basic part of it. A more advanced and deeper dive version could be available for sell by your Services organization 2) Automated as much as possible and leveraging telemetry so that this Health Check can be delivered at scale across big number of customers with limited efforts. This clearly requires an effort from your engineering teams to instrument your product 3) Benchmarking against the remaining customers or similar size customers, similar industry customers, can also provide interesting feedback and ways to assure proper Reference architectures is something many people overlook in favor of "reference customers". The reference architecture could very often be a combination of the experience of multiple customers and point to what good looks like and what delivers most of the potential included in your product. A good Health Check would point out of the box to applicable reference architectures.

Those meetings must be (1) cross-functional and (2) on regular basis which makes sense for the rhythm of the business. 1) Cross-functional means that reviews should include all different functions/departments relevant for the topic, consider Product, Support, Marketing, Sales, Sales Engineering, Customer Success, Services/Consulting. This way the meetings are actionable and end with committed action plans. 2) The "regular" cadence would depend on the number of customers you need to service and how often you interact with them. I wouldn't consider anything less than a monthly meeting and in many cases a weekly or once every two weeks is a good frequency. The agenda can be divided in two parts - Hot customers and In-focus customers. "Hot" refers to customers which for some reason would need regular review of progress and adapting to changes, e.g. new big customers, challenges with adoption, big ongoing issues with the service/product, escalation of sort, etc. The in-focus customers are all other customers in your portfolio, which have not been reviewed in those cross-functional meetings for more than 6 months (this duration can be changed to whatever makes sense for your business). The idea is that each and every customer is reviewed at least once or twice a year, assuring the whole organization knows what can be done to improve or maintain their experience and what could get us to the next level. The review of individual customers may include - usage patterns, key challenges, support history, customer satisfaction feedback, recent QBR findings, changes in the customer's strategy, changes in the environment of the customer which may impact their direction and adoption, new use cases and features which can help adoption. If you start with those meetings, make sure that: 1) The purpose of the meeting is formalizing and committing an action plan for each customer and that means the meeting ends with such plans. Don't meet in order to decide that you will meet separately to make a plan. This must be clear to everyone and it is best to have it prominently on the agenda and meeting invitation. 2) Asynchronous preparation and follow up - all key roles must come prepared to the meeting. Materials required for decisions are provided ahead of time for everyone to read up on them asynchronously. Certain roles and a chair of the meeting make sure that regular follow up on previously agreed action plans is done asynchronously in a tracking document, so that everyone who wants/needs to see the updates can do so outside of the meeting. This allows the meeting to be focused entirely on its purpose - see (1) above.

There are thousands of reasons for failed adoption and only one which should matter to customer success organizations - value realization. If the customer doesn't understand what is value, how it materializes and what is required to make it real, adoption won't take off. Value realization is a mystical and often misunderstood term as it refers to multiple different facets of the same thing: 1. What is value - or why would anyone use the product, what is it that they hope to achieve 2. How do you get the value - what are the key use cases. You would be surprised how many of your customers don't really understand the full potential of your product, which is missed opportunities and pure waste from a Lean perspective as they invest efforts and money without getting the full return on investment 3. How do you make it easier for people/teams to adopt the new use cases - this may require enablement, training, communication, test/learning instances, etc. The easier it is to do the new thing, the more people and teams would actually adopt it. If any one of the above is missing the customer would fail in adopting the new technology.