---
title: Product
description: Shape and deliver your product, then keep work moving toward the founder's goal through evidence, decisions and follow-through.
category: Product & design
when: Turn a selected idea into a useful product, improve its offer or experience, investigate results, or take ongoing responsibility for progress toward a business goal.
---

# Product

Choose work that advances the founder's goal, deliver the agreed result and learn
what changed for customers. Start at the needed outcome, not a mandatory sequence.
Use [working together](product/collaboration.md) for meaningful intermediate decisions.

## Start from what exists

Recover the current goal, requirements, working product, relevant customer evidence,
recent changes and unfinished decisions. Separate implemented behavior from plans
and unchecked claims. Make the intended outcome observable, with a relevant
baseline and decision date when needed; activity is not progress by itself.
A folder with credentials and skills is not a product.
Reuse valid work; investigate a consequential conflict rather than silently replacing
the founder's direction. Explain the next outcome and why it matters now.

For a broad business goal, consider delivery, acquisition, monetization and ongoing
operations together. Some work can proceed in parallel; more development is not
automatically the priority. A low wallet limits affordable work, not which strategy
is effective. Keep a narrow requested repair within its scope.

| Needed outcome | Start here |
| --- | --- |
| Ongoing progress toward a business goal, or continuation of agreed work | [Business Loop](product/business-loop.md) |
| A direction, customer or offer worth exploring | [Market and acquisition](market-and-acquisition.md); a selected idea does not need rediscovery |
| An agreed product, useful result and first whole version | [Define value](product/value.md) |
| A credible offer, price and customer commitments | [Shape the offer](product/offer.md) |
| A clear journey, public explanation and interface | [Design the experience](product/experience.md) |
| An explanation of a loss, weak result or opportunity | [Diagnose](product/diagnose.md) |
| A first release, justified improvement or known repair | [Plan and deliver](product/deliver.md) |
| A judgment on current results and what follows | [Evaluate](product/evaluate.md) |

When an idea is selected but the product is not built, choose the smallest coherent
release that delivers its promise. Use the applicable methods above to settle
missing decisions, then `egbe-os-product-build` for engineering and implementation.
Existing research, requirements, designs and code are inputs to continue, not
documents to recreate. Add accounts, payments, AI or a particular stack
because the result needs them, not because Egbe offers them.
If a consequential demand question comes first, propose a bounded check instead
of treating a full build as the only next step.

Use the EGBE skill index to find the named skills and other needed capabilities;
these are task-specific choices, not a checklist to run in full. A known broken
payment path needs a repair; an untested price or offer needs evidence. Working
checkout proves capability, not willingness to pay. For ongoing business responsibility,
use [Business Loop](product/business-loop.md); for a narrower recurring need,
use [evaluation](product/evaluate.md#arrange-useful-follow-up) before configuring it.

Keep concrete scope, requirements, decisions, evidence and results in the work's
existing records under `egbe-docs/`. Update the relevant product requirement when
an accepted change alters it. No new master tracker or audit document pack is needed.
Keep a one-task adjustment in its plan; change this method only for an adopted
ongoing way of working, following EGBE's playbook-change instructions.