Ashutosh Singh's Post
Ashutosh Singh · article · 2026-04-10 Reader 🖥️
Traditional product specs fail for AI features because they lack the technical specificity engineers need; PMs must replace vague feature descriptions with precise behavioral definitions, golden examples, failure-mode handling, cost/latency constraints, explicit scope boundaries, and eval criteria.
practical · listicle / prescriptive guide — A LinkedIn post offering six actionable rules for writing AI product specs that engineers will actually use. Purely practical — no theoretical framework is developed.
Structure
| Part | Role |
|---|---|
| Hook (paragraphs 1-2) | States the problem: AI PRDs are ignored by engineers |
| Diagnosis (paragraph 3-4) | Identifies root cause: specs written in a pre-AI style with vague requirements and no technical context |
| Six prescriptions (numbered list 1-6) | Core content: actionable rules for writing better AI specs |
| Closing appeal (final paragraphs) | Social motivation: be the PM engineers want to work with, not the one they route around |
Key terms
- AI PRD Spec-Driven Development
A product requirements document specifically for AI/ML-powered features, which must include model behavior specs, evals, failure modes, and cost constraints - Golden Examples Evals
A curated set of 5-10 input/output pairs that define correct model behavior and serve as the basis for evaluation - Evals Evals
Systematic tests that measure whether an AI model meets accuracy and quality thresholds, analogous to QA for traditional software - Failure modes
The specific ways an AI feature can produce wrong or low-confidence outputs, plus the fallback behavior the product should exhibit - Route around
Engineers bypassing the PM and making product decisions themselves because the spec is too vague to be useful
Propositions
- explicitMost PMs still write AI product specs in a pre-AI style (long documents, vague requirements, zero technical context), and engineers consequently ignore them.conf: high
- explicitAI specs should define model behavior as input/output pairs rather than naming features.conf: high
- explicitWithout golden examples (5-10 input/output pairs), there is no way to measure whether an AI feature is successful.conf: high
- explicitIf PMs do not specify failure modes and fallbacks, engineers will make those product decisions unilaterally — and they should not.conf: high
- explicitAI features have real infrastructure costs (latency, inference cost) that specs must explicitly constrain.conf: high
- implicitScope creep is the primary killer of AI features, more so than technical failure.conf: medium
- explicitEval criteria should be defined before launch criteria because AI products require continuous quality measurement, not just ship-date readiness.conf: high
- implicitThe quality of a PM's spec determines their professional standing with engineering teams.conf: medium
Arguments
PMs must fundamentally change how they write AI product specs. strength: medium
Explicit premises:
- Current specs use a 2020-era style with vague requirements and no technical context.
- Engineers ignore such specs and build what they think was meant.
Implicit premises:
- Engineers ignoring specs leads to products that don't match PM intent, which is a bad outcome.
- The misalignment is the PM's fault (fixable by the PM), not a structural or organizational problem.
Inferences:
- If PMs adopt the six practices, engineers will read and follow the specs.
Golden examples are essential for AI spec success. strength: medium
Explicit premises:
- Golden examples provide 5-10 input/output pairs showing correct behavior.
- The AI team uses these to build evals.
- No golden examples means no way to measure success.
Implicit premises:
- Success measurement is a prerequisite for a well-functioning AI feature.
- PMs are capable of constructing valid input/output pairs without deep ML knowledge.
Inferences:
- Including golden examples enables measurable, accountable AI development.
Failure mode specification is a PM responsibility, not an engineering decision. strength: medium
Explicit premises:
- If PMs don't specify failure modes, engineers will decide them.
- Engineers shouldn't make these decisions.
Implicit premises:
- Failure modes are product decisions (user experience, brand risk) rather than technical decisions.
- Engineers lack the product context to make good failure-mode tradeoffs.
Inferences:
- PMs should explicitly document what happens on model error, low confidence, and edge cases.
Narratives
- The PM whose spec gets skimmed and closed: engineers open the doc, skim it, close it, and build what they think was meant.
→ Creates an emotionally resonant pain point for the target audience (PMs) and establishes urgency. - Two PM archetypes: the one engineers fight to work with vs. the one engineers route around.
→ Social pressure / aspiration framing to motivate behavior change. Reduces the decision to identity ('which PM are you?').
Questions addressed
- ✅ Why are AI product specs ignored by engineers?
Because they are written in a pre-AI style: long, vague, lacking technical context, behavioral definitions, and evaluation criteria. - ✅ How should a PM write an AI product spec that engineers will actually use?
Follow six practices: behavioral definitions with I/O pairs, golden examples, failure modes, latency/cost constraints, explicit scope exclusions, and eval criteria before launch criteria. - ⭕ How do AI product specs differ from traditional product specs?
Partially addressed — the six additions are listed, but the post does not discuss what to keep from traditional specs or how the two integrate.
Gaps
- evidenceNo data, case studies, or examples are provided to support the central claim that these six practices actually change engineer behavior. The argument relies entirely on the author's authority and the reader's intuition.
Read next: Look for empirical studies on spec quality and engineering compliance, or case studies from AI product teams. - scopeThe post assumes a team structure where PMs write specs and hand them to engineers. It does not address embedded/cross-functional teams, pair-programming approaches, or iterative spec development — all common in AI product development.
Read next: Explore literature on AI product development process models (e.g., Google's ML product management practices). - depthThe assertion that engineers 'shouldn't' make failure-mode decisions is stated without justification. In practice, failure modes often require deep technical knowledge (e.g., model calibration, confidence thresholds) that PMs may lack.
Read next: Consider shared-ownership models where PMs define user-facing fallback behavior while engineers define technical thresholds. - assumptionThe post assumes PMs can produce valid golden examples (input/output pairs) without significant ML expertise. For complex AI features (e.g., generative AI, multi-modal systems), constructing representative examples may itself require technical depth.
Read next: Investigate collaborative approaches to eval dataset creation between PM and ML teams.closed byGenerative AI in the Real World: Aishwarya Naresh Reganti on Making AI Work in Production — Describes a collaborative eval-dataset creation process — human annotation with reasoning codified into rubrics, inside a continuous cross-functional feedback loop spanning engineering, SMEs, and testing — rather than PMs authoring golden examples alone.