# Start product recommendations with rules, not AI.

**Author:** Ivan Misic  
**Published:** 2026-09-06  
**URL:** https://ivanmisic.net/blog/product/start-recommendations-with-rules

**In plain English**

Start with a small set of products that already matter to the business. Define which customers and products are eligible, decide what wins when rules conflict, and measure the result. Add AI only when you have reliable data, a clear objective, and evidence that rules are no longer enough.

For a first release, I would start product recommendations with a small set of products and explicit rules.

A product needs to show the “best next offer.” By the end of the meeting, an AI engine has appeared on the architecture diagram (no one remembers drawing it).

Nobody has yet written down which offers can be combined, which customers are eligible, or what “best” means.

## Start with the products that matter

I once worked on recommendations for a portfolio of around 500 products. Eight best sellers drove more than 70% of sales, but the business request still covered the full portfolio, every possible combination, and every possible outcome.

Why start with all 500?

I would pick ten products that already matter. For each one, decide which add-on, upgrade, or follow-up product makes sense. Put those combinations in front of customers, record the outcome, and learn. The rest of the catalog has not disappeared. It has simply stopped holding the first release hostage.

A small scope also makes bad assumptions visible. If a team cannot agree on the best companion offer for ten important products, adding another 490 will not create clarity.

## Eligibility belongs to customers and products

A recommendation usually hides two separate decisions:

1. **Eligibility:** which products are valid for this customer, and which products can be combined with each other?
2. **Ranking:** among the valid choices, which one should appear first?

Customer eligibility can depend on ownership, location, account state, channel, consent, or the ability to fulfill the order. Product eligibility is different. A wall shelf should not be paired with brackets that cannot carry its weight. An installation service may cover only some locations. Two care plans may cover the same purchase and should not be sold together.

These are constraints, not predictions. Filter invalid combinations before ranking anything.

Then choose how the compatibility rule works. An allow list says which combinations are valid. A deny list assumes combinations are valid unless a rule blocks them. Neither is always right.

| Situation | Better starting point | Reason |
|---|---|---|
| Only a small share of combinations is valid | allow list | a new product stays unavailable until someone approves the relationship |
| Most combinations are valid, with a few exceptions | deny list | the team maintains only the exceptions |
| A wrong combination creates high customer or fulfillment cost | allow list | the safer default is to block an unknown combination |

Pick one default and define what happens when a new product has no rule. Do not maintain an allow list and a deny list as competing versions of the truth. That is how the same basket becomes valid in one service and invalid in another.

Ranking comes after this filter. Here is the same logic written as product rules someone could actually enter. Priority 1 becomes the default when two rules in the same group qualify.

| If | Then | Else | Priority |
|---|---|---|---|
| For mounting hardware, an **oak wall shelf, 120 cm** is selected and its compatible concealed brackets are in stock | return the **concealed steel bracket pair** | return no concealed-bracket recommendation | 1 |
| For mounting hardware, an **oak wall shelf, 120 cm** is selected and its compatible black brackets are in stock | return the **black steel bracket pair** | return no black-bracket recommendation | 2 |
| For installation, an **oak wall shelf, 120 cm** is selected and the delivery postcode is inside the service area | return **wall-shelf installation** | do not show the installation service | 1 |
| For matching furniture, an **oak dining table, 180 cm** is selected and six matching chairs can ship in the same delivery window | return the **set of six oak dining chairs** | return no chair recommendation | 1 |
| For protection, a **three-seat sofa** is selected and the basket does not already contain a care plan | return the **five-year furniture care plan** | do not offer another care plan | 1 |

If both bracket rules qualify, the concealed pair is the default and the black pair remains an alternative. The customer sees the products and services. The team sees the conditions, resulting offers, and fallbacks. If no rule qualifies, returning no recommendation is a valid result.

<figure>

![Recommendation flow from customer and product eligibility through explicit rules and priority to offers shown in the interface](/images/blog/product/rules-before-models.png)

<figcaption>Eligibility and priority make a useful first recommendation system. Catalog complexity stays behind the interface.</figcaption>

</figure>

## Keep the rule table boring

I do not mean building a generic rules platform. That is how a contained need becomes a program.

For the first version, a configuration file, spreadsheet, or small database table is enough. It only needs to answer four questions: who is eligible, which combinations are allowed, what wins when several offers qualify, and why the result was shown.

Store those decisions somewhere the team can inspect and change safely. Define who owns them, what happens when no rule matches, and how a proposed change is tested before customers see it.

Start light and slightly dirty. Do not build a polished administration interface before you know how often the rules will change and who will own them.

Years ago, I built a drag-and-drop navigation manager for a help and support section. The navigation was configured once and then changed perhaps twice a year. We spent around two weeks building an interface that saved someone two or three hours of editing a file.

Wrong investment.

If rule changes become frequent and the file becomes an operational problem, build the smallest interface that removes that problem. Until then, let engineering keep the structure controlled and give commercial or operations teams a safe way to propose and test changes.

If the explanation for a recommendation cannot fit in a support note, the first version is probably too clever.

## Somebody has to reconstruct the decision

When a customer sees an unsuitable offer, somebody will investigate. Whoever takes that job needs the same thing: which rule fired, on what input.

A deterministic rule can return a useful explanation: “Shown because you selected the oak table, these chairs belong to the same range, and the bundle is in stock.”

Bad rules are perfectly deterministic, but you can inspect one and see why it fired. That matters while the team is still arguing about what “best” means.

This is also why a pile of stakeholder wishes is not a strategy. The decision order has to be explicit. I covered the same prioritization failure from a broader product angle in [The laundry-list trap](/blog/product/laundry-list-trap-prioritization).

## Rules capture knowledge you already paid for

Think about the time invested in salespeople, shop staff, customer support, product managers, and operations. They learned how the products work, which combinations create trouble, which questions customers ask, and when an offer helps rather than irritates.

That knowledge is hard to copy because most of it is spread across people, documents, systems, exceptions, and habits. A small rule table will not capture all of it, but it forces the team to turn part of that knowledge into explicit decisions that can be tested.

You can build an internal AI system around your data, documents, propositions, guardrails, and business rules. But the structure still has to exist. The model needs to know which outcome it is trying to improve, which combinations are forbidden, what information it may use, and who owns the decision when it is wrong.

If the team cannot explain the recommendation without AI, the model will inherit the same ambiguity with a more impressive architecture diagram.

## AI does not remove the product decision

A model still needs an objective. Click probability? Conversion? Margin? Retention? These goals can point to different recommendations.

It also needs data that reflects the decision you want to improve. Historical clicks may reflect [placement](https://developers.google.com/machine-learning/guides/rules-of-ml), availability, or a strong campaign rather than customer preference. A model can learn those effects without understanding why they happened.

Before supporting a model, I would want clear answers to four questions:

1. What measurable outcome should improve?
2. Which decisions cannot be handled well by explicit rules?
3. Is the available data useful, permitted, and understood well enough?
4. How will the team compare model performance with a simpler baseline?

The baseline matters. If an ordered rule set performs just as well for the current volume and use case, the model is extra machinery without extra product value.

AI can speed up implementation. It cannot decide what a good recommendation means. That is the larger argument in [AI made building easy. Knowing what to build just got expensive](/blog/ways-of-working/ai-made-building-easy-knowing-what-to-build).

## Rules create the baseline

Rules force you to write down inputs, outputs, exclusions, and what wins a conflict. Then you can see which rules collide, where people override them, and which products never produce a useful next offer.

I would record the eligible set, what selected the result, what we showed, and what the customer did next. Suppressions, overrides, and errors belong beside it so the team can see where the normal decision failed.

That tells me where the rules fail and whether better ranking is worth paying for. It also gives a future model something honest to beat.

## Earn the engine

Expand when the first slice works. Build an administration interface when rule maintenance becomes the expensive part. Add a model when it can beat the rule baseline on a goal worth improving.

Until then, ten products and a boring table will teach you more than an AI engine covering 500 products nobody has agreed how to recommend.