A recent twitter post prompted some thought around product engagement with customers, incorporating feedback and closing the loop, at scale.
A short twitter-esque conversation made me question, how can I respond, with room for thought, that would also scale to others asking; how do large scale products scale to meet their customer needs?
The Startup Life
Products typically start small with an identified market opportunity that defines a need. They identify potential solutions and focus on the ability to competitively build a solution.
In the beginning, life is simple and full of excitement. There are a few problems to solve, and the team likely focuses on a few customers to hone the product to fit the actual need. This model of direct customer interaction continues to inform the product and at some point, a decision must be made; are they building the product for a few customers, or are they building for the masses.
The book, The Disciplines of Market Leaders breaks this down into three categories:
- Customer Intimacy – Building tailored solutions for specific customers.
- Product Leadership – Building the best-in-breed product, for the masses, but not necessarily the cheapest as the product leadership is valued.
- Operational Excellence – The most efficient means to deliver a product, for the masses. Typically, at the best price, and/or the fastest result, but may not have all the features of others, as it is just not efficient to do so.
Each of these are unique markets, where Customer Intimacy could often be defined as consulting services over a technology, or around a particular product. For the purposes of this article, I’ll focus on the Product Leadership and Operational Excellence disciplines, as these are the ones that need to scale to the largest customer base to be successful.
Get Out the Megaphones
Someone is likely thinking about the marketing strategy. How will customers hear about the product so they may purchase it? A message is broadcasted for many to hear the megaphone. They’ll likely have multiple megaphones, each targeting a specific group.
In addition to specific marketing campaigns, there are other megaphones that engage customers:
- The best products should speak for themselves. They’re just intuitive to use, and immediately self-rewarding. At least for the mainline features, with a tail of additional features, enabling the breadth of use.
- Documentation informs users for the broadening use cases. The interaction of several individually intuitive features that may need some information for how to stitch them together. As products become more robust, with multiple ways to accomplish similar tasks, the docs also help customers understand which capabilities target specific scenarios.
- Blogs for targeted topics, typically narrowly focused on specific capabilities with a more creative and engaging voice.
- Videos are more interactive, providing a personal touch of the presenter to convey a thought in an entertaining way. Competing for the attention of users requires a balance of entertainment and education.
As the company grows beyond a few key founders, they quickly realize the need to scale out, specializing roles to increase the targeted megaphones.
- A sales force that takes the message of the product team, formed by marketing and engages a set of customers.
- A technical implementation team, that supports the sales force as the skills to attract customers tend to be different than those that can demonstrate the expertise of a product and its application to your business.
At this point in a company’s success cycle, they likely start feeling some pain. Excitement as the sales team brings in customers and the product teams are getting funding to build the capabilities they always wanted to build. But the sales team is also constantly asking the product teams to engage with all customers to answer all their questions. At some point the question is raised, when will the product team have time to build the features if they’re always engaging customers? Where’s the balance? This is where many companies diverge to the path of success or failure.
Funnels
We often consider the sales funnel, as the number of customers we can attract, and how many we close as they go through the bottom of the funnel. But, let me use the funnel as another metaphor. With all the megaphones broadcasting the amazing product, how to capture the feedback, to assure the amazing product is actual so amazing in the customers eyes. Or, does it stay amazing as the customers start to use it, and find gaps that can be opportunities, or the reason they move to the competition as the product fails to meet their evolving need?
Above I focused on the megaphones as outbound messaging. These human megaphones can be inbound information as well, as the people involved with customers are getting constant feedback. Are the salespeople able to close the deal? If not, why? Are the technical people able to implement a solution for customers? If not, why?
These are the primary funnels of inbound information to pay attention to. It informs the product teams for how they should consider their next round of investments. This also works well, when the company is small, and they know all the customers by name, and by salesperson.
Can You Intimately Know all Your Customers at Scale?
Early on, someone at the company likely knows every customer by name, and how they use the product. This scales to a point. The question is what is the scale by which they define success? Most, not all, software companies must scale to the point where it is just not practical to have someone engaged with each and every customer. The model of large-scale software companies is such that they must become operationally efficient to deliver a wide range of capabilities at a competitive cost. In the software industry, people are the highest costs. I’m not just referring to the developers. This includes the salespeople, the support teams, and the management of these various groups. In the disciplines of Product Leadership or Operational Excellence, can they be competitive at scale, if every customer has dedicated support people? Dedicated support for every customer is more akin to the Customer Intimate business model, where the customer is expecting to pay a premium for the dedicated support.
Funnels & Filters
As the company grows, how do they filter this constant flow of information? They might think about where to focus the megaphone. If the product targets people that snow ski, they’re likely not going to get the best sales from people in the Caribbean. There will be some that travel, but is this the most efficient use of the megaphone resources? The inverse is also true. Prioritizing the inbound information is a funnel to capture the masses of information, at scale, and discern it down to actionable and marketable work.
Considering the most expensive resources are the people, how do we filter the inbound information to the product teams? If the product teams are engaging every customer, when do they have time to build the product? If you have enough people to engage every customer, which discipline are you focused upon as your Product Leadership and Operational Excellence focused customers will likely different expectations than Customer Intimate customers.
When building the inbound funnel, consider what information the customer needs, and what information the product team needs. Most customers simply want to know how to get X done now. Sure, there is the cool factor of “talking to the product team” and shaping the product, but in the end, they are focused on their business, and they need a solution now. Their time is valuable, so what is the most efficient way to solve their need?
The Value of Time
Most humans value their time and want to get back to the task at hand. The customer wants to serve their customers, and the product team wants to continue building the best product they can, for their customers.
The question then remains, how to route and filter so everyone get’s the value from their time?
Many organizations build a model around the field aggregating their customers needs and reporting it back to the product team. While it may seem efficient, there’s so much loss of information as the best products tend to focus on what the customer needs, not necessarily what they ask for. Did you ever play The Telephone Game as a kid?
Sorting through aggregated feedback from the field is good insight, and either confirms work in flight or provides clues to new areas that should be investigated through iterative, focused conversations with the end users of the product.
However, sorting through the asks and needs typically requires interactive conversations, to better understand the needs, often correlating them with other efforts that make 2+2=10.
Building a Scalable Feedback Model
The challenging with getting feedback is how to prioritize and aggregate feedback across all customers? If you can only talk with a subset of the customers, should it only be the big customers that have account teams? How do you validate investments that apply to a large breadth of customers? How to correlate groups of feedback that might lend to an alternative design that might be slightly larger, but impact a far broader set of customers?
More importantly, how do customers get visibility to how their feedback is being received and prioritized?
Feedback at Scale
In the above diagram, we have 3 categories of feedback. The first is the “usage feedback”. Telemetry and usage feedback can inform what capabilities are being used, and where they’re having problems.
The second captures tools that scale to the masses. As a product team, how do you capture requests, and let users rank them? How can you provide iterative feedback to help understand, propose a solution and gauge the effectiveness of that solution?
Focused Support
Lastly, we have the more dedicated feedback channel. The customer may have more dedicated support for providing feedback, and in most cases, the dedicated support team can solve their problems without having to engage the product team. If the majority of feedback from the frontline is going straight to the product teams, they likely have a problem, indicating large gaps, a problem with how the product is being messaged, or a an even bigger opportunity for a new area of growth. However, that product evolution will likely be far more effectively developed through direct customer engagement.
Train the Trainer
There’s another area of megaphone focus, where the product team produces a set of content for the field, including sales and support. The product team content may be answers to common questions, technical presentations that may be re-shaped by the field to better message the product. Just as we need to filter the inbound, we need to enhance the outbound messaging as well. This Train the Trainer content also help facilitate higher quality product team feedback, but this is a great discussion for another article.
Closing the Loop
With all the feedback of a large-scale product that can’t engage directly with every customer, how could they close the loop with the customer? While customers like their feedback to be heard, they also like to know if the feedback is being acted upon. How frustrating is it to spend time and effort providing feedback, and not know the result? If the product team put’s the request in the backlog, when will it be available? When can customers get early engagement to validate if it solves their needs? And, how long should they plan to wait?
We’re back to the scaling problem. Most product teams have a small set of customers they do the early validation with, just as they did in the startup phase. If the capability is broadly applicable, they would have far more customers interested than they can directly interact with. By using community focused tools, product teams can provide status updates for when the work has been started, how the capability is taking shape and when it might be available for usage. Or, that it might have been delayed as another higher priority, broader impacting capability got moved above.
Megaphones & Funnels
At the end of the day, building solutions at scale is complicated. Not only do product teams have to build products to scale, but they also need to build the sales and support systems to scale as well. As the company grows, the few people that could wear multiple hats, interacting with each and every customer must scale as well. Having dedicated sales, support, marketing and product development is part of every companies’ growth plan. A measure of success is when they can’t possibly intimately know all of their customers. However, every customer must feel they’re voice is heard, and they’re being supported.
Providing that feedback loop, so customers have transparency to the backlog is often what they really want. If the product team can’t build the exact solution the customer’s needs, or by when they need it, giving full transparency allows everyone to adapt their business plans accordingly.
Maybe, It’s Just an On-Behalf of Feature
Back to the original post.
Should a customer, working with an account manager, have to provide the feedback to a community site themselves?
While the account manager could, are we back to the Telephone Game problem, where the account manager doesn’t represent the problem in the customers words? Should the account manager enter the customers email address, so the customer can get direct customer feedback of the progress, engaging directly with the product team to avoid the fidelity loss. Perhaps there’s some on-behalf of capabilities to these tools that should evolve.
GitHub, UserVoice, Others…
The more targeted area of feedback, which tools do you prefer for providing interactive feedback at scale:
- UserVoice provides great tooling for voting, ranking, customer engagement and two way communications, but lacks backlog integration.
- GitHub issues provides integrated repro steps, and coordination with a product backlog, but no user voting or great customer communication tools.
Maintaining both is confusing to customers, and difficult for products to maintain. Which do you prefer? Do you have other tools you like?
<p value="<amp-fit-text layout="fixed-height" min-font-size="6" max-font-size="72" height="80">
Steve Lasker 