From seven failures to 10x growth
From seven failures to 10x growth
Jam’s CEO on product-market fit and hockey stick growth
👋 Hi, it’s Kyle Poyar and welcome to Growth Unhinged, my weekly newsletter exploring the hidden playbooks behind the fastest-growing startups.
Jam, the seed-funded bug reporting tool, achieved 10x usage growth in 2023 and just crossed 1,000,000 Jams created. Getting users to adopt a new product is hard, says CEO and co-founder Dani Grant, and it took Jam 18 months and seven failed launches before it finally worked. Dani joined Growth Unhinged to unpack how they did it – everything Jam did to grow from 0 to one million. (You can read the full Zero to One series here.)
Growing from 0 to 1,000 was A LOT harder than the next 999,000. This is when giving up didn't sound so crazy. It took 18 months and seven failed launches before the 8th finally worked.
As a former Product Manager (PM) at Cloudflare, I was used to launching something and immediately having thousands of users adopt it. At Jam, I thought I’d see it, too.
We started with 45 user interviews out of the gate. There was so much emotion and frustration around the problem we wanted to solve – so much so that one of the earliest users we interviewed offered to make the Jam brand (which is still our brand to this day). Another early interview offered to pay for the product and onboard his entire team even though there was no product to sell. Each time we’d launch something, tons of people would sign up but then nobody would use it.
We had to do something radically different to figure out a version that worked and finally get to product-market fit (PMF). Here’s exactly what we did.
This is a guest post from Dani Grant, CEO and co-founder of Jam.
From 0 → 1,000 Jams
Why did v8 of Jam work? We ignored tons of good advice and tried something different.
1) Dogfooding
All the startup advice says you should launch early and get your product into users’ hands. But instead, we didn't let a single user in until we were happy using it ourselves. Those weeks of internal testing made all the difference. We were harsh critics, and the feedback loop was super tight.
We spent six weeks building the eighth iteration of Jam and then tested it in house for a few weeks until we got to the point where we’d miss the product when it was gone.
2) Small scope, high quality
People say if you're not embarrassed by your v1, you've shipped too late. People told us to “just ship” because you’ll know you have PMF when people are even willing to use a broken product.
This is outdated advice. Today, quality is non-negotiable. We didn't ship until the product was bug-free. This made a huge difference in early usage.
3) Few, focused pilots
We only let in a handful of early users. Our first goal was just five weekly active users (WAUs).
We found them by posting in Slacks and subreddits. Then we validated their need for Jam before granting access. That way we could test our hypothesis by whether or not they retained.
We were extremely focused and had a hypothesis about which customers would find so much value in the product that they would use it every week. Specifically, we looked for companies with a complicated front end where the quality of their app directly corresponds to revenue.
All of the pilot customers, except one, were brand new to Jam. We sought out new customers, people who had never tried an earlier version of Jam, because we learned that it’s nearly impossible to change a first impression. We needed to experiment with a new cohort that had zero preconceived notions.
4) Retention
We only tracked one metric in the early days: retention.
You can't fake retention. If a product is not useful, you don't retain. Our team tracked usage in a simple Google Sheet and watched for streaks week over week. Only once retention was healthy did we open up Jam to the public.
When we were 19 weeks in, two of the original five pilots had 19 week sprints. Finally, 20 weeks after the pilots and more than six months after starting work on v8, we were ready to launch.
From 1,000 → 50,000 Jams
Fun fact: the night that we put a signup button on the website, a French YouTube channel (here’s the actual clip) pitched Jam on their series and 200 French people signed up for the product overnight.
But we weren’t doing any proactive marketing at that point.
In fact, this was a super painful time for us. Two months after opening signups, Jam went down intermittently for a week. The codebase had been through eight pivots and we had a rocky code foundation. Since we had been in an experimental phase up until this point, we hadn’t prioritized spending the time to build a clean codebase.
In product-led growth (PLG), the only thing that matters is the product and the product grows just by people using it. The most important thing to focus on at this stage is finding any rough edges of the product and fixing them so people keep using it and share it elsewhere.
Ultimately, we spent six months rewriting all the important parts of the code, bit by bit. We swapped out our database and refactored the core flows. It was painful to stop shipping new features for six months, but we couldn’t have been a productive team if we hadn’t taken that time. (At this point, the product was still completely free to use.)
During this time we continued to keep tabs on what users wanted and invested in scaling user feedback. We started reaching out to the top 100 users each week to check in. We’d track their feedback in Coda and discuss it as a team in Slack.
From 50,000 → 100,000 Jams
With the product now ready for shipping new features, it was time to add growth loops. Jams were already easy to share, but we also added four basic loops (nothing fancy). Now about 20% of signups are from one of these flywheels.
Invite your team
Call to action (CTA) for logged out users to sign up for Jam
Share via email
Refer a friend
The first two (invite your team, CTA for logged out users) worked well for us.
When we tested the option to refer a friend (and get free swag), though, it didn’t work as we had hoped. While 55% of our signups come from word of mouth, only a very small percentage are from refer a friend. That’s because people don’t use the refer link; they just talk about it.
With PLG, the better the product, the more people use it, and the more it grows. So, more user feedback = more growth! We focused on quickly shipping features people want and always letting them know. That encouraged those users to give even more feedback!
All our product data tracking used to be in Google Sheets manually. Now everything is in a Metabase dashboard which I open daily. To track what users are asking for, my co-founder wired up Slack + Grain + Coda + Linear with Zapier to track feature requests and close the loop with users when we ship what they asked for. (He wrote more about that here.)
From 100,000 → 500,000 Jams
We wanted to find more ways to connect with existing users and reach new ones. So we started writing more about our learnings from building Jam.
At first, this made me so nervous. But it has been really positive. And it’s now how many people hear about Jam. (The tool that all of this happens in is Typefully.)
We also started hosting events so we could meet more of the community in person. We had heard from an early employee at Figma that events were big for them in the early days and had a hypothesis it could work for us, too.
Our first event was Engineering Horror Stories off the Record. We didn’t know if people would show up, but we met so many of our users. Now we’ve done 10 events in four cities and are planning one event per month. Ideally in the future we could empower builders to run their own events that we sponsor — and we just launched a sponsorship program for these builder meetups with interest from folks in 15 different countries.
(We’ve considered virtual events, too. The problem is that I haven’t been to a virtual event that’s been really great.)
From 500,000 → 1,000,000 Jams
As we passed 100,000 Jams, Irtefa (my co-founder) and I did a 4am live brainstorm where we wondered what the most aggressive version of Jam marketing would look like. Then, we just started to do it ourselves.
It was time to hire people to take over what we were doing and expand on it. We hired two creators who love building on the internet. We’re now experimenting with new types of content (like Instagram) as well as some paid marketing – stay tuned.
The profile of a founding marketer differs so much company to company and we had to be super specific about the tasks and skills required to be successful at Jam. For us, the new hire had to be extremely organized around all of the different tasks; that was more important than having 10 years of experience in developer tools.
Closing advice
Reflecting on these three years, going from zero to one is MUCH harder than growing something that’s already working. Product-market fit was super binary; there weren’t shades of PMF for us.
Looking back, there were three things I wish I had done differently.
I wish I had a different mindset to get to PMF. Being a Type A, I tried to work as hard as I could to get there. But the mindset you need to be in to get to PMF is slow, curious and creative. You can’t rush it.
I wish I read The Mom Test earlier. It changed how we did user interviews and gave us a recipe to get more insights from each call. Game changing in the early days.
I wish I set better expectations with the team. The biggest risk is that people give up. How do you keep the team afloat as you search for PMF? What I figured out later was to set better expectations with the team about how long it took other companies and how long it may take for us. (This blog post was very motivating.)
This piece is part of a series about the startup journey Zero to One. Catch up on prior editions featuring Rewind, Warmly, Pinecone, Attio and Tango. If you’d like to add your 🔥 story, just hit reply.
 | A guest post by
|