Skip to main content
FeatureFactory
Build pillar · product plan → work orders

Work Order Generator

Paste a product plan, list your goals and acceptance criteria, and get structured work orders - scope, acceptance, and definition of done - ready to hand to a build agent or an engineer.

Inputs

4
Work orders generated
4
Acceptance criteria mapped

Criteria per order

Illustrative - a balanced split keeps orders shippable in isolation.

WO-01
2
WO-02
1
WO-03
1
WO-04
3

Markdown

# Work Orders

> Derived from product plan: Reviewers cannot tell which pull requests are risky until they open them.

## WO-01 - Surface a risk score on every PR in the list view

**Scope:** Deliver the changes required to surface a risk score on every PR in the list view. In scope for this order only; do not expand beyond the acceptance criteria below.

**Acceptance criteria**
- [ ] A numeric risk score (0-100) is visible on each PR row without opening it
- [ ] No score is shown for draft PRs

**Definition of done**
- [ ] Code reviewed and approved by at least one other engineer
- [ ] Automated tests cover the acceptance criteria and pass in CI
- [ ] Merged behind a flag or safely deployable in isolation
- [ ] Instrumented so the outcome can be measured post-ship

## WO-02 - Highlight PRs touching high-blast-radius files

**Scope:** Deliver the changes required to highlight PRs touching high-blast-radius files. In scope for this order only; do not expand beyond the acceptance criteria below.

**Acceptance criteria**
- [ ] PRs touching flagged paths show a distinct warning badge

**Definition of done**
- [ ] Code reviewed and approved by at least one other engineer
- [ ] Automated tests cover the acceptance criteria and pass in CI
- [ ] Merged behind a flag or safely deployable in isolation
- [ ] Instrumented so the outcome can be measured post-ship

## WO-03 - Cut median time-to-first-review for high-risk PRs

**Scope:** Deliver the changes required to cut median time-to-first-review for high-risk PRs. In scope for this order only; do not expand beyond the acceptance criteria below.

**Acceptance criteria**
- [ ] The score recomputes within 5 seconds of a new push

**Definition of done**
- [ ] Code reviewed and approved by at least one other engineer
- [ ] Automated tests cover the acceptance criteria and pass in CI
- [ ] Merged behind a flag or safely deployable in isolation
- [ ] Instrumented so the outcome can be measured post-ship

## WO-04 - Integration, telemetry & outcome measurement

**Scope:** Wire the delivered slices together end-to-end and add the instrumentation needed to confirm the product plan outcome after release.

**Acceptance criteria**
- [ ] All prior work orders are integrated on the target branch
- [ ] A dashboard or event stream exposes the metric the product plan promises to move
- [ ] A baseline value is captured before wide rollout

**Definition of done**
- [ ] End-to-end path verified in a staging or preview environment
- [ ] Success metric is queryable and attributed to this change
- [ ] Rollout / rollback plan documented

Generated work orders

WO-01

Surface a risk score on every PR in the list view

Scope. Deliver the changes required to surface a risk score on every PR in the list view. In scope for this order only; do not expand beyond the acceptance criteria below.

Acceptance criteria
  • ✓A numeric risk score (0-100) is visible on each PR row without opening it
  • ✓No score is shown for draft PRs
Definition of done
  • •Code reviewed and approved by at least one other engineer
  • •Automated tests cover the acceptance criteria and pass in CI
  • •Merged behind a flag or safely deployable in isolation
  • •Instrumented so the outcome can be measured post-ship
WO-02

Highlight PRs touching high-blast-radius files

Scope. Deliver the changes required to highlight PRs touching high-blast-radius files. In scope for this order only; do not expand beyond the acceptance criteria below.

Acceptance criteria
  • ✓PRs touching flagged paths show a distinct warning badge
Definition of done
  • •Code reviewed and approved by at least one other engineer
  • •Automated tests cover the acceptance criteria and pass in CI
  • •Merged behind a flag or safely deployable in isolation
  • •Instrumented so the outcome can be measured post-ship
WO-03

Cut median time-to-first-review for high-risk PRs

Scope. Deliver the changes required to cut median time-to-first-review for high-risk PRs. In scope for this order only; do not expand beyond the acceptance criteria below.

Acceptance criteria
  • ✓The score recomputes within 5 seconds of a new push
Definition of done
  • •Code reviewed and approved by at least one other engineer
  • •Automated tests cover the acceptance criteria and pass in CI
  • •Merged behind a flag or safely deployable in isolation
  • •Instrumented so the outcome can be measured post-ship
WO-04

Integration, telemetry & outcome measurement

Scope. Wire the delivered slices together end-to-end and add the instrumentation needed to confirm the product plan outcome after release.

Acceptance criteria
  • ✓All prior work orders are integrated on the target branch
  • ✓A dashboard or event stream exposes the metric the product plan promises to move
  • ✓A baseline value is captured before wide rollout
Definition of done
  • •End-to-end path verified in a staging or preview environment
  • •Success metric is queryable and attributed to this change
  • •Rollout / rollback plan documented

From product plan to work orders, deterministically

A product requirements document tells you what to build. Work orders tell an engineer - or an AI build agent - exactly how the work is sliced, scoped and checked. The gap between the two is where most AI web-development goes sideways: a vague prompt produces vague code, and nobody can tell whether the feature actually landed. This tool closes that gap by breaking a product plan into small, shippable units with explicit acceptance criteria and a definition of done.

The decomposition is deterministic: one work order per goal, with your acceptance criteria distributed across them, plus a final integration and measurement order so telemetry is never an afterthought. If you have not written the product plan yet, start with the product plan generator or read how to write a product plan. To sharpen the checks each order carries, pair this with the RICE score calculator when you need to prioritise which orders ship first.

Work orders are the Build step in the FeatureFactory loop. See how it connects to the rest on the Build and Measure pages - because a factory that ships without measuring is just guessing faster.

Frequently asked questions

It applies a deterministic decomposition: one work order per goal, plus a final integration & measurement order that closes the loop. Your acceptance criteria are distributed across the goal-derived orders so every order owns a concrete, checkable slice.

Ship work orders that measure what they ship

FeatureFactory takes you from product plan to shipped feature to measured outcome - Plan, Build, Measure in one loop. These work orders are the handoff point. Wire them into the product and every ship comes with proof.

Get early access Take the tour