Scaling Product Management: Strategic Investment Allocation

Editor’s note: This is the fifth part in a series on Scaling Product Management From Series B to IPO. Read the first, second, third, or fourth parts to catch up on what you missed.

In product orgs, constrained resources are a given—demand for engineering time will always exceed your team’s bandwidth. In this challenging macroeconomic environment especially, the strategic allocation of R&D investment matters more than ever.

While prioritization at the project- or feature-level is the responsibility of individual contributor PMs, it’s on product leadership to set the priorities that guide decision-making and ensure alignment across the org.

A successful PM org whose business is ready to IPO isn’t working in fire-fighting mode. They have a short- and long-term vision for product excellence—and a rock-solid strategy for achieving it.

In my previous roles as a product leader at SendGrid and GitLab, I had the opportunity to help set the product vision and strategy that saw SendGrid through an IPO and subsequent acquisition by Twilio, and guided GitLab through their IPO. Here’s what I learned about building a strategic foundation that’s solid enough to carry your PM org from series B through IPO and beyond.

Invest in strategic planning

When I joined SendGrid back in 2013, it had all the markings of an early stage tech startup—including a cultural aversion to anything reminiscent of waterfall methodology. Agile or bust, there was very little emphasis on medium to long term product planning.

While this worked back when our team size was small enough to pivot on a dime, it became problematic as the company scaled. As we grew, our teams became distributed and engineers specialized more. We were noticing cross-team dependencies emerging late in the development cycle and causing delays and general frustration. It was also very difficult to prioritize, as everything seemed like the top priority. Longer-term planning had become a necessity.

As young companies move towards IPO, creating a product plan that helps set long term direction and strategic priorities for the near term is crucial for continued growth at scale. But in order to reach future goals, plans need to be broken down and addressed in multiple time frames.

At GitLab, we created a set of layered plans for the 10, three, and one year time frames. Here’s what that looked like:

  • Product vision: At GitLab, we communicated a 10-year product vision that’s tied to the company mission. The vision outlines each area in which GitLab plans to expand, explains the surrounding context, and describes what success might look like. A good vision should be inspirational, ambitious, and vague about how you’ll get there.
  • Product strategy: We mapped our direction for the near future via a three-year product strategy. The product strategy outlines known challenges that are critical to address in the three-year period, including ways to avoid or mitigate their impact. Most importantly, it articulates specific strategies that contribute to the long-term vision and are actionable and relevant in the medium-term. A good strategy makes hard choices about what must get done and makes clear what is out of scope for the short term to ensure the company can focus on what matters most.
  • Annual themes: We also aligned on a set of annual product investment themes each fiscal year. Good themes are pithy, memorable, and provide a simple narrative about what matters most across the whole product line for the year. Themes help keep day-to-day priorities aligned with future goals and facilitate cross-team collaboration. Not every team’s mission will directly contribute to a theme. When a team working on a one-year theme needs to collaborate with others, the other team should regard thematic projects as higher priority than normal.

I prefer long-form written documents to slide decks or bullet point lists, as lots of nuance gets lost in formats other than prose. These documents should be socialized at all levels for feedback, communicated repeatedly, and treated as living documents that get reviewed and refreshed at least twice per year as necessary.

Allocate portfolio investments across three horizons

At some point, the first product will start to experience slowing growth, often due to a limited market size. Before you hit this point, you need to invest in new product areas that will help you extend your total addressable market (TAM) and lay the groundwork to continue growing rapidly in 2-5 years. At both SendGrid and GitLab, we managed our investments across three horizons, using the McKinsey Three Horizon Model as inspiration.

Horizon 1 is the investment bucket for the current product(s) that have reached maturity. In this bucket, it’s about investing enough to continue to deliver on the core value proposition, scale the performance, security, and user experience of the product, and decrease operating costs. As profitability rises, funds from Horizon 1 can be used to fund Horizon 2 and Horizon 3.

Horizon 2 is the investment bucket for the product(s) that have demonstrated early customer traction and are in position to grow faster than the company average. These product(s) should be run more like a series A startup, where fast growth matters more than profitability.

Horizon 3 is the investment bucket for incubation. In Horizon 3, it’s about learning fast and knowing quickly whether to continue or shut down an early stage product concept. Horizon 3 projects should be managed like a seed stage startup, with specific gates to demonstrate customer traction. If suitable traction isn’t quickly discovered, then projects should be shut down to avoid wasting time & investment capital. If traction is demonstrated, then Horizon 3 products can graduate to Horizon 2 and receive increased investment to fund rapid growth.

The investment allocation will vary company to company, but something like 70/25/5 is a typical split between the three horizons.

Prioritize product investments with a scoring framework

GitLab is a huge product, covering over eighty market categories. Our 40 product teams were packaged into ten stages that contribute to DevOps. How did we decide which stages to invest in?

To answer this question strategically and more objectively, we had a rubric we used to assess the investment opportunity for each DevOps stage. The three investment drivers we used were as follows:

  1. Product usage driver: A measure of the number of active users per month
  2. Revenue driver: A measure of the contribution to revenue
  3. Served Addressable Market (SAM) driver: A measure of the size of the market that the product can serve over the next three years

Each driver was scored on a one to five basis, with each scoring level having a specific definition. With a rubric in hand, you can score an area—in GitLab’s case, a DevOps stage—along these three driver dimensions, add up the scores, and compare and contrast scores for different areas. Higher scores indicate reason for more investment, whereas lower scores may identify areas that should be deprioritized.

At GitLab, we leveraged this scoring system to help align on moving from a fairly evenly “peanut-buttered” investment approach to consolidating 80% of spend across four of the 10 stages. Although we began with the scoring framework, there was nuance in how we interpreted the results. You can’t just rely on what a formula spits out at you—you have to use this information as an input to make your own choices.

Use strategic inputs to operationalize your investment allocation

Once you have some combination of a three-year product strategy, annual product themes, three horizon investment allocation targets, and investment allocation scores, you will have a lot of inputs to help determine your final investment of R&D resources. The challenge is then to operationalize the changes so your R&D organization is aligned to the product investment strategy. This is typically challenging, however, as moving humans between teams oftentimes creates personal stress, disrupts team chemistry, and slows down velocity.

We executed a large number of these transitions while at GitLab, and here are some best practices I learned to minimize the human impact from these necessary but tough changes.

  • Explain the why. Leverage the work you’ve done on strategy, themes, horizons, and investment scoring to explain why the change is necessary and good for the company.
  • Invest heavily in detailed and clear communications that come jointly from the Head of Product and the Head of Engineering. Think through the questions the team will have, and write up thoughtful responses to anticipated questions.
  • Host live sessions to allow people to hear directly from you and ask questions.
  • Leverage all people managers to double down on the transition communications, have 1:1 discussions with each impacted person, and check in regularly on how team members are doing.
  • If possible, enable people to opt in to switching teams first before dictating that people move.
  • Accept that velocity may slow down in the short term as people shift between teams and learn new technical domains.

Key takeaways for product leaders and founders

  • Invest in strategic planning. Start with a 10-year product vision and work backwards to map it to a 3-year product strategy. Use the product strategy to identify 1-year themes to help guide teams in their day-to-day and facilitate collaboration.
  • Allocate investments across three horizons. Find the right balance between investing in profitable core products (H1), high growth new products (H2), and incubation (H3).
  • Prioritize product investments with a scoring framework. To identify investment opportunities, assess product areas across three drivers: 1) product usage, 2) revenue, and 3) served addressable market. Use a rubric to set objective standards and attribute a score for each driver. Areas with higher score totals indicate greater opportunity.
  • Use strategic inputs to operationalize your investment allocation. Now leverage this strategic work to align the R&D organization against the highest priorities. Use thoughtful communication to help execute seamless transitions and minimize the switching cost to the humans involved in reallocations.
Scott Williamson
Scott Williamson
Product Advisor

Scott Williamson is a Product Advisor, helping B2B SaaS companies scale their products through periods of high growth. Most recently, Scott was Chief Product Officer for GitLab, where he led a team of 65 in Product Management, Product Operations, Growth, Pricing and Corporate Development functions. Prior to GitLab, Scott was VP of Product for SendGrid over a six year period, where helped lead the company to a successful IPO and $3B acquisition by Twilio. Scott lives in Boulder, CO with his wife and two teens. Outside work and family, Scott enjoys training for and competing in Olympic distance triathlons.
You might also like ...
Pricing & Positioning
Scaling Product Management from Series B to IPO: How to Optimize Your Pricing & Packaging
Editor’s note: This is the fourth part in a series on Scaling Product Management From Series B to IPO. Read...
by Scott Williamson
Product Management
Scaling Product Management From Series B to IPO: Establishing a Customer-First Org
Editor’s note: This is the third part in a series on scaling product management from Series B to IPO. Read...
by Scott Williamson
Product Management
Scaling Product Management: How to Hire and Build High-Performing Teams
Editor’s note: This is the second part in a series on scaling product management from Series B to IPO. Read...
by Scott Williamson