Building a digital product: what AI doesn't change

Romain Kuzniak, former Chief Product Officer at OpenClassrooms, shared an insightful perspective with us: AI changes almost everything in a digital project, except for the fundamentals. We’ve distilled three key takeaways from his talk, plus the ongoing headache of funding.

No sooner do you master one tool than another replaces it. No sooner do you make a choice than an announcement renders it obsolete. Leading a digital project today is like chasing a speeding train, and with the resources of a non-profit, you’re starting two cars behind.

The temptation is to run faster. Romain Kuzniak flips the question: rather than asking what AI changes, he asks what it doesn't change. Because you can only build a solid strategy on what will still be true in ten years, not on what shifts every month.

Romain knows what he’s talking about. When he joined OpenClassrooms, it was a small team of about a dozen people; twelve years later, when he left, it had nearly 700 employees. Today, he runs his own company, Ignito. His conclusion is simple: AI changes how you build a product (your platform, your app, your chatbot), not what makes it valuable. And creating value for the people you support has always been the core mission of non-profits, even without the product-management jargon.

We’ve identified three fundamentals: start with what matters to your beneficiaries, aim to learn quickly rather than building perfectly at the start, and lead with objectives rather than features. Plus one thorny issue that Romain didn't quite resolve: how to manage all this when facing funders who demand a precise roadmap. It’s an eight-minute read.

‍

Fundamental 1: Start with what matters to your beneficiaries, not a tool

You know the drill: start with the beneficiaries' needs, not the tool. We even wrote an entire article. Romain sums it up with a mantra to hang on your wall: AI provides solutions, not results. People don't use a solution for what it is, but for what it allows them to achieve.

Identifying a need isn't enough, though: it has to be a need that truly matters. The question to ask yourself is simple: are your beneficiaries actually waiting for this project, or is it just another good idea?

Imagine a legal aid non-profit choosing between two projects: a chatbot that explains social benefits, or an automated reminder before every renewal deadline, where missing a date means weeks without income. The first comes from good intentions, but the information already exists elsewhere—no one was really waiting for it. The second solves a problem that has concrete consequences in their lives.

Watch out for another less obvious trap: starting with yourself. Beginning with your own goals ("reach more beneficiaries," "increase platform usage") and working backward to a solution doesn't necessarily work either. People use a service because it solves their problem, not because you need them to use it. As for AI, it brings new problems to light and builds solutions faster; it doesn't choose the problem for you.

In practical terms. Describe your project without using the words "AI," "chatbot," or "algorithm": what is the problem, for whom, and what change does it make in their lives? If you can't do that, you've started with the tool. If you can, ask the second question: do your beneficiaries want it enough to change their habits? If the honest answer is "not really," the project can wait.

‍

Fundamental 2: At the start, don't aim for quality—aim to learn quickly

Romain borrows a framework from Kent Beck, a historical figure in software development. A product goes through three stages:

- Explore: you have few users and are still searching for the real problem.

- Scale: things are taking off, everything is hitting capacity, the goal is to keep it running.

- Operate: the product is stable, many people rely on it, every decision counts.

Each stage has its own best practices, and the most counterintuitive one concerns exploration: you aren't aiming for quality, you're aiming to learn fast. At the beginning, you have everything to gain and almost nothing to lose: with few users, a mistake costs very little, and the right path can change everything. Later on, when many people depend on your tool, the dynamic flips: a wrong move can be costly.

Yet, most non-profit AI projects are in the exploration phase. This leads to a common trap: spending 6 months polishing an assistant before showing it to a single beneficiary. It is better to have a makeshift prototype, shown early, that teaches you what people actually need. And that is where AI helps: you can prototype in a few weeks today, without needing deep technical expertise.

One final, decisive reflex: name the stage out loud, in front of your team and your board of directors. Otherwise, people will criticize your prototype for not being a finished product, even though that was the whole point.

In practice. Before your next decision (hiring, investing in a technology, refining the design), ask yourself what stage the project is in. If you are still figuring out who you are helping and how, you are exploring: finishing touches are premature. Note the stage, and tell your team.

‍

Fundamental 3: a roadmap is about goals, not a list of features

The common reflex is to view your product roadmap as a list of things to build. It ends up trapping you: once written down, you build "because it's on the list," even when it no longer serves your mission. It is better to frame it in terms of goals: not "build a recommendation module," but "get X% more young people to complete their career guidance path." A goal leaves the solution open, and often a small adjustment (a link, a follow-up) is enough where you had imagined a major project.

Its format: a table with three columns: now, next, later. With one firm rule: only one thing in "now." Because the scarce resource isn't ideas, it's attention: the more projects you open at once, the more you dilute it, until you finish none of them. With two employees and three thousand beneficiaries, eight priorities are effectively no priorities at all. Easier said than done, we know, especially when every grant comes with its own deliverables; all the more reason not to add to them yourself.

The "later" column is mainly used to write down in black and white what you will not do, so that those ideas stop coming back to the table. This is actually where the AI ideas accumulated over the last two years ("what if we made a chatbot?") end up. The most difficult decision, and often the best one, is to let go.

In practice. Look at your roadmap again. Is each line a measurable goal ("X% of...") or a feature to be delivered ("build...")? If features dominate, you are managing for delivery, not for value. And count your current priorities: if there is more than one, you haven't prioritized yet.

Yes, but our funders want a precise plan

All of this assumes a level of freedom that non-profits don't always have. During the session, someone asked the tough question: our grants describe exactly what we are going to do, with specific targets; if we deviate, we risk losing the funding. How can you reconcile that with a flexible roadmap?

Romain acknowledged that there is no off-the-shelf answer, but he made a useful distinction: committing to inputs ("train 100 people") versus outcomes ("100 people find a job"). The outcome is more meaningful, both for you and the funder. But, as he noted, it is riskier: if the result isn't achieved, the money might not follow.

We would add a nuance, because not all non-profits can afford that gamble. When your cash flow only covers six months, making funding conditional on an outcome you only partially control (returning to work also depends on the market) is no longer ambition—it's roulette. There is even a trap that economists call Goodhart's Law: when a measure becomes a target, it ceases to be a good measure. A non-profit pressured to "hit its numbers" to survive will end up selecting the beneficiaries who are easiest to place,  which is the exact opposite of its mission.

The sweet spot: manage by results, contract by means. Commit to your funder based on what you control (training one hundred people), and alongside that, voluntarily display the result you are aiming for and how you measure it (how many find a job within six months). Your funding is secured, the funder receives rare transparency, and you build a track record, result by result, for your next renewal. Your roadmap remains your internal compass; it doesn't need to be your contract.

Key takeaways

AI primarily accelerates execution: you prototype in days, build faster, and experiment more. It doesn't change the fundamentals: build on what doesn't change, start with a real problem, and do one thing at a time. Romain adds a sharp nuance: far from leveling the playing field, AI widens the gap between those who master these fundamentals and those who don't. At OpenClassrooms, his teams had eighteen years of projects in the backlog; they scrapped them all. The problem has never been a lack of ideas, but the ability to choose.

His final story is about neither AI nor methodology. A user of Capitaine Train, a French train ticketing service, once asked on Twitter if they could book a seat for their cat. Two and a half years later, the feature was released, and the team, having tracked every request, found his message and replied: it's been available since yesterday. The person shared the response, stunned that they hadn't been forgotten.

Perhaps that is what doesn't change: the value of a product, like that of support, lies in the genuine attention paid to real people. That attention has always been your core business. AI can free up time for you to provide it; it will not provide it for you.

Romain Kuzniak's talk took place during the launch event for forwa, the first European program supporting 15 non-profits fighting against inequalities in access to education and employment through AI.

‍

Our sources

- The three stages of a product (explore, expand, exploit) : Kent Beck, the "3X" model

- Why you can try anything at the start but not later (convexity, antifragility) : Nassim Nicholas Taleb, Antifragile (2012)

- Attention as a scarce resource : Herbert Simon, "Designing Organizations for an Information-Rich World" (1971)

- "When a measure becomes a target, it ceases to be a good measure" : Goodhart's Law (Charles Goodhart, 1975), formulated by Marilyn Strathern (1997)

- "Focusing is about saying no" : Steve Jobs (WWDC, 1997)

- Prioritizing without the pain : the RICE method (Reach, Impact, Confidence, Effort)

- "Now / Next / Later" roadmap : the now-next-later format, popularized by Janna Bastow (ProdPad)