How I Run 0→1 Product Sprints: A Framework for Founders

Most product sprints I've seen start with the wrong question. The team asks "what should we build?" when the real question is "what problem are we confident enough in to build against?"

After running 0→1 sprints at PropertyGuru DataSense, CTOS Data Systems, and for a dozen consulting clients at KG Consultancy, I've landed on a three-phase framework that cuts through the noise.

Phase 1: Problem Compression (Days 1–3)

The first sprint is not about features. It's about reducing a messy problem space into one precise bet you can test in two weeks.

Most founders arrive with a list of problems. That list is not a product strategy. It's a backlog of anxieties. Problem compression means you pick the one pain point where:

1. The evidence is real: not "users said they want this" but "users are doing something painful right now to work around this absence"
2. The wedge is narrow: the smallest possible version of the problem, solved completely for one type of user
3. The test is clear: you can falsify your hypothesis with a 2-week prototype

Key insight: The wedge you're looking for is always smaller than you think. A single user, a single workflow, a single moment of frustration. That's your 0→1.

At PropertyGuru DataSense, we didn't set out to build a full property advisory platform. We started by asking: what does a bank analyst actually need to verify a single property valuation? That compression led to ValueNet, which became the foundation for a full data product suite.

Phase 2: Evidence Sprint (Days 4–11)

Two weeks. Three user interviews minimum. One working prototype. The goal is falsifiable evidence, not a demo.

The common mistake: teams treat this sprint as a build sprint. They spend 10 days building and 2 days "testing." The ratio should be closer to 4:10. Build the minimum surface area needed to provoke a real reaction, then spend the majority of time in front of real users.

What counts as evidence:

• A user changes their workflow because of your prototype
• A user asks "can I actually use this?" Not as politeness. As urgency.
• A user breaks the prototype trying to do something you didn't design for (this is gold)

What doesn't count:

• "This is really interesting" (interest is free)
• NPS scores from a prototype (people are kind to prototypes)
• A completed demo walkthrough where the user didn't ask a single clarifying question

Phase 3: Decision Gate (Day 12–14)

By day 14, you should be able to answer three questions without hedging:

1. What specific evidence do we have that this problem is real and urgent?
2. What did users do with the prototype that we didn't expect?
3. What's the smallest thing we could ship in the next 4 weeks that someone would pay for?

If you can't answer all three clearly, you don't have enough signal to invest in a full build. Run another sprint, not a bigger build.

This is the gate most founders skip. They get excited by positive user feedback in Phase 2, skip the decision framework, and move straight to a 3-month build. Six months later they have a product nobody uses.

The One Thing Most Founders Get Wrong

They conflate "users liked the demo" with "users have a problem worth solving."

A demo can be liked because it's well-designed, because you're likeable, because users are polite. None of those translate to adoption.

The test that actually matters: watch a user try to use your prototype without your help. Don't explain anything. Don't prompt. Just watch. What they struggle with tells you more than anything they say.

If you're about to start a 0→1 sprint and want a second set of eyes on your problem definition, reach out. This is exactly the kind of engagement I do with founders and operators in Malaysia and SE Asia.