From idea to delivered product: the 5 steps I follow on every project
Many projects fail not because the idea was bad, but because nobody asked the right questions at the right time. Six months of coding, something "finished" gets delivered… and nobody uses it. I have seen this scenario play out repeatedly in large corporations and startups alike.
After 11 years in the industry — from Cisco datacenters to the product teams at Chanel.com, including Saana, a sovereign medical LLM used by hospitals in Montpellier — I have refined a way of working that avoids this trap. Here are the 5 steps I apply on every project, with a clear picture of what you can expect at each stage.
Step 1 — Scoping & discovery: understand before you build
Before opening a code editor, I take the time to understand the real problem. Not the problem as stated in the brief, but the problem as it actually exists for end users.
This phase typically lasts one to two weeks. Together, we define:
- Who uses the product and in what context (in the field, at a desk, on mobile, in an emergency?)
- What the minimum scope is for the product to be useful from its very first version
- What we will not do — the out-of-scope is just as important as what is in scope
- The success criteria: how will we know it has succeeded in 6 months?
What you receive at the end of this step: a scoping document, a prioritized feature list, and an honest initial estimate. No budget surprises down the line.
"The out-of-scope is just as important as what is in scope."
On Saana, we spent several weeks interviewing healthcare workers before writing a single line of code. That upfront work prevented us from building something technically impressive but unusable in a hospital corridor.
Step 2 — Design & prototype: validate before you code
Once the scope is defined, we design. Wireframes, user journeys, screen flows. The goal is simple: give you something concrete to react to before development begins.
A clickable prototype costs ten times less to change than a fully developed application. This is prevention, not decoration.
This step produces:
- Wireframes for every key screen
- A navigable prototype you can test on your phone or computer
- A validation session with your future users (even an informal one is invaluable)
You stay in control: you sign off on each screen, you request changes, and development only begins once you are aligned on what you are going to receive.
Step 3 — Sprint-based development: regular results, no black box
This is where many projects go off the rails. You enter a "black box" — weeks with no news, then a big-bang delivery that does not match expectations.
At Twenty, we work in two-week sprints. At the end of each sprint, you attend a demo: you see what has been built, you give your feedback, and we adjust for the next sprint. No black box — just regular, visible progress.
I have refined this approach across very different contexts — 6 simultaneous agile teams at Air Liquide, 110 people managed on a product roadmap, 2 Scrum teams for the product pages of Chanel.com. Every time, the principle is the same: the client sees progress and can steer the project before it is too late.
What you see at each sprint:
- A functional, testable version of the product
- A simple dashboard: what is done, what is in progress, what is planned
- A sync checkpoint to decide the next priorities
In practice, this method has allowed us to reduce delivery time by 30% on average across our projects.
Step 4 — Go-to-market & launch: the product does not stop at production
Putting a product into production is one step. Getting users to actually adopt it is another. And this is often where projects stall.
The launch at Twenty covers:
- Production deployment in a secure environment (sovereign hosting when required, as with Saana)
- User training — not an 80-page manual, but short, practical sessions tailored to real-world use
- Adoption tracking during the first weeks: who is using the product? Which screens are causing friction?
A delivered product that nobody uses has no value. Adoption is part of the deal.
On School Run — a gamified mental arithmetic app I co-founded, now live in 8 countries and 4th of the Google Play Store in its category — we learned that the quality of the launch shapes the long-term trajectory. A poor start is very hard to recover from.
Step 5 — Run & continuous improvement: you stay in control, we handle the tech
Once the product is live, life goes on. Users send feedback, needs evolve, technology moves forward. This is the day-to-day of the Run phase.
At Twenty, you can delegate to us:
- Hosting and application availability
- Corrective and evolutionary maintenance
- Security — updates, audits, GDPR compliance
- Future iterations, planned according to your business priorities
You stay in control through clear monthly reporting and regular check-ins. You set the priorities; we handle execution. This is exactly what I offer clients who do not want to manage an in-house technical team but want a product that keeps evolving.
What this method changes in practice
What this method is not
It is not a magic recipe. It requires regular involvement on your side — not intensive, but regular. Thirty minutes a week to validate a demo is what makes the difference between a product that feels like yours and a generic one.
It is also not suited for everyone: if you are looking for someone to execute a fixed specification without any discussion, that is not what I offer. My role is to be a partner, not a delivery vendor.
Let's talk about your project
Do you have a product idea, a project that is stalling, or a team to structure? I set aside time for a free initial conversation to understand your context and tell you honestly what I can bring to the table.
Reach out directly:
- WhatsApp: +33 6 34 42 50 56
- Email: contact@twentyconsultancy.com
- LinkedIn: Dibrilou Diagne
A well-scoped project is a project with a real chance of succeeding. Let's start there.