D'une idée à un MVP en 3 semaines — Mon processus

Le problème avec la plupart des MVP

Ils ne sont pas minimum. Ils ne sont pas viables. Ils ne sont que des produits incomplets.

J'ai vu des équipes passer 6 mois à construire un MVP que personne n'utilise. Le problème n'est pas l'exécution — c'est la portée. Ils ont essayé de construire le produit complet et ont appelé la première version un MVP.

Un véritable MVP répond à une question : est-ce que cela résout un problème réel pour des personnes réelles ?

Tout le reste est du bruit.

Semaine 1 — Définir l'action centrale unique

Chaque produit a une action qui compte plus que toutes les autres. La trouver.

Pour ImpacTrack : soumettre un rapport d'impact Pour EduCNet : un étudiant accède à un cours Pour une application de réservation : un client réserve un rendez-vous

Cette action unique est votre MVP. Ne construisez rien d'autre jusqu'à ce qu'elle fonctionne de bout en bout.

Ma liste de vérification pour la semaine 1 :

• [ ] Écrire l'histoire utilisateur centrale en une phrase
• [ ] Esquisser le flux minimum sur papier (3-5 écrans maximum)
• [ ] Définir le modèle de données — seulement les tables dont vous avez besoin maintenant
• [ ] Choisir la pile (ne la changez pas en cours de projet)
• [ ] Configurer le référentiel, CI/CD et la pipeline de déploiement

# Configuration du jour 1 — j'utilise cela chaque fois
npx create-next-app@latest mon-mvp --typescript --tailwind
cd mon-mvp && git init && git push origin main
# Vercel connecté à main — chaque push est déployé

Semaine 2 — Construire le chemin heureux uniquement

Le chemin heureux est lorsque tout fonctionne parfaitement. Construisez cela d'abord.

Pas d'états d'erreur. Pas de cas limites. Pas de « qu'est-ce qui se passe si l'utilisateur fait X ». Juste le flux qui fonctionne lorsque l'utilisateur fait exactement ce que vous attendez.

Ce que je construis pendant la semaine 2 :

• L'authentification (e-mail + mot de passe, rien de sophistiqué)
• La fonctionnalité centrale — de bout en bout, sans raccourcis
• Une base de données, un serveur, un déploiement

Ce que je ne construis pas :

• Le flux de mot de passe oublié
• Le panneau d'administration
• Les notifications par e-mail
• L'application mobile
• Les analyses

// API de la semaine 2 — très simple
func CreateBooking(w http.ResponseWriter, r *http.Request) {
    var req BookingRequest
    json.NewDecoder(r.Body).Decode(&req)
    
    booking := Booking{
        ClientID:  req.ClientID,
        Date:      req.Date,
        CreatedAt: time.Now(),
    }
    
    db.Create(&booking)
    json.NewEncoder(w).Encode(booking)
}
// Pas de vérification d'authentification pour l'instant. Pas de validation. Juste l'action centrale.

Semaine 3 — Rendre cela utilisable par une personne réelle

Maintenant, vous ajoutez la couche minimum de polissage qui permet à quelqu'un qui n'est pas vous d'utiliser réellement le produit.

• Les messages d'erreur de base
• Les états de chargement
• La mise en page responsive pour les appareils mobiles
• Un tour de test utilisateur (trouver 3 personnes, les regarder utiliser)

La chose la plus importante pendant la semaine 3 : regarder quelqu'un utiliser votre produit sans les aider. Chaque endroit où ils hésitent est un bogue.

Les règles que je suis

Règle 1 : Pas de nouvelles fonctionnalités jusqu'à ce que l'action centrale fonctionne Si l'action principale ne fonctionne pas parfaitement, rien d'autre n'a d'importance.

Règle 2 : Expédier le jour 1 Déployer en production le premier jour. Même si c'est juste une page de destination. Avoir quelque chose de vivant change la façon dont vous pensez au projet.

Règle 3 : Parler aux utilisateurs avant d'écrire du code Au moins une conversation avec un utilisateur potentiel avant de commencer. Pas un sondage — une conversation.

Règle 4 : Limiter les décisions dans le temps Vous avez 5 minutes pour choisir une palette de couleurs. 10 minutes pour choisir entre deux bibliothèques. Plus longtemps et vous procrastinez.

Ce qui se passe après 3 semaines

Vous avez quelque chose de réel. Pas fini — réel.

Montrez-le à 5 utilisateurs potentiels. Obtenez leur réaction honnête. S'ils veulent l'utiliser à nouveau, vous êtes sur quelque chose. S'ils ne le font pas, vous avez appris quelque chose de précieux en 3 semaines au lieu de 6 mois.

C'est le but d'un MVP.

---

Besoin de livrer rapidement ? J'aide les équipes à passer d'une idée à la production en quelques semaines. Travaillons ensemble.