PLG and Product Management: Tips from SendGrid’s VP of Product


This post is by Scott Williamson from Openview Labs


Click here to view on the original site: Original Post




There are a lot of moving parts to manage a product. In addition to building the actual product and figuring out the best way to get it to market, you also have to prioritize your roadmap, understand the tradeoffs between building new features and optimizing for growth, wrangle pricing, and—as your business and user base evolves—potentially figure out how to successfully launch a new product inside your existing company. It’s a lot to juggle. I’ve had the benefit in my career of working with two distinctly different kinds of companies, one that used a more traditional sales- and marketing-led go-to-market strategy, and one that employed a strongly product-led approach to growth (PLG). At CA (which acquired a startup called Wily Technology), I worked on a single, complex and costly product that was sold to enterprise IT shops with heavy direct-sales involvement. At SendGrid (recently acquired by Twilio
the approach is the exact opposite—a product-led, self-serve model with a much lower price point. Over the years—10 with Wily/CA and 6 at SendGrid/Twilio—my various roles within these organizations taught me some invaluable lessons on a wide range of product-related topics.

PLG – Not Just About Growth

PLG is an enormously effective (and increasingly popular) way to sell a SaaS product, but it only works in certain circumstances and with certain kinds of products. The complexity and price point of the CA product, for instance, required us to engage in a long sales cycle that involved partnering a highly-paid sales rep with a highly-paid sales engineer who could talk about integration into the client’s environment. SendGrid, however, was designed to sell itself, and this was possible because the product was much simpler and the price point was much lower. The dynamics of each scenario create a ripple effect into other areas of the company including things like R&D spend, staff allocation and your product road map.

R&D

If your go-to-market strategy requires a heavy direct sales investment, then the envelope you have to work with for R&D spend tends to be smaller. At CA we spent approximately 15% of revenue on R&D for my particular product line (Application Performance Management), while at SendGrid (where the PLG approach kept us from needing to make such a steep investment in sales) we were able to invest approximately 25%+ of revenue on R&D.

Staffing Allocation

There was also a corresponding difference in the ratio of engineers to product managers based on the demands of each go-to-market strategy. At CA, the ratio of engineers to product managers was 20:1 and we had to share a pool of designers. At SendGrid, we have a 6:1 ratio of engineers to product managers and a 1:1 ratio between designers and product managers. As you can imagine, the variance between the makeup of these two teams creates two very different product development experiences.

Product Road Map

Another area in which these two models vary greatly is who has influence on the product road map, and to what extent. At CA, where the client roster was relatively small, but comprised of very large companies, a single customer could have an inordinate amount of influence over which features we added to the product. When you have a single customer that’s paying you $60 million over the course of 8 to 10 years, you tend to listen to that customer and feel obligated to cater to their needs. The problem with this is that it can very quickly lead to feature bloat, which ultimately leads to long-term subpar product results. SendGrid, on the other hand, has about 80,000 paying customers, and even our Top 10 largest customers represent only a small percentage of our total revenue. Because revenue is spread out over a large number of smaller clients, no one customer can tank our quarterly financial performance. Just as importantly, having a widely distributed customer base means that we can listen broadly and focus on implementing features that benefit the masses instead of the few. While it’s natural to pay more attention to your larger customers, best practice is to focus your efforts on doing things that the majority of your customers will understand and appreciate. We’re pretty ruthless at SendGrid about fighting unnecessary complexity. Our self-serve audience needs to be able to grasp the user experience immediately without the support of a sales team, so we need to be very careful about any changes we make. One way we’ve found to compromise in situations where a larger customer is insistent about a particular feature is to turn it into a service offering for high-end customers. This allows us to keep the core product free of feature bloat that would confuse and annoy our primary audience. It also gives us the opportunity to monetize more complex services.

Development Priorities – Product versus PLG Engine

A question that often comes up for PLG companies is how to prioritize product development against development of the PLG engine that drives acquisition. It’s a question that can feel a little like a chicken-and-egg quandary, but if you look at it through a different lens, things clear up pretty quickly. At SendGrid, because 98% of our customers come in through our self-service engine, we view the website and signup flow as part of the product, not separate from it. We have core engineering teams that focus on those parts of the customer experience and how they roll up through the product. This holistic approach allows us to consider all aspects of the user experience together—from the time someone visits the website or looks at our docs all the way through to purchase and engagement. And at each step in that journey, our primary goal is to remove friction. Overall, we prioritize tasks and projects within this holistic view using the RICE system—reach, impact, confidence, and effort. And we look at projects in terms of potential outcomes, comparing potential project-to-project results. This gives us an objective method by which to rank importance. Using this approach, we consistently prioritize smoothing out the onboarding process at least as highly as adding new features. We also invest heavily in foundational things like scaling up and making sure we have the security, availability, and APIs, etc. we need to be able to deliver on our original brand promise. We know both these areas have very strong ROI for the company. Our formal growth team is comprised of three teams that together manage our acquisition funnel.
      • Our revenue marketing team handles demand generation to fill the top of the funnel. They’re involved in SEM, SEO, and brand building through various web channels to ensure our customers can find us.
      • Our website team is in charge of the initial experience—how we present the product including pricing and our signup page. This is where the whole flow and customer experience begins, so it’s critical to have a team focused on these areas.
      • And then our growth engineering team manages the signup funnel and things like in-app messaging and running tests and experiments to reduce friction as people move through the funnel.
The three teams meet on a weekly basis, review funnel metrics, and prioritize tasks. They define and drive small projects to make incremental improvements at each stage of the customer journey, and consistently chip away at those objectives.

New Products – When and Why to Build Them

Another common question—and a super hard one—is whether it’s a good idea to build a new product and, if it is, how to do that. It’s an inevitable question because, at some point, any fast-growing company is going to need to expand. Though every case is unique, in general you need to be really careful about this question because any time you introduce a new product, it distracts from your original one. You need to pick your moment. And you need to realize that the question is going to open a Pandora’s box of other debates, such as whether you’re building a platform or an application. The platform versus application debate was in full swing when I joined SendGrid. More precisely, leadership was asking whether we wanted multiple developer tools sitting next to email, or to be an email communications company. Those are very different paths, and each one had the support of about 50% of the company. Ultimately, we zeroed in on being an email communications company, and that drove the decisions that followed. In terms of new products, we built two: Marketing Campaigns and Services. The decision to develop Marketing Campaigns was driven by customer needs. Like our core product, our email API is targeted at technical developer types, but we saw a need for a way to enable the nontechnical part of the company to also be able to use SendGrid. Companies wanted to aggregate all their email functions into SendGrid, so we needed to give them a way to do that. Market dynamics also played a role in our decision to move ahead with Marketing Campaigns. Our core email infrastructure market is modestly sized, and we knew it couldn’t continue to sustain 30%, 40%, or 50% growth rates. Marketing Campaigns allowed us to tap into an adjacent market called email marketing, which is five to six times larger than email infrastructure. The combination of filling a customer need and simultaneously giving ourselves more market headroom to accommodate rapid growth made this decision a no brainer. The other product we developed was Services, and it came about for different reasons. Rather than increasing market size, Services allowed us to improve customer outcomes for clients in our existing market. As an added business benefit, customers who use Services tend to be stickier and have better retention. They spend more with us over time and tend to have a higher NPS. Before implementing Services, we were essentially giving a lot of that away via our support and our customer success teams. The approach we chose allowed us to improve customer outcomes and our incremental revenue run rate at the same time.

New Product Build – Four Big-picture Strategy Tips

If you do decide that it’s the right time to build a new product, you can save yourself a lot of trouble if you keep a few things in mind.

Make the project a priority.

First things first, when you make the decision to move forward, make sure that everyone—from the CEO down—knows the project is a priority. In our case, SendGrid’s CEO made it very clear that we needed to invest “disproportionate energy” on the project in order to succeed. If you aren’t really clear about this, people will be unsure if they should divert resources. We actually created a company within the company, kind of like a mini business unit. This helped give people a shared sense of purpose, ensured better lines of communication between all the key players, and gave us a familiar way to hold everyone accountable.

Invest in high-end project leads.

Take care to invest heavily in a really high-end architect, engineering manager and PM. You want people who have experience on the kind of project you’re working on. It doesn’t have to be the exact same thing, but at least something of a similar scale and level of technical challenge. You want to be sure that your team has the expertise to be able to guide you through the process and help you avoid the pitfalls.

Use an iterative launch strategy.

Instead of trying to do everything in one go, break things down into iterative developmental milestones and create a plan that clearly defines what you want to accomplish during each phase. This way, you’ll know how big the task is, you can hire the right size team (with the right skills), and make sure you have an appropriate checkpoint to review whether you’ve done what you intended, are getting the traction you expected, and so forth. Having these incremental check points allows you to manage the build, testing and release processes much more effectively.

Get everyone on board with the launch.

Finally, once you reach the go-to-market phase, you need to circle back to the idea of making the product a priority across your entire organization. Failing to do this can leave your new product floundering. In one case, we didn’t know the new target user or market well enough, and we didn’t do a great job of convincing the company that this was an effort we needed to prioritize. As a result, in the early days our sales team was afraid to sell the product and our customer success team was afraid to recommend it. Everyone was tiptoeing around it because it was new and we didn’t have the information and training we needed to put it out there with confidence. Once you’ve launched the product, there are two success indicators you can always rely on to let you know how things are going. First, money talks. If the market is responding well to the product—signing up, sticking around—and you’re hitting your projected milestones, you’re likely in good shape. The other signal is internal buy-in. At SendGrid, we developed a multi-hat marketer target persona for Marketing Campaigns named Olivia. We knew things were coming together when we started hearing people in customer support or sales talking about Olivia. When your teams begin internalizing the target user, market and competitors, you know things are clicking.

Pricing – Something to Invest In

Finally, you can’t talk about product without talking about pricing. And yet, it’s often one of the most underappreciated levers, almost an afterthought. Sometimes, this is because people get so wrapped up in product features that pricing just gets overlooked. Other times, it’s because people are risk averse and worried about making a bad move. Either way, pricing is something you need to address head on. Even small pricing changes can have a huge impact on your bottom line. If you miss on pricing, it can cost you in a big way. I think about pricing as part of the product experience. With the vast majority of our customers in the self-serve bucket, we have to make sure our pricing is self explanatory. A new user has to get it right away, understand the value, and be convinced that they should buy. At SendGrid, we decided several years ago that it was important to build a pricing function that would be responsible for doing the necessary homework to get pricing right. We engaged a director, who owns several functions, and we hired two pricing professionals whose job it is to think about pricing all day every day. That might seem like a big investment, but it’s been worth every penny. We treat these pricing experts like product managers. They are trained on the same skills as product people—customer interviewing, problem and solution validation, and so forth. They often ride along with PMs to make sure they understand the product, the solution, and the target user. Just like with so many other aspects of product development and management, it’s critical to avoid guessing as much as possible. Talk to your customers, understand the value you’re delivering. Do all the homework to make sure that you’re getting all the details right.
The post PLG and Product Management: Tips from SendGrid’s VP of Product appeared first on OpenView Labs.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.