Build, Test, Repeat: A Startup’s Guide To Early-Stage Product Building

Build, Test, Repeat: A Startup’s Guide To Early-Stage Product Building

The era of "move fast and break things" is over, according to Dani Grant, co-founder and CEO at Jam. The key to success today is to move fast while prioritising quality.

You’ve probably heard the advice “move fast and break things” thrown around in the startup world. This catchy motto came from Mark Zuckerberg, who initially intended it as advice for Facebook’s design teams and management. However, many entrepreneurs have since interpreted it as a call to prioritise speed, get their product to market as quickly as possible, and refine things along the way.

Is this really the best approach? Dani Grant, co-founder and CEO of Jam, gave us her take on this on our crossover episode between Evolving for the Next Billion and Founder Real Talk, and dropped some valuable advice for early-stage product building.

Jam is a developer tool launched in 2020 that has revolutionised software bug reporting by allowing users to capture troubleshooting information into a shareable link. Today, Jam is used by over 15,000 users across organisations like Unilever, Dell, T Mobile, SeatGeek, StubHub, Ramp, Autodesk, and On Deck. Before co-founding Jam, Dani started her career as a product manager at Cloudflare and went on to be an analyst with Union Square Ventures (USV).

In this article, Dani shares some key insights based on first-hand experience, including:

Validating your product is vital

One of the first things you must do as a founder is validating your work has a real future – a key lesson I got from my experience in the VC world. Conducting user interviews and gathering feedback from potential customers can provide valuable insights into the market’s needs and preferences, allowing you to tailor your product to meet those needs from the get-go.

So the first thing that Jam did was conduct user interviews to validate that what we were solving was not just a Cloudflare problem but an industry-wide problem. The initial 45 interviews were emotional – and we saw that people had real frustration about how bug reporting was being done. In fact, one of the people that we interviewed tried to pay us and schedule an onboarding for his whole team – but there was no product yet. With that, we knew from the beginning that this was a problem we needed to solve, as it was a day-to-day frustration that kept teams from being productive and honestly enjoying working with each other. Today, our customers tell us that with Jam, their teams are a lot more productive and happier because they’re not running into the frustrations of having difficulty explaining what are the bugs that need to be fixed.

Aim for small scope, high quality

After validating the problem you’re trying to solve, the next step is to figure out how to address it. This takes a lot of experimentation and product iteration cycles to get right. In the early days, the popular advice was to “move fast and break things”, going as far as to say if you’re not embarrassed by the first version of your product, you’ve shipped too late.

While I do think that launching fast is important, many people have taken this advice to mean that startups can afford to have a janky product – and that when people jump through hoops to use your product, you have product market fit.

This may have been true 10 years ago, but with the abundance of alternatives out there today, you need clarity when you’re searching for product market fit. Having bugs in early-stage product building obscures clarity, as you would not be able to identify if people are leaving because the product doesn’t work, or that you don’t have product market fit. Therefore, “small scope, high quality” is the mantra at Jam – we kept our scope small so that we could ship a bug-free product. This gave us the clarity that we needed to find product market fit at the early stage.

Iterate quietly

Again, early startup advice says to launch your product fast so that you can quickly receive feedback. However, at Jam, keeping things small and quiet was what helped our product iteration cycles. We focused on building a product that even our own team wants to use and that we would miss when it’s gone. That’s the fastest iteration cycle because you are the customer. Instead of constantly launching, announcing, and testing our product in public, we stayed small, quiet, and focused.

“Dogfooding” adds clarity

Another important lesson in searching for product market fit is “dogfooding” – a process of self-criticism to get clarity because we’re the best critics. While users may not want to give us all the ugly feedback, we will do it ourselves. So we dogfooded heavily, using our own product to get a firsthand understanding of the user experience and identify areas of improvement.

However, be careful not to overdo it, as that was one of the mistakes we made early on. We used our product more than we would expect a user to in replacement of other tools that they have in their stack. This led us to misunderstand how users might be using our product and obscured clarity. Moving forward from that lesson, we tried dogfooding as a user would use it, which really helped us improve the product quite quickly.

Measure customer retention

We also found that the most important metric to track was retention, which indicated to us when to begin iterating again. Most companies track weekly active users, but we track “high-frequency users”. These users have used our product three out of the last four weeks. The reason why we track this is that it not only measures user growth, it also measures engagement and retention. That makes it a harder metric for us to grow, and that’s why we like it. That’s the North Star.

For instance, in the early days, we built a web app where users could frame their website and leave comments. Engineers can then receive the link and the comments would be right there. It seemed promising, so we kept developing it. But what we found is that people used it heavily for the month leading up to a launch. However, in their day-to-day, the friction was too high to go to a web app. Our usage became really spiky, so we continued iterating. By tracking retention, we could see what our users were telling us – that this is close, but it doesn’t solve the problem exactly. So we iterated and made it connect to the development tools of the web application, and that became the current iteration – the current flavor of Jam.

Nurture an open culture of feedback

While nailing the technical aspects of early-stage product building is crucial, it is equally important to cultivate a healthy startup culture. In many cases, this starts with having a good co-founder relationship, and the key to that is to have a very open culture of feedback.

Your job as co-founders is to support each other’s growth and help each other be the best possible leaders you can be. And you need to be able to give each other feedback. Irtefa and I sync up every day for at least a couple of minutes. Every time, he ends by asking if there’s any feedback for him. This gives me permission and a trigger to ask for feedback as well. And if you do that every day, it normalises feedback and gets you into that habit, helping you improve together. So I suggest that every co-founder who wants to improve their co-founder relationship, be the Irtefa in the partnership and ask for feedback daily. It’s not only very helpful in building a healthy startup culture, but it’s also infectious and makes me feel inspired to keep learning and growing.

Learn more about Dani Grant’s founder journey in our Evolving For The Next Billion podcast.

Fresh insights delivered to your inbox.

I would like to receive news and updates from GGV.