Table of Contents
So our investors said we need more product led growth...
At this point you’ve almost certainly heard about “Product Led Growth” (PLG) if not been hit over the head with it. The main premise is that a simple & fast-to-value product, combined with a self-serve trial and viral sharing mechanisms, can create a flywheel of growth.
A lot of PLG reads like it’s for B2C companies, or really simple B2B products. But the broader premise is that the product experience itself should be part of the discovery, evaluation and purchase funnel, which could (and arguably should) apply to all software. So, assuming you are on a PLG train, how do you execute?
Invest in systems early on. Not just systems like reusable components or an experimentation framework, but also systems that allow non-Growth teammates to extend and iterate on experiments.
Build a growth team to create a PLG flywheel
As with most change, there’s an organizational and system component. First, spin up a Growth product team separate from your core product team.
Core product teams are rarely aligned towards growth initiatives. Their mandate is generally to solve customer problems through core product functionality and feature-sets, and deliver against that product roadmap. So, to execute a product-led growth strategy, companies generally create a growth team goaled against acquisition, conversion or upsell metrics.
Second, invest in systems early on. Not just systems like reusable components or an experimentation framework, but also systems that allow non-Growth teammates to extend and iterate on experiments.
Invest early in systems to help you achieve product led growth
Whatever you build has to be maintained & extended.
Growth is the bridge between GTM and Product. Since both are constantly changing, the bridge has to, too! Whether new use cases or personas, when every change needs new engineering work, they inevitably don't get updated and flows go stale.
Customer facing teams have a closer perspective.
In B2B SaaS, Growth teams and Product managers talk to users but largely for research. Especially for mid-market or enterprise customers, it’s often the customer success teams who are working through both tactical and strategic problems with customers. This gives them a raw perspective on how customers experience the product and value journey and ways it can be re-defined.
Progress > > Perfect.
While a full product redesign can solve challenges more deeply, the ROI on such an effort is hard to justify (and unrealistic to do every 4-6 months). Having a system that enables a wider set of customer-facing teams to contribute can speed up experiments and bridge the gap between deeper product refreshes.
Ensure your systems are scalable and iterable
During my tenure on the Intercom Growth team (a multidisciplinary team of ~25) we built product experiences ranging from an onboarding guide to product tutorials. These experiments could, at times, increase core activation metrics by upwards of 80%! But as the company moved from a pure self-serve to a more sales-led upmarket approach, those mechanisms hit roadblocks in scaling.
For one, it was all hard-coded. That meant as the core teams released new features, or as the go-to-market teams identified new customer segments, we weren’t able to easily adapt existing experiences. Second, these in-product flows were never designed for a customer success manager to tailor for a specific account (especially those with more complex use-cases or rollout plans).
These early wins + scaling challenges are not unique to Intercom. Dropbox, famous for its viral momentum and organic product growth, also had to confront the question of how to keep experimenting quickly.
Waqas Sheikh was most recently the Group PM for Business Platforms at Dropbox. For many years, Dropbox had a dedicated multidisciplinary Growth team tackling initiatives ranging from sending expired payment method emails, to pricing initiatives. But as the company and its product surface area grew, it became increasingly difficult to maintain, let alone grow these customer experiences. Yet given the size of Dropbox and the company took an approach of building a systematic platform internally to empower its Growth teams to move faster.
How to procure said “system”
Assuming you’re now convinced that taking a systematic approach will actually enable your company to move faster and iterate more quickly, how do you go about and get one?
- You build it yourself.
- You incorporate 3rd party solutions.
1. DIY
At Intercom, the team eventually built the Product Tours product to replace the homegrown product tutorials that the Growth team built (and maintained). Not only did that create a new product that could be monetized, but it also allowed PMs and designers to build new tutorials without engineering lift each time.
At Dropbox, the scale and magnitude was quite different. At steady state, over 100 people contributed to the various platform surface areas spanning billing to engagement and experimentation. Interestingly, these platform investments started at the transactional layer (payments, billing, email) before increasingly moving to the surface, touching in-product ads, notifications and cross-channel communications.
These systems empowered not only Growth and Product stakeholders to participate and iterate quickly, but also brought internal stakeholders from Finance and Sales to Customer Success to the table, who could leverage these systems for operational efficiency. These systems spanned far beyond the reusable components that also empowered faster velocity, and instead took a more holistic cross-functional approach.
2. Plug and play
The reality is that most companies aren’t able to resource internal product infrastructure. That’s why we built Bento, to enable customer-facing teams to change things like the order of steps a user takes, or even change the content for a specific (usually large) customer. When there's a new use case that the product supports, or a new persona that GTM wants to serve, Bento makes it easy to add new branches and flows without needing engineering to rebuild a flow.
A core benefit is enabling companies with constrained engineering teams to ship in-product onboarding in days. Another is enabling non-engineers to easily iterate and contribute to content. Finally, systems like Bento provide infrastructure like analytics out-of-the-box and can do things like over-invest in success states, or notifications – things that often are de-scoped in the course of a project.
If you’re looking to bring in a system, you can evaluate it against the same reasons to have systems in the first place.
- How easy is the maintenance?
- Can non-engineers be empowered to participate?
- Can you make progress quickly (and be empowered to learn)?
Need a system for customer everboarding?
And finally, if you are thinking about how to scale customer activation, especially by bringing some aspect of self-serve to your product onboarding journey, I’d love to show you how Bento can help your team activate customers faster, and have a scalable way to iterate as you grow. Read how a PM at Ironclad made self-serve a reality with Bento.
