Spec-Driven Development (SDD) has quickly moved from being an experimental workflow to something many teams are now exploring seriously. The idea of expressing intent through a specification and letting tools and agents use that to plan, generate, and validate work sounds appealing, but fitting it into the realities of day-to-day engineering is a different story.

In this talk, we’ll take a grounded look at how SDD can coexist with the messy realities of modern software teams. Where do features live? In your project board, or inside the codebase? What if you do not have a monorepo? How do you balance evolving specs with distributed ownership and asynchronous delivery? In fact a more fundamental question being what is even a spec and the mixed use of jargon like PRD.

Drawing on examples from my work and the broader Spec-Driven ecosystem (OpenSpec, Spec-Kit, and similar tooling), we will explore what is working, where it is met with friction, and where SDD actually adds value. This is not a tutorial or a pitch for the approach itself. It is an attempt to map the principles of SDD onto the practical rhythms of product engineering, design, and AI-assisted implementation.

If you have been curious about SDD but unsure how it fits into your team’s structure, this session will give you a realistic lens to evaluate and adopt it at your own pace.

Learning Outcomes
1. Is SDD only for Greenfield? or does it work for Brownfield and if yes how?
2. Understanding the ecosystem, tooling and their philosophy to categorise and chose one that aligns with your thought process
3. What Spec-Driven Development looks like in practice - across different team and code repo structures.
4. How big should a feature be for SDD? What limits can you hit?
5. Avoiding token drain generating Markdown Mountains
6. What SDD does not replace? and the basic skills that help extract the most out of SDD