Carl Ejlers Notes Building to learn

Building to learn.

AI has made it cheap to figure out the right thing to build. Notes from a year inside Denmark's largest accounting platform.

August 2026

The distinction

There is a distinction the Silicon Valley Product Group has given the industry: building to learn and building to earn. What you ship to customers is built to earn. Everything before it, the prototypes, the experiments, the things made to be thrown away, is built to learn: to figure out what is worth shipping in the first place.

Figuring out what to build has always been expensive from both ends. A testable prototype cost days, so teams rationed the experiments, and what an experiment would have answered got settled by opinion instead. And a wrong opinion is the most expensive thing in product work: the wrong feature gets built, shipped, maintained and carried. That is what AI actually changed. Not how fast a screen gets drawn: how cheaply you can find out whether it should exist and what form it should take.

AI enablement

At e-conomic this work is called AI enablement, and my part of it has been the prototyping side. Not making prototypes: making the harness that lets the organisation learn faster, with prototypes built on the design system and the principles the system is built with.

The harness is wired to the design system on GitHub, and it explains the design system and its principles and patterns to any model before it draws. It is for PMs, UXers and product teams in general: you can get AI to create a prototype from an idea, a feature request or a PRD. A prototype built this way is an experiment wearing the product's own clothes: real enough to learn from, cheap enough to throw away when it has answered. That is the whole point of building to learn. The throwing away has to be painless, or you start defending the prototype instead of the user.

The page you are reading runs on the same architecture. One stylesheet as the truth, a system page that documents it, a check that fails anything outside it, and an AI building within those constraints. Teaching a machine your system turns out to be the same discipline as keeping one.

The cycle

Most of my work with AI happens at stations of one ongoing cycle. Insight comes in, from the feedback that arrives continuously and from interviews. All of it lands in an opportunity solution tree, Teresa Torres's way of holding discovery together: one desired outcome at the top, the opportunities that could move it beneath, and the solutions and experiments under those. The tree is what I figure out from: what to build, which experiments to run. Prototypes then test the answer with customers, and what comes back starts the next round.

A couple of ways I work with AI

Interview synthesis What interviews surface is synthesised with AI, then fed into the tree.
User feedback The stream that never stops. AI routines keep track of it as it comes in.
Behavioural data Decisions get informed by the data that is already there. When it isn't, I stitch it together from what is.
Opportunity solution trees Where all of it lands. The tree is what I decide from: what to build, which experiments to run.
Prototyping tools The harness above: built once, so every prototype after it starts on the system.
Prototyping Built to test with customers. The last step of the cycle, and the start of the next one.
Exploring design directions Different solution ideas, refined until they are ready for testing.
Stakeholder decks Communication inside the organisation. Sharing ideas, directions and decisions, getting feedback.
Product documentation AI helps me build it out. It is how the work stays aligned with other teams, and how it gets delivered to implementation.
Keeping organised Everything gets documented as I work, in a form AI can read.

What I would tell a peer

AI didn't lower the bar for shipping. It lowered the price of finding out what to ship, and teams that spend the savings on more questions will beat teams that spend it on more features.