In the original toolkit, I called this competency Feature Specification. Today, I call it Product Definition. The job was never just to write a spec. It was to make clear what we’re building and why. Now, that clarity can come from a working prototype, a written document, or ideally the two evolving together. The artifact changes. The responsibility doesn’t.
AI raises the stakes. Teams now include agents that can turn direction into working software at remarkable speed. The old problem was too little context; the new problem is often too much. The challenge is to choose the right artifacts and synthesize them into one concise, coherent, executable definition.
What this essay explores
- Define the outcome, functionality, and user experience clearly enough for people and agents to build.
- Use PRDs and working prototypes together to make product intent tangible and testable.
- Separate decisions that reflect intent from incidental details and questions that remain open.
- Give agents enough context to avoid default choices without overwhelming the team.
- Evolve the shared definition through reviews, testing, conversations, and building.
- Scale from defining your own work to setting standards that align entire teams.
The work is choosing exactly the context the product demands, not simply adding more.
Key takeaway
Product Definition is a shared, evolving understanding of what to build and why, expressed with exactly the context people and agents need to make strong decisions.
