Intelligent Products

Whether it gets better with use. That requires the feedback to be designed in from the start: what the user did next, whether the suggestion was accepted, what was corrected. A product that collects none of that cannot improve no matter what model is behind it, and adding the collection later usually means the first year of usage is gone.

No, but the sequence matters. The first work is usually instrumentation rather than intelligence: making sure the product records what people actually do with it, in a shape that can be learned from. That is unglamorous and it is what makes everything after it possible. Skipping it produces a feature that demonstrates well and never improves.

It is measured against the behaviour it was supposed to change, not against model accuracy. A recommendation that scores well and that nobody accepts has failed. We agree what the feature is for in terms a business person would recognise, hold a group that does not get it where that is possible, and read the difference.

Design for it, because it will happen. That means a visible way to correct it, a path that does not dead-end when confidence is low, and a record of the correction that feeds back into the system. Products that treat a wrong answer as an impossible case are the ones that lose trust the first time it occurs.

Less than people assume for some things and far more than they hope for others, and the difference is worth knowing before committing. Learning that applies across all your customers, which job types routinely overrun, which forms get abandoned, accumulates quickly because every account contributes to the same picture. Learning that is specific to one customer needs that customer's own history, which means a new account starts knowing nothing. That is the cold start problem, and the answer is not to wait: ship the sensible default behaviour first, be honest in the interface that the product is still learning, and let the personalised version take over per account as the evidence arrives. Products that hide behind not having enough data usually never start collecting it.

It can, and that is a design failure rather than an inevitable cost. The line in practice is between a product that is visibly using what you told it and one that is visibly using what it observed about you. A suggestion that explains itself, this customer's last four jobs moved to the afternoon, reads as attentive. The same suggestion with no reason attached reads as surveillance, because the user is left to imagine what else is being watched. So every suggestion carries its reason, users can see and clear what has been learned about them, and anything drawn from sensitive categories is left alone regardless of whether it would improve the prediction.

You do, and if the product is multi-tenant the more important question is what may cross between customers. Aggregate patterns learned across accounts are usually fine and are what make the product better for everyone. One customer's specific data influencing what another customer sees is usually not, and it is the kind of thing that surfaces in a security questionnaire long after it was built. We decide that boundary explicitly at the start, write it down, and enforce it in the data layer rather than relying on it being remembered.

It comes back out, and that has to be a decision you are able to take rather than one the architecture prevents. This is the practical reason for holding a group that does not receive the feature wherever it is possible: without a comparison you cannot distinguish a feature that worked from a quarter that was good anyway. It is also why the plain behaviour is kept working underneath rather than deleted once the clever version ships. A product that cannot fall back to its simple path has bet itself on a model being right, which is not a bet anyone should place on a feature that is a few months old.