One of the most common failure points I see in early-stage startups isn't a lack of progress, it's disagreement about what progress actually means. Two founders can look at the exact same three months and read it completely differently: one is convinced things are moving in the right direction, the other is convinced the product is underperforming, and neither is really wrong, because neither is anchored to a shared definition of success. Every conversation after that becomes interpretation instead of evaluation, which is exactly the moment you can least afford to lose clarity.
The fix I keep coming back to is deceptively simple: define success in advance, at time-bound checkpoints both founders agree on before launch, so that when the difficult update conversation happens later it's a comparison against expectations you already set, rather than a debate about who's reading the situation correctly.
I like structuring this around 30, 60, and 90 days, and keeping each checkpoint anchored to something observable rather than a feeling. At 30 days, I'm usually looking for evidence that the system works in the real world, a first paying customer, a small number of genuinely active users, no unresolved critical issues blocking core usage. Nothing dramatic, just proof the thing functions outside the room it was built in. By 60 days, the question shifts to early traction: is there a small but consistent paying cohort, any sign of repeat usage, a feedback loop with real users that's actually running. By 90 days, I want directional clarity more than volume, consistent acquisition signals, a clearer read on what's resonating and what isn't, enough signal to make an informed call about what the product should become next.
The exact numbers matter far less than the fact that both founders agreed to them beforehand. What matters is that everyone's evaluating progress against the same reference points instead of their own private version of "on track." This is usually where the real tension lives: one founder is optimising for patience and iteration, the other for validation and urgency, and without shared benchmarks both of them can be technically correct, which is exactly what makes the disagreement so hard to resolve on the merits.
Time-based success criteria won't guarantee the outcome you want. What they guarantee is that you'll know, at each checkpoint, whether you're on track, and in my experience, that's usually the more urgent problem to solve.