Too often, businesses measure success by the number of features shipped rather than the impact those features have. The real goal isn’t just to deliver features—it’s to create meaningful outcomes for our users. This shift in mindset starts at the product definition stage, with product and engineering working together, supported by leadership that empowers them to explore, research, and validate user needs.

What Are We Even Building?

Using Agile methodologies doesn’t mean skipping the critical work of understanding your users, evaluating your systems, and researching your market. Agile isn’t a shortcut—it’s a framework for continuous learning and iteration. The best teams don’t build based on assumptions; they gather data to validate their ideas before committing development resources. The priority should always be solving real problems, not just ticking off feature requests.

Stop Taking Orders

Great product managers, program managers and engineers don’t function as simply "order takers." You’re not a waiter (no disrespect to food service personnel). Too often, teams approach stakeholders, customers, or business leaders and simply ask, “What do you want?” Then, they compile those requests into a roadmap without clear prioritization or a real understanding of the business goals. This is a surefire way to end up in what Melissa Perri calls the “product death cycle” from her insightful book, Escaping the Build Trap.

She explains: “The product death cycle is a specific form of the build trap. You are implementing ideas without validating them. It’s not the customer’s job to come up with their own solutions. That is your job. You need to deeply understand their problems and then determine the best solutions for them.” (Emphasis mine.)

I’ve worked at companies trapped in this cycle—often because of the misguided belief that Agile means no upfront work or documentation. That couldn’t be further from the truth.

The Role of Sprint 0

Before planning or estimating begins, Sprint 0 is the time to ask critical questions that lay the foundation for a successful project:

• Why are we building this? What problem are we solving, and for whom?

• Who is our customer? What is the key benefit they’ll receive from this product?

• How does this align with business priorities? Why is the company willing to invest in this work?

• What’s the competitive landscape? Who are our competitors, and how do we differentiate?

Once the answers to these questions are agreed upon, they should be prominently documented and revisited frequently—perhaps as part of a project initiative description reviewed in standups or sprint planning.

Just as important as knowing what we will do is defining what we won’t do. Clearly listing the big-ticket items that are out of scope prevents scope creep and keeps the team focused. This list should be visible and regularly reviewed.

Another key aspect of Sprint 0 is understanding the people involved. Beyond your immediate team, who are your key stakeholders? What dependencies exist? Identifying these early helps build relationships and ensures that critical conversations happen before roadblocks arise.

At this stage, while you may not have a fully detailed technical solution, you likely have an idea of what’s needed. Document the high-level technical design, highlight potential risk areas, and consider buy vs. build decisions. Ask:

• Do we have the right skill sets for this project?

• Are there assumptions about specific tools or libraries?

• Are there any known risks we should prepare for?

Speaking of risks—no team can predict the future, but they can anticipate potential challenges. Identifying risks early allows for proactive mitigation planning. Sprint 0 is the time to have open, honest conversations with stakeholders about risks, needs, and consequences if critical support isn’t provided.

Finally, consider trade-offs before moving into estimation. What aspects of the project are flexible, and which are fixed?

• Can scope be adjusted?

• Are resources flexible or locked in?

• What level of quality is expected?

• What is the timeline, and is there any flexibility?

Knowing the answers to these questions ensures informed decision-making and a smoother development process.

Final Thoughts

Agile isn’t about moving fast for the sake of speed; it’s about moving intelligently. Taking the time upfront to validate ideas, define clear goals, and align stakeholders prevents wasted effort and ensures that what gets built delivers real value. Sprint 0 is not a bureaucratic step—it’s a critical foundation for success. By shifting focus from feature output to meaningful outcomes, teams can escape the build trap and create products that make an impact.