From Support Hero to Customer Hero
Having recently finished the Scenario-Focused Engineering book, I’ve been considering how to put some of the practices into use for our Windows team. With three devs to build the Todoist for Windows 10 app, there’s not a lot of dev time we can afford to sacrifice for other activities.
At the same time, we definitely have ample opportunities for improvement:
- Sometimes we don’t meet customer expectations. A lot of customers expect at least 100% feature parity with the web app
- Some of our UX is too friendly towards touch, while mouse and keyboard users expect ruthless efficiency
- We lack a strong grasp of how the expectations of the Windows userbase differ from the general Todoist population. This makes placing bets on Windows features like Timeline integration purely instinct-driven decisions
- While we’re working hard towards a rock-solid app, balancing quality work against externally determined feature scopes can be challenging
While we’re likely to execute on (4) in the long-run if we sustain our current team process improvements, (1–3) will not happen without deeper customer understanding. If we can’t deliver a unique Windows experience for our users, we could just as well throw in the towel and release an Electron app. Windows users deserve better.
How do we gain a better understanding of our Windows customers’ needs and force ourselves to prioritize them more aggressively? It turns out we’ve already taken the first steps without realizing it.
Support Hero
When our team grew beyond a single person, the responsibility for some common activities became less obvious. Who should answer to support team questions? Who should be watching telemetry and transforming crashes into bug reports? Who should be watching out to make sure we meet a baseline quality for our releases?
We’ve settled on the idea of a Support Hero role. From our team spec:
Every week, one person is designated the “Windows Support Hero”, based on a rotation system. The person has a few responsibilities:
- Responding to tickets in Todoist Support
- When you’re letting support know on Twist that you’ve added a user story/bug, please include a link to the VSTS work item. This makes it easier to follow up on an issue.
- Monitoring telemetry for both preview and production apps in App Center
This idea worked out fairly well. It turns out that devs enjoy taking this opportunity to get a bit closer to the customer. And knowing the name of a person whose problem you’re fixing is quite powerful. We’ve seen a significant improvement in bug lead time since we introduced the Support Hero. We’ve also gotten feedback from our partners at the Support team that the new role made our team more responsive when communicating about user issues.
But the current role definition also has limitations that prevent it from becoming the customer touchpoint we need to deepen our understanding with the customer and push hard on customer’s behalf.
The Support Hero has less than 50% allocation. The person in the role still needs to substantially help with the execution of the cycle scope (we run a SCRUM-like process modified for remote orgs in our team).
Second, the weekly rotation makes it hard to build deeper connections with customers beyond talking about specific bug reports. Five days is short window for even simple user research techniques like discount usability testing.
These issues could be overcome by widening the scope of the Support Hero role and slowing the rotation cycle a bit. Enter the Customer Hero.
Customer Hero
Customer Hero is a Support Hero with a few extra activities thrown in:
- Design and execution of Windows 10 app-specific customer research. Includes partnering with other teams on execution of these research projects
- Evaluating customer research data, formulating bug reports and suggesting user stories for the backlog based on learnings
- Fixing issues that require only a small amount of effort immediately to cut down on lead time
- Act as a reviewer for majority of PRs to reduce the amount of expensive context switching for the rest of the team
Aside from these new activities, the Customer Hero would also have more time for existing activities, especially around watching telemetry and transforming it into actionable bugs.
To make the pace a bit more manageable, we would experiment with rotating the Customer Hero only every two weeks, or even just once a month. It also gives the role an opportunity to see multiple consecutive versions in production, which would be helpful for issues where we need to add telemetry before solving an issue.
Here’s a schedule of the Customer Hero’s two-week rotation:
Aside from the activities above, the Customer Hero is continuously in touch with support to process incoming issues, generate repro steps and provide well-defined bugs for complex issues that should be accepted into the next iteration. The Customer Hero also monitors telemetry and adds well-defined bugs to the backlog based on the telemetry inflow.
We’ll need to see how much time the Customer Hero role takes, but ~70% allocation seems like a reasonable jumping-off point.
Success Metrics
How do we know this new role succeeds or fails?
First, our crash rate lead time for bugs that have user impact goes down significantly. This is achieved by fixing low-effort bugs immediately, outside of the sprint. By having a deeper understanding of customers, the Customer Hero is also expected to put more pressure on the team to prioritize customer-impacting issues.
Second, we move from delivering features that are on par with other platforms to features that go an extra mile and delight our Windows customers. It can be the extra drag & drop interaction when we implement favorites, keyboard shortcuts when redesigning the scheduler or one of the many things we right now have no idea our users want. We’ll have to get creative to track meaningful metrics. One idea is to make the web version of Todoist a baseline for satisfaction ratings and measure the Windows 10 app against it.
Third, even though the Customer Hero role will eat up more resources relative to the Support Hero role, the team velocity should not slow down significantly. What we invest in more expanded role, we should recoup in the term of more focus for the rest of the team as well as better defined bugs and user stories.
Experiment with process changes is always scary as it usually leads to worse team performance in the short-term. But willingness and free hand to experiment are one of the best parts of working at Doist 💙.
I’m excited to share this idea with the team soon and get their take on it!
Thx Christoph Krenn for contributing ideas to this ;-)
