Too many teams rush into sprints before the direction is clear, and it eventually backfires as unnecessary work and a high price tag. Discovery and Sprint 0 help the team pause for a moment and build shared understanding before execution. When done right, these phases set a strong foundation for development and lead to less waste and more value.
When a product team decides to implement new features or build a new product, there’s usually a strong desire to start sprints and other agile ceremonies immediately. Too often, teams move forward with only a handful of assumptions — the origins of which not everyone knows — and a half-filled backlog acting as a compass, mostly containing only technically well‑defined tickets.
This kind of start leads easily to a feature that doesn’t fully meet user needs, unnecessary work, and a general feeling of moving fast but learning very little.
If the team would take even one or two weeks before the actual development sprints begin to focus on building shared understanding and finding the right direction, the following sprints would be easier and clearer to execute. This critical moment is known as product or service discovery and sprint zero. The most important outcome of these phases is aligning the vision with reality.
Product Discovery and Sprint 0 not only clarify direction but also reduce the risk of investing in the wrong solution. When we ensure early on that we are solving the right problem and identify the critical uncertainties, leadership and project managers gain better predictability and control. This minimises costly surprises that might occur later.
Product Discovery – Clarifying direction before building
Product Discovery is a process aimed at clarifying the team’s objectives before anything is built. It involves researching user needs, business goals, and technical constraints and opportunities. The outcome is the overlap of these three important perspectives. At this stage, the goal is not heavy documentation but ensuring the team has a clear direction.
Key questions of this phase are:
- Are we solving the right problem?
- Who are we building this for?
- How will we measure success?
The methods are flexible: you can interview customers and other key stakeholders, create prototypes, or even test ideas on the street. The most important thing, however, is the goal: clarify direction and learn before committing.
The designer’s role is crucial when uncovering insights from end users. Designers can plan and facilitate co‑creation activities that answer the key questions of product discovery. The format is open: interviewing users and stakeholders, prototyping, or quick field testing. What matters the most is staying focused on the goal; clarifying direction and learning early. This ensures the team gains the insights needed to make informed decisions before development begins.
Sprint Zero – A step toward reality
Many people confuse Product Discovery and Sprint Zero or see them as separate concepts. But actually, they complement each other in building a strong foundation.
Sprint Zero often triggers mixed feelings — understandably so. It is sometimes perceived as a time‑consuming bottleneck or a mini‑waterfall phase before actual development, which goes against agile and lean principles.
The key to success is having the entire team spend a moment creating a clear view of shared goals and the structures that support achieving them. This gives development a strong start.
Concrete outputs from Sprint Zero may include:
- A clarified product vision and clear success metrics
- The first prioritised backlog
- Quick user validation of critical functionality
- Shared team rules, roles, and ways of working
- Description of technical constraints and selected systems
- Identification of risks and dependencies
If too much time is spent here or if Sprint Zero is seen as mandatory for everything, it will slow down development and value creation. The solution lies in balance, knowing when it’s necessary and when the team can move straight into development. At its best, a well‑scoped sprint zero accelerates progress.
A real‑life example:
In one team, the backlog was full of different features and deadlines were pressing the whole team. When a new team member — a designer — joined the moving train, the team had to pause briefly to reassess its direction. Together they realized that one of the major backlog items would have required massive development effort and new technology — and was primarily based on leadership’s assumptions about user needs.
The designer suggested asking users directly. The team conducted a few interviews, and the results changed everything: the scope of the planned feature shrank to a fraction of its original size. This saved significant time and money — and allowed the team to focus on functionality that truly created value for users.
Sprint Zero and Product Discovery together – the compass and the first steps
Product Discovery and Sprint Zero form a powerful pair, enabling the team to start development with greater confidence and produce value faster instead of just outputs.
You can think of the difference this way:
- Product Discovery is the compass, ensuring the team is headed in the right direction
- Sprint Zero takes the first steps, turning early insights into a backlog and ways of working
In this transition, the designer’s expertise is significant: designers turn insights into concrete outputs, visualise user journeys, and support the Product Owner in refining the backlog into meaningful, testable units.
If discovery stops, learning stops
Continuous discovery is a way of working, not a one‑time exercise. It’s important to involve the entire team in early research and direction‑setting, but start small: test one assumption, one user flow, or one prototype at a time. All discussions should tie back to the shared product vision to keep decisions aligned. Above all, uncertainty is okay, not everything needs to be planned upfront so that learning can guide the next steps.
In a world where speed increases and growth targets drive decision‑making, it may feel difficult to pause and remember that development is inherently cyclical. That’s why, after sprint zero, it is essential to maintain this iterative cycle instead of slipping into waterfall mode. Discovery findings should continue to be reviewed and challenged regularly. Agile service development has proven to be an effective way to produce high‑quality services regardless of company or organizational size.
In our next blog post, we will dive into building a vision that guides the whole team forward and clarifies direction. Stay tuned!
