Back to resources

Problems With Prioritization: A Glass Jar Metaphor


7 July, 2021

Ketki Duvvuru

Ketki Duvvuru

Product Lead at Superhuman

Ketki Duvvuru, Product Lead at Superhuman, shares insight about how to prioritize at a fast-scaling startup. Think of it like a glass jar that you have to fill with rocks, pebbles and sand!


Superhuman is in hyper-growth. Our customer base is growing quickly, and so is our team. That means we can — and must — execute more than one project in parallel.

Our most important priority for the quarter was to build the ability to create calendar events. We staffed as many engineers as we could on the project but knew that past a certain point, increasing team size does not accelerate a project’s progress, per the mythical man-month theory.

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

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.

Actions taken

Two options were obvious to consider and each had its own tradeoffs:

  • To add the new engineer to the ongoing top priority project, though it was already well-staffed. a. Pro: People were already working on it, and the new engineer would quickly ramp up.

b. Con: There was a hard deadline associated with it, and the urgency it entailed made it not the best learning environment. As a beginner, it was questionable if they would be able to make a meaningful contribution. Also, adding more people to a well-staffed team could make it less effective.

  • To add the new engineer to the second-highest priority that was not started and not staffed. a. Pro: It was the next highest priority project on our roadmap.

b. Con: Working on this project in parallel could slow down the first project due to shared resources of product, design, and senior technical architecture.

We decided to go a third route. We took a self-contained customer-facing feature of less priority which didn’t require the same amount of architecture or design effort but was nevertheless useful and valuable to customers. The more relaxed environment would also allow the new engineer to become familiar with the codebase at his own pace.

As it turned out, prioritization is much more than working on the most important projects first. Instead, prioritization is all about balancing resources, knowing where the gaps and extra capacity are and how those can be filled. To better explain this thinking, consider a glass jar:

A glass jar represents your team’s overall capacity. Big rocks are your strategic projects of the highest priority, pebbles are nice-to-have enhancements, and particles of sand are minor tweaks that wouldn’t make a big difference individually but add to the overall experience.

The order that you fill in the jar is critical. If you put particles of sand first, you will not be able to put big rocks. If you cram it with big rocks only, you will have a lot of unused space. We wanted to start with big rocks, add some pebbles, and pour in the sand in the space between the two. By doing so, we could maximize the capacity of the jar. Therefore, we put our calendar feature first, but instead of the next big rock, we added a pebble that could fill the gap - a web application feature called quick quote.

Lessons learned

  • Prioritization is not just about rigidly following a stack ranked list, but it also requires appropriate balancing resources and managing dependencies. It requires creativity and flexibility.
  • Staffing projects can be a game of Tetris: not all pieces fit together well, and some configurations leave unnecessary gaps. Ensure your product backlog includes items of various sizes to enable the team to work efficiently.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader

Related stories

How to measure Engineering Productivity?

30 November

When you grow fast, its normal to focus on Value delivery aka "Feature Releases". Too many releases too soon will inevitably lead to piling tech debts and before you know, inefficiencies creep in, performances goes down, and ultimately any new release takes too long. Sounds familiar? Then read on..

Ramkumar Sundarakalatharan

Ramkumar Sundarakalatharan

VP - Engineering at ITILITE Technologies

How I failed at my startup

14 October

There are nine specific building blocks and functional areas every org/company need to work to launch the product and provide services to customers. How effectively founders tackle them determine the destiny of the company.

Mission / Vision / Charter
Scaling Team
Building A Team
Praveen Cheruvu

Praveen Cheruvu

Senior Software Engineering Manager at Anaplan

Scaling a Team in Two Parts: The Product and Manager

2 August

Viswa Mani Kiran Peddinti, Sr Engineering Manager at Instacart, walks through his experience scaling a team, product and his skills as a leader.

Managing Expectations
Scaling Team
Viswa Mani Kiran Peddinti

Viswa Mani Kiran Peddinti

Sr Engineering Manager at Instacart

Building Up Your Technical Skills in a Fast-Paced Industry

8 July

Otavio Santana, Distinguished Software Engineer at Zup Innovation, shares his best practices for upskilling without stretching yourself too thin.

Different Skillsets
Personal Growth
Otavio Santana

Otavio Santana

Java champion, software engineer, architect, and open-source Contributor at Independent Technical Advisor

How Product Management Chose Me

23 June

My accidental journey into product management

Personal Growth
New PM
Career Path
Michael Castro

Michael Castro

Sr. Manager, Product Management at Capital One