Scaling an Enterprise SaaS Product Team
2026-03-07 22:17 Diff
https://www.braze.com/resources/articles/scaling-an-enterprise-saas-product-team

Since day one, the Braze product has been a primary driver for how we unlock opportunities. Whether we’re building differentiated capabilities, enhancing our customer experience, or moving into new markets, our product has been the engine that drives our business.

On this journey, we’ve had to figure out how to scale our product development process as an enterprise software as a service (SaaS) business. This required facing challenges that don’t exist in consumer products. For instance:

  • Enterprise SaaS offerings are complex, involving activities that don’t exist in consumer tech: Think of multi-month sales cycles or customer integrations that involve partners.
  • You can’t just freely experiment with your users in B2B SaaS; business-critical applications require business-critical reliability.
  • When you partner with large global brands, you can face pressure to divert your roadmap for needs that are legitimate but customer- or segment-specific.

Crafting a SaaS product is challenging. This is why many SaaS roadmaps boil down to building whatever the biggest sales prospect asked for last, or whatever the biggest trend is in their market. These strategies are the opposite of what it means to be product-driven, and the opposite of what their customer base wants.

In this post, we’ll walk through four tactics that we employ at Braze to scale up our enterprise SaaS Product organization:

  1. Empowerment of teams who own strategic product decisions
  2. A scientific approach to deciding what should be built
  3. Building for the long term
  4. An emphasis on removing distractions

Let’s break down what this means in practice.

1. Empower Your Teams

Being product-driven starts with empowered, autonomous teams.

SaaS products can be complicated when compared to their consumer equivalents. My toddler figured out how to stream the show Sharkdog before he learned to take off his shoes. On the other hand, I would never trust a small child to operate a full Salesforce implementation—it’s hard enough for a team of grown adults.

As products grow in scope, it becomes impossible for anyone to understand every detail. To guarantee that those closest to customer needs are calling the shots, we’ve shifted to making the majority of our product decisions in a bottoms-up manner, where strategic decisions are made as far down the org chart as possible. In connection with that approach:

  • We’ve empowered cross-functional teams of engineers, designers, and product managers with the authority to set and execute their roadmaps, since they intimately understand what experience is most appropriate for our business.
  • Our Product and Engineering leaders don’t tell these experts exactly what to build (barring very rare exceptions); instead, we aim to set goals and swimlanes. Where possible, top-down prioritization inputs ideally manifest as sharing context or making a case, rather than deciding by fiat.
  • Teams are designed to have as few dependencies as possible. Autonomous teams plan and build faster, leading to stronger morale and better business outcomes.

What does this look like in practice? At Braze, we have a team who owns our Messenger products, from SMS to other future messaging platforms. Like all of our Product teams, they’re empowered to run their roadmaps based on their deep customer and market knowledge, rather than being directed from afar by someone with limited context.

We do provide teams with a degree of top-down guidance on where we want to drive product investments—for instance, making orchestration more efficient and powerful, or pushing the frontiers of how Braze customers can reach consumers. This mix of top-down guidance plus bottom-up empowerment ideally allows independent teams’ strategies to integrate into a coherent, impactful whole.

2. Take a Scientific Approach to Product Development

Empowerment is only valuable if teams consistently make great decisions. We want teams to take a scientific approach to prioritization, using well-reasoned arguments to inform what they decide to build and testing those arguments empirically.

Devising SaaS roadmaps can be complicated. In addition to considering universal inputs such as user feedback or usage data, SaaS teams must also weigh sales insights, competition, analyst reports, pricing implications, and more. With such a swirl of factors, it’s all too common for enterprise roadmaps to wind up being driven by anecdotes.

At Braze, we’ve embraced this scientific approach by investing in ways to gather data and learn fast. Some of these strategies include:

  • Standing up systems for collecting and categorizing customer- or team-generated product feedback (e.g. via ProductBoard, internal questionnaires, and customer surveys powered by our own product)
  • Conducting extensive user research and organizing regular customer conversations with our Product and UX team members
  • Instrumenting the Braze platform to capture relevant customer data that we can analyze
  • Relying heavily upon early-access periods to get real customer data on product viability. This empirical research is essential for building great products, and requires thoughtful partnership with post-sales teams (you can’t experiment on your users the way a consumer-facing tech giant might when you’re building a business-critical application!).

A tip: Invest in a writing culture in your Product organization. Well-reasoned, clearly written proposals that include thoughtful analysis are a powerful way to encourage a logical, data-informed decision-making culture.

Additionally, sometimes data isn’t enough. Data is a way to make a compelling case for prioritization (and often the best when it’s available), but it isn’t the only way to craft a logical argument. Writing down the case for prioritizing a feature or product can often help to set a thoughtful course when perfect data isn’t available.

For example, we built our Canvas and Currents products based on strong first-principles arguments for what we believed our customers would need with respect to automation and data; had we waited for mathematical proof that these were the right features to build, we would have missed the boat.

3. Building for the Long Term

Product organizations need to invest for the long haul. This is especially true in SaaS as businesses naturally compound, so Product teams need to think about maximizing value over a long time horizon, rather than optimizing for short-term gains.

At Braze, we reinforce our bottom-up organizational strategy with teams that ideally stick together for years. This allows product managers, engineers, and UX experts to forge strong partnerships and compound their expertise over time. We believe that a history of shared wins also encourages teams to invest in their products more thoughtfully, building toward a long-term strategy instead of being reactive and responding to the latest inputs they’ve received.

If we were constantly dissolving and reforming teams, we would disincentivize long-term investments, even when they’re in the product’s (and the company’s) best interests. Long-term bets require difficult trade-offs—we’ve had instances where we needed to slow the delivery of revenue-generating products for months to build critical foundations.

What does that look like in practice? When Braze built our simple survey in-app messages, we took the time to completely reconstruct the infrastructure associated with our existing in-product messaging capabilities. That took additional time and effort, but it also opened up many additional, powerful capabilities as we launch new types of editing and composition experiences. But the team that envisioned this foundational transformation saw it through, and is now launching more advanced products faster than ever.

4. Minimize Roadmap Diversions

Finally, we need to give Product and Engineering teams space to do their best work.

If you sell enterprise SaaS, you will get pressure to divert your roadmap. It’s like a law of gravity, and just like gravity this pressure increases as the mass of your business grows. However, you also need to pay attention to these asks—SaaS businesses require happy customers to be successful.

That being said, you can’t succeed if you veer from your long-term plans at a moment’s notice. Diverting from your roadmap is kind of like eating junk food—a little bit is expected, but a pattern of overindulging can cause serious issues over the long run. Moreover, the more junk food you eat, the more you reinforce the habit: Junk food becomes a fixture of your diet.

While we don’t expect to avoid 100% of one-off product requests, we’ve gone as far as we can to minimize their distraction. Some of the strategies we’ve used include:

  • Building a flexible platform that allows us to make more use cases possible
  • Treating one-off asks as escalations and making sure that both Product and post-Sales leadership are aligned before tackling them
  • Strongly preferring one-off asks that consist of features we’d like to build someday, and even more strongly discouraging diversions that we would be unlikely to ever support were it not for the acute ask

One final note on this: The calculations you make on what diversions to embrace differ greatly when you’re a tiny company vs. a larger growth-stage business. If you’re a struggling early-stage company, the junk food of roadmap reprioritization may well give you the calories that your company needs to survive—and there’s no shame in that.

Final Thoughts

We don’t claim to be perfect when it comes to these four different dimensions of operating as a product-led company, but we’re proud to strive for the ideals laid out in this post. Braze has had strong product and engineering DNA from day one, and we take pride in our product-led roots—but that doesn’t mean that maintaining a product-driven approach hasn’t taken a lot of work and care.

Interested in working at a product-led organization? Check out our careers page to learn more about Braze and see our open roles.