Start a new product in Taiga

Prepare one clear outcome

This scenario uses a fictional equipment request service. A manager records an employee’s equipment request and the decision. Employee self-service is a later extension. Use synthetic records during learning. The scenario does not authorize real personnel data.

Before creating the product, confirm that the organization and relevant shared context are set up. Identify the person who owns the service outcome and the team that owns its operating environment.

Write an initial boundary: the first version records requests and decisions. It does not order equipment, approve spending automatically, or change payroll records.

Choose how the product starts

Choose Start from scratch for this new service. Use Import codebase when an existing repository should define the starting point. Import is a choice at product creation, so make it deliberately.

Creation also asks whether Taiga writes Infrastructure code and CI/CD pipelines. These are separate responsibilities. If your platform team already supplies a part, turn that generation option off and describe how the work is done today.

For example: “Our platform deploys reviewed container images through the existing repository pipeline. Use its workload identity and environment configuration.” Confirm that this description is accurate before relying on it.

Put context before the conversation

Discovery starts with Context. Add relevant product reference material and standing instructions before the conversation. Put rules shared by several products at the organization or factory level.

For the equipment service, useful context includes the employee identity method, approved data services, and the rule for manager access. State unresolved questions explicitly. Do not invent a retention period to complete a form.

Then describe the service in the conversation. Explain the users, desired result, restrictions, and what is outside scope. The specification is saved as a draft while you work.

Review and publish intent

Read the specification for assumptions that would change implementation. In this scenario, check whether a manager can see all employee requests or only requests in their team. That difference affects permissions, data flow, and tests.

Publish the specification when its content is suitable for downstream work. Draft changes do not replace the published version until you publish again. Continue through the required documents and review their assumptions. The Discovery lesson explains dependencies and outdated documents.

After all eight required documents are published, finish Discovery and plan the initiatives. The generated sequence is a proposal you can inspect and change.

Connect the real delivery target

Connect the repository before detailed initiative planning. Define the intended environments at the same time, even though an environment is not required to start planning.

An environment description does not grant cloud access. Your pipeline performs deployment. Check the repository branch, identity, infrastructure ownership, and required setup tasks with the responsible team.

The useful outcome of this scenario is a defined product and reviewable work grounded in its real delivery environment. Practice the decision sequence in the Taiga workflow simulation.