Teklens logo
DEEN
Back to the Playbook
DefineDefinitionDE-05

Draft PRD

Define what to build and why, with observable requirements checked against the real code, so design and engineering can proceed without guessing.

Product statusAvailable now

Context in4 required inputsApproved feature brief or clear problem · Target users and customer evidence · Product objective and success metrics
TransformationProduct Manager + Product Agent + Architecture AgentLocal Files · Atlassian · Code Analysis · UI Drafting
OutcomeProduct Requirements Document with a feasibility note per requirement.Artifact: PRD

Why it matters

A PRD written away from the code produces edge cases in QA and production. Here every requirement gets a feasibility note from the APIs, the schema and the tests before anyone builds.

Owner

Product Manager

Human-led

Participants · Agents

DesignerEngineerProduct AgentArchitecture Agent

Trigger

Event-drivenA feature or opportunity has been approved for definition.

Required context

ConfluenceApproved feature brief or clear problemCustomer evidenceTarget users and customer evidenceProduct BrainProduct objective and success metricsCodeCurrent behaviour and affected code

Optional context

Design systemUI draftsArchitectureEffort estimateArchitectureArchitecture analysisAnalyticsAnalytics baselineFilesCompliance and security constraints

Skills

Local FilesAtlassianCode AnalysisUI Drafting

Methods used inside this Activity: Problem-led PRD structure · Requirement feasibility check against API, schema and tests · Requirements challenge: ambiguity, contradiction, missing non-goals

Activity steps

  1. 1Define problem, users and success metrics.
  2. 2State the solution direction and observable requirements.
  3. 3Check every requirement against APIs, schema and tests in the code.
  4. 4Challenge weak, ambiguous or contradictory requirements.
  5. 5Set scope, non-goals and open questions.

Output

Product Requirements Document with a feasibility note per requirement.

Artifacts

Creates: PRD

Updates: Product Brain

What good looks like

  • Problem-led and concise.
  • Requirements are observable and testable.
  • Every requirement has a feasibility note from the code.
  • Contradictions and gaps are resolved or listed.
  • Scope and non-goals are explicit.

Quality gate

Product approves; engineering and design review before build commitment.

Destination

ConfluenceTeklens onlyProduct Brain

Usually next

People and agents work from the same Product Brain. The owner stays accountable. Assigned agents prepare and check. A named person approves at the gate.

Deep dives from the AI PM Lab

Articles that explain the thinking behind this Activity.

Show us exactly how product work happens today.

Thirty minutes with a founder. We compare your process with the Playbook and pick the first Activity to run on your Jira and your repo.

Book a demoBack to the Playbook