A Discovery Phase That Actually Works

Most project failures don't happen during development—they happen before it even starts. Requirements that seemed clear turn out to be assumptions. Stakeholders have conflicting visions. "Simple" features hide complex edge cases.

We've learned to front-load the hard conversations. Here's how.

Week One: Listen More Than You Talk

Day 1-2: Stakeholder Interviews

We talk to everyone who has a stake in the project. Not just the person who signed the contract—their team, their customers, sometimes even their competitors (through public information).

Key questions we always ask:

• "What does success look like in 6 months?"
• "What's the worst-case scenario if this project fails?"
• "Who else should I be talking to?"

Day 3-4: Existing System Audit

If there's an existing system, we use it. Not a demo—actual use. We try to accomplish real tasks and document every friction point, confusion, and workaround.

Day 5: User Research (When Possible)

Even three user interviews surface patterns. We ask users to show us, not tell us, how they work. Screen sharing and thinking-aloud protocols reveal more than any survey.

Week Two: Synthesize and Validate

Day 6-7: Findings Document

We write up everything we learned. Not a glossy presentation—a working document with quotes, screenshots, and our interpretations clearly labeled as such.

Day 8: Requirements Workshop

We present findings back to the client and work through priorities together. This is where conflicting requirements surface. Better now than in sprint 4.

Day 9-10: Technical Feasibility

With real requirements in hand, we assess technical constraints. What can we build in the timeline? What are the risks? Where do we need more information?

The Deliverables

By the end of discovery, we have:

• **Problem Statement**: One paragraph describing what we're solving and why it matters
• **User Personas**: 2-3 archetypes with real quotes and observed behaviors
• **Feature Priorities**: MoSCoW categorization agreed with stakeholders
• **Technical Approach**: High-level architecture and identified risks
• **Timeline Estimate**: Range-based estimate with assumptions documented

Why This Works

The obvious benefit is fewer surprises. But there's a subtler advantage: alignment.

When everyone has participated in discovery, they understand *why* we're building what we're building. Feature requests get evaluated against documented user needs. Scope discussions reference real constraints.

It's not magic. We still have projects that go sideways. But the discovery phase means we catch most problems when they're cheap to fix—before we've written a line of code.