Write the PRD before you build the configurator

A brand asks for a custom configurator. The team builds it. The main product can be selected, every result is technically valid, and the interface behaves as specified.

Then a more important question arrives: how do we help customers discover the other products that make this configuration more useful?

We have lived this one, and we tell it without the brand's name. Nothing was broken. The configurator did exactly what the brief asked. The brief described a selection tool, and the customer needed help assembling a setup that works. That question belonged in the brief, before anyone drew a screen.

This is what a Product Requirements Document is for. Not a long specification, and not a ritual. One shared place where the team decides what the experience must help the customer do, what the system has to support, and what is deliberately left out.

A working configurator can still be incomplete

Most configurators start from a visible selection problem: which version should I choose? That can be the right place to start. It is rarely the whole decision.

Around the main choice, the customer usually also needs to know:

1. what is required to use the main product at all;
2. which products are compatible with the option they picked;
3. what extends the product into another situation or season;
4. what is optional rather than necessary;
5. what to do once the main configuration is complete.

When these questions surface after the interface is designed, the gap is not a missing cross-sell block. The scope described the wrong job. Adding a carousel of accessories under the result treats the symptom and leaves the decision undefined.

That is an architecture problem before it is a design problem. If the store needs a quiz, a filter or a configurator in the first place, choose between a quiz, a filter or a configurator from the decision, not from the feature list.

Decide before you design

This is not a project plan. Some catalogs, integrations and product rules need far more work before anything is built. The first pass is a discipline for a smaller question: can the team make the important decisions visible before it starts building?

The first pass answers five questions.

1. What is the customer trying to decide? "Build the right setup" is too vague to design against. Is the customer choosing one compatible product, assembling a complete configuration, comparing two close options or adapting a setup to a specific use? Name the uncertainty too: compatibility, performance, required parts, future use, or the difference between two products that look alike. The answer decides what the configurator shows, and what it refuses to show.

2. What does the customer need before and after the main choice? Before it, a short explanation of the problem the product solves. After it, a required component, a compatible accessory or a product that extends the setup. This is where cross-sell becomes a real design question. The goal is not to put more products in front of someone. It is to find the next relevant decision and explain why it belongs there. Required, optional and useful-only-in-one-situation are three different messages. Collapse them into one recommendation and the customer has to work out which is which.

3. Which product relationships are real? A list of products is not a catalog. Before the interface, write down which products are compatible, which are alternatives, which are required together, which are optional additions, which extend the setup to another use, and which are invalid in combination. If the team cannot explain these relationships, the interface cannot explain them either. A polished selector on an unresolved product model only makes the confusion easier to browse. This is why we treat the catalog as a decision system, not as a spreadsheet behind the pages.

4. What is deliberately out of scope? For each proposed feature, finish one sentence: after this exists, the customer will be able to… If the ending is vague, the feature needs a sharper job. If it depends on product data or compatibility rules that do not exist yet, it belongs in Later, not Build.

5. What evidence defines working? Decide it before development makes the checks expensive. The list depends on the project, but it usually includes valid and invalid combinations, a reason shown for each recommendation, required and optional products labelled correctly, the handoff from configuration to product page or cart, mobile behaviour, analytics events that describe the intended decision, and a sensible answer when no valid recommendation exists.

None of these checks proves commercial success. They prove that the built experience behaves as agreed, which is the precondition for measuring anything else.

Keep, Cut, Build, Later

Every configurator project arrives with a backlog of good ideas. Sorting them is part of the PRD, not a separate meeting. A simple split is enough:

The point is not to make the project smaller for its own sake. It is to stop the team from building the visible part of a problem while the decision underneath stays open. A short Later list is also a kindness to the next phase: it records what was considered and why it waited.

In practice, Cut is where most of the argument happens. A comparison table, a wishlist button, a second entry point from the homepage: each sounds reasonable in a workshop. Ask the sentence from question four. If nobody can finish it with something the customer actually needs to decide, the item is noise, however good it looked in the reference site.

What the document looks like

The useful document is short. The thinking it records is not optional. Before anyone designs the configurator, write down:

1. the customer situation, in one paragraph;
2. the primary decision;
3. the decisions around it, before and after;
4. the product relationships, as a table the catalog team can check;
5. the features that are cut or deferred, with the reason;
6. the acceptance evidence.

Then ask one question of the first interface sketch: does it solve the whole decision, or only its most visible step?

The relationships table is the part teams most often skip, and the one that matters most later. It is what the product data has to hold, what the recommendation logic reads, and what the design has to explain. Visual choices sit on top of it; we write about how visual decisions sit on the architecture separately.

Who should be in the room

A PRD written by one person is a wish list. The first pass works when the people who own each layer of the decision read the same page: whoever owns the catalog and its data, whoever answers customers' questions, whoever will design the screens, and whoever will build and maintain the logic.

Each of them catches a different gap. The catalog owner knows which compatibility rules exist only in someone's head. The person who answers customers knows which question comes up after the purchase, not before it. The designer sees where two messages will compete for the same space. The developer knows which rule is cheap to hold in product data and which one will need custom logic.

The output is not consensus on every detail. It is a shared list of what is decided, what is open, and who closes each open point before the build starts.

Fix the structure while it is still a conversation

A PRD does not promise a perfect build. It gives the team a chance to disagree while changing the structure is still cheap: a sentence in a document instead of a rebuilt component, a remapped catalog or a redesigned flow.

When we build a configurator, the rules come first and the screens follow. That is what configurators built on decided rules ↗ means in practice: the relationships, the invalid combinations and the next step are agreed before they become code, design and product data.

If you are about to brief one, start smaller. Write down the one decision the configurator must complete, and the decisions around it. If that page is hard to write, the build will be harder. We can look at it with you in an initial audit ↗, before the first screen exists.