Restructuring the Braze Product Team

The most important driving force behind any software product is the group of people who build it—and their relationships with one another. Therefore, it’s important to arrange teams in a way that allows them to have as much leverage and impact as possible.

At Braze, we’ve thought extensively about how our product and engineering organization is designed, and want to share our learnings from a major departmental reorganization that helped us greatly improve how we prioritize features, develop team expertise, and build our product more efficiently.

Early Structure: Product/Market Fit and Beyond

Finding product/market fit—and leveraging it to grow a business—is a crucible through which all startups must pass. Throughout this stage in a startup’s development, experimentation speed and the ability to rapidly capitalize on opportunities are critical. To that end, our original product team structure looked like this:

This structure, which divided up our team based on functional specialties, worked well for several reasons.

First, it allowed us to efficiently tackle transformational product changes on the way to product/market fit—experts could own huge swaths of our codebase and use the languages, frameworks, and design decisions with which they were most comfortable. Fueled by massive amounts of caffeine, army-of-one project “teams” regularly tackled huge endeavors. These included building our customer-facing public API and overhauling our entire message-sending infrastructure, often filling the role of sole engineer, product manager, and designer. These types of extreme measures would be madness at a large company, but are necessary and almost routine during early growth.

Additionally, this structure helped us gain deep mastery of certain technical areas with only a 10–15-person team. Many elements of our core products—e.g. our front end’s model-view-controller layer, APIs, and high-throughput message-sending code—were fully understood by only a few individuals.

At the time, it was simple and all we needed. When speed is everything, organizing based on simple guidelines helped to reduce cognitive overhead and allowed us to focus attention where it could do the most good.

Later Structure: Growth and Scaling

As our team grew past 30 or 40, however, this structure began to break down. We ultimately identified reorganization of our product team as a solution to some of our largest challenges. We were expending unsustainable effort juggling skill sets and timelines to compose teams for strategic projects. We also spent inordinate amounts of time on prioritization, and often found ourselves force-ranking all product priorities across the business since our technology-based team structure did not map directly to the most essential product needs. And finally, we had few opportunities for team members to develop deep experience with particular customer use-cases.

We ultimately switched to an organization structured around Agile cross-functional teams similar to the Squad/Tribe model popularized by Spotify. Our new org structure looks like this:

The majority of our team works within “product verticals,” corresponding to a key area of our product or business. For example:

• Our Email & Enterprise team runs Email from top to bottom, as well as certain product areas such as permission management that are critical to many of our largest customers.
• Our Messaging & Automation team owns several product areas relating to user segmentation, messaging, and our flagship orchestration product, Canvas.

Within a vertical, we expect prioritization to be (relatively) straightforward, as each vertical corresponds to a specific set of customer needs. Certain teams such as Visual Design, DevOps, and our Infrastructure Engineering groups span the entire platform, building consistency in key areas.

Impacts

Our reorganization significantly reduced cross-team dependencies. Previously, we struggled with the Sudoku-like scheduling problem of slotting the right balance of specialized skill sets (engineering, design, product management, etc.) onto a given project at a given time. It also aligned short-term incentives—before the transition, teams often found themselves relying on counterparties who were aiming at unrelated goals. With our new structure, product teams are independent, have far more control over timelines, and are fully aligned on goals, increasing productivity and morale.

The new org design also improved prioritization. For example, our Email & Enterprise team might need to decide between upgrading our email infrastructure, building a core email feature, or fixing an enterprise usability problem—a straightforward and easily quantifiable decision, since all three relate to our customers’ needs in similar ways.

A team struggling with too many high-priority needs is also an indicator that their product area needs more resources. This allows us to reframe difficult prioritization problems as staffing needs, which are still challenging but conceptually straightforward to address.

Finally, focusing most teams on a particular product area has allowed individuals to build deep expertise and highly productive working relationships over time. Initially, in the first few years of building, individuals could hold essentially the entire product and codebase in their heads, but as we grew this became impossible. Product problems are fractal: each time you look closer, you find more nuance and depth. As a result, spending many hours in a particular area of a product or codebase and deeply understanding its business needs is one of the best ways to achieve real product breakthroughs. Additionally, creating focused long-term teams builds ownership and rapport, and allows unspoken working relationships between a consistent set of collaborators to gel.

Of course, no system is perfect. With a focus on product-oriented pillars, we increased the potential for teams to optimize for localized needs at the expense of holistic priorities. For example, one might focus on localized tech debt (“this controller is cumbersome”) instead of global issues (“changing our front-end framework would increase overall engineering velocity”). In anticipation of this need, we took steps to establish the cross-cutting teams mentioned above, and have used dedicated committees for other broad projects—for example, a committee to build a holistic product/design system of front-end components and design patterns.

Our new structure also brings higher activation energy for holistic, transformational product changes. Some areas of our product, such as our back-end APIs, are jointly owned by several teams. The threshold for making sweeping changes to broad, cross-cutting areas of our codebase is higher, so this type of structure works best once the skeleton of your product is largely formed.

Takeaways

Overall, we’ve been satisfied with our redesigned product org structure: We’ve resolved or greatly improved our challenges around team dependencies, prioritization, and building long-term product expertise, and also have a helpful roadmap for how we’ll scale. In particular, we’ve learned that:

• Removing dependencies and aligning incentives leads to huge efficiency gains.
• Apples-to-apples prioritization is both simpler and more effective.
• Deep expertise in a particular customer or business need leads to better product outcomes.
• Working with the same team members over an extended period is critical for building great working relationships.

I’d recommend this structure for any team sharing certain key characteristics: a cross-functional organization in which functional experts such as product managers, designers, and engineers are equal stakeholders; more than roughly 15–20 people on the combined product development team; and, most important, firm product-market fit. And if this type of team structure sounds appealing to you, we’re hiring!