Based on our newfound data feet, we’ve started consistently tracking the adoption rate of our latest features. As it happens, we’ve been impressed with the results!
I know, I know: being at such an early stage means it is arguably easier to hit customer needs on the head. Regardless, we’ve built a tight feedback loop with customers that works for us, and has contributed to these above-par results.
In this post, we walk through how we work through customer requests at incident.io today, and a couple of things we’d like to do next to improve further.
We receive feedback via 4 main channels, ranked by how contextualised and detailed the feedback is:
From most to least client-facing:
#supportchannel. We use our own product, but it’s invaluable to be able to see how everyone else uses it, and how this differs across different customers.
This is a well-known must-do, but we try to be extremely thorough in digging into the use cases and contexts around feature requests. Jobs-to-be-done and customer segmentation are key to delivering the right solution. Here are some examples of how we surface deeper customer needs:
...[W]e see test incidents as a useful way for people to upskill themselves on the product in private. Can you help me understand why you'd want to prevent people from creating them? Thanks!
What's the value this provides over a standard Slack channel. Is it just that it's communicated widely that maintenance is going on, or the ability to flip quickly into incident mode, or something else? Not trying to grill you, but curious as to your motivations and ideal scenario here 🙂
When we push a Slack Connect message from a customer into Productboard, the app pings the channel in a thread to say someone at incident.io took note of the customer’s feedback. It’s a small detail, but it’s proven really powerful to make our customers (duly) feel heard. We’ve had quite a few users say things like ‘Thank you for listening’ off the back of those.
It’s often easier for users to feedback on something concrete. Thus, we write out a short proposal to our users for any new feature. This helps cement (double-combo pun!) what the feature will look like, and match that to the mental model of their use case and organisation.
We’ve been able to quickly shift the scope and look of a feature in days, based on those proposals.
Though we will eventually hire a Product Manager, the fact that Customer Success (CS) and Engineering work hand-in-hand on product without a middle(wo)man has been incredibly powerful.
The role of CS is: to make sure we collect as much feedback as possible; to document that feedback; to groom and broadcast it via ProductBoard/Linear and the internal
#product Slack channel.
This way, engineers have 1) a very clear picture of how many and what type of users request what feature, and 2) rich context and use cases to work from on (vs already-interpreted solutions).
All things being equal, we prioritise making existing customers happier over winning over new customers (Prospects).
This means we need to reflect consistently if a feature request would help us win a deal, or make an existing customer’s life easier. In reality, life is messy and there’s overlap — they often want the same things!
We’re less than a year old as a company and highly capacity-constrained. There’s lots we still want to experiment with to have an even tighter customer <> product loop.
A couple of things we’re mulling on and will hopefully implement soon (come give us a hand!).
Enter your details to receive our monthly newsletter, filled with incident related insights to help you in your day-to-day!
Image credit: Andy Hermawan