How FreshBooks started over (12 yrs in)
Derisking the riskiest of bets a startup can make, the advantageous loops of community-led product development, and scrutinizing user-buyer distinctions to scale pricing.
Welcome to the fortieth edition of The Baton. A fortnightly newsletter that brings you three, hand-curated pieces of advice drawn from the thoughtful founder-to-founder exchanges and interviews taking place on Relay and the interwebz. So, stay tuned!
In this edition, you’ll find instructive and inspiring pickings from the brains of FreshBooks’ Mike McDerment, Pocus’ Alexa Grabell, and Snyk’s Guy Podjarny.
Recently on Relay:
AMAs (upcoming): Next Thursday (Feb 24th) we’re really looking forward to hosting Tray.io’s founder and CEO, Rich Waldron for a Relay AMA. From origins in a place with a non-existent tech scene, to “(literally) bootstrapping the business by selling Wellington boots on eBay,” Rich and team have built Tray.io into a decade-in-the-making scale-up that now serves companies such as Cisco, Eventbrite, Segment, and others. If you’re keen on joining, please request an invite, here.
#1: Starting over by (literally) building out their own competition — FreshBooks’ co-founder, Mike McDerment, recounts a novel tale of reinvention; how they fundamentally refactored a decade+ old product with millions of users when “the no. 1 rule in software is to never do a rewrite.’ (Source: BoS)
It’s worth spending some time and talking about the number one rule in software development. Don’t rewrite your software! There it is! There’s some really good reasons why…
First of all, it will take longer than you think and cost more and it will be harder. Estimating is hard…
And then there’s the old [challenge], guess what? Most IT and technical projects of any scale, they don’t finish. They fail. So that’s a problem.
While you’re working on a rewrite, your competition is catching up. And so we had a lead on a bunch of vectors but you’re standing still when you rewrite so people have the opportunity to catch up.
You can make mistakes in a re-write and undermine the trust of your customers…
And then my personal favourite is what I like to call the sophomore jinx. You ever had a band you really loved and the first album is amazing and you go buy the 2nd album and it makes you want to cry…
So when you think about building a whole new software platform, you flip the switch on a rewrite, who’s to say it’s better? That’s when you start finding out. So for all these reasons and a whole bunch more, the number 1 rule in software is you don’t rewrite.
Did I mention we had tried 3 times before and failed?
…
So I really want to figure out how do we de-risk that problem?
Because to work for 2 years and to end up flipping the switch and have it perform worse just seemed like a non-starter to me but that’s almost what you should expect.
…
What if we created another company that competed with ourselves? Put another product out there. We’d get the benefit of knowing how it’s actually performing. You’d actually know the funnel…
Are you ready to put your business and all your traffic on top of it? Do people like it? Does it actually work? These are questions you don’t know if you flip a switch one day.
We created a company, its own name, logo, website, URL, incorporation documents, terms of service, we spent legal fees on that stuff and we just had this completely independent thing.
And the team did that, they built it up and it made them feel like it’s our thing. That was pretty cool, that was BillSpring. A pretty novel approach to this that other folks will be copying in the years to come. It helped us solve a bunch of business problems which is why I like it. So that was BillSpring.
I think that’s the maybe the most novel part of the story for what it’s worth. And it presents some interesting problems cause we ran them both parallel for 8 months and this happened.
…
Someone called in and said ‘I’d like to cancel my account. And I’d go to this new product called BillSpring instead.’ How do you like that?
…
It wasn’t just the product that changed it was how I interacted with the teams and how the PMs did their leading. We interviewed over 2,000 customers in the building of the product so that rapidly became part of how we do things. The rewrite didn’t just change the software but… how we ran the company.
#2: The “huge unlock” of building a community, a category, and a product, in tandem — Pocus’ co-founder and CEO, Alexa Grabell, on the advantageous loops that surface when you evolve the three disciplines together. (Source: Relay)
We started the community at about the same time that we started aggressively dedicating resources to building the product mid 2021. This was a very strategic and intentional decision. I wanted the community to inform our product roadmap and I never wanted to build a product in a silo.
My goal was to build the Product-Led Sales solution that PLS practitioners needed and literally would do anything to get their hands on. So how was I going to figure out what that was? By building with them.
I’ll be honest, we had a really good sense of what we wanted to build from working with PLG companies and doing intense customer & product discovery for ~6 months with our design partners. But, we needed to continue to validate this, test hypotheses, and experiment.
There are two key benefits of building product and community at the same time:
First, I can receive real-time feedback. I would Slack DM a community member a specific question about a new product feature. I trust the community members’ opinion as I’ve gotten to know them through building Product-Led Sales frameworks. On the other side, they are excited to provide feedback as they are passionate about building the future of PLS.
Second, building a community and category goes hand-in-hand with building a product. Power users and early adopters of our product are also the experts and innovators of the Product-Led Sales category.
I’ll explain what I mean by this with an example. In our product, Product-Qualified Lead (PQL) scoring is a very important concept. In Pocus, you can define PQLs, experiment with different scoring models, and then surface PQLs to sales reps at the right time.
How is someone going to use Pocus without understanding what a PQL is? They can’t. So what they need is education around PQLs. Where did that come from?
That came from our community.
Building a community and a category at the same time as building the product has been a huge unlock for us. It allowed us to learn things from our community and then pivot our product roadmap. Our community building, the category work, and the product roadmap were all a feedback loop that continued and still continues today.
Additionally, the category and community allowed us to build a product that differentiates us from our competitors. From the community, we learned that every sales team in PLG has a very different PLS motion — this is not a traditional top-down sales playbook that can be copy & pasted across organizations. We kept hearing that there is no one-size-fits all solution for Product-Led Sales.
So, we made the product very flexible and customizable so each PLG company can build workflows, dashboards, and PQL scoring models that work for their business. We scrapped everything that was hard-coded and rigid, and built a very flexible no-code solution that enables users to experiment — which the community was asking for.
Because of these collective efforts, I am getting quicker iterations of feedback to my product than I would have ever had. There would be no way we could build this robust of a product in this short of a timeframe if we didn’t do the category and community part.
#3: Straightening out the user-buyer disconnect by matching use cases and personas — Snyk’s co-founder, Guy Podjarny, describes how their first attempts at freemium tumbled when they conflated passionate users with buyers. (Source: GGV Capital)
So Snyk is developer-first security. The most important user of the product is the developer. And I’ll admit that I take some enjoyment in telling the C-suite, ‘you’re not the most important user of my product.’
Because you [C-suite] and I share the same risks. The worst thing that can happen is that the software sits on the shelves. It doesn’t get adopted by developers.
It doesn’t matter how amazing and wonderful the AI, or the technology is, if the developers don’t pick it up, it’s not going to help you.
…
However the budget for purchasing for securing the organisation is often times, especially as the organisation gets bigger, often times, sits with security people.
Snyk’s motion is that it’s a bottom-up solution. Open source projects can use it for free. And that serves as a visibility vehicle for developers and it is a good contribution and helps the open source community be more secure.
From a business perspective, a lot of those people consuming those open source projects, supporting those projects, if they like what they see from Snyk, they might pull it into their product.
Subsequently it is freemium for private code. So it allows a developer without getting a tonne of permissions to use it.
We’ve invested in making that path low friction. There’s a bunch of ways in which the developer can consume the product for free. There’s a command line interface, there’s a git integration, there’s IDE plugins.
The bottom-up is almost entirely focussed on developers. It’s not about getting security people to start using the product, but getting a developer to start using the product.
But the commercial tier is more focussed on governance. So the understanding is that developers come in, they secure their daily work, but the flip, the point at which people are looking to pay for it, is when you’re saying, ‘now I want to know what’s going on.’
…
Those bits very much tip you over to the payments tier. Who pays? It’s from the security budget. And in most organisations that means security but sometimes it’s digital transformation initiatives, in smaller organisations, it comes from the CTO or the VP of engineering…
…
When we launched Snyk, we launched a crappy little beta in October of 2015… at that point we had maybe tens of thousands of free users and we expected, [as we] opened this $X a month type payment for developers to purchase.
We opened it up. We waited for the floodgates. Nothing happened.
We got a handful of users converting.
That led us to a realization…
…
Governance is mandatory for the buyer. The buyer isn’t writing code. The product is not at all about them. They need a totally different set of capabilities and a reliable support engine.
This notion of the use case and matching the use case with the persona is something that is not just discussed enough.
You ask someone what is it they go for in terms of market problems, they’ll say, ‘hey, companies are doing xyz and it is so inefficient, we can do it so much better, because of this amazing technology.
They forget the people and the use cases that happen in the middle.
Until next time,
I hadn't heard the Freshbooks story before! So so good. Thanks for sharing.