Jeffrey Jorgensen

September 11, 2026

Proposal: An Agentic Product Development Process

This is a hot take, and a work in progress. Last edited: June 17th.

A product + design + engineering operating model that preserves engineer autonomy while improving quality, coherence, and customer outcomes.

The opportunity is to formalize how design plugs in so that:

  • engineering keeps driving product development with high velocity,
  • design work is pulled in at the right moments, not bolted on at the end,
  • prioritization reflects business + customer impact, not just “who asked first,”
  • shipped experiences become more cohesive, usable, and scalable.

This proposal introduces a lightweight, repeatable process that fits an agentic culture—centered on a Design Requests backlog in Linear and a simple prioritization + delivery cadence.

1) Guiding principles

  1. Product remains the product driver. Product chooses what to build and when.
  2. Design optimizes for customer outcomes and coherence. Design focuses on clarity, UX quality, consistency, and “what’s next.”
  3. Work moves via pull, not push. Design pulls from a clearly defined request backlog that engineering adds to when it’s determined UI/UX needs refinement.
  4. Short feedback loops > heavy process. Minimal ceremony; fast decisions; iterative shipping.
  5. One source of truth lives in Linear. Requests, scope, priority, status, and decisions are visible and trackable.

2) Roles (clear ownership, no PM required)

Engineering (Feature Owner)

  • Owns the feature/problem end-to-end.
  • Creates the Design Request when design input is needed
  • Provides context, constraints, and success criteria
  • Implements the iteration post-design and ships

Design (Experience Owner for the request)

  • Owns UX exploration, flows, UI, content clarity, and system consistency
  • Runs lightweight critique and validation as needed
  • Produces deliverables sized to the request (from quick tweaks → full flows)

Product Team (Prioritization Council)

  • A short, likely-weekly recurring meeting to prioritize design work from: 
    • customer value
    • business impact
    • risk
    • urgency
  • Makes tradeoffs explicit, keeps the backlog healthy.

(Optional but recommended)

3) The Linear workflow: Design Requests as a first-class backlog

Create a dedicated “Design Requests” workflow in Linear

  • Team: “Design” (or a dedicated project board within current structure)
  • Issue type: Design Request
  • Standard fields:
    • Feature owner (engineer)
    • Product Area
    • Request type (Tweak / New flow / IA / Visual polish / System work)
    • Customer impact (Low/Med/High)
    • Business impact (Low/Med/High)
    • Urgency (Now / Next / Later)
    • Target ship window (if any)
    • Link to feature issue/PR (if exists)
    • Screens/recording (Loom encouraged)

Design Request template (what engineers file)

Engineers open a request when:

  • a feature is functional but needs UX refinement,
  • there’s uncertainty about flow, edge cases, information architecture,
  • visual/pattern consistency matters,
  • the experience may create support burden or confusion.

Required sections in the request:

  1. What are we building / improving? (1–2 sentences)
  2. Customer problem / job-to-be-done
  3. What’s live or in-progress today? (screenshots/video)
  4. What needs design help? (be specific)
  5. Constraints (tech, timing, platform, known limitations)
  6. Success looks like… (measurable or observable)

This keeps design from hunting for context and keeps autonomy with the engineer.

4) Cadence: simple rituals that keep things moving


A) Weekly “Design Triage” (30 minutes)

Participants: EPD/R&D

Purpose: Prioritize the design backlog and keep alignment with customer/business needs.

Outputs:

  • Requests are assigned a priority and size (S/M/L).
  • Each request is tagged with one of: 
    • Quick Win (≤2 hrs)
    • Small (≤1–2 days)
    • Medium (≤1 week)
    • Large (multi-week; requires slicing)

B) Twice-weekly “Design Desk” office hours (optional, 45 minutes)

Purpose: Fast clarification for engineers before they file, or while design is working.

This reduces low-quality requests and speeds iteration.

C) Async design review in Linear (default)

Design shares:

  • a short Loom walkthrough + link to Figma,
  • decision summary in the Linear issue,
  • what changed and what engineering should implement.

Live reviews only when the scope is medium/large or cross-cutting.

5) End-to-end flow (example with Jason)

Step 1: Product determines what we’re building

Product + Design compile research into crafted PRD

Step 1: Engineering ships v0 (or is close)

Eng builds the feature with strong autonomy.

Step 2: Eng files a Design Request in Linear

She includes: Loom, what feels off, edge cases, constraints, customer feedback

Step 3: Design Triage prioritizes

Design compare requests against business/customer needs and pick what design pulls next.

Step 4: Design produces the iteration plan + solution

Design explores and documents:

  • user flow adjustments,
  • layout/pattern improvements,
  • copy clarity,
  • states (empty/loading/error),
  • consistent components.

Step 5: Engineering implements and ships v1

Enginering updates the feature, ships improvements, and links the PR/release note back to the Linear request.

Step 6: Close loop

Design request is closed with:

  • “shipped in release X”
  • any follow-ups as new requests.

This supports rapid iteration while keeping the ownership where it is today.

6) Prioritization model (simple, explicit)

Use a lightweight score or rubric in triage so tradeoffs aren’t political:

Priority Factors (suggested):

  • Customer impact: Does this remove confusion? reduce friction? unblock adoption?
  • Business impact: retention, expansion, conversion, support cost reduction
  • Risk: compliance, data loss, trust, major UX regressions
  • Reach: how many users touch it
  • Effort: size of design + engineering iteration

Even a “High/Med/Low” across these makes decisions clearer and repeatable.

7) What design produces (right-sized outputs)

Design deliverables depend on request size:

Quick Win / Tweak

  • annotated screenshot
  • microcopy suggestion
  • spacing/alignment update
  • component swap recommendation

Small–Medium

  • updated flow + key screens
  • state definitions (empty/loading/error)
  • interaction notes
  • “implementation checklist”

Large

  • slice into milestones (“v1 flow”, “edge cases”, “polish/system alignment”)
  • design brief + decisions log
  • structured critique checkpoints

8) Quality bar: “Definition of Ready” + “Definition of Done”

Design Request is “Ready” when:

  • problem + goal are stated,
  • current state is shown (screen/loom),
  • constraints and ship window are known,
  • owner is named.

Design work is “Done” when:

  • solution is documented (Figma + Linear summary),
  • acceptance notes exist (states, behavior, copy),
  • engineering knows exactly what to change,
  • any follow-ups are filed as separate issues.

9) How this improves the process

Benefits

  • Preserves engineering agency while reducing UX drift.
  • Clear intake and prioritization prevents design from being reactive.
  • Business/customer lens is applied consistently through triage.
  • Faster iteration cycles: v0 → design polish → v1.
  • Better consistency over time (design can identify recurring system needs).

Common failure modes this prevents

  • “Drive-by” design asks that lack context.
  • Design work getting interrupted constantly.
  • Polished UI without solving the underlying customer confusion.
  • Inconsistent patterns as the product grows.