Scaling a Product Team From Inception Through IPO: My Conversation With Kevin Wang
Great products are built by great teams. I love bringing great product leaders together to share their perspectives and learn from one another. Recently, I had a chance to sit down with Kevin Wang, SVP of Product at Braze, a leading customer engagement platform, to talk about how product teams evolve at each stage of the business. It’s a topic he knows well. Kevin joined Braze in 2012 as employee #5 and has since scaled the product team, leading the organization through the company’s IPO in November 2021 and beyond.
Starting from scratch
In the early days of scaling, a startup’s development, experimentation speed, and ability to act quickly on opportunities are critical. Small companies have an advantage in that they can be nimble.
Until a company has found product/market fit, having a PM or product team is unnecessary. When Kevin joined Braze, he joined as a software developer; there wasn’t a product team. At Braze, this allowed for faster experimentation and iteration. “We had so little process that we could move as fast as possible. With a startup, you’re looking for these outlier outcomes; outlier outcomes tend to imply outlier risk. It’s like you’re going to the casino and just putting it all on red six times in a row. If it doesn’t work, it doesn’t work. That’s your life if you’re aiming for high growth.”
According to Kevin, finding product/market fit (PMF)—and leveraging it to grow a business—is a “crucible through which all startups must pass.” Some would say a company has product/market fit as it nears $1M ARR, but Kevin believes the earliest indications come sooner. “$500K is the real inflection point. You can’t hit that number without initial product/market fit unless you rely on just one or two big deals.”
Premature scaling – $500k-$10M ARR
Kevin thinks startups should start building the product team once the company starts scaling past the first few million in ARR. At this stage of Braze, Kevin modeled his original product team after “Agile cross-functional teams.”
According to Kevin, this structure, which divided up the Braze 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.”
Kevin remembers this period as a slog because there is more work to be done than there are people to do it. “You can’t hire your way out of your human capital needs unless you over raise, but that raises the stakes even higher.” You must power through. “The main challenge for the overall team up until $10M or so in ARR is that there’s so much more work to be done than there are people to do it. That’s a strain.”
Growth stage – $10M–$50M
According to Kevin, the growth stage is the hardest time. The company at this stage is “big enough that everything is unwieldy, but you need to grow really fast still, so you’re still doing things that don’t scale and that can set you back.” You never have enough people during this phase, and burnout is common. It’s also hard to hire great people because–unless your company is an outlier–you aren’t yet a proven winner.
Dunbar’s Number (or the rule of 150) suggests that there is an upper limit to the number of connections humans can make before communication and relationships break down. The workplace is not immune, and Kevin remembers that the transition from small to big org was not easy. Additionally, this phase often follows significant account growth, and pressure from enterprise renewals can intensify. Companies must navigate this phase carefully: Communication slows down, and cohesion between departments as a connection to the main core of the business becomes much harder to maintain.
Scale stage – $50M–$250M
During this stage, the entire company is trying to create a repeatable machine, and the product plays a critical role. “You need to turn your team/department/company into a machine,” Kevin explains. “The people who do that win, the people who can’t struggle.”
It’s not unusual to see turnover increase. Employees who thrived during the early days may not get the same rush as the company matures. The organization that once felt like a family starts to feel more like a corporation, and the charm of the early days is gone. Not everyone wants to stay. “My general rule of thumb is up until about $10 million in ARR, you probably turnover about ⅓ of your senior leaders,” Kevin explains. “When you go from $10 to 100 million, you probably turnover an additional third.”
Once you pass the Dunbar Number, roles and decisions become–appropriately–more formally siloed. “It becomes impossible for people to have the shared context or the sort of the singular context to make every decision within the business.” Because a positive outcome relies on continued acceleration, leaders need to be thoughtful in aligning key functions as the organization grows.
According to Kevin, the question you face at this point is: “How can you strategically start to align different parts of the business more? When your company was small, you might have had engineers sitting in a room building stuff, then it gets passed under the door to the sales team who are basically told ‘Go. Find people. Sell it.’ That’s not as workable when you need to close tens of millions of dollars of new bookings that quarter. You want alignment across teams. Then you can identify a big opportunity and work as a team. There’s a big, big market over here. We can attack it with this product, with this go-to-market strategy. We’ll train the sales team this way to go after it.”
As the product and engineering team exceeded 30 and then 40 people, Kevin and his Engineering counterparts found the agile-cross functional team structure started to break down. Kevin believed that restructuring his team would better meet the needs of the business.
The move to the Squad/Tribe model (popularized by Spotify) was based on the following observations about working in a now large company:
- 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.
Most of his current team now works within “product verticals,” corresponding to a key area of the company’s product or business. Prioritization within each vertical is relatively straightforward because each vertical corresponds to a specific set of customer needs. This reduces cross-team dependencies and allows each vertical to prioritize for customer use cases. Teams develop deep expertise and highly productive relationships. Kevin likes this specialization. He believes “product problems are fractal: each time you look closer, you find more nuance and depth. Spending many hours in a particular product area or codebase is one of the best ways to achieve real product breakthroughs.” But there’s no perfect system. With individual teams focused on product pillars, a company might lose sight of the more holistic priorities, so Kevin recommends dedicated committees that work outside these silos for broad projects and macro efforts.
Scaling a team from inception to IPO is no small feat. And as companies enter hyper-growth, change may be the only constant. Adapting processes and tools as your company evolves is both necessary and nuanced. There is no one-size-fits-all solution, but I do think it’s helpful to learn from the leaders who’ve made that journey.
Based on my conversation with Kevin, these are my parting words to rapidly-scaling product teams:
- Continually ask what’s working and what’s not.
Kevin’s story proved that processes, communication practices, and tech stacks will need to evolve as your team grows. By constantly thinking about what’s coming around the corner, it’s easier to make minor adjustments to the plan over quarters or years rather than being forced into jarring team reconfigurations all at once.
- Know when to make a change.
A singular occurrence may not warrant a change, but it’s time to act when a pattern emerges. Since startups move fast, you can gather many data points about people, processes, and situations, which means that you can make strategic or operational calls more quickly.
- Manage change thoughtfully.
Evolving how your team works as the company develops is critical. But, it can be hard on employees when their team structure or workflow changes. Communicating the reasons for change and explaining not just the benefits for the company but also the gains for individual team players—as Kevin did—will help maintain morale and keep everyone marching towards a common goal.
Thank you, Kevin, for taking the time to speak to me. The work, you and your team, have done at Braze is impressive. It was fascinating to pull back the curtains and see how you thought about team-building as Braze accelerated towards IPO.