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 the first, second, or third parts to catch up on what you missed.

What’s a signal your pricing is off?

If the price point is too high, you’re losing share. You may be seeing a decline in your growth rate or an increase in your competitive loss rate. If it’s too low, you’re suffering from bad unit economics. Maybe you’re attracting a customer segment that incurs a lot of costs but doesn’t generate enough revenue, or you’re flat out under-priced and leaving money on the table. You might also have a pricing metric that doesn’t align with customer value, or packages that don’t align with clear customer segments, which can limit new customer revenue.

Just like your product itself, pricing and packaging should be reviewed and updated on a regular basis to avoid these downfalls. Getting a pricing change out the door involves a degree of complexity, collaboration, and risk that will likely make it one of the company’s biggest undertakings of the year—far more so than a typical product release.

I led a couple of major pricing changes during my time as CPO at GitLab and VP of Product at SendGrid. In both cases, they took quarters to execute. Both were high risk, and both took a long time to get alignment on how to approach the risk and navigate the details. Given those experiences, I would estimate at least a quarter, if not multiple quarters, for an end-to-end pricing project duration.

Why pricing is so hard to optimize

This won’t come as a surprise—pricing becomes increasingly hard to change at scale. Once you have a material amount of revenue and customers paying a certain price, your pricing and packages develop an inertia. Mature companies undergoing a pricing change are likely to experience friction in three areas:

• Handling risk: Adjusting pricing puts the revenue stream your company depends on at risk. That’s why getting agreement from leadership to even consider a change can be so challenging. Sales wants to be sure they can hit their target, the CEO wants to make sure they can meet expectations, and nobody wants to make a mistake.
• Navigating complex systems: To actually implement a pricing change, you need to change the website, the pricing page, your backend systems, and probably even the product itself. It’s a complex initiative that touches numerous areas of the business—if not all of them.
• Reconciling lack of expertise: It’s fairly common for internal teams to lack pricing experts. Either companies choose to proceed with uninformed decisions based on gut intuition rather than intentional research, or they never make any new pricing decisions to begin with, because they aren’t confident that they have enough data.

It can even be overwhelming to decide where to focus your pricing efforts. You might consider topics like:

• Redesigning packages for different target segments
• Clarifying the value drivers in each package
• Adjusting the pricing metric
• Finding a better balance between fixed packages and usage-based pricing
• Aligning the price point with people’s perception of value

Regardless of where you focus, there are five foundational steps for optimizing your pricing and packaging.

Step 1: Instrument the full customer journey

Identifying your target customer segment and anchoring the purchasing experience in how they want to buy is the first step to understanding the customer journey.

If you’re selling straight to developers, they likely expect to self-serve. On the other hand, if you’re selling to a larger, more complex company where multiple departments are involved in the buying process, you’re probably going to need a sales-led motion.

From here, you need to instrument and mirror the full customer journey—from awareness to sign up to onboarding to hitting that aha moment—in order to identify drop-offs and then fix them with user experience or packaging and pricing improvements.

Building an accurate customer journey funnel requires someone to pull data together from several different sources—marketing attribution, website tracking, customer revenue data, and product analytics. When all this data sits in different silos, and separate teams own different phases and systems, pulling everything together into a unified view of the customer journey can be hard. It’s worth the effort—this step is necessary for driving the go-to-market alignment that will serve as the foundation to the entire pricing project.

Step 2: Target each package at a clear buyer segment

At GitLab, we had a “buyer-based” pricing model. Our Free product tier was targeted at individual developers, our Premium tier was for team leads, and the Ultimate tier was directed at executives.

Whenever the product team built something new, we’d ask ourselves “who cares about this the most?” If it was the executive, it should go on the Ultimate tier. If it was the individual developer, it should go in the Free tier. Considering that the GitLab product org was shipping an average of 50 new enhancements or features each month, having this framework helped us make good packaging decisions at scale and across a large team.

By having a clear buyer target for each package, you can also steadily build value for that buyer, and when they look at your package lineup, it’s clear which package is for them. In the absence of a clear buyer target for each package, the rationale for what should be in your Good / Better / Best packages can be quite murky, and you may end up with packages that don’t match a buyer’s needs, expectations, or perception of value.

Step 3: Adopt a value-based pricing philosophy

When I first started at GitLab, we had a $4 per user per month Starter tier. This was introduced back when GitLab was an open source alternative to GitHub, and the value perception of the product was weak relative to the competition. At $4, the Starter tier was less than half the price of GitHub at the time, making it attractive to get started on a paid tier with GitLab.

Fast forward five or six years, and GitLab had a credible lead over GitHub in terms of building out a full DevSecOps platform. We believed that the value perception for our product exceeded that of this competitor, so there was no longer a need to undercut them on the low end. We decided to remove the $4 Starter tier because we felt like starting at $19 more accurately captured the value of GitLab. (Note: GitLab has since raised the price of the Premium tier again to $29 as the perceived value of Premium has continued to increase due to consistent innovation and maturation of the product.)

Even after this change, there was still a major gap in price between the Premium and Ultimate tiers. With Premium costing $19 and Ultimate coming in at $99, Ultimate was priced at five times more. Being able to use GitLab across a whole development organization and unify the whole team on one tool is extremely efficient and valuable to leaders.

Sid, the CEO and owner of pricing at the time, sensed that the perceived value to an executive buyer was a lot higher than the perceived value to a team leader, which is what contributed to the 5x delta between Premium and Ultimate. By pricing Ultimate at $99, over the ensuing years we were able to add considerably more value to the Ultimate package, and materially increased the Average Selling Price (ASP) for GitLab.

Step 4: Invest in pricing research

Pricing research is most critical when risk is high. When you’re in a situation like I was at SendGrid or GitLab, there’s a lot of money at stake and a lot of current customer behavior to analyze. Investing in rigorous research—either internally or externally—allows you to test proposed pricing changes before launching at scale and can help you make a high-confidence decision.

Oftentimes, companies don’t have the skills or the bandwidth to run pricing research in-house. It requires a fairly niche skill set with a lot of technical expertise. Certain research techniques that have been proven to be effective for pricing research are not something that every product professional understands.

At both SendGrid and GitLab, we chose to build in-house pricing teams so we could make frequent pricing and packaging optimizations. The pricing team was run from the Product organization, and in both cases we started with a relatively senior individual contributor who could eventually scale to build out a pricing team. As that person established the function and proved its worth to the organization, we built out a small team to run more projects simultaneously.

In addition, we hired third party firms to help with super strategic projects. These firms have large organizations, access to large buyer/user panels, and sophisticated pricing analysis methods and tools. These services can be quite expensive, but if you consider the leverage you get out of a pricing change done right, in my experience at least, they’ve proven to be good investments. The research, however, is only one piece of the puzzle. You need to combine the research results with your own understanding of the context to make a good decision.

Step 5: Build financial models to inform decisions

Major pricing decisions when you’re approaching IPO are typically one-way doors—regardless of the outcome, you’re probably going to have to live with it for a while. Since they can’t be easily reversed, it makes sense to have data inform your ultimate call.

To do this, you’ll need financial data like revenue, churn, up-tiering, and average selling price. You’ll also need to be able to cut up the data by different customer segments and cohorts—and layer product usage data on top.

Next, you need a model that reflects the variables that you want to use to make a pricing decision and forecast what might happen. Typical variables that you’ll want to be able to adjust are new customer acquisition rate, churn rate, up-tiering rate, discounting rate, and average selling price.

Before making the decision to remove our lowest paid tier at GitLab, we built a model that showed revenue streams and customer behavior for each tier. This model allowed us to imagine a world where the Starter tier didn’t exist, and align with the assumptions we were making about what might happen in this new world. We developed worst case, expected case, and best case scenarios. After we projected everything into a well-built model, the data suggested that removing the lowest paid tier would result in a net positive change for us—which turned out to be true.