“I had no idea who the buyer, other than me, would be,” recalls Summit’s founder, Matt Wensing (@mattwensing), as he illustrates how for certain products, being customer-led, can be decidedly detrimental at first.
In the following exchange, Matt traces how both his startups followed a wide-open period of discovery, quite unlike the focused, relatively predictable path of most B2B offerings that begin with a more defined sense of who they’re solving for.
He also discusses the different types of pivots that Summit has undergone, the upside of being a product-first founder, the signalling value of integrations, and what shipping 150 podcast episodes with a fellow founder have meant to him.
— Inventions vs. services
— Summit’s many pivots (and why PMF demands getting everything right)
— The downside of rushing to the market
— Making the shift from self-serve to top-down selling
— Why it’s worth postponing integrations
— Documenting the founding journey
Inventions vs. services
A great, oft-repeated section of advice for founders points at obvious-sounding statements such as “build what customers ask for” or “make customers happy.”
What if someone is trying to figure out who their customer is?
To which, most folks would respond with confusion: “maybe you don’t know who your ideal customer is, but how can you not know who you’re serving in the broadest sense?”
Well, in some cases, you don’t.
Sometimes people just invent things. Consider Open AI. Clearly, it has huge applications for a lot of fields. I’m certain, though, that they don’t know who their best/ideal customer is.
It’s an invention.
Services, on the other hand, begin with a customer in mind.
Say I’m from a particular industry. I understand it really well. And there’s a particular problem I’ve faced in a given role, which, I feel, can be solved with a specific solution. I’ll then set off on a journey with a defined (if not yet ideal) customer base to hone the product.
When it comes to inventions, you’re taking a different path.
Discovering and exploring different directions, markets, and use cases to learn who is interested in the invention at its most basic level. And then who would be most interested if you were to develop it to its fullest potential.
You’re early in the evolutionary flow of things.
And this could be a long, bafflingly non-linear journey.
With both Riskpulse (my previous startup) and Summit, I believe that I was on the invention trail. I had built something, basically driven by my own joy and curiosity. So I had no idea who the buyer, other than me, would be.
I was just willing to bet that I’d discover others who might appreciate or enjoy the tools.
Summit began because I, as a founder, needed to build financial models. Turns out that the obvious customers for this, financial operations people, weren’t a great market to go after.
Why?
The premise was offering combined powers of mathematics, calculations, and coding, all through a low-code interface.
But, in hindsight, it turns out that the people who need that most aren’t finance teams that love and use excel, nor the engineers or coders who’re regularly tasked to create such tools.
They’re instead people who’re most removed from product and engineering and who need platforms to create new things on their own to drive growth goals: marketing and sales teams.
This realization took us quite a bit of in-market discovery. Similarly, with Riskpulse, I created one of the first interactive weather maps on the internet.
That seems crazy to say today but back then the only way you could access weather information was through static graphics.
And who did we end up serving eventually?
Fortune 500s.
Solving supply chain risk problems that were caused by weather.
But back in 2006, when I was building that technology, that invention, if you will, I had no clue that that market segment would consistently, predictably appreciate (and get the most value from) using it.
The product certainly evolved a lot, but, again, that evolution was preceded by a long period of discovery. Whereas if I had been in the supply chain space or, in Summit’s case, had been at a growth/marketing position, maybe I would have seen these gaps from the inside.
Maybe.
Because I’m not sure if I had come in from that direction I’d even think of these ideas. 
Summit’s many pivots (and why PMF demands getting everything right)
I have found that there are different categories of pivots that founders can think about somewhat proactively. Sort of like thought experiments.
Summit’s early messaging was around the following: “Tell your forecasting spreadsheet you’re never getting back together.” Targeting people who used spreadsheets for financial forecasting and modeling and giving them reasons to switch.
Today, our H1 reads: “Your platform for low-code calculators, simulations, and forecasts.” And we’re aiming at growth and marketing people.
When I look back at the pivots we went through, here are the types that I can trace:
The first sort was where we went from a product that was meant for internal use cases (like Retool) to one that solved external use cases.
If you were to add a share/publish button to an internal tool, does that lead to users sharing what they’re creating with others? Does that then become a real benefit for them? Then you’re likely on the cusp of figuring an external use case.
Summit went through just that.
The second kind of pivot was going from being a product at the core (where we had to build features upon features every time somebody would come to us and ask, “hey, this doesn’t do X?”) to a low-code programming language.
That change allowed us to address a consistent, long tail of demand for features that had little to do with each other. What users were really asking for was flexibility. And we offered it by enabling them a low-code development environment.
Those first two pivots made us let go of some of our original, deeply-held assumptions about knowing who Summit was for. Culminating in a third pivot. Where we discovered sales and marketing teams that needed publishing capabilities and a toolkit that was programmatic even if they didn’t know programming.
Thus we turned into a platform for them to develop functions, calculators, forecasts, and simulations, for their audiences, prospects, and leads.
The constantly annoying thing about going through such pivots is that you never really know how close you are, you only know that you’re getting closer.
It’s always scary to look at a successful pivot and recognize how close one was; “we just had to flip this one thing upside down!”
And it’s incredible that the market does not give you credit for being right about, in some cases, 7 out of 8 things. That’s the thing about product-market fit. You have to get every piece right.
At least, directionally correct.
It’s frustrating, discouraging even, to change thing after thing about your business but not quite hitting the right note on the PMF front. You have to press through, though. Once you’re out of ideas, maybe you can quit. But if you still have time and ideas, keep at it.
You’d be surprised by where you can get by way of these instructive iterations.
I know we were.
The downside of rushing to the market
Product-first founders tend to be technology-driven.
Or as I had noted above, start with inventions over services.
This has some unique advantages. I’ve seen companies that by having clarity on who they’re serving from the beginning, end up rushing the product development process, going to the market fairly early, and even scoring good traction.
The downside to that is that they don’t have the luxury to go back and change things when they learn something new. The product is taking off and changing stuff means paying down technical debt or doing some foundational work.
That is a wonderful problem to have, as some would say. But it can also be significantly difficult to pause everything or change the wheels on a car as it’s going.
Being product-first means when you finally do get to product-market fit, the product is ahead of sales and marketing. You’ve kept technical debt at a minimum and have created a sufficiently abstract product/platform that’s going to scale well.
That’s where I’m comfortable.
That just suits my DNA. That’s how I’d like to sell. So that when I have the customer figured out and I go on sales calls, they’re blown away by the product.
Making the shift from self-serve to top-down selling
I did enterprise sales for 5 years at my previous company. So, with Summit, I had thought I would do this one without being sales-driven and instead focus on being bottom-up, product-led, and self-service only.
The market, I’ve now discerned, doesn’t want to buy our product that way.
At least, not today.
Maybe, years from now, a self-service path would open up.
Which has translated into arriving at pricing that justifies how our customers want to buy, how they want to be onboarded, and everything that goes along with an upmarket shift.
And this is where, you could say, a fourth pivot, this time with our go-to-market approach, is taking shape. New categories of products (Summit is a new addition to the marketing technology stack) often require entering at the high end.
Requiring high-touch, outbound sales because people don’t yet know how to use your product, they don’t know what questions they should be asking, they’re not even aware that they need this product.
If you’ve built something new and it doesn’t justify a GTM motion that involves inside sales or enterprise sales, think about packaging up that little use case. Elevating it in a way that you can sell it to a VP, a director, or a C-level exec at an org.
So yeah, that’s what I’ve been doubling down on. Sales and revenue growth. The rest, I believe, including fundraising will take care of itself once we’re successful.
And it’s going well thus far.
I’m excited.
Why it’s worth postponing integrations
Until you’re really confident about who you’re building for, postponing integrations can be really beneficial and grant you the extra agility to change during the early days.
I know that integrations are getting easier. There are now platforms where you can write one integration and they, in turn, allow you to integrate with others in a given category.
But it’s still worth waiting.
We put off quite a few integrations for a while and I’m glad we did.
A lot of people write to product teams and ask, “does this integrate with X?” That can be a vague premise to start working on one. So we have to push back and try and answer questions such as:
- If this was integrated, what data would you want?
- How often would you want that data?
- What would you actually do with it?
In Summit’s case, we found that most people requesting integrations didn’t really need them. Sometimes all they wanted was to automate the collection of small bits of data. Or the ability to upload a spreadsheet.
Deliberating over each integration request can help you stay nimble and not overinvest in an area that you’d likely won’t even need, until you know who your most appreciative customers are and how they want to use your product.
Once you do know that, integrations can be fantastic.
They can anchor your product into a specific positioning.
They can tell people what you are and what you aren’t.
When we started, people wanted us to integrate with QuickBooks, because we were seen as a financial platform. Today, we integrate with HubSpot and other CRMs as that’s supportive of the use cases we know we solve best for growth and marketing teams.
An integration can be an opportunity to signal to potential customers that we exist in this space and not that one.
When someone sees that we integrate with HubSpot, they might observe that we work with numbers but they’re likely not going to conclude that we’re a financial tool. They’d probably even assume that we must be a tool for marketers or salespeople.
Pricing is another such signal.
If I’m paying $65/month for QuickBooks that price point will influence how much I’m willing to pay for an add-on that integrates with QuickBooks.
The way we read this is that if someone has invested time and resources into setting up a CRM or a marketing hub, they’re pretty serious about their marketing technology stack.
That’s helpful in two ways:
- It gives us a really high pricing anchor,
- It also lets us say and commit to, “we’re going to help you get more value out of the 20K/50K they’ve invested in their stack.”
Part of your price tag, then, is equipping them to use a platform better and more often, and as a result, get disproportionately more out of it.
Documenting the founding journey
The podcast, Out of Beta, has been great for my relationship with my co-host. It’s been a fun way to keep in touch with a fellow solo founder, weekly, for over two years (we’re at 150 episodes!) now.
It has inserted a reflective cadence into my life. Each week I have the chance to consider what was done and how I feel about it. Sometimes you look back and see how in certain weeks you get more done than what some companies get done in 6 months.
In the first couple of years of the business, when I didn’t even have teammates, doing the podcast really helped with my psyche and accountability.
I tend to be driven by validation and affirmation, so just having somebody to share the ups and downs with really helped keep me fueled up for the journey ahead.
We’re changing up the format now to do more recording upfront and then hopefully release an entire season all at once every 3-6 months. Netflix style. As a founder, it means I can record and not worry about what I’m saying. Because I know editing will come later, I can be more transparent.
If you’re a solo founder or running alone, that kind of medium or forum can be really nice. If not a podcast, you can still join a mastermind group or some place where you can have these regular, supportive interactions.
Even if you’re not keen on publishing, recording these vulnerable conversations can make for an incredible archive for your thinking.
I recommend it.
From a PR/marketing perspective, it’s awesome to be at conferences where people come to you and say, “I know what you’re building, I’m interested in/like what you’re doing, as I’ve been listening to the podcast.”
Related reading from the Relay archives:
— ProdPad’s co-founder, Janna Bastow, on why the perennially commended advice to scratch one’s own itch is “muddled with survivorship bias”
— Arrows’ co-founder, Daniel Zarick, on deleting a 1/3rd of their product and replacing it with a best-in-class integration