Insights into managing a customer request backlog remotely from the team at KnowledgeOwl

A long, long time ago, I started writing a blog post about how we capture and manage the backlog of our customers' requests. For whatever reason, I couldn't make much headway with it. But in the last couple weeks, as I've watched numerous folks publish tips, tricks, and guides for working from home, I realized that our customer backlog process could be a useful case study for those of you trying to abruptly transition to managing processes remotely.

You see, KnowledgeOwl is a 100% remote company. Our team includes people in five different time zones and three different countries, spanning over 15 hours' time difference. Only Marybeth and Pete, our cofounders, are physically located in the same metropolitan area. All of our meetings and communication happen online. In a word: we've already been socially distancing (at least physically) as a company, for years.

In the midst of that, we are also a responsive software company, and we need to meet regularly to review and make decisions on bug reports and feature requests from our customers. We use a combination of tools to make this happen. Here, I'm going to outline how we run this process in the hopes that it might prove useful to you, too.

The tools

First, a quick primer on the tools we use:

• Gmail + Helpscout: Our support email runs through a Gmail account; all support emails and contact form submissions are routed to Helpscout, where we manage them as support tickets.
• Asana: We use Asana for tracking all of the non-ticket work we do. We have projects for our Backlog, for what's currently In Development, for each of our professional services projects, for our pipeline of prospective enterprise customers, for capturing things relating to all of our major features, etc. (Full disclosure: I am an Asana ambassador.)
• Velocity: Not essential to the process, but still worth noting: we use Velocity to visualize task completion and workloads in Asana. Most notably, we use it to visualize our highly coveted weekly Bug Champion award. It comes with a primo virtual parking space. 👌
• Slack: All of our team communication happens in Slack. We don't email. We Slack. We have channels for different teams and topics. We are used to synchronous and asynchronous conversations in Slack, and we heavily use their threads feature.
• Zoom: We use Zoom for all of our meetings. We've tried lots of other tools, but since we often screenshare, we use Zoom because they've been the least buggy for screensharing.
• KnowledgeOwl: Yes, we use our own product. That's where I'm writing this blog post, where we write and host all of our support documentation, and where we document our own internal processes and onboarding resources.

While we use a bunch of other tools, these are the relevant tools of our backlog process.

The overall process

All of our support communication runs through HelpScout.

When someone submits a non-critical bug report or requests a new feature, we capture that request in our Backlog in Asana. Bugs get a "bug" tag; feature requests don't get a special tag. We capture the area of KnowledgeOwl the request pertains to, the URL of the HelpScout ticket, and the customer who requested it. All new bugs and features go into our Backlog's Inbox section; additional reports or requests for existing tasks generally mean that we bump the task from its priority section up to the Inbox to re-review.

Once a week, a subset of our team meets to review all of these requests, spec them out (customer impact rating + effort estimate rating + Minimum Viable Product solution), and prioritize them into buckets.

That meeting happens in Zoom. I run it. We don't share webcams for this meeting. I share my screen and we methodically work through:

• A quick review of our Velocity Bug Champion chart, to award last week's Bug Champion award to the person who closed the most bugs. We don't count a bug as "closed" until a customer has been notified and a release note or documentation update (or both) has been posted, so sometimes I am the bottleneck on a developer getting credit for their bug. Docs or it didn't happen.
• Any general agenda items (which are captured in a separate Asana project) -- these include process or larger roadmap/strategy topics, as well as updates on long-running features or bugs.
• Review and discussion of bugs. Whomever worked the bug ticket will present it to the group, we'll quickly discuss what might be causing it, do our estimates, and divide it into Top 10/15 bugs (which are our top priority) or other priority buckets.
• Review and discussion of feature requests. Usually Marybeth or I will act as the voice of the customer representing these requests to explain the use case, the team will consider that use case and decide on an MVP, estimate the customer impact and effort for that MVP, and then put that request in one of several prioritization buckets.
• For both bugs and feature requests, sometimes they highlight documentation gaps or we flag them as needing a documentation bandaid: when explaining how to avoid or workaround the issue is faster than fixing it.

Keep it simple

We have aimed to keep our prioritization process fairly simple. Most of us dislike meetings and every hour we're in meetings is an hour we're not improving the product, working with customers, writing documentation, etc. Meetings are treated as a necessary evil to enable us to work on the things that matter most.

Yes, you read that correctly: we spend an hour a week, max, on this process.

Recently, I started recording these meetings in Zoom so that the team members who can't make it due to scheduling conflicts or time zone issues have a way to stay in-the-loop on what's being discussed and prioritized. We'll revisit this decision in a couple months to see how well it's working.

Takeaways you can use

Meetings are not where work gets done. I feel like I should say that really loud for the people in the back. In a remote environment, with the exception of something like pair programming, meetings are NOT where work gets done. They are the planning, decision-making, and prep work, and maybe the team bonding glue, that helps facilitate work getting done. The more meetings you have, the less work you're getting done. Have fewer meetings and make them count.

Treat meetings as a necessary evil. While we are a tight-knit group of owls, we are comfortable having one-on-one Zoom meetings or Slack calls or group chats on most issues. We reserve meetings for things that simply can't be done as well any other way:

• Prioritization involves a great deal of discussion and explanation, which is much faster to facilitate verbally with a screenshare than over chat.
• Every other week, we have a touch-base meeting. These are optional but encouraged hour-ish meetings. I try to change up the time they're offered so that folks in different time zones have at least one a month that falls within their regular working hours. These are our more "social" team meetings. We have a brief agenda: How's life? What have your wins at work been lately? Are you bottlenecked or struggling on anything? Do you need our input on anything? But mostly, they're a way for our totally remote team to bond a bit. If one of us is getting overwhelmed, this is typically where and when we talk about it. This is the one meeting we share webcams for, so occasionally we might show a quick tour of our new office space or apartment or an adorable fur baby pose.

Meeting purpose is clear and, if it's a standing meeting like prioritization, it's run consistently the same way, every time. We only use meetings when nothing else will do. We don't generally hijack the prioritization meeting with other topics, aside from that quick open agenda at the beginning. We have Slack channels and, on occasion, one-off all-team meetings for those discussions. The meeting purpose is clear and we focus on that.

Reviewing individual items is done consistently, too. I daresay the team could run this easily without me, because I'm pretty systematic in facilitating these conversations. The person who logged the bug or feature reports on it and explains it. We discuss what constitutes the accepted solution or implementation (in agile terminology, we establish Minimum Viable Product, or MVP). We estimate customer impact and research/development effort. And then we put it into a prioritization bucket. Once that is done, we move on to the next item. We work through the list and either stop when the hour runs out or when we finish the list--whichever comes first.

Compartmentalization is key. You might be used to wandering to someone's cubicle or office and just lobbing anything at them, in any context. With remote work, we've found it's way better to compartmentalize. If you're using a chat app like Slack or Teams, have a separate channel or team for different topics. We have them for different areas of interest, different major projects, etc.

This holds true for our use of Asana, as well. We used to run everything from the Backlog. But over time, we found that it worked better for us to keep the Backlog for storing all the things, and then use a separate In Development project to track what was currently being worked on. This allowed us to better streamline our full development life cycle (development, code review, testing, release, live verification, customer notification, documentation update) and made it easier for us to each see what we were responsible for or who was waiting on us for what. While we might briefly do status updates on certain things at the start of our prioritization meeting, otherwise we only do prioritization.

We run our processes, rather than our processes running us. We generally practice Minimum Viable Process -- the simplest, least complicated process to achieve the desired end. We're a small team. Ain't nobody got time for complex processes. We constantly review and update our processes. This is good for any business, but I think it's even more important for folks working remotely. In a totally remote environment, each of us has to take ownership of our own work and focus. That means that, to the extent we can, we like to structure our working environment in ways that keep us as productive as possible. We have a Slack channel called #process where someone can raise a process question, suggestion, or struggle at any time. Often, we revise processes entirely in Slack, though occasionally we will have a meeting or we'll work in a small change during a prioritization meeting. I accidentally started an annual process review meeting and this has become one of our favorite meetings, where we set goals for the year and review ways we could streamline how we work or fix existing pain points.

We use tools that make sense for us. And we talk about how they don't work well. We periodically purge tools that we don't use a lot and evaluate alternatives. Example: for a long time, I was the only one using Zoom, and then I gradually wooed the rest of the team over when GoToMeeting was being finicky for them.

Leverage your internal expertise--and knowledge. We've long had a #tips-and-tricks channel in Slack for people to share the best way they've found to solve a particular problem. We've just started doing Zoom-based lunch and learns for tools, so that each of us can share our expertise. And we are currently going through a massive documentation effort to make it easier for those of us with specialized knowledge to share that knowledge to the rest of the team so they can jump in for us if our current life circumstances make it challenging. Yup, we're knowledge base-ing it up over here. 😊

Looking ahead

So far, our totally remote culture has largely insulated us from the massive workplace upheavals some of you have faced. But since we span so much of the globe, we anticipate that each owl is going to be affected differently, at different times, by current events. We anticipate that much of this year will involve agile adjustments to changing circumstances. We hope that sharing some of our experiences on a totally remote team will give you a few more tools to roll with whatever the next few months throw your way. Let us know if you have additional questions or want more tips on how we're doing things!