Pager fatigue: Making the invisible work visible. Register now
Pager fatigue: Making the invisible work visible. Register now
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 launched our list of Top engineering voices to follow in 2025 to spotlight those engineers who aren’t just building behind the scenes, but also writing, posting, and contributing in ways that make the whole community smarter.
Today, we're introducing AI SRE, your always-on teammate that spots issues, surfaces root causes, and takes action to help you resolve incidents faster.
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.
Ready for modern incident management? Book a call with one of our experts today.