Cheap Code Raises the Value of Product Judgment
- Harshal
- 3 minutes ago
- 2 min read
AI can make small tickets wasteful, but product judgment still needs a PRD.
Some teams argue that a pull request (PR, a code change) should come before a product requirements document (PRD). I disagree, including on AI-native teams.
I still rank them PRD > PR > ticket (one scoped engineering change item).
Tickets are a way to communicate
Engineering tickets were a way for different functions to communicate with each other. For example, product managers or designers communicate the changes that the engineering team needs to build.
Skip tickets for small AI coding changes
When writing a tracker ticket (Jira, Linear) takes more effort than implementing the change, skip the ticket. Implement the change directly. This case shows up often with AI-assisted coding for AI-native teams. You already know the fix. The ticket adds little value.
PRs are concrete, reviewable, closer to shipped value, and less likely to go stale.
Why PRDs still matter for product judgment
A product requirements document (PRD) defines the customer problem, the components needed to solve it, and the behavior and metrics that indicate success.
Skip-ticket logic applies only to tickets. One PRD usually leads to dozens of PRs. Each PR solves one local step. The PRD defines the full problem and shows how the steps connect.
What a good PRD must define
A good PRD does two jobs.
It clarifies the big picture:
Connects multiple parts of the system
Surfaces second-order effects early
Explains customer impact clearly
Forces prioritization decisions
It defines execution:
Problem
Target user
Non-goals
Success metrics
Trade-offs
Sequencing
An example feature without a PRD
Without a PRD that captures big-picture context and execution details, teams optimize locally. They ship fast and miss the outcome.
Example: a team could ship browser notifications in one clean PR with the hope the code will look efficient and complete. However, a short PRD will force the team to make the decisions explicitly:
What user behavior defines success for notifications?
When should the webapp request permission?
How can users grant, block, and later change consent?
Where should notification preferences live?
How should preferences work across shared accounts and multiple browsers?
Skip PRDs for small repeatable changes
Some small changes do not need a PRD. If you are writing the same PRD and the same engineering ticket, skip the PRD.
What shifts when AI lowers build cost
AI reduces build cost. The relative value shifts: building gets cheaper, and product judgment gets scarcer.
AI changes the economics of product work in three ways:
More ideas become buildable. The team needs a stronger filter.
More PRs become reviewable. Reviewers need shared context.
More changes can ship quickly. The team needs clearer sequencing.
On AI-native teams, a solid PRD (including one drafted with AI help) matters more because the bottleneck shifts to deciding what to build and in what order.
Practical rule: PRD, PR, or ticket?
So optimize for the real bottleneck: skip low-value tickets when they add process overhead without adding clarity, keep PRDs for cross-system work where decisions and sequencing matter, and treat PRs as implementation evidence.
