---
title: "Start a clear product with Praxis"
route: "/solutions/by-stage/starting-a-product"
description: "Turn intent into an accepted requirement, design decision, and verified increment before AI-generated code gets ahead of the product."
template: situation
intent: "Help a founder stop coding ahead of product clarity."
parent: "/solutions/by-stage"
primaryCta: { label: "Read the BA guide", href: "/docs/plugins/ba" }
schemaType: Service
hero:
  eyebrow: "Starting a product"
  headline: "Start building after the product is clear — not before."
  sub: "When code arrives while scope is still moving, make the product decision acceptably concrete before another role starts building."
  primaryCta: { label: "Read the BA guide", href: "/docs/plugins/ba" }
sections:
  - { id: pain, kind: pain, heading: "The moment code gets ahead of the product" }
  - { id: why-agents-rush-ahead, kind: explanation, heading: "Why a fast agent makes this worse" }
  - { id: praxis-flow, kind: flow, heading: "A flow that makes intent buildable" }
  - { id: first-package, kind: cards, heading: "The first package another role can accept" }
  - { id: proof, kind: proof, heading: "What remains visible" }
  - { id: next-step, kind: cta, heading: "Start with the requirement" }
---

## The moment code gets ahead of the product

You are a founder looking at a convincing implementation while the customer promise, business rule, and acceptance condition are still being argued in chat. The code is real; the product decision is not.

## Why a fast agent makes this worse

An individual coding agent can answer the prompt in front of it. It cannot make an unsettled decision durable for the Architect, Developer, and the person who must accept the result.

## A flow that makes intent buildable

Start with the uncertain request. BA clarifies the business rule and acceptance, asks the owner to approve the scope, and creates the initial canonical WP. Architect opens that same package and adds the relevant technical design. Developer then implements one bounded increment and records the checks. One founder can work through these responsibilities in separate sessions.

## The first package another role can accept

- **Accepted scope** — the request, business rule and acceptance criteria are reviewable.
- **Initial canonical WP** — BA supplies a stable identity and links for Architect.
- **Technical enrichment** — Architect adds selected decisions and constraints to that package before Developer begins.

## What remains visible

Architect can open what the founder approved rather than reconstructing intent from chat. A later Runtime execution package has a separate local identity, so record its mapping to the canonical WP when used.

## Start with the requirement

Read the Business Analyst guide, then use one live product question as the first accepted package.