How do you decide what to build? First, you must decide what not to build.

As Superhuman's product lead, I think deeply about the best ways to solve customer problems — and the order in which to solve them.

Product prioritization is crucial at fast-scaling startups. Here's how we do it…

A tale of 2 features

In summer 2020, our engineering timeline was a tale of 2 features.

One was our most requested customer feature, ever: Calendar Events.

The other was a tiny enhancement our customers didn't know they needed, but quickly came to love: Quick Quotes.

How did we prioritize these 2 features?

One goal, many methods

There are many ways to prioritize. Your method must align with your stage:

• Early-stage: the Wedge
  When you have limited resources, there's little benefit in ancillary enhancements. You need to get your foot in the door with customers. Focus on your primary solution, the Wedge — a single use case that solves an important need.
  
  
• Growing towards product-market fit: RICE
  When multiple ideas contribute toward the same goal, organize them with RICE. Estimate Reach, Impact, Confidence and Effort for each idea, then prioritize by score.  
  
  
• Hypergrowth: the Glass Jar
  During the phases of scale and hypergrowth, it is not enough to focus on a single goal. You need a portfolio approach to manage multiple projects and goals, and scheduling these initiatives requires managing dependencies.

Product during hypergrowth

Superhuman is in hypergrowth. Our customer base is growing quickly, and so is our team.

That means we can — and must — execute more than one project in parallel.

We want to run the Superhuman Product-Market Fit Engine, doubling down on what our customers love while systematically addressing objections. But we need to staff multiple efforts with care, ensuring one project's progress doesn't negatively impact another.

That's where dependency management comes in.

We knew we wanted to build Calendar Events. And we could have asked every engineer to work on it. But this would have demonstrated the mythical man-month — past a certain point, increasing team size does not accelerate a project's progress.

Our next most important project was Select All — an equally big and challenging feature. If we worked on 2 large projects in parallel, bottlenecks would slow us down. Both required shared resources like product and design, or senior technical architecture.

That's why we turned to the Glass Jar. It's a memorable metaphor for effective prioritization, crisply applied to SaaS product management by David Sacks.

Filling the Glass Jar

Planning projects during hypergrowth is like filling a Glass Jar.

• Rocks: your largest projects and most strategic initiatives
  Rocks have the greatest potential benefit, but also the highest estimated cost. They require significant upfront investment before they generate returns.
  
  
• Pebbles: your medium-sized projects
  Pebbles have a smaller overall positive impact, but are easier and faster to execute. These are mildly desired by many users, or desperately needed by some.
  
  
• Sand: your tiniest, nice-to-have improvements
  Sand could be small tweaks to existing features, or internal pet peeves.
  

Now, fill up your jar! What's the best way?

Fill your jar with rocks first. Then squeeze in pebbles, and finally sand, to fill all the gaps.

If you fill your jar with sand first, you cannot easily fit in rocks. Your team would not achieve big initiatives.

If you fill your jar with rocks only, you would leave space unused. Your team would be inefficient, and your product would not improve as fast as it could.

Finding our rock

We began by prioritizing Calendar Events.

This was a big rock: we needed to build new user interface elements, and deep API integrations, and think carefully about discoverability and edge cases like offline, authentication, and different clients. Despite all these moving parts, we realized there was an upper limit to how many engineers could work in parallel.

Around the same time, a new engineer joined our team. We wanted to strike a balance between launching him into an impactful project and giving him space to understand Superhuman’s product and codebase.

Our new engineer's project had to be relatively self-contained, but also touch an important part of the codebase. We needed a pebble!

Picking our pebble

Which pebble, though?  

When delivering a pebble, it is important to do so quickly. We looked for something beneficial, then rapidly switched from analysis to execution.

If we spent too long figuring out the very best pebble, we wouldn't have time to build it. The smaller the stone, the faster the analysis must be.

Let's think about replying to a complex email. A common way to do so is to reply in-line, or copy and paste parts of the message in your response. In Gmail, this process can take many steps.

We knew we could do better. Enter Quick Quote:

This project met our criteria:

• The feature was small and self-contained.
• We could build it to uphold our product principles of speed, visual minimalism, and keyboard over mouse.
• Compose and Reply are important parts of the code that every engineer should understand deeply.

It was time to build!

Calendar Events and Quick Quote both shipped in summer 2020, and our customers absolutely loved them!

Harmonious projects

Executing the most important projects is only part of the job.

Product managers need to ensure that multiple projects succeed simultaneously.

We succeeded with Calendar Events and Quick Quote because these projects were harmonious. One had cross-functional dependencies, whereas the other was small and self-contained. Both could move forward with minimal impact on the other.

More is not always better, especially when it comes to the rocks in your jar!