A Product is the lasting asset
Consider a reservation platform that has been used for years. The code, data model, business rules and release history belong to the platform, not just to the next task. A Project has a narrower objective: upgrade the framework, add a location or introduce quote preparation. Ending that initiative should not discard the knowledge needed for the next one.
Keep shared rules and local scope separate
A rule about which office may access a reservation applies across initiatives. A decision to build a calendar view belongs to a particular Project. Link the Project to the relevant rule version instead of pasting a new copy into every brief. Otherwise two initiatives can quietly acquire different interpretations of the same business constraint.
Do not overwrite the past with a new intention
The owner may deliberately change the cancellation policy. Preserve the old rule and the release that implemented it, then record the newly approved policy. A specification change is not yet a deployed change. The interface should distinguish the target, the code that passed acceptance and the version running in each environment. This makes later investigations possible without reconstructing decisions from chat fragments.
Coordinate changes to shared code
Separate Projects do not imply separate permission to overwrite the same files at the same time. Forge’s shared Product workspace retains a write boundary across initiatives. Planning and isolated analysis can progress without silently changing a running attempt. A new requirement is reconciled against the active scope, while earlier accepted evidence stays tied to the original revision.
One reservation product, three initiatives
A reservation system may go through an initial build, a framework upgrade and an AI-assisted rescheduling feature. These are three Projects, but there is still one Product. Office boundaries, cancellation rules and the meaning of a confirmed booking should not be rediscovered independently each time.
Keep the approved rule version in the Product. Let the framework upgrade reference it without changing it. Let the rescheduling initiative propose an explicit amendment when needed. The accepted code version, the approved target and the deployed release can differ during development; make those links visible instead of marking everything “current”.
| Decision | Useful requirement | Evidence |
|---|---|---|
| Product | Lasting software, rules and history. | A stable identity and versioned specification. |
| Project | A bounded improvement with a reason. | Scope, dependencies and acceptance criteria. |
| Release | A deployable implementation of selected changes. | Code/data version and evidence mapping. |
Where this goes wrong
Copying the entire specification into each Project creates competing versions of truth. Conversely, changing the shared context must not silently rewrite an active attempt. Identify the affected work, preserve its snapshot and decide whether it can finish safely or needs a controlled restart.
Projects organize change. The Product preserves what makes the software coherent.
Turn it into a working checklist
- Give the software a stable Product identity.
- Link Projects to rule versions.
- Distinguish target from deployed state.
- Coordinate shared-code changes.
A concrete next step
Create a Product index containing its rule revisions, active Projects and deployed releases. A reviewer should be able to answer “which rule did this task use?” without searching a previous agent conversation.
Watch a related case
The video could not be loaded. Try again later.