Essay
NPS-driven engineering: building consumer digital products people love
An engineering leader's account of organising a 100+ enterprise technology organisation around customer love as a primary KPI — what worked, what almost worked, and what it has to do with AI.
For most of my time at the LEGO Group, I led the enterprise technology behind LEGO’s consumer digital experiences across mobile, web, and the multi-tenant foundational platforms for identity, consent, AI-driven content moderation, engagement, and analytics that made them possible. By the time I closed that chapter, the team was running consumer digital experiences with NPS in 50+ — high enough to matter. This essay is about how an enterprise technology organisation ends up at that kind of number, and why I think NPS-driven engineering is increasingly the right posture for AI-era product work.
I am writing this partly because I keep being asked the same questions and partly because the lessons map directly onto AI work. The same instincts that produce a strong NPS on a kids product surface also produce AI products that customers come back to.
Why NPS, and why for engineering
NPS is an imperfect metric. It compresses a noisy signal into a single number. It is gameable. Many engineering organisations reject it for these reasons.
I think this misunderstands the metric. NPS is useful in engineering for one reason: it forces the organisation to share a customer view. Internal metrics — uptime, build speed, defect rate — measure the inputs. NPS measures whether any of it mattered. When NPS is shared across product, design, and engineering, arguments about priorities become arguments about what customers actually experience, not about whose function is most heroic.
For a children’s product, NPS has an additional property: it forces honesty about who the customer is. The metric only works if you know whose love you are trying to earn. For us, that was clearly the child — measured in proxies that respect age-appropriate research practices — supported by trust from the parent.
What it took
The number did not come from a single program. It came from a set of practices that, over years, started to compound across a 100+ enterprise technology organisation in Denmark and Romania.
Engineering decisions defended on customer terms
The hardest cultural shift. Engineers learned to defend trade-offs in terms of what the child experiences, not in terms of what the codebase prefers. Refactoring proposals ended with a sentence about why the customer benefit was worth the risk. Performance budgets were owned, not aspirational.
Real research, frequently
Children are honest about what they like and what they do not. Listening to them — properly, with researchers, with the right ethics, at the right cadence — produced a stream of specific, actionable findings. Engineering attended the readouts. The team developed a shared sense of taste that no metric could substitute for.
Quality engineering as a product investment
Pull-request hygiene, test coverage, eval suites, regression tracking, AI moderation quality — treated as features of the product, not as engineering overhead. Quality is one of the few things children’s-product customers will fire you over.
Platform investment that did not slow product
The trap for any internal platform investment is that it stops the product team. The platform team’s job, in our case, was to invest a step ahead of where the product team needed it — across identity, consent, moderation, UGC engagement, and analytics. This is what I now think of as the foundational-platform posture, and it is exactly the posture an AI platform needs.
A team that wanted to be there
People stayed. Senior engineers wanted to build for children. Designers cared. Researchers trusted that their work would be acted on. Hiring slowed down — by choice — to protect the bar. The single best NPS lever, looked at with hindsight, was a stable cross-cultural team in Denmark and Romania that loved the customer.
What this has to do with AI
I think the NPS-driven engineering posture maps onto AI product work better than the posture most enterprises currently have.
The default AI posture, especially in enterprise, is benchmark-driven. The team optimises for an internal metric — eval score, retrieval precision, response time — and ships when the benchmark looks good. The product launches. Customer love does not follow.
The NPS-driven posture inverts this. The internal benchmarks are scaffolding. The thing you are trying to move is whether the customer comes back, recommends the product, trusts it. For AI products, this means evals exist to predict NPS, not to substitute for it. It means human review of customer-facing failures is not an exception process; it is a core engineering practice. It means the team that ships the AI is the team that owns the customer relationship.
This is harder than it sounds, especially inside companies whose existing engineering culture rewards different things. It is also, in my experience, the strongest predictor of which AI products inside Nordic and global enterprises actually reach scale.
What I take with me
I am about to start a new chapter as a digital and AI transformation advisor. The lessons from a decade at LEGO — about platform posture, about NPS as a shared truth, about customer love as a measurable thing — are the lessons I am bringing in.
If you are running an enterprise technology organisation and trying to move toward this posture, the advisory page explains how I work.