Infrastructure upgrades, improving user flows, a backlog of support issues, bugs, security work, improving latency, refactoring old code, building new features. If you’ve ever worked on a Product team, I’m sure you’re very familiar with this list. And I’m sure you’ve asked yourself, “How do I prioritize all of these things I care deeply about?”
At HubSpot, we face the same problem. We are made up of over 140 small, autonomous product teams comprised of engineers, product managers, designers, researchers, and more. These teams are constantly asking themselves, their managers, and leadership how they’re supposed to decide which item on a very long list is most important to tackle first. And when there's always a desire to release new features, how do you justify spending weeks on your support backlog?
The good news is that we, as humans, are no strangers to complex prioritization. We make value decisions about how to prioritize some actions over others every day, often unconsciously. We don’t look for healthier foods if we’re still struggling to find shelter, for example. Just as we can relatively easily see where we stand along a spectrum of wants and needs, so too can we identify at what level our product needs our attention.
Enter: the Mainsail
(We love nautical references here at HubSpot. This is only one of many.)
If you’ve studied basic psychology the graphic above should look familiar to you. Based on Maslow’s Hierarchy of Needs, we’ve created Mainsail to help everyone in Product, Engineering and UX understand and prioritize all of our customers’ needs while maintaining the autonomy that makes up the DNA of our Product and Engineering organization. The seven levels of the Mainsail are split into two sections: Guardrails and Goals.
The Guardrails are each tied to a metric (or metrics) with an explicit SLA (service-level agreement) that Product teams can track to assess their health:
The Goals levels on the Mainsail typically relate to new features, though sometimes new features can be the solution to a Guardrail level. The metrics for Goals vary by team, though we are working on standardizing these over the next year as well.
Some examples of Goals metrics include:
The idea is to move “up” the mainsail, starting with Security, by getting each level healthy before focusing on the next level up. Your Guardrails must be healthy before working on Goals (or you at least need to have a very good plan for how you’ll achieve your Guardrail SLAs while also working on Goals). For example, say you’re a product team working on a new feature that adds functionality to a report with the goal of having it in beta by next quarter. This work likely falls into the Value level. If a high-risk security issue comes up, the team can use the Mainsail to prioritize the work in the Security level over the new functionality they have planned. Sometimes this looks like pausing work on the new functionality completely, and sometimes it looks like taking one engineer off of the feature work and dedicating their time to fixing the Security issue.
Another great example comes from migrating or deprecating internal infrastructure. It’s hard to complete major, cross-organization migrations when you’re working with 140 autonomous teams. Oftentime the team that owns common infrastructure might not feel they have the influence to have their work adopted by all teams, resulting in long periods of time where they could have to support multiple solutions or potentially forgoing a migration entirely. That could either mean increased complexity and support burden, or complacency with what exists today. The Mainsail helps in both of these cases by giving teams a mechanism to prioritize the most critical infrastructure work across all teams.
We track our Mainsail data in a single dashboard that is accessible to the entire organization, but beyond this guidance, we leave it up to each team to decide how to tackle these items and trust that they know what’s best for their customers.
Implementing the Mainsail has been possible at HubSpot solely due to our culture and values. Like any change, it hasn’t been easy. Having a clear, simple process that was created (and improved upon) by listening to feedback from our teams was key, as was always keeping the customer at the forefront of every discussion. At the end of the day, Mainsail has given our teams a shared language for how to prioritize the multitude of inputs and requests on their plates while maintaining autonomy.
It’s our mission to help millions of organizations grow better, and we believe that giving them secure, reliable, performant and usable software will help do just that.