In the following exchange, Jam’s co-founder and CEO, Dani Grant (@dani), dispels a persisting yardstick of starting up and describes how long-esteemed, “must-be-embarrassing” first versions can actually muddle product-market fit signals.
She also lists: practices instilled with the aim of producing polished products while still enabling them to ship with great urgency, Jam’s PLG-driven word-of-mouth wins, and solving for developers and all their collaborators at once.
— On why “move fast and break things” is bad advice
— The practices that allow Jam to prioritize quality and speed
— Notes on Jam’s GTM path towards 15,000+ users
— Unifying the problem statement to serve multiple personas
On why “move fast and break things” is bad advice
I believe “move fast & break things” is outdated advice that no longer serves founders well in 2023.
For sure that’s a controversial opinion, but that’s my experience.
When you’re searching for product market fit, the most common advice you hear is people telling you that you should ship broken/janky stuff fast, because you’ll know that you have product-market fit when people are willing to jump through hoops to use your product anyway.
But I believe that’s bad advice.
In today’s world where software is essential, users have less patience for buggy products. As a founder searching for product-market fit, I’ve found that prioritizing quality over quantity led to clearer signals from the market and faster product-market fit.
When we started building Jam, we followed the same and shipped minimum viable products quickly to test new ideas in the market. However, we found it challenging to determine if something wasn’t working because it wasn’t the right approach or because it was too slow or had too many bugs.
Once we began prioritizing quality internally, we quickly achieved product-market fit.
“Small scope, high quality” became our mantra. When you’re a founder looking for product-market fit, you need clarity, and “breaking things” obscures clarity.
PS – how do you know if you’ve achieved PMF?
We tracked retention as the most important metric, but the best advice I’ve received on this is from Mike Adams, founder of Grain. He says: there’s a time when all you can think about is product-market fit, and at some point you realize you haven’t thought about PMF in a while.
Somewhere in between, you probably hit PMF. That was definitely our experience. At one point, it was all we thought about – my phone even used to correct OMG to PMF.
But nowadays, we’ve moved onto new challenges. We realized at some point that we hadn’t had to think about product-market fit in a while.
The practices that allow Jam to prioritize quality and speed
Speed is the biggest advantage startups have against giants, so we put a lot of thought into how we can find ways to move even faster.
Here are 5 things we do at Jam to move faster.
1. Make sure every bug report is detailed
This will save engineers hours of investigation and follow up. Without sufficient detail, one bug can take a day to investigate.
We use Jam at Jam, which makes this trivial to do.
(Jam is a free tool that will auto-fill all the relevant engineering details for you).
2. Write (verbose) code comments
This lets anyone jump into any part of the code to fix or add a feature without spending tons of time figuring out how it works. 5 minutes writing out clear context will save 5 hours later.
3. Setup an on-call rotation
One engineer every week focuses on deploys and fixes, so every other engineer can focus on larger projects without getting pulled into daily routine things. Jam’s on-call rotation is ofc called Jampion.
4. Release everything behind a feature flag
Feature flagging enables us to deploy frequently, with less risk.
5 - Spend a little time now to avoid weeks of tech debt cleanup later
Counterintuitive, but we add one day extra of planning, and one day extra of cleanup to every project to avoid weeks of tech debt cleanup in the future, and ship many fewer bugs in-between.
One of the things we do frequently at Jam is retros. Most of these practices came out of ideas suggested at a retro. When you’re building a company, you’re building a machine that can execute together no matter what challenge is next in front of it.
So it’s important to also have time to pause and reflect on what’s working and helping you move fast, and what’s not. That way you can keep iterating on your company like you iterate on your product.
Notes on Jam’s GTM path towards 15,000+ users
We’re really grateful to our community of users.
They are the driving force of Jam’s growth. We just crossed a major milestone of 15,000+ users, and that growth has been through word of mouth.
I like the bottom-up model of product-led growth because it means that the better we make our user’s lives, the more we get to grow Jam. That feels right to me, and it ensures that our focus is always on the most important thing – bringing even more value to our users.
There is a great Startup School video where Sam Altman says the key to a successful startup is building a product so good, people spontaneously tell their friends about it.
I believe that to be true.
While of course the most important thing is to build something that brings our users real value, our growth is also supported by the nature of building a communication tool where sharing Jam is baked into the product usage.
When you use Jam, you share the bug reports you’ve captured with Jam with your teammates. So, through that, one teammate will bring in Jam and by using the product, introduce it to the rest of their team.
They will only do that if they love the product though, so we see it as our main job to obsess over the product details and make sure we build something that users truly love.
We’ve also experimented with other ways to get the word out there, including collaborating with influencers we admire, and making our own content.
Here’s one of my favorites – an infomercial parody my co-founder and I recorded where we dressed as beekeepers and hunted for real bugs, with real jam.
Unifying the problem statement to serve multiple personas
What’s interesting is while you’d imagine that having users who are both bug reporters (PMs, QA, founders, designers, customer support, etc) and bug receivers (engineers) might get tricky, it turns out that what bug reporters really care about is being a great collaborator to engineers, and unblocking them to move faster in fixing issues.
That makes things much simpler.
It means that whatever is good for the engineer is what their collaborators want.
So we try as much as possible to focus on creating a great and fast debugging experience for engineers, while making it as easy and quick as possible for their collaborators to generate bug reports.
What we want is to create a situation that’s a win-win: fast for the bug reporter, and perfect for the engineer.
Related reading from the Relay archives:
— Cord’s co-founder, Nimrod Priell, on why MVPs worked in a different era
— Merge’s co-founder, Shensi Ding, on serving two different personas across the product’s lifecycle
— Lou’s co-founder, Rachel Pardue, on shaping the self-serve path to their first 1,000 customers