GRGokul Rajaram@gokulrTECH
PRODUCTSPEC: OPEN STANDARD FOR SOFTWARE INTENT
tl;dr ProductSpec is the open standard for software intent before implementation.
The more I worked on PRDs, the more obvious one thing became: Product specs need an open standard.
Why?
Because the PRD has become an overloaded artifact.
Every company has its own template. Every team has its own preferred format. Every PM has their own way of writing. That was manageable when the only readers were humans sitting in the same org context.
AI changes the requirement.
A Product Spec now has to be readable by humans and executable by AI agents.
That means the spec has to carry intent clearly enough for a designer, engineer, product leader, and coding agent to understand the same thing:
• What problem are we solving?
• What is the product bet?
• What is in scope?
• What must be true before this ships?
• What metrics tell us whether the bet worked?
This is why I open-sourced ProductSpec.
ProductSpec is a Markdown standard for software intent before implementation.
The core sections are simple:
• Problem
• Hypothesis
• Scope
• User Experience
• Acceptance Criteria
• Success Metrics
The deeper design principle: Structure the parts machines must execute or compare. Leave readable the parts humans must reason about.
That is why ProductSpec keeps Problem and Hypothesis as readable prose, while giving structured formats to the parts agents and tools need to parse:
• Scope: what is in, out, and deliberately cut
• Acceptance Criteria: what must pass before launch
• AI Evals (within Acceptance Criteria): the evals an AI feature must pass before shipping
• Success Metrics: what should be measured after launch
When to use ProductSpec
ProductSpec is not for every act of building. It is for consequential software work where intent needs to survive handoff. For an individual builder, a Product Spec is useful when the work is complex, risky, long-lived, or being handed to an AI agent loop. For quick experiments, one-off scripts, or throwaway prototypes, it may be faster to brainstorm, build, and iterate directly.
For a team or organization, ProductSpec is most useful when coordination cost appears: multiple people, multiple agents, design and engineering handoffs, customer-facing launches, AI features with evals, or decisions that will need to be revisited later.
ProductSpec does not replace Git, Jira, Linear, Figma, analytics tools, OpenSpec, Spec Kit, or AI coding agents. It sits upstream of them.
ProductSpec -> Engineering Spec -> Tasks -> Code -> Evaluation -> Learning
-- Git stores implementation history. A Product Spec can live beside code in Git, but code commits should not be the first durable record of why the work exists.
-- Jira and Linear store work history. A Product Spec can become epics, tickets, or tasks, but it should remain the durable statement of intent behind those tasks.
-- Figma stores design artifacts. A Product Spec can link to prototypes, mockups, or screenshots through user_experience, but it does not replace the design source of truth.
-- Analytics tools store outcome data.
-- OpenSpec and Spec Kit turn intent into engineering plans.
-- AI coding agents execute implementation tasks.
-- ProductSpec stores the software intent behind the work: the problem, hypothesis, scope, acceptance criteria, and success metrics that downstream tools should preserve.
I'd love for this standard to be broadly adopted, which means it must be broadly owned by the builder community.
Founders, PMs, engineers, designers, researchers, AI builders: please contribute examples, critiques, section changes, parser implementations, validator improvements, and integrations with GitHub, Jira, Linear, Figma, OpenSpec, Spec Kit, and agent workflows. (link below on how to contribute)
If you have scars from writing product docs that looked aligned but failed during execution, those scars belong in the standard.
My goal is for ProductSpec to become the open source format for software intent before implementation.
(links below)