Your first product

This walks one product from nothing to a set of initiatives ready to build. It assumes the organization is already set up, because the policies created there are what your specification is written against.

This page walks it in three phases of your own work: describe the product, shape its documents, and plan the work.

Describe

A product starts one of two ways, and creating one asks you to choose: Start from scratch, where you describe what you want to build, or Import codebase, where Taiga reads an existing repository and drafts the product’s documents from the code for you to review.

This page follows the first path. Import an existing codebase covers the second, and from Plan onward the two paths meet, except that an imported product gets its first initiatives planned for it when Discovery finishes.

Creating the product takes you straight into Discovery.

What Taiga builds for this product

Creating a product also asks whether Taiga writes its infrastructure code and its CI/CD pipelines, starting from your organization’s default. Leave both on if Taiga builds the whole delivery path; turn one off if your platform team already owns it. When you turn one off, say in a sentence how that half is done today, because that sentence is what Taiga designs and plans against. What Taiga builds, by default covers what each switch changes, and you can change the answer later in the product’s settings.

If material already exists that this product should be built from, put it in before you start the conversation. Discovery opens on its Context step, which takes reference files and standing rules for this product. Discovery reads both while you talk, so material added first shapes the specification, and material added later only shapes what comes after it.

Discovery is where a product gets defined. It starts as a conversation: you describe what you want to build, and Taiga builds a structured specification from what you say, covering vision, users, capabilities and technical requirements. You do not need to prepare anything or know the vocabulary. Answer in your own words, and say when something is undecided.

Your progress is saved as a draft, so you can leave and come back. Work through the sections until the specification is complete, then publish it.

Publishing is the moment it starts to count: nothing downstream reads a draft. It is a milestone rather than a point of no return, because a published specification can be edited again as a new version until you finish Discovery. Read it through before you publish all the same, because everything generated afterward is written from what you publish.

You are done with this step when a specification is published.

Shape

Discovery is not only the conversation. Publishing the specification moves it on to its Documents step, where the rest of the document set is generated from it, one document at a time and in a fixed order.

Eight documents are required, counting the specification you already published, and two are optional. While Discovery is open, the product’s home, its sidebar row and its breadcrumb all take you to the step it has reached, so there is one place to continue from. The required ones, in the order they are generated, are:

1. User flows, which define how people interact with the system.
2. Architecture, the technical structure, designed from those flows.
3. Technology decisions, what you build it with, chosen against your organization’s approved technology.
4. Data flow, documenting how data moves through the system. The security work reads it.
5. The security set: a DPIA, a threat model and a risk register. These are three separate documents, generated individually like the others.

Each document is written from some of the ones above it, and the order is a rule: a document can be generated only once every document above it is published. Taiga offers only the next one, and refuses to start a document out of order. Reviewing a document does not hold up the next one: it can be generated as soon as everything above it is published, read or not.

You can generate them one at a time, or all at once: Generate remaining on the progress line writes every document still missing, one after another in that order, after asking you to confirm. It keeps going if you leave the page, and each document lands as Needs review. Stop ends the run after confirming: the document being written is cancelled, nothing after it starts, and everything already published stays. If a document fails, the run stops there. Retry on that document generates it on its own; Resume generates it and carries on with the rest.

The optional two are the Look & Feel, one rendered screen of the product’s look, navigation and forms that everything built afterwards is grounded in, and the Service Blueprint: how the service is delivered end to end, written to be read without a developer in the room. Generate the blueprint if people outside the building team need to understand the service; nothing downstream waits for it.

Review each document as it appears rather than at the end. They feed each other, so a wrong assumption in the architecture is cheaper to fix before the threat model is written from it.

This is the step that used to take weeks or even months. Producing a specification, user flows, an architecture, a data-flow model and a full security and privacy assessment is normally a project of its own, spread across several people. Here it is hours, which changes what is worth reviewing carefully: the bottleneck moves from producing the documents to agreeing with them.

You are done with this step when all eight required documents are published and you have finished Discovery. Finish Discovery is not offered until all eight are published, so the product cannot move on from half a picture. Finishing locks the document set, opens the rest of the product, and takes you to Initiatives. To change a locked document later, reopen Discovery from the document’s page, then finish it again.

Plan

Finishing Discovery lands you on the Initiatives page. Select Plan initiatives there.

An initiative is a slice of work that agents can plan and build. This is where the specification stops being a description and becomes a set of things to do.

What you get is a sequenced set of initiatives, not a feature list

Taiga reads the whole document set, not just the specification, and produces initiatives in the order they can actually be built.

It starts with foundations. The first initiative has no dependencies and covers the things everything else needs: infrastructure, CI and deployment, containers, environments. If you turned Infrastructure code or CI/CD pipelines off, it covers only the halves Taiga still builds, plus containerization, configuration and a health endpoint. On an imported codebase it is scoped to what is missing rather than rebuilding what works.

It covers the layers, not just the features. Persistence, authentication, the core domain, and a real user-facing shell early enough that the product is demoable rather than a backend with a UI promised later. Where a DPIA or threat model exists, compliance work is part of the initiatives rather than a phase at the end.

It is ordered by dependency, not by wishlist. Every initiative records what it depends on, and priority follows that graph: nothing is scheduled before the thing it needs.

It is estimated. Each initiative carries a size, deliberately spread across small, standard and large rather than everything landing on the same number.

It is traceable. Each initiative cites the documents it came from, so you can see why it exists. Security work cites the threat model and DPIA; anything user-facing cites the user flows.

One thing it deliberately does not do is create initiatives for cross-cutting work. There is no “Testing” or “Error handling” initiative, because those belong inside every other one. A set of initiatives padded with those looks thorough and defers the actual work.

Read it before you build from it

The first initiatives are a proposal, and this is the last cheap moment to disagree. Reordering, resizing or deleting an initiative now costs a click; discovering the sequence was wrong three runs in costs the runs.

You are done when the product has initiatives.

Before you plan an initiative in detail

Connect the product’s repository. Detailed planning requires it: Taiga reads the code before it decides on concrete steps, so the plan describes changes to your codebase rather than to a guess about it.

Define an environment at the same time. It is not required in order to plan, and it matters more than that makes it sound.

It matters most for the very first initiative. That one builds your foundation: infrastructure, CI and deployment, containers, hosting. It is the pipeline from your repository to your cloud, and those layers are planned as one because they are coupled: the infrastructure definition feeds the pipeline, and the pipeline deploys to that infrastructure.

Planning it without an environment means planning that pipeline against a guess about where it terminates. Every later initiative inherits the result.

Both live in Product settings.