When we started ProductPlan in 2013, our vision for creating a product-led company was informed by our previous adventures. A product for product managers by product managers and borne from first-hand knowledge and personal experiences.
Most of my previous work experience was in product management, having spent nearly 20 years primarily in new product development. I knew what it was like to take a product from an idea on paper to achieving product-market fit and the hurdles product managers encounter along the way to communicate their strategy and vision via SaaS product roadmaps.
I wanted to build something I could grow and be passionate about.
I always wanted to build a product of my own from scratch—something I could grow and be passionate about, and would build equity. What gave me the confidence to do so were two key experiences. The first was when I had the opportunity to develop some of the earliest SaaS products: GoToMyPC, GoToMeeting, and GoToWebinar. I had the chance to learn and make some mistakes along the way, but they were ultimately very successful products using a SaaS model.
Next, I went to an early-stage enterprise SaaS company called AppFolio. I was one of the founding team members for the company—which eventually went public—and we were successful at developing enterprise-class software for SMBs.
My experiences with those companies and helping them take these products from a blank sheet of paper through to market launch helped me realize that I had what it takes to do that myself. I’m a little bit older and more experienced, and I realized that the time is now if I wanted to do this.
It All Starts with Homework and Research.
My friend Greg Goodman and I co-founded ProductPlan in 2013. We based it in Santa Barbara and decided to bootstrap the company, so we’re entirely self-funded.
I began validating the fundamental hypothesis with product managers, confirming that there was a lot of pain around communicating and prioritizing the product roadmap. And as companies grew, they had so much misalignment around the product strategy.
To me, becoming a product-led company starts with a thorough understanding of customer problems.
Over the years, I’ve refined a fairly structured market validation process for developing new products or major changes to existing ones. First, I create a hypothesis, interviewing approximately ten prospects to validate and thoroughly understand the problem I’m solving. I look for patterns to know I’m on to something.
When I can predict what they’re going to say, I know I can move onto the solution validation phase, where I can then make sure they’re willing to pay money to solve that problem. From there, it’s time to define what the solution will have (and not have), conducting about 20 interviews to understand the answer, cherry-picking which features must be part of the MVP.
For example, when we were using a prototype to show prospective customers what the features might look like. It became apparent that people needed to export their roadmap. An export feature then became a part of the prototype and interviews. This learning happened all before coding started.
With this initial feature set defined, you can float trial balloons about pricing, asking them what they think is a fair value. You ultimately want to come up with an ROI to drive that final pricing model and validate the sales process, understanding who is going to pay for it and who the decision-makers are in that purchase decision since it’s not always the same as the end-user.
From Prototypes to Product-Market Fit to Product-Led
Before a single line of code was written, we knew we had a high probability of getting paying customers, many of whom were the folks we’d interviewed during the research process. But product-market fit didn’t happen until after launch.
We’d lowered our risk enough to hire our first engineer and started collecting payments on the “beta.” But it wasn’t until people began trying and buying through our marketing channels in a repeatable way we knew we’d finally found it.
We could scale the business by using a repeatable sales process and a product that solves a real problem. That’s the start of becoming product-led, in my opinion.
Figuring Out the Model and Getting to Scale
By launch, we had built an acquisition and sales model that was entirely self-service. However, the first-time user experience wasn’t ideal because people started with a blank roadmap, and they didn’t know what to do.
While we initially overcame that with onboarding, much of it is now automated. We have templates to get them started, along with walkthrough tours and on-demand educational resources. Very early on, we began investing in content marketing to create an inbound model.
This is our primary strategy to this day, and we double our content marketing every year because it’s working. We knew we didn’t want an aggressive sales team approach because, as product managers ourselves, we learned how we’d want to be sold to.
Product managers are experimental; we want to try things out on our own without a hard sell. So we continue to have an inbound sales model. Although we’ve added product specialists (account managers) that work with customers to understand their situation and show them how we can help them solve their problems, it remains a very soft touch.
On the SaaS pricing side, I had a lot of GoToMeeting experience because they were also using self-service—a try-then-buy model. We did a lot of experimentation about things like when to ask for a credit card number. That learning helped us skip some of that trial-and-error for ProductPlan.
That said, if I had one thing to do over again, it would have been building pricing experimentation into our model from the start. People were buying it, but we didn’t learn early enough which packages would resonate with the market. Pricing and purchase behavior is irrational, and customers don’t care about your acquisition costs or model. They’re looking for an ROI that works for them.
Adding a Sales Team to a Product-Led Organization
Our original idea was to be 100% self-service with an entirely inbound model. But we ended up moving upstream into enterprises much sooner than we expected we would.
These customers were buying large packages on their own via the self-service channel and started doing things like asking to be invoiced instead of using a credit card. So a few years ago, we added account management and customer success teams to help them get up and running and maximize the value they got from the product.
We had some other surprising realizations. We’d initially thought our customers would be product managers at software companies. Still, we started getting all kinds of organizations buying the product, including municipalities, government agencies, banks, and healthcare organizations.
Every organization is now a software company.
We realized every organization is now a software company to a certain extent, with their own IT groups, digital products, custom internal software, web sites, and mobile apps. They all had product managers, program managers, and project managers needing to communicate what they’re doing.
As for hiring salespeople, we’re bootstrapped and resource-constrained, so we didn’t spin up a sales team and a playbook and see what happens. As a startup couldn’t afford that expensive misfire.
So, we hired organically as our model was proven out, and we didn’t rely on commissions or quotas... we just wanted people who were driven and enthusiastic about the product. Six or seven years in, we’re selling to large organizations, and it’s spreading organically through those accounts as more people inside them keep expanding their accounts. We have customers worldwide, including in the Fortune 100, using the product, and we’re excited about the potential in the future.
Building Growth Into the Product
We did key things from the beginning to build product growth into our product and pricing model.
On the product side we did the basics such as building an easy-to-use sharing feature so product managers could share the roadmap widely within the organization. We made it possible for them to embed live roadmaps into the systems they already used such as Atlassian Confluence.
On the pricing side, we did something unique that is still a differentiator today. We gave away free licenses to anyone in the organization who wanted to review and comment on roadmaps. This benefited our customers and us in several ways. Our customers were able to share the roadmap widely within the organization, which is one of the key challenges we uncovered in our validation at the beginning. But the big benefit of this model was that awareness of the product plan grew internally as roadmaps were shared widely with free licenses. It was somewhat viral and was an example of product-led growth.
A Front-Row Seat to Product Management’s Evolution
When we developed GoToMeeting, in the pre-agile world, we conducted market validation and interviewed people who used similar solutions.
We developed hypotheses around which features were needed and how to differentiate from our competitors, which is how we landed on an “all-you-can-eat” concept where up to 10 people could join the meeting for a flat rate. That pricing model is now very popular but was innovative at the time.
I wrote a thick Product Requirements Document (PRD), predicting ahead of time which features we’d need in the product. Of course, in our current agile world, that’s not how things happen today. We still had an MVP in mind, but we’d already baked in what it would look like, which features we’d need, the target market, etc. Since there was no type of Scrum, you’d write your PRD, throw it over the fence, and wait for a finished product to eventually arrive.
Today, agile processes and a product-led growth philosophy give us a way to expand use of our product without significantly growing the number of employees we hire. You can develop prototypes and put it in front of customers iterating along the way, which is a dramatic shift.
Things now are much more flexible and adaptable.
