After building for the last ~2 years, we have not found product-market fit at Groundswell. And we wanted to share what we’ve learned throughout this process.
We still think this product should exist, but we have come to the conclusion that this is only possible to build within a greater “platform” (or as a compound startup).
Before going into the top things we’ve learned, we wanted to give a bit of context on how we got to where we are today.
Our original vision → “The Brain for Revenue Teams”
We set out to build The Brain for Revenue Teams.
What is “The Brain for Revenue Teams?” This:
![Groundswell Pitch Deck for Seed Fundraise - Google Slides 2023-07-31 at 1.15.25 PM.jpg](https://s3-us-west-2.amazonaws.com/secure.notion-static.com/e9e79d5c-e045-44cc-8601-1554af686651/Groundswell_Pitch_Deck_for_Seed_Fundraise_-_Google_Slides_2023-07-31_at_1.15.25_PM.jpg)
Where we started (our wedge) → a “product-led sales platform”
We decided to start with product usage data (the top “bubble” in the graphic above) for the following reasons:
- We believed (and still do believe) that if you’re a PLG company, product usage is the highest intent signal there is for SDR/Sales Teams for targeting (and for Marketing and CS Teams, for that matter)
- As founders, our most recent experiences gave us a unique advantage to build here (Brendan was at Zoom, Hari was at StreamSets - both were perfect examples of PLG companies that struggled to operationalize product usage data for the GTM Team)
- It seemed like the obvious wedge in 2020, when we made this decision because A) VCs invested lots of money ($10s of millions) in over a dozen early-stage companies in the “PLG CRM” space, B) people were writing lots of articles (here, here, and here) to build out a category around PLG/PLS, and C) “message-market fit” was a rocket ship around the education of PLG/PLS (here and here); said another way, PLG was very promising
- We had to start somewhere, we couldn’t boil the ocean; and the other “bubbles” were solved problems with point solutions already (so there less of an opportunity to build novel IP in these categories)
What we learned over the past 2 years
- Product usage data is a great feature, but not suited for a standalone platform
- We believe that it would be more practical to incorporate product signals and related actions into an existing signal-based selling platform as a product line. This is due to several reasons:
- The market size for a company solely focused on operationalizing product usage data is relatively small and may not be sustainable. Only a few large companies have enough free users to create a reliable pipeline.
- It is more logical for an existing sales platform to introduce product usage signals into their stack, instead of us adding all other signals. Consolidation is becoming a common trend in the market - by joining a bigger platform, we can build a company that is part of a more comprehensive platform.
- Very few companies have data in an analytics ready state
- Most companies have lots of data in their cloud data warehouse, but it’s not in an “analytics ready state.” Meaning, it’s not ready for a platform to have a UI simply sitting on top of it.
- We started with Segment, which sends data in a very predictable way. But as we moved up-market, we found that the majority of product data (and other necessary and/or helpful data) was sitting in their data warehouse. And it turns out that to get that data ready to use takes many months (in the best-case scenario) and a lot of coordination/buy-in from the data engineering team. Even our direct competitors who have lots more resources aren’t able to onboard customers in less than 6+ months.
- The owner of “product-led sales” is still very unclear, making it hard to sell and implement a PLS solution
- Executing Product-Led Growth and Sales is a complex undertaking that requires a deep understanding of the approach. Unfortunately, very few companies have the clarity and foresight to carry it out effectively. Majority of the customers we work with:
- Do not have a clear owner and alignment among teams
- Do not have well-defined criteria that all GTM teams agree on and optimize for
- Do not have analytics-ready data
- To successfully implement PLS, educating the market on its requirements and supporting customers during implementation is crucial.
- Small TAM → this product works best for companies with large install bases (limited number)
- Our goal was to identify qualified buyers among a large pool of free users for PLG companies, which was like finding a needle in a haystack.
- However, we discovered that many companies did not have enough free users to generate a significant number of qualified leads for their sales teams. This was true for most of the 20 companies we worked with.
- In other words, there is a ceiling to the value we can add.
- Therefore, our customers first needed to acquire more users through marketing and sales outbound efforts, before we could add value. We often found ourselves trying to help our customers with outbound efforts by utilizing various signals in addition to operationalizing their product usage data.
- We think that the number of PLG companies will grow significantly over the next 3-5 years, but we may just have been a bit early (”There are no bad ideas, only bad timing”).
- A DIY solution to operationalize product-usage data is “good enough” for most companies
- Most companies can use reverse-ETL or a BI tool and get 80% of the way there, and that’s good enough for them
- Before we started the company, we did nearly 100 customer interviews (not hyperbole), that’s a lot! We hustled to get these conversations set up. And in hindsight, one of the most common takeaways with those conversations was “we know this is a problem, so much so that we’ve built a solution internally, using reverse-ETL+CRM or leveraging a BI Dashboard.” To me, this was the opportunity — this was the “real estate” to replace with something like Groundswell. But I think, in reality, those solutions were “good enough” for the remaining juice that can be squeezed out of a product usage data.