Learn more about Consider Learn more

How to prioritize bugs while avoiding this classic mistake

It's been a little too long since you've run through sign up for your product. You remind yourself you should do this once a week. Anyway, time to do this. You get through the first few steps, all looking good. You get to the credit card form. Oh man, are you serious? All the labels are just a little misaligned. It looks like a mess. You go to open a bug. Oh there's one from a few weeks ago. It's labeled "P2", the lowest priority in the system. You cry a little bit inside.

This was an experience that we ran into pretty often in our previous lives leading the Growth team at Intercom. The problem was our priority system was defined by how "big" the broken thing was. Something like:

  • P0: major feature unusable
  • P1: minor feature unusable or major feature slightly unusable
  • P2: minor feature slightly unusable

You're gonna feel pretty dumb calling the labels on the credit card form a "major feature", let alone "unusable". A detail like this may not directly impact usability but screams the opposite of quality at a critical juncture in your relationship with a customer.

Prioritizing by time

Our fix was to change our prioritization system to be based off how long we're comfortable with a bug being live. We paired this with a dashboard that showed us overdue bugs, alongside open bugs. The new priorities:

  • P0: cannot be live, close immediately
  • P1: close within 1 week
  • P2: close within 1 month

My favorite thing about this system is how simple a framework it is for deciding the priority of a bug. Doesn't matter if it's just spacing or alignment or a major feature being broken, if you're not happy with it being open: P0.

We've successfully implemented this system twice: first in its original context, Growth, and then at Consider. For both these product areas attention to detail is crucial. You won't trust a new email client that's a little janky. Just like you won't trust a credit card form that's a little janky. If that applies to your product area, give it a try.

When to email, when to Slack

You walk out of your fifth meeting of the day. You look at your phone. You see the unread badge on the Slack icon. 18. Fuck. You open the app. You read a DM from Sarah: "Hey, I think we should change up the entire roadmap for the end of the year? What do you think?". Sarah might not be getting a response today. And then you forget. 17 to go.

Is this really the peak of 21st century work communication?

At a newly founded startup, there are more important things to do than think through which communication tool is right for which scenario. However, as soon as you start growing, your default choices can quickly become untenable.

A simple framework

A good start to restoring sanity is having a simple framework for when to Slack and when to email. Slack excels for shared priorities. It's live, realtime, easy. However, the same qualities that cause Slack to excel for shared priorities make it terrible for mostly everything else: it's interruptive, it's hard to return to later, and it doesn't respect others' time.

Before you Slack anybody, ask:

  1. Is this a shared priority for all the recipients of this message?
  2. If not, is this important enough to warrant an interruption?

If the answer to both questions is no, send an email instead.

Instill this framework in your team and you won't regret restoring a little sanity and respect to your work communication.

The next piece of the puzzle

Perhaps the toughest thing in email is how much you have to build in your v1. You have to build almost everything in Gmail, without any bugs, before doing anything new. This makes for a somewhat awkward public story: you don’t want to share too much when you’re potentially years away from realizing even the start of your vision.

Today, we are excited — and a little nervous — to reveal the most significant piece yet of our email puzzle: Groups. Groups is like Slack channels but for email. With Groups you can join a new company and see the strategy memo the CEO sent the week before, you can switch teams and immediately have full context for everything the new team has been working on, and you can increase your passive awareness of what’s going on by poking around other teams’ email. More on Groups in a moment.

We are also sharing for the first time that we have raised $5M in seed from Kleiner Perkins and Bedrock. Mamoon Hamid led from Kleiner Perkins and joined the board. Eric Stromberg led from Bedrock. I’ve known Mamoon and Eric each for 5+ years and we are so thrilled to have them and their firms as partners on this journey.

Why groups matters

Email’s future is as an asynchronous, less immediate, more thoughtful counterweight to Slack. Asynchronous communication is fundamental to doing deep creative work: it doesn’t interrupt you, it gives you space to think. However, there is work to close the gap between what we believe email can and should be, and what email is today. The first step in closing the gap is to examine all the ways email is used today and ask ourselves: how would we design this if starting over? Enter: Groups.

With Groups, we are bringing Slack channels to email. You can now easily browse and search all public email (anything sent to a Group) in your company, without leaving your email client:

Within each Group you have a shared history of past conversations, regardless of when you joined a company or team:

When you get a fundamental detail right other things tend to fall into place. Every public conversation in your company now has a shareable URL and you can join conversations that didn’t originally include you. This unlocks workflows like this:

We’ve been using Groups internally at Consider for a few months and it’s changed how we use email. We are less afraid to use email as a system of record, confident that new coworkers will be able to find things. We CC fewer people, confident that people can find and join a conversation when necessary. And we are interrupted a little less by Slack — giving us all more time to think.