As a company grows, scaling a product organization becomes exponentially more complex. Should you double down on your existing product and market with richer offerings and more price tiers? Or should you expand to an adjacent market? Perhaps a new use case for a new market segment? Or create a new product? How should your team organize and plan? Could a product ops role help eliminate silos and improve team efficiency? When a company grows from under 100 employees to 300, 2,000, or 10,000+ employees, each stage faces unique challenges.
In this post, I’ll share learnings from scaling a product organization and building and rebuilding engineering teams at companies like PayPal, Shutterfly, Bigcommerce, and Feedzai during their various scaling phases.
Specifically, this post will cover five topics:
- When it’s time to review the “scaling problem”
- How to organize your product teams
- How to apply a portfolio approach to managing product
- When and how to adopt a multi-tiered planning process
- Why you need a source of truth for everyone, not only product teams
When Does the “Champagne Problem” Start?
“Looking back, we should have addressed scaling way earlier,” said Eddie Machaalani, co-founder of Bigcommerce,
When should you start thinking about scaling?
When your engineers can’t fit in the same room!
– Eddie Machaalani, Co-founder of Bigcommerce
That’s at about 20 engineers or 4 scrum teams. Sharing and collaborating between teams starts to require more deliberate effort to prevent silos and loss of context.
In addition to the size of the team, the scaling challenge becomes more prominent once a company reaches product-market fit. Customer growth creates use case expansion, making it much harder to prioritize. And it’s also when the tech platform needs to be revamped.
Some founders call it the “champagne problem.” Nevertheless, it’s still a very hard problem.
One of the first things to tackle is the structure. Not the HR-related structure, but the structure of collaboration nodes. Consider when it makes sense to introduce a product operations manager to “PM the PM experience.”
How to Organize Your Product Teams
There are a few ways to organize your product and engineering teams:
- System component/ product area, e.g. web, mobile, data platform. This matches well with engineering expertise.
- User journey – such as onboarding, using, and reporting.
- Persona (aka vertical) like merchant, consumer, operations.
- Goals/ outcomes e.g. growth, retention, scalability, innovation.
All of these structures have pros and cons, especially if you stick to one type for too long.
In an output-focused organization, the stable team is highly valued to reduce the learning curve and increase delivery velocity.
In an outcome-focused organization, the internal mobility and flexible team is more valuable in bringing new ideas and learnings from one part of the organization to another.
Sean Kane, VP of Engineering at Upwork
Additionally, initiatives are often carried out by multiple teams, regardless of how the teams are structured.
What I’ve seen work best is a hybrid structure with more periodic changes.
For example, organize by goal/ outcome with the semi-permanent structure of component/ system. This way, goals are aligned within the same “temporary” team while there is still some technical/ domain continuity for fast ramp-up.
At Bigcommerce, initiative teams were built with engineering pairs (semi-permanent structure by component/ system) and adjusted every 1-2 quarters depending on the needs of the business and product.
How do you decide on the formation and size of these initiative teams? This takes us to the product portfolio management approach that every scaling company needs to adopt.
How to Apply a Portfolio Approach to Managing Product
“Portfolio? We only have 1 product.”
– Anonymous Founder
If you still think a portfolio approach only applies to companies with “many products”, check out the responsive product portfolio management framework.
A digital product is often a “bundle of multiple products” for different personas, or to achieve multiple goals. For example, a marketplace has buyers, sellers, and other players.
The responsive product portfolio management (Responsive PPM) approach allows you to categorize all the things you want to do as a portfolio of investment categories. You’d allocate various amounts of resources to these buckets at different times to produce the best outcome for your company within that time frame.
To learn more, read about the rock, pebble, and sand portfolio management analogy.
In a responsive portfolio framework, you may also evaluate your product portfolio across multiple dimensions including goals, products and customers. For example, the goal dimension of the portfolio has buckets like growth, retention, cost; and the product dimension of the portfolio has buckets like core expansion, new use case/ solution, new market, etc.
The portfolio approach has an influence on how your teams are structured. At Feedzai, when there were about 20 product engineers, we broke the product team into a Platform team for the original core product and multiple solutions. This gave each of the product leaders a focus on their “permanent” structure. At the same time, goals were set and adjusted from time to time, due to the nature of the market, product, and business.
As soon as you hit product-market fit, the product team should start discovery on the next product or extension, as it takes time, trial, and error to find one that may work.
– Saurabh, Chief Product Officer (CPO) of Feedzai
An effective product organization assesses and adjusts the team structure periodically to balance the needs of the portfolio. This leads to the next topic – tiered planning.
When and How to Adopt Multi-Tiered Planning
Many people think problems such as chaos and misalignment are unavoidable growing pains. However, they are often addressable problems.
Eddie Machaalani, co-founder of Bigcommerce
First, leaders need to adjust their perspectives as the company grows. At a smaller company, leaders commonly keep tabs on the company through day-to-day scrums and one-on-one meetings. As the company grows, it’s necessary to have separated vantage points.
A scaling company has 3 levels of vantage points – the executives focus on the long-term vision, while the teams focus on bi-weekly sprints. The VPs and directors are the ones to align both executives and with each other on how to achieve the long-term vision before they can empower their teams to move towards the direction that the whole organization is moving towards.
These 3 levels of focus naturally lead to the 3 levels of planning cadence – annual, quarterly, and bi-weekly.
And they are not just once a year or once a quarter type of events. Just like scrums have daily stand-ups after sprint planning, quarterly planning is accompanied by weekly or bi-weekly check-ins.
Aligning on the strategic focus (also called “bets” or “big rocks”) in the annual cadence is critical to setting the direction of the company. It could be growth via acquisition strategy at Shutterfly, or growth via expansion in LATAM at PayPal. These strategic bets set the direction for quarterly initiatives.
The quarterly planning focuses on both the breakdown of bets and the adjustment of the focus for the next cycle based on outcomes from the previous quarter. Allocation to various portfolio buckets is evaluated as a guideline for prioritization within each bucket. High-level resource needs and dependencies are identified and addressed before they hit teams to prevent “agile madness”.
Why Do You Need a Source of Truth for All, Not Only Product Teams?
Product and engineering teams tend to be more self-reliant and don’t mind using spreadsheets and decks. But this approach is not only time-consuming, it delays the access and accuracy of information to the rest of the organization. Chaos and misalignment happen when product teams “hoard” information. Oftentimes, features were delayed or even canceled while marketing, sales, or support continued with their motion unaware of the change. Or the same feature may have different names in different decks, emails, or other channels causing major confusion across areas.
The first change all scaling companies should make, if not one already in place, is having product operations develop a source of truth on the product roadmap. What will be available, when, who can be reached for more information, and what’s planned but not committed yet are all important for the organization to know.
The speed of access to information directly correlates to the speed and quality of decision-making.
The Scaling Mindset
In personal growth, there are phases of the leadership pipeline: managing yourself (individual contributor), managing others (manager), managing managers (director), functional managers (VPs), business managers, etc.
As the company grows through its first 50 people, there are ICs and managers. When it hits 100+, the managers will need to grow into Director level roles, and some ICs would have to grow into manager-level roles. By the time the company hits 300 people, another round of collective growth is needed for directors to grow to VPs, and managers to directors, and so forth. Because each of these leadership level transitions requires significant adjustment on perspective and focus, scaling is difficult.
Process, organization, cadence, mindset, and tooling are all critical parts of scaling. At key stages of a company’s scaling, leadership must adjust all of these parts to work well in the new phase. While a tool does not solve all problems, a good tool enforces best practices. A good agile tool helps the engineering team to practice agile, whereas a good Responsive PPM tool helps the product organization to become an outcome-focused responsive organization.
