Pivoting to Supaglue

Since Supaglue’s public alpha launch last week, we’ve gotten a lot of questions from friends and founders on why we pivoted from our previous product (Supergrain) and decided to build an open source integrations platform for developers. This is the story of how we got there.

Background

By December of 2022, we had been building marketing technology for almost a year, and we’d been working on a B2B marketing automation product for almost 4 months. We had a few design partners using our product, which helped marketers run personalized email campaigns using their customers’ product usage data. We also had a handful of prospects lined up who were interested in running POCs with us.

But as we headed into the holidays, many of our prospects started dropping out. More importantly, we saw a disturbing pattern where prospects were able to solve the core problem we solved using a different solution: reverse ETL.

Our product gave marketers more flexible segmentation and personalization, but it wasn’t good enough to justify swapping out an existing email tool. It was simply much easier to adopt a reverse ETL tool incrementally as an 80% solution, than to replace a mainstay like HubSpot with Supergrain. We found this was the case even at mature PLG companies that, in theory, would have the greatest need for our product.

Pivoting

We shared the update with our lead investor Benchmark, who encouraged us to step back from marketing and consider other ideas. In other words, pivot.

Pivots are hard, and as a founder, you’re forced to think about what happened and what went wrong. As we reflected on our martech journey, we realized we made the right decisions along the way, but that we made them too slowly. Had we iterated more quickly, we could have learned faster and saved months of time.

So while there are many ways to pivot (and what we did might not be the best path for others), the primary metric we decided to optimize for was speed. To hold ourselves accountable, we self-imposed a time constraint of <1 week for deciding on the new direction. 1 week was arbitrary, but the longer it took for us to decide, the later we would talk to real customers and the longer our team of engineers would be stuck waiting for clarity on where the company was headed.

Practically, the time constraint meant we were not going to research new domains, deeply analyze markets, do a ton of user interviews, or try to optimize for the best idea. Instead, we would pick and run hard at the first idea that checked enough boxes to be viable. If it turned out to be a dead end, we’d come back to the drawing board and try another path. But we weren’t going to wait around.

Ideating

We had spent most of the year selling to marketers, which was unfamiliar territory for me and Tom. While we learned a lot about marketing in the process, we also knew it wasn’t a domain we felt really excited about. While being deeply passionate about a problem isn’t necessarily a requisite for success, it certainly helps and makes the journey more fulfilling.

For the new direction, we both wanted to work on a problem we’d experienced ourselves, for a persona our team deeply understood.

We quickly honed in on developer tools, and brainstormed a list of problems we had faced ourselves over the last year and a half of building the company. This exercise wasn’t exhaustive, which in retrospect was probably a good thing: if we couldn’t remember the problem we faced, then it probably wasn’t painful enough of a problem to solve.

In the end, two ideas made our shortlist as particularly annoying issues our team had to deal with:

1. Tooling to simplify connecting to, querying, and building applications on top of cloud data warehouses like Snowflake and BigQuery.
2. Tooling to simplify building integrations for CRMs like Salesforce and HubSpot into B2B SaaS applications.

Both of them met our threshold of viable ideas to evaluate further.

Deciding

We ended up choosing option 2 (developer tooling for CRM integrations) for several reasons:

• Market. We knew that integrations was a big market generally with significant exits like MuleSoft and large private companies like Zapier. We also saw companies that were solving a similar problem (e.g. Merge) getting traction. We couldn’t say the same for the data warehouse application market, which still felt very nascent.
• Personal experience. We felt the latter was a more visceral problem for us. We knew it was a clear problem that B2B SaaS companies needed to solve to unlock revenue for customers, because we had been in that exact situation ourselves. We also knew that if we had evaluated other vendors and were unsatisfied with the options enough decided to build in-house, we probably weren’t the only developers who felt the same way.
• Product differentiation. Finally, we had some ideas for how to stand out and deliver more functionality and a better developer experience than existing products in the market. We took inspiration from developer-centric products we admired like Clerk.dev, which was rapidly gaining adoption by bundling backend APIs with React components to make user management fast. By bundling CRM APIs with React components for user-facing settings, we believed we could reduce development time for integrations from months to days.

We gut-checked some of our assumptions with Benchmark, who gave us a thumbs up and some words of encouragement. We had a new direction!

Beginnings

The first order of business was scheduling time to talk through the new direction with the team. It’d been a whirlwind of a few days and still lots of open questions on the product, the market, customers, etc. We knew it would take time to get everyone onboard.

In the meantime, we began the process of winding down the old product with existing customers, and taking the next steps in our new journey: validating the problem and learning through user interviews. Fortunately, we had an idea of where to start: since customer-facing CRM integrations was a table stakes feature in so many products built for go-to-market teams, many companies that were previously competitive or adjacent to our previous product were now prospective customers!

One last thing we had to do was come up with a new name for the company. There was lots of marketing content floating around the internet and mindshare associated with our old product, and we didn’t want anyone to get confused about the new product. We dug up the spreadsheet we’d used to brainstorm company names and spent an hour looking for dotcoms that were easy to pronounce, spell, and sounded good. I guess we couldn’t let go of the “super” prefix and we ended up with Supaglue.

And with that, we were off to the races! The next part is how we went from an idea to public alpha launch in about a month, which is a story for another blogpost.

‍