1729 AI Labs

Stage 1 · Product Discovery Studio · Human judgment

Decide what should exist. By using it first.

Most discovery ends with a document that guesses what to build. Ours ends with the product, approved by the people who'll use it.

Bring an idea, a sketch, or a full spec. In a day it's a working frontend — every user, every role, every workflow, real permissions, realistic data. Your stakeholders test-drive it. You leave with the product they approved and the PRD that describes it.

One behavior instead of four interpretations.

How the week runs
Pricing exceptions · v3 · day 4
Request exception
My requests
Request
Status
Discount
Value
Acme Corp — 6% off list
Pending · Regional mgr
6%
$12,400
Northwind — 11% off list
Escalated · Finance
11%
$48,900
Contoso — 4% off list
Approved
4%
$3,100
Logged in as Sales rep · sees 2 of 6 screens Realistic data · RBAC applied
Approval queue
My region
Override ≤ 8%
Request
Status
Discount
Value
Acme Corp — 6%
Needs your approval
6%
$12,400
Fabrikam — 7.5%
Needs your approval
7.5%
$9,800
Northwind — 11%
Out of your authority
11%
—
Logged in as Regional manager · sees 3 of 6 screens Realistic data · RBAC applied
Escalations > 8%
Pricing tables
Rejected
Request
Status
Discount
Value
Northwind — 11%
Escalated from West
11%
$48,900
Tailspin — 14%
Escalated from East
14%
$71,000
Wingtip — 9%
Rejected · reason logged
9%
—
Logged in as Finance · sees 3 of 6 screens Realistic data · RBAC applied
Audit log
All decisions
Item
By
Day
Time
Acme Corp — approved
R. Patel · Regional mgr
Day 4
09:12
Northwind — escalated
auto · rule 3.2
Day 4
09:40
Wingtip — rejected
M. Chen · Finance
Day 3
16:05
Logged in as Auditor · read-only · sees 2 of 6 screens Realistic data · RBAC applied
01

The document was never the requirement

A PRD is an interpretation. Every engineer, designer, and tester who reads it builds their own version in their head. Six readers, six products.

The gap between what the business asked for and what shipped is discovered in UAT — when it costs the most to fix. Point tools didn't touch this. Copilots make the coding faster; the requirement is still prose, and every handoff still re-interprets it.

The Product Discovery Studio replaces the document with the product. You approve behavior you've clicked through, not sentences you've read.

The old way

  1. Idea
  2. document
  3. read six ways
  4. build one of them
  5. UAT
  6. "that's not what we meant"
  7. rework

The Product Discovery Studio

  1. Idea
  2. working product
  3. each role uses it
  4. decisions surface
  5. approve
  6. build exactly that
02

How it works

Start with whatever you have.

There's no template to fill in first. The less you bring, the more the first version teaches you — a one-line idea becomes a full product in a day, and the questions it raises are the ones that would have surfaced in month five.

  • A sentence
  • A napkin sketch
  • Last quarter's slide
  • A 60-page spec
  • A legacy system to replace
  • Anything in between

  1. Day 1

    Your input becomes a working frontend

    All roles, all workflows, realistic data. Where the input was thin, the first version makes the gaps visible instead of hiding them.

  2. Day 2

    Each stakeholder logs in as their role

    The approver approves. Ops works the queue. The customer sees the portal. What's wrong surfaces on a screen, not in a meeting.

  3. Day 3

    Missing decisions go to their owners

    "Can a regional manager approve their own region?" — routed, answered, built into the next version.

  4. Day 4

    Fourth version, final walk-through

    Roughly nine hours of your people, total, across the week.

  5. Day 5 · Human gate

    Approve the product

    That approval is the requirement. Nothing gets re-interpreted after it.

Expose the unknowns before they become the backlog.

03

What the Studio does

The system does the work. Your people make the calls.

Gathering context, generating versions, finding the open questions: that's the system. Choosing, approving, rejecting, steering: that's your team.

Resolve

One working behavior, not competing readings of a document.

Expose

The questions that would have surfaced in month five surface in week one.

Validate

Real users, real roles, real screens — before a line of backend exists.

Define

An execution plan and decision record the build can run from.

04

What you walk out with

The frontend

Running
  • Every screen, every role, every workflow
  • RBAC applied per role
  • Realistic data, not lorem ipsum
  • Shareable link — put anyone in front of it

The PRD

Generated

Generated from the approved product, so it cannot drift from it.

3.2 Override authority
Regional managers may approve exceptions ≤ 8% within their region. Above 8% routes to Finance.
↳ decided day 3 · owner: VP Finance

The decision record

Audit-ready
  • What was decided, and what was surfaced
  • Who resolved each one, and when
  • What was explicitly left out

Yours to keep

Build it however you build.

Take the frontend and PRD to your own team or your vendor — or send the approved product to the Dark Factory. Discovery stands alone. The build is optional.

05

Validate with real users, not a deck

Every role sees only what it would see in production.

Role-based access means you can put actual users in front of their actual screens. Feedback lands on a product, not a wireframe — so approval means something.

Sales rep

  • Request exception
  • My requests
  • Approval queue — not visible to this role
  • Audit log — not visible to this role

Regional manager

  • Approval queue (my region)
  • Override ≤ 8%
  • Other regions — not visible to this role
  • Audit log — not visible to this role

Finance

  • Escalations > 8%
  • Pricing tables
  • Rejected requests
  • Raise a request — not visible to this role

Auditor

  • Audit log
  • All decisions, read-only
  • Approve — not visible to this role
  • Edit — not visible to this role
06

Your team's time

Nine hours. Then zero.

Two months of requirements in the old model — and it keeps coming back during test. In the Studio your people spend one week and about nine hours, and they are not pulled back in to explain the decision.

The old model measures progress in phases. This one measures it in decisions.

HOURS / WEEK FROM YOUR TEAM Traditional Requirements · ~2 months Test · fix · re-decide Studio 4 versions · week 1 · 9 h Approved. The row above is in week 1 of 8. Then zero — your team is not pulled back in.
07

Who it's for

01

Product managers who own the "what"

— and keep being blamed for the "how".

02

Teams whose requirements cycle is measured in months

Two months to a document nobody trusts. One week to a product everyone has used.

03

Anyone who has shipped exactly what the document said

— and still got it wrong.

08

Where it goes next

Option A

Build the way you build today.

Hand the frontend and PRD to your team or your vendor. The approval is the spec, the record is the audit trail, and the frontend is the acceptance test.

Option B

Send it to the Dark Factory.

Architecture, code, integrations, infrastructure, tests, release evidence — built from the approved context and deployed to your cloud. Your team is not pulled back in to explain the decision. Change it later? Hit update. It ships again.

See Stage 2 · Lights-out execution

Either way

The human gate is the same.

Approve the product before the build. Lights out on execution. Never on authority.

Humans decide what should exist.
The Product Discovery Studio makes it executable.

Stop describing the product. Approve it.

Idea in. Approved product + PRD out. One week.

Stage 2 · Lights-out execution
See the Dark Factory Contact