Actioning Customer Feedback
There’s a bit of a war going on the age-old adage “The customer is always right.”
Mark Cuban, famed entrepreneur, even flat out said these controversial words while crushing the dreams of Surprise Cake, a small novelty business on Shark Tank.
True, while it’s not wise to turn your product roadmap into a rat race of delivering on all of your customer’s whims, it’s equally foolish not to listen to them, carefully and with intent.
Customer relationships aren’t that different from regular relationships. Trust is built on transparency, listening, communication, and delivering on expectations. Fail to execute on establishing these qualities and relationships start to crumble. How many of us have unnecessarily escalated a situation with a partner, parent, or child because we chose to push back instead of listen first, and then respond?
The customer may not always be right, but their feedback and feelings are always valid.
Customers may not be right, but the important thing is…they think they are. That usually stems from a problem or experience they had with your product, or a love for your product that runs so deep they desire for your product to expand into meeting even more needs. If everything was already meeting or exceeding expectations, why would they take the time to deliver the feedback or suggestion?
Customers that write in with feedback are like the dear friends that tell you that you have spinach in your teeth.
In fact, according to research by Esteban Kolsky, 13% of customers with a problem share that complaint over 15 people, but only 1 in 25 unhappy customers complain directly to you. That means for every 1 person who tells you there is spinach in your teeth, 24 people have a bad impression without saying anything at all, and there are even 3 people telling 15 people each about the spinach, resulting in about 45 negative impressions from one piece of spinach that only a single person mentioned.
That’s a really good friend.
Now, if a friend then tells you “You have spinach in your teeth, and in my opinion the best way to remove it is using a machete” well….that’s when you should use your judgement and expertise, deciding something like a toothpick is a much better way to solve the problem then a machete.
The customer may not always be right on how to solve a problem or meet a need, but they are absolutely right when it comes to sharing they have a need or problem in the first place, and that’s what needs to be addressed.
Understanding feedback: problems vs. feature requests vs. workflow gaps
There’s three different buckets feedback typically falls into: Problems, feature requests, and workflow gaps.
Problems
Bug or significant UI/UX confusion area that causes your customers a degree of frustration when they encounter. A bug is a bug and should be fixed, especially when it effects multiple users and causes any sort of disruption to a customer’s workflow. Full stop. If you are not prioritizing bug fixes with your engineering team, your product is going to lose customer love fast.
UI/UX that is consistently reported as confusing should also be addressed, regardless of whether or not it’s working as intended. These are those “bug or feature” type snags customers report.
Feature request
Cut and dry request that can be answered with a yes or no. For feature requests, it should be a clear yes or no answer vs. a problem that can be solved multiple ways. These should be prioritized by impact. We’ll cover segmenting customer feedback by impact later in this post.
Workflow gap
Workflow gaps are areas missing in the customer’s workflow that cause them friction using your tool. Often times these masquerade as feature requests, because customers phrase them in a way they would solve the gap - but that may not be the best way to solve the gap. These require research and customer validation.
Lets take Surprise Cake as an example on how we can listen to customer feedback, and yet still solve the problem in a way that makes sense for the business with a path of minimal effort. This is the business and Shark Tank episode Mark Cuban proclaimed “The customer is not always right.”
The product is a pop-up container you can put inside a cake to fill with surprises or gifts.
The feature request was “You should sell cakes.” The business decision that lost them the shark tank deal was to pivot to become a one-stop-shop, baked cake, gifts, and all.
Logistically, this is not a great idea.
After all, the business is not a bakery. The amount of lift to make this happen is enormous, like creating an entirely new business and business model.
Note: Despite not getting a deal on Shark Tank, it does look like they pursued this approach, and is still actively in business. That said, they did lose a deal, and there is an easier way to have solve this problem based on customer feedback that could have been less effort.
The feature request would be “sell cakes,” but the workflow gap is actually “As a consumer, I love the product and concept of a surprise gift tube inside a cake, but do not want to (or potentially cannot) bake a cake.”
I empathize with this problem, because I myself am terrible at baking, so I would completely overlook a product that required me to bake a cake.
The customer is not wrong for not wanting to bake a cake, but the best solution to this problem may not be to overhaul the business model to become a bakery and baked goods shipping logistics operation in order to sell cakes. Selling cakes is the machete answer to the workflow gap of baking a cake.
But, there’s more than one way to solve the problem of a customer baking a cake. Partnering with grocery stores, famous bakeries like Milk, or any other business that already has logistics and operations around cake delivery would be a great place to start. Then, when customers write asking to sell cakes, the customer facing team can point the customer to a list of bakeries or grocery stores who sell Suprise Cakes.
Customer wins. Business wins.
No need to overhaul the business and the customer feedback was still listened to and addressed.
Getting more meaningful feedback from customers
The way many businesses handle customer feedback reminds me of the ancient parable of the blind men and the elephant.
In the parable, a group of blind men who have never encountered an elephant before all touch the elephant in order to learn more about it.
The problem is, each man feels a different part of the elephant’s body, like the ears or the tail. Because they only feel one part, they come to describe the elephant in wildly different ways due to their limited experience with a single aspect.
As the parable goes:
A group of blind men heard that a strange animal, called an elephant, had been brought to the town, but none of them were aware of its shape and form. Out of curiosity, they said: "We must inspect and know it by touch, of which we are capable". So, they sought it out, and when they found it they groped about it. The first person, whose hand landed on the trunk, said, "This being is like a thick snake". For another one whose hand reached its ear, it seemed like a kind of fan. As for another person, whose hand was upon its leg, said, the elephant is a pillar like a tree-trunk. The blind man who placed his hand upon its side said the elephant, "is a wall". Another who felt its tail, described it as a rope. The last felt its tusk, stating the elephant is that which is hard, smooth and like a spear.
Now, imagine caring for that creature.
How on earth would you keep it alive, yet alone thrive?
When individual disparate departments take it upon themselves to collect and gather customer feedback, either by surveys, interviews, and individual research, without looking at the 360 degree view of the customer based on stage of lifecycle, use case, and other customer segments, their perceptions can become a lot like the blind men’s experience with this elephant.
Customer facing teams can serve as the business’ eyes and fill in the gaps of customer context between what’s otherwise disjointed pieces of feedback. The conversations they have with customers are one of the most important channels for customer feedback.
Aggregate feedback from where customers give it
Surveys are one tool for aggregating customer feedback, but they should not be the only tool. For one, survey response rates can vary tremendously, and the lower the response rate the less accurate it can be. Customer interviews are amazing, but it can be hard getting customers to agree to them if you don’t already have strong customer relationships. Additionally, the ones who do agree usually come from a small subset of “power users” who can bend the limits of your product. They typically don’t represent the masses.
So, where are “the masses” of customers giving feedback?
Everywhere they talk with your business.
Sales calls, support emails, website chat, social media, whatever channels you have open with customers are exactly where you can find this valuable feedback. And they usually don't leave feedback in more than one channel or place, unless they really love you - and the customers that really love you are usually not who you have to worry about keeping. If they sent your support team an email, they are really not likely to also fill out a survey. That's work, and the customer is paying you, not the other way around.
Using a customer engagement platform like Help Scout or Hubspot can bring all of your customer conversations from every part of the customer lifecycle into one central place, like email, phone, chat, either natively than by using various integrations with other engagement channels.
If you truly want to collect meaningful feedback, you need to aggregate feedback across every source, and look at the big picture of everything together, segmenting feedback by impact. This cannot happen when departments execute customer research in silos.
Ask the right questions
Your customer facing teams should be tracking and logging all feedback, which can then be prioritized before delivering the highest impact items to Product teams for roadmap consideration.
Bugs and UI/UX confusions are pretty straight forward, but in order to get to the crux of whether or not something should be classified as a feature request or a workflow gap, your team needs to understand the customer’s workflow. This requires a little bit more probing and prodding to get to the bottom of the actual need. For that, there are three magical questions that can help you uncover this information:
What are you trying to accomplish?
How are you currently doing this?
How much pain is this causing?
These questions can be asked by any customer facing professional transforming them into miniature customer researchers.
Here's a breakdown of what each of these questions achieve when it comes to aggregating more meaningful feedback.
What are you trying to accomplish?
Frequently customers write with the assumption that you either understand their workflow, or simply failing to provide any context of what they are trying to do when they ask for a feature request. Asking the customer what they are trying accomplish helps the customer (and your team) take a step back and think about what is the end goal of the process, and are there any other roads to get there?
There can only be two outcomes:
There’s another solution to the customers problem within the product.
There’s not another solution to the customer’s problem within the product.
If it's option A, this is a win! You simply need to educate the customers on the way to solve the problem that already exists. They likely did not think of this solution because they may have been trying to solve the problem in a way a competitor does, or how they do things in their old and manual process, which may not be the same as your product. As long as your product solves the problem in a superior, less effort way, there's nothing more to relay on the product side.
A savvy way to implement impactful change around this customer feedback is by creating guides, videos, and other forms of enablement that educate on this alternate process so that customers can find this information on their own in the future!
How are you currently doing this?
This helps you understand your customer’s workflow, and whether or not you can accommodate their workflow with your product or service.
Again, you have two options:
This customer and their workflow is similar to other customers in your ideal customer profile, and so it’s a product gap that’s worth solving.
This is not a workflow that is aligned with your ideal customer profile, and so it’s not a product gap that’s worth solving. At least not immediately.
It's important to track both, but how you leverage with product and also manage expectations with the customer changes.
If it’s worth pursuing, you can let the customer know that you'll talk it over with Product, and may schedule more time to probe deeper on the workflow to research. Then, do exactly that. Bring to the next meeting with product (your customer facing teams absolutely should be having a regular cadence with product) and talk it through, closing the loop with requesting customers once further decisions are made yay or nay, and once again if it ends up getting deployed.
If it’s not worth pursuing, you can let the customer know that it is not in the current plans, managing expectations, but that you'll keep an eye out for other customer requests as it sits, logged, in an icebox, graveyard, or other holding place for items that don't make it to the roadmap. This way, it's still collecting momentum. As the product evolves and customer base changes you may find more and more customers asking for this - opening your product to a new interesting audience! Because you are tracking this, you can resurrect the request without losing any valuable customer data. Not only does this help communicate the impact of solving this to product, but also makes it easy to win back customers who may not have been a fit before, but are once that workflow gap is solved.
How much pain is this causing?
This question is helpful for determining priority. If a customer states it's a nice to have but they fit your ideal customer type, it's something that can be looked at, determined whether or not it's an easy win, and then prioritized on the long term backlog. If the customer explains it is something that's giving them significant pain, and the customer fits within your ideal customer profile, chances are your other ideal customers are experiencing similar problems and these are the ones you know to go to bat for with product.
Next steps…
From the answers to all these questions, you have clear next steps.
Based on the answer to the first question, you can educate the customer on an alternate way to solve their workflow issue (win!) or based on the answers to 2 (and in some cases 3) a solution makes it’s way to the roadmap (win!) or you kindly explain to the customer why this isn’t something that’s currently scoped in the product.
The customer knows their feedback has been not only heard, but listened to, and has appropriate expectations for what comes next.
Tracking Feedback
When possible, tracking feedback is best done with a tool that directly integrates your help desk and what your engineering and product teams use equally.
For example, the Help Scout JIRA integration facilitates a perfect environment for tracking this sort of feedback and creating a feedback loop between the two teams.
Using this combination of tools, an email, chat, or a note and transcript from a phone, sms, or social integration lands in Help Scout, handled by one of your customer facing team members, whether that is sales, success, or support. From inside the conversation itself, customer facing team members can log feedback as bugs, stories, or tasks, JIRA’s terminology for categorizing issues.
Here's how you can map the categories in JIRA to the types of feedback above:
Problem = bug
Task = task, if it's just a copy change or something like a confusing button color.
Feature request = story (but should be tagged as feature using a label or field for better filtering)
Workflow gap = story (but should be tagged as workflow gap or something similar, again, for filtering purposes).
Then, each of the subcategories above has their own template:
Bug Template
Expected behavior: This should be a description of how something is expected to operate.
Actual behavior: This should be a description of what happens outside of those expectations.
Steps to reproduce: What steps in the product (or outside of the product, if specific to a certain browser or third party tool) result in the deviance from expectations. Important to note: Unless the bug is related to security, or for some other reason is merited a high severity or high priority issue, it should not be passed to the engineering team until it’s consistently reproducible.
Severity: How bad is it? If it’s a security vulnerability, for example, this would be high.
Likelihood: How widespread is the bug? Is this affecting a single customer or all accounts? If the bug is very easily reproducible in a common action for customers, this may be a high likelihood even if only one report has come in.
Priority: Priority is determined by Severity and Likelihood. If it’s a high severity and likelihood, that’s a P1 - the highest priority.
Story Template
Description: What is the TL:DR of the need. This should be described as “as a [name of user persona] I would like to [general need] - or something like that.
Problem: What is the exact problem to solve, or pain point the customer is getting into.
Possible Solution: A possible way to solve this problem. Going back to our machete situation, this doesn't have to be what the customer suggested, but it can be.
Impact: This harkens to the customer segments, high velocity and high value. Is it from a high value customer or a critical mass of high velocity customers? Then it's a high impact.
Revenue value: Is this something that could win new customers and market share, or something that only comes up post sale? If post-sale, is the pain bad enough it could result in churn?
Customer value: Maybe it's not going to win or solve churn risk, but maybe it will make lots of customers happy which increases product stickiness, and therefore could buy you some time when the churn-worthy problems come up.
We also designate the difference between workflow gaps and feature requests using a Tag in JIRA to make it easier for ourselves to communicate this with product when we track feedback.
Tagging high-volume requests
For high-volume customer requests, it’s wise to tag the customer conversation directly in your CRM. This makes it easier to put a datapoint to the number of customer requests when communicating high-volume issues with product, report on feature request trends, pull up examples of customers who requested the issue for additional research, and close the loop with the customer later.
Once a JIRA ticket (or other issue tracking tool) has 5 customers connected, create a tag and track in your help desk at the conversation level instead.
Segmenting feedback for business impact
As much as we'd like to believe we love all of our customers equally, the truth is not all customers have the same impact on the business. While the old adage may say the “the squeaky wheel gets grease,” if that squeaky wheel is a free or low value customer, that grease makes for a slippery slope.
Instead, all feedback should be segmented by business impact. There are a few different ways to look at this: high value customers, high volume customers, and strategic customers.
High value customers
These customers are the customers that if you were to lose a single one your business would feel the dent. SAAS companies frequently classify this as their enterprise clientele, but depending on your product and pricing this could mean anyone. A good rule of thumb is if a customers annual contract pays for at least one salary, they deserve to be in this category. These customers deserve dedicated resources on customer success and engineering.
Obviously the goal of any business should be to attract as many high value customers as possible, and frequently high value enterprise needs intersect across businesses: Security and scalability features like SSO or SAML, granular permissions, and administrative controls are three things that come to mind that I have encountered as themes across multiple enterprise businesses of different industries.
These customers will always be the most demanding, and your business should almost consider them like design partners. In fact, as part of the “high touch” team, you may consider a solutions consultant to help prioritize development.
High value customer feedback can be further segmented into two types: feedback that is true for similar customers, and feedback that is bespoke to them.
Feedback that rings true for similar customers
These should absolutely be prioritized first above any other. If more than one high value customer expresses a need, this should be a non-stop ticket to the short term roadmap.
Feedback bespoke to them
If these customers are true enterprise, they will likely have some custom needs in regards to integration and implementation. They are also typically open to paying for this. These requests should not be prioritized or executed without paying for custom development. This is where a solutions consultant is a handy addition to the high touch team.
High volume customers
These customers value may not be compelling enough to drive momentum at an individual account level, but can make up a huge value in droves. Depending on your customer base, high volume customers could make up 80-90% of the overall revenue, just in individual accounts.
Prioritization decisions around high volume customers should be made based on how many customers are requesting. If it's one, maybe not worth taking a look. If it's 5 or more, as we know that can be one request for every 25 who say nothing, now we start to see momentum.
Strategic customers
Strategic customers are an interesting one, as they could potentially have a huge business impact, or hurt your business dramatically. Strategic customers are customers that may have a use case outside of your core ICP (ideal customer profile) but could open your product to new markets. For example, maybe you have a tool where your core customer base is B2B, but with a few tweaks it could also serve D2C customers. It’s a risk because you can open up your business, but it’s also not an area you know you have product market fit. This means you’re almost back to square ne “start-up mode” for this new product, development, and audience.
Because of the uncertainty, my professional recommendation would be to not prioritize strategic customers until the highest priority needs of your high value or high volume customers have been met. This can be measured by conversion rate, expansion, life time value, and retention of ICP customers. If these business metrics are healthy, and you have resources for exploratory work, go for it!
Dealbreaker requests
Another good way to segment feedback is by lifecycle stage, and what happens to a customer after the feedback request. If customers who request or report something are trial customers who fail to convert, or if they are long term customers who then churn, this is a way to identify what I call “Dealbreaker features.”
Tactically, dealbreaker features can be used by tagging or tracking certain features, then using that conversations with that tag as a filter for any trial to paid conversion or churn reporting. This can be accomplished with a combination of Help Scout tags and Hubspot lists and reports.
Actioning feedback
Tracking feedback is one thing, but in order to facilitate meaningful change feedback needs to reverberate throughout the business. A key component to achieving customer-led growth is establishing feedback loops between your customer facing teams and other business departments.
Feedback loops between teams can be established with regular cadence meetings or shared tool sets across departments. The more teams operate in silos, the more fragmented the customer experience, which increases friction and reduces the chance of customer success.
Product feedback loop
The product feedback loop is where customer facing teams communicate feature requests and friction to product, and product communicates back the roadmap, prioritization, and releases with customer facing teams.
Forums for communicating with Product
Feedback logged and tracked in JIRA with your customer facing teams should be relayed to product on a regular basis. Weekly for high priority, high value customer needs, and monthly for trending feedback.
Impact Pulse: Weekly Cadence
The intention of this meeting is to discuss any priority requests for your highest value, enterprise customer segment. This should be held with the customer facing team members who manage those high value customers, AEs, Enterprise CSMs, or account managers. This is an opportunity to surface any blocker or high pain issues that need to be addressed with product. Once again, this should be reserved to discuss high pain issues for customers that, if they were to churn, would do significant damage to your business, worth hundreds of thousands or even millions a year.
Voice of Customer: Monthly Cadence
While the impact pulse should focus on the priority requests of your highest value customers, voice of customer should be where trending feedback from a critical mass of customers is discussed. This should be used to discuss any problems to solve or feature requests that a great number of customers request. The goal of this meeting should be to get those items on the roadmap, and determine next steps. Next steps may be more research, scoping, or development, but those steps should be clear.
If features brought to this meeting don't make it on the roadmap, there should be a clear reason why offered from product, and the loop should be closed with requesting customers. Additionally, a saved reply should be created to explain the reasoning to customers on why the feature won't be pursued for any future asks.
Growth feedback loop
Growth feedback loop can also be understood as the “Marketing and Sales” feedback loop depending on how your organization is structured, your growth strategy, and your customer type. If you’re in a Product-led growth company, this would be marketing. If you have an Enterprise sales process, then Sales should be included as well.
Here are just some ways that post-sale customer-facing teams can help sales and marketing teams with growth related initiatives.
Inform ICP (Ideal Customer Profile)
No one knows which customers are successful more than post-sale high touch teams, frequently Customer Success Managers, but this could also be account management. They will easily be able to tell you the profile of the healthiest type of customer who gets the most success and value with your product. This is who your Marketing and Sales teams should be going after. Velocity teams (frequently under the support umbrella) can also tell you who is not successful. Biggest problems, most off-the-wall feature requests, who is putting a square peg in a round hole when it comes to product frequently manifest as repeated support requests and negative interactions.
When it comes to defining your ICP, make sure post-sale customer facing representatives on both the high touch and high velocity side are present in determining who sales and marketing should target as potential customers.
Case Studies, logos, and other social proof
Similarly to defining the ICP, your customer facing teams can spot what sort of case studies you should be generating to attract best-fit customers. Since they are also working with these customers, they can also facilitate the intro to marketing teams. Willing participants can easily be tracked and tagged in a CRM.
Value propositions
You can guess the value proposition of your product or a new feature, or you can use actual customer voice to tell you what they find valuable. No one hears the true reasons why customers love using your product more than customer-facing teams.
Frequently it comes in calls learning how to use something new, or in a response to getting help with a feature in a “by the way, we love X because Y….” Your customer facing teams should be tracking these sound bytes using some sort of note and tracking tag in their help desk system like customer-love. Then, that feedback can be shared with product marketing and marketing teams to help shape value propositions, insuring you attract customers to your product for reasons that have already proved to be successful.
Messaging
Your messaging should be the same language your customers speak. When customer facing teams, specifically customer success, identify a customer’s goals and desired outcomes for using a product or service, they will articulate their needs. These needs and quotes can be captured and turned into messaging that matches your customers voice, and tracked similarly to value propositions.
Customer lifecycle
Your customer facing teams know what common questions and common hurdles come up at every step of the buying, onboarding, and expansion process. They likely already have enablement, guides, and saved replies that answer these questions.
These can be spiffed up and operationalized and turned into nurture campaigns, create buyer enablement, and facilitate a seamless experience for customers moving through the buying and customer journeys.
Forums to address with Growth
The following forums are tools and tactics that can be used to facilitate the engineering to customer teams feedback loops.
Hubspot, Help Scout, or other CRM and Customer Platform
Feedback can be tracked in the help desk or CRM by using tags, custom fields, or properties. This helps growth teams aggregate research on their own to get an idea of feedback coming in from customer conversations.
Revenue Ops Cadence
Revenue Ops is the end-to-end business process of driving predictable revenue growth through marketing, customer facing teams, renewals, and expansion through transparency and execution alignment. If you're not meeting already, your marketing and growth teams should have a regular (can be monthly) cadence to sync up on these items with your customer facing teams.
Technical feedback loop
The technical feedback loop is the one that most affiliate with customer support, specifically “Tech support.” While some teams have bugs routed through product to be “prioritized,” I'm a firm believer in customer facing teams working directly with engineering on bugs. They should be addressed as soon as they come up and can be reproduced, not prioritized on a roadmap alongside features.
You wouldn’t let bugs live in your house, you’d squash it immediately, and call an exterminator at the hint of an infestation. They have no business in your house, and no business in you product.
Bugs
Again, bugs should be fixed if they are reproducible, full stop. They look bad, generate a ton of friction, and hurt customer trust with your product (if this is broken, what else could be?) I'm always baffled when I hear of customer facing teams having trouble getting their engineering teams to address bugs, but it happens. If you are one of these engineering teams, shame on you.
If they are challenging to reproduce, or are the result of an obscure extension to reproduce, this story changes. Then, they should be prioritized by volume, severity, and impact.
UI/UX confusions
These are what some customer facing teams call “bug or feature” type functionality. Unlike bugs, they don’t need to be prioritized immediately, but it’s good for the teams to communicate with each other on these to understand whether or not something is broken, or if it’s working as expected but for some reason customers don't quite “get it.” These should be tracked like stories by impact and volume, and evaluated with design if there's a better way to visually communicate the sticking point.
Customer facing teams can also improve this hurdle/confusion with enablement. By creating videos and guides that walk customers through confusing sticky point, and prompting instructions in-app when they get to those points.
Performance
Frequently your customers will also report slowness and performance issues. This may be related to the scale of certain accounts. If it’s determined that source of slowness is definitively not something on the customer’s side, like their internet connection, it’s important to address.
Performance issues can make the app unbearable to use, and they can be hard to catch in testing since the ways customers use the account will undoubtedly be a much greater scale than your test environment. But, when they are resolved, customers most definitely appreciate it.
Forums to address with engineering
The following forums are tools and tactics that can be used to facilitate the engineering to customer teams feedback loops.
JIRA or other issue tracking software
Like stories to product, technical issues can be logged in an issue tracking software to work through with engineering.
Urgent on-call system
Urgent issues can be flagged by creating a custom field in JIRA that triggers an ops-genie alert:
In the JIRA bug template to alert emergency issues
This alert signals to engineers to communicate about urgent issues in a Slack channel for in the moment investigation instead of every day bugs or issues.
Incident response slack channel
Cadence meeting
For non-urgent bugs, engineers can invite members of customer facing teams to weekly or biweekly bug triage meetings to discuss any customer bugs or technical issues that emerged during the week. This can give your teams an opportunity to connect on context that may be helpful in the engineers investigation.
Closing the loop
As important as actioning customer feedback is making sure requesting customers know you took their feedback to heart. This means it's important to close the loop with customers (and no, telling them to watch for your release notes or product blog is not enough - especially when it's so easy these days with the right technology!)
If you’re tagging customers in a help desk like Help Scout, it should be easy enough to set an automated workflow or rule that follows up automatically when the improvement is made. This makes it easy to close the loop with requesting customers at scale.
Releases
The last stop on the customer feedback loop is alerting customers when a change takes place. There's a few different stages of maturity when it comes to product and feature releases:
The release process is entirely defined as how engineers deploy a feature. There is no customer outreach process, and no internal training for customer facing teams.
The release process is still primarily defined around engineering deployments, but release notes are published by customer facing teams.
Marketing or sales is looped in to new features for the purpose of selling, but there is little orchestration around educating customer facing teams on the new features beyond what is published in release notes.
Post sale Customer facing teams are looped in before the release goes out, with enough time for knowledge base documentation and internal enablement and education on a feature, but all releases are treated with the same weight - big or small.
Customer facing teams are looped in well before feature is released, while still in development, assisting product with the beta if it's a major release. There is a defined, tiered process to releases that accounts for small and large releases alike.
So, how do we get to stage 5?
Tiered feature releases
Obviously not every feature requires fanfare, but that doesn’t mean most new features should go under the radar. Using a tiered feature release process can help streamlining your product launch efforts so that you’re generating buzz for the big releases, but still closing the loop for the small quality of life improvements. Showing customers product momentum (and that you’ve listened to them!) is a powerful way to keep them around.
Tier 1: High revenue value and customer value
Tier 1 would be considered an “Epic” or even a new “Product.” This is a major opportunity for acquisition and expansion. For Tier 1 features, a full on launch process should commence.
Tier 2: High customer value, not acquisition value
Tier 2 might be an epic, but is geared more to high customer value vs. high acquisition. There may be revenue value in retention and also win-backs. This may have a beta period of only existing customers, especially high value customers. For these, there should be a launch process that is more customer centric than market-centric: customer marketing and win back campaigns for churned customers.
Tier 3: High to medium customer value, no revenue value.
Quality of life improvements. It’s not something “sellable” but it is something customers care a lot about. Launch process should involve updating documentation, saved replies, internal enablement and of course, replying back to requesting customers.
Tier 4: Well, that's nice.
Small quality of life improvements, like a settings change, or a change in UI to make things less confusing. For these, there’s not much of a launch process beyond release notes, updating documentation, and replying back to customers.
If you noticed a trend, in every one of these cases any requesting customers should be followed up with. Again, the Help Scout JIRA integration really saves the day on small releases and bug fixes. When customer conversations are connected to a JIRA ticket or task, they automatically re-open making it very easy to close the loop with customers that requested a feature.
For large releases, running a workflow on tagged conversations tracking feature requests can close the loop with everyone who requested automatically, and still look personal.
Getting to Phase 5 of Product launch maturity
If you would like to get to phase 5 and aren't already, feel free to Copy my product launch template from Canva to present to your company.
Link to template for product launch plan
If you'd like to understand all of the customer facing activities that need to be coordinated for Tier 1 product and feature launches, feel free to copy my Trello template (other tiers can be easily reduced from that template): Product Launch board template
And or course, with every release customers will have feedback, and the process begins again!
Conclusion
Are customers product designers, not likely, no. They aren't necessarily expert UI/UX designers, and they also may not be savvy business people. But, they are people who use your product and can deliver valuable insight into what is and isn't working.
To not listen to them is to deny yourself a treasure trove of information, and your customer facing teams are best positioned to aggregate, track, segment, and advocate for that feedback to inform business decisions.