Scaling Product Management From Series B to IPO: Establishing a Customer-First Org

May 25, 2023

Editor’s note: This is the third part in a series on scaling product management from Series B to IPO. Read the first and second parts here and here.

A successful organization—product and otherwise—is laser-focused on the customer. When this focus gets lost, that’s when you notice issues like the following creep up:

  • Inconsistent product experiences
  • Low NPS
  • Declining UX, and
  • Poor user and/or customer retention.

When it comes to scaling from Series B to IPO, getting customer-focused most often looks like pursuing the right problems and projects. As a company grows and stakes rise, there’s less room for error. Where you invest your R&D time matters—and you’re going to want to choose the investments with maximum impact. Establishing a customer-first org increases your chances of making the right choices.

In my own experience as VP of Product Management at SendGrid and CPO at GitLab, I’ve seen firsthand how maintaining focus on the customers and users results in a product that can withstand the strain of hypergrowth. And what customer focus really comes down to is:

a) knowing who you’re building for, and
b) building things that effectively solve their problems.

To get both right, you need to establish a problem and solution validation framework, interview customers, avoid shipping your org chart, and use validation findings to say no with confidence.

1. Establish a problem and solution validation framework

At both SendGrid and GitLab, we established a clear problem and solution validation process which guided what we built—and what we didn’t. Only once we were confident that a proposed solution would effectively solve an acute customer problem could development begin.

If we didn’t have that confidence, we needed to continue the validation process or scrap the idea.

At GitLab specifically, we broke our product development flow into two tracks: validation and build. Although these two tracks move independently of each other, a major project or feature cannot enter the build track until it successfully passes through validation. According to the GitLab handbook, the goal of the validation track is to:

  • Understand the user problem we are trying to solve
  • Identify business goals and key metrics to determine success
  • Generate hypotheses and research/experiment/user-test
  • Define the Minimum Viable Change (MVC) design pattern and potential future iterations
  • Minimize risks to value, usability, feasibility, and business viability with qualitative and quantitative analysis

For problem areas that are new, large, or not well understood, PMs work together with UXers to deeply understand the problem. This phase typically consists of conducting at least five problem interviews with target users, and then capturing a one-page summary of the project in an Opportunity Canvas, which is reviewed with product and design leadership. Approved canvas reviews proceed to Solution Validation.

In Solution Validation, designers take the lead by creating a right-fidelity prototype to envision a solution to the problem. Then designers and PMs conduct at least five more interviews with target users to validate that the prototype design sufficiently solves the user’s problem. From there, the project enters the Build Track.

2. Make customer interviews top priority

In my first 18 months at SendGrid, I met with ~100 customers. For my first two quarters at GitLab, I made the “number of completed customer interviews per PM” one of the product organization’s OKRs. This gave me and the product org a solid foundational knowledge of who our customers were and what they wanted. This research informed our org level development priorities, allowed us to share valuable insights across teams, and built up our credibility.

Keep in mind—time spent talking to customers can be time wasted if you aren’t intentional about what you need to learn, or if you don’t follow qualitative interviewing best practices. Conducting high quality interviews is an essential PM skill, so at SendGrid the whole team participated in a qualitative interview training by Cooper Design, and at GitLab most of the team took an excellent remote course called Continuous Interviewing from Teresa Torres. Getting the entire team up to a proficient level with customer interviewing paid enormous dividends, as each team member was able to maximize the quality of insights from precious customer interviewing time.

Interviewing best practice suggestions

I prepared for these interviews by composing a list of questions to go through with each customer. This consistency allowed me to cross-check insights across interviewees. If multiple people all bring up the same thing, that’s a good indication that their sentiment might be shared across a much larger customer segment.

Other best practice suggestions include:

  • Ask open ended questions and avoid yes/no or leading questions
  • Ask them to describe what they’ve actually done, rather than what they intend to do
  • For problem interviews, avoid pitching your solution to the problem until the very end, if at all
  • For solution interviews, bring an interactive prototype and ask them to solve the intended problem using the prototype without any guidance or prompting, and talk out loud about their feelings on and reactions to the experience
  • Reassure interviewees that negative or harsh feedback is OK and not to worry about insulting you

Removing friction from interview logistics and scheduling

One reason many PMs don’t conduct enough interviews is that it’s hard logistically to identify, source, schedule, and conduct customer interviews. Do everything you can as a product leader to remove friction from the process for team members. At SendGrid and GitLab, we chose to hire a UX Coordinator, who helped with sourcing and scheduling customers for interviews.

If you can’t hire a dedicated person to help, consider other ways to automate or simplify the process, such as maintaining a database of customers/prospects willing to be interviewed, enabling customers to sign up for interview slots directly in the product, or having Sales/Customer Success line up interviews for the product team.

3. Don’t ship your org chart

When a company lacks a repeatable validation process, it’s much easier to build things that don’t matter. One thing I see often is PM teams begin to ship their org chart. What that looks like is when you build a product that’s optimized for whatever area you own, without taking the customer’s use case(s) into account.

When I was at CA Technologies as a senior director of product management, I was part of a new business unit that was formed from the convergence of four product areas. Our goal was to help customers understand why this business unit existed, and we really wanted to drive synergy between these four product lines. We cooked up an idea that we thought would solve all our problems.

It looked great on paper. It clearly explained why the business unit existed, and it seemed like something that would be interesting for a customer. Then, we envisioned a product feature that pulled it all together, and immediately set out to build it.

The integration didn’t drive cross-sales like we intended. Nobody used it. Because nobody cared. They never asked how the four products would work together. Did it solve a real problem for them? The answer was no.

Focus on the use case, not your internal structure

If you have each product manager looking at their own slice of the product, seams begin to show between teams. As a PM or a designer, you’re incentivized to drive outcomes in the area that you own—not necessarily a broader outcome across the product as a whole. When this happens across product divisions, you end up with a product experience that feels disjointed.

At GitLab, one of our key features was called the merge request, and multiple teams were contributing to it. At one point, we realized that this feature’s performance had gotten slow and suffered from cluttered UX. We had a UX research team audit the merge request feature with specific instructions to ignore team boundaries and focus on the use case.

The team built a user journey map which pinpointed good and bad experiences within the user journey. Then, we were able to farm out the poor experience fixes to the teams that owned them and over time improve that end-to-end experience by focusing at the use-case level.

4. Use the validation process to say no with confidence

At SendGrid, we ran a tight ship. The business was scaling at hyperspeed, requiring the product to deliver billions of emails per day. In that environment where every aspect of the system needs to scale to enormous levels, engineering had a “measure twice and cut once” kind of mentality. Having that level of rigor and scrutiny meant that the development process took time and required the product org to be very selective about what we asked engineering to build—thus we discarded things early that otherwise might have consumed a lot of our development team’s time and energy. On the problem front, only about half passed the validation process.

As an example, one executive asked us to upgrade our self-serve purchase flows to accept multiple currencies. This person had run a similar project at a previous company and saw a lot of success. We got to validating the project and interviewed potential customers in various countries where we thought we might want to offer local currency. What we learned is that paying in U.S. dollars wasn’t an acute pain point. Most of our customers were fluent in English and were used to buying things with credit cards in USD.

Sure, it would’ve been a nice feature to accommodate additional currencies, but we found that the current setup wasn’t materially impacting people’s purchasing decisions. They were just going to buy the best product. The incremental revenue from offering additional currencies wouldn’t have been worth the expensive price tag to implement, so we said no.

Key takeaways for product leaders and early-stage founders

  1. Commit time to getting to know your customers. As a product leader, having a deep understanding of who you’re building for and their problems will not only help guide executive-level priorities, but it will build your credibility across your teams.
  2. Run large projects through a clear problem and solution validation process. Especially at scale, you don’t have the time to build something your customers don’t care about, or launch a solution that doesn’t adequately address their problems. A validation framework entrenches customer focus in your PM org culture.
  3. Don’t ship your org chart. Instead of building a product that’s optimized for whatever area your team owns, focus on the customer’s use case(s) even if that requires contributions from multiple teams.
  4. Use your validation process to say no with confidence. The more scrutiny you can have with what projects and features you pursue, the better. Having an established validation process to point back to can help you communicate your decision-making to other teams.

Keep an eye out for the next installment of the Scaling Product Management series. Subscribe to the OpenView newsletter and connect with me on LinkedIn to be the first to know!

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.