What does your company brand promise? Dani Grant from Jam.dev
Jam shipped and launched on Product Hunt seven separate times over 18 months. Each time, people signed up and then nobody came back. The only thing that changed with version eight wasn't the idea — it was that Dani Grant stopped tracking signups and started tracking one number: retention.
Dani Grant is the co-founder and CEO of Jam.dev, a bug-reporting tool built to capture everything an engineer needs to reproduce a bug — DOM playback, console logs, network requests, stack traces — in one shareable link. She and her co-founder built it after living the problem themselves as product managers at Cloudflare, spending their days chasing down engineers to prove a bug was real instead of shipping.
We get into why Jam's first seven launches all failed the same way, what she actually means when she says the company is having weekly conversations with its top 100 users, and the specific Cloudflare habits — building deliberately disposable proofs of concept, and never shipping anything externally until the internal team already trusts it — that she's carried directly into how Jam builds today.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
What does Jam actually do, and why did you build it?
Jam is like a flight recorder for web application bugs — when a PM or QA tester hits something broken on staging, they click the Jam extension and it copies a shareable link with everything an engineer needs to debug: the last 30 seconds of DOM playback like a video, console logs, network requests, the timing waterfall, the stack trace, session metadata, even user IDs. The engineer opens the link and has a perfect re-recording of the bug without a single follow-up question or screen share. My co-founder and I were both product managers at Cloudflare, on Cloudflare Workers and the 1.1.1.1 DNS resolver, and instead of unblocking engineers we spent our time chasing them down trying to prove a bug was real, because they couldn't reproduce it. There was no tool that helped non-engineers show engineers what was actually happening in the software, so we built one ourselves.
You've talked about shipping seven different versions of Jam before the eighth one worked. What changed?
In the first two years, we did 45 user interviews right out of the gate and heard so much genuine frustration on those calls that we knew we'd hit a real nerve — one early interviewee tried to sign his whole team up and pay us before we even had a product. So we built and launched on Product Hunt, got a lot of signups, and then nobody kept using it. We changed things, launched again, same result — that was the story of the company for about 18 months, seven different flavors of Jam, all different approaches to the PM-to-engineer communication problem. The eighth one worked, and what changed wasn't a single insight so much as what we were actually measuring: we stopped looking at signups and started tracking one metric, retention. We saw people using it in genuine weekly streaks, and that felt fundamentally different from anything before it.
How do you actually tell the difference between something that's interesting to people and something that's working?
The bar to get someone to adopt a new tool into their actual workflow is incredibly high, because it means changing their behavior and taking a real risk on something new — think about how many new products you've tried this year versus how many you've actually kept using weekly. The difference between working and not working is retention: are people just checking something out because it's interesting, or has it become part of their core weekly workflow? It helps to break 'my startup isn't working' into smaller sub-problems — if you're getting real signups and interest, that tells you you've found problem-market fit, a real problem people will go out of their way to try to solve. The separate, harder question is whether you've found product-market fit: does the product solve it well enough that people come back every week. If you have problem-market fit, that's genuinely validating, because it means you should keep going — Notion took three years to reach product-market fit, and Figma took even longer.
Is there a shortcut to product-market fit, for a founder who doesn't want to iterate through years of the desert?
The most reliable shortcut is doing something that already has proven product-market fit, just meaningfully better — Linear didn't invent the issue tracker, issue trackers already had product-market fit, they just executed faster, better designed, and more ergonomic than what existed. You don't have to invent something new, you just have to do it better. What's been humbling to see, though, is meeting founders whose last company was a smashing success I genuinely admire, and watching them start over and have to go through the exact same multi-year iteration process as everyone else. That's just the nature of it — the beginning of a company is murky and not that fun, no matter your track record.
If someone copied Jam feature-for-feature tomorrow, how much would that actually matter?
People with a product background tend to think of a company as basically its product — everyone says a company is more than its product, and you nod along while quietly thinking, sure, but mostly it's the product. Over time I've seen that's actually missing the point. Datadog and Sentry have genuinely similar product categories, but completely different go-to-market motions and brands: Sentry is something an individual developer signs up for with a credit card and just starts using, while Datadog runs a top-down enterprise motion — conferences, cold outreach. Copying the product doesn't mean copying the company, because the company is the go-to-market, the brand, and the trust you've built, not just the feature list.
How do you think about brand for a tool like Jam?
No developer has ever said they wish they could spend more time fixing bugs — using our product is never someone's favorite moment in their job. So our job is to get out of the way, be fast, be simple, and keep things light, both for the engineer debugging and for the person who just hit an unexpected problem mid-task and needs to feel back in control with as little cognitive load as possible. More broadly, I think of brand as the feeling a company promises its users — ease, productivity, being in control — and a brand is only as good as its consistency in delivering that feeling every single time. Apple makes me feel a sense of pristine, high-quality design; if they shipped one ugly product, that trust would break immediately. The real job for a startup's brand is identifying exactly what that feeling is supposed to be, and then guarding it relentlessly, the way a TV show can nail its first season and then completely misjudge what made it good going into the second.
How do you make sure Jam doesn't drift away from feeling 'dead simple' as it grows?
Once you've put the feeling into words — for us, dead simple, easy, fast — you evaluate everything internally against those specific words. When we're looking at a design, we ask: could this be even more dead simple, could it feel even easier or faster. We've also learned some concrete patterns from watching users on screen shares. Trendy UI choices like unusually shaped buttons actually add cognitive load, because users haven't seen that pattern before and have to think about it — a completely standard button is instantly recognizable. Pro tools lean on icons because their users invest time becoming experts and value density and speed, but in a moment of panic when something's broken, we'd rather use words and verbs — 'take a screenshot,' 'share your last minute' — so the brain doesn't have to guess what it's clicking.
How do you decide what to build next, especially now that you have far more users pulling you in different directions?
I expected more users would mean more scattered, conflicting requests — that was my experience as a PM at Cloudflare, where users ask for the whole gamut of things. But at a startup, there's usually just one obvious next thing everyone's asking for at the same time. Every week I email the top 100 users from the previous week — a script pulls the list, an email tool sends a simple 'how's everything going, what would you like to see next,' and I personally reply to every response. Because it's specifically the most active users from that exact week, the responses are relevant and immediate, and we consistently get the same two or three requests clustered together rather than a scattered wishlist. All of that feedback goes into an internal Slack channel called 'users say the darnest things,' and because the whole team sees it, deciding what to build next rarely feels like corralling anyone — it's usually just obvious to everybody at once.
What specific habits from Cloudflare have you carried into how Jam builds product?
A few things. Cloudflare is a genuinely audacious company — they made TLS free for the entire web, and the constant internal question is 'could we be thinking bigger.' They also reward shipping above almost everything else; velocity, getting something real into users' hands, is what's actually celebrated. The less obvious one: when Cloudflare builds something genuinely new, like Workers, they build a proof of concept explicitly meant to be thrown away first — fast, scrappy, just to answer 'should we build this, and what should it look like' — and only then build the real version properly. Critically, no external user touches it until it's good enough for internal Cloudflare employees to actually want to use themselves; if it's not good enough for us, we have no business thinking it's good enough for someone else. We follow that same sequence at Jam now, and the tightness of that internal feedback loop has been a genuine unlock.
What's the most important thing you've learned that you'd pass on to another founder?
There's classic startup advice to be embarrassed by your first product, to duct-tape something buggy together and ship it. Fifteen years ago that was excellent advice, but in a world where everyone relies on mobile and remote software constantly, things genuinely have to be good for people to bother using them. One of our biggest unlocks was deciding to stop shipping buggy releases and hold ourselves to production quality even before we had product-market fit — purely as a discipline, it changed the nature and clarity of the user feedback we got back almost immediately.