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!
For example, we were delighted to see that our new tutorial flow was completed end-to-end by 35% of our users (against an industry average of less than a quarter for 6-step product tours like ours).
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:
#support
channel. 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 organization.
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!).
We created a dedicated page for Anthropic to showcase our incident management platform, complete with a custom game called PagerTron, which we built using Claude Code. This project showcases how AI tools like Claude are revolutionizing marketing by enabling teams to focus on creative ways to reach potential customers.
We examine both companies' comparison pages and find some significant discrepancies between PagerDuty's claims and reality. Learn how our different origins shape our approaches to incident management.
The EU AI Act introduces new incident reporting rules for high-risk AI systems. This post breaks down what Article 73 actually mandates, why it's not as scary as it sounds, and how good incident management makes compliance a breeze.
Ready for modern incident management? Book a call with one our of our experts today.