Le blog
Méthodes Agiles
Proof of concept : comment concevoir une V1 fonctionnelle ?
20 octobre 2016 par L'équipe Soluti

Dans un monde idéal, un entrepreneur a une idée, affine un concept, crée sa startup puis une V1 de son produit… et tout le monde est content. Dans la réalité, en revanche, tout n’est pas si simple, et c’est au moment de proposer une V1 que le bât blesse. Les conséquences d’une version alpha mal conçue peuvent être graves : échec de la startup, dépenses inconsidérées, mauvaise gestion des équipes, fuite des premiers clients… Mais pas de panique ! Grâce à ce petit guide en mode B.A.-BA, vous saurez tout ce qu’il y a à savoir pour faire un proof of concept sous forme de V1 fonctionnelle, qui mettra l’eau à la bouche de vos clients... et à celles de vos potentiels investisseurs !

Avant tout, bien définir son projet

Développer la V1 d’une application, ça ne s’improvise pas, encore moins quand il s’agit de faire ses preuves aux yeux d’investisseurs potentiels. Pour réussir, il faut impérativement réfléchir :

  • Au budget disponible, histoire de ne pas dépenser plus que ce que l’on a en poche
  • Au temps imparti, pour n’être ni trop ambitieux ni trop en retard
  • À la cible, pour intégrer des fonctionnalités adaptées au public que l’on vise
  • À l’objectif du produit, pour se concentrer sur sa valeur ajoutée par rapport aux solutions qui existent déjà
  • Aux besoins clients, pour développer une application utile dès la V1

Toutes ces informations vous seront précieuses pour définir un socle de développement. Lequel vous aidera à créer l’architecture de votre produit !

Must, should, could

C’est un fait : les startups ont souvent une santé financière fragile. Rançon (avant l’heure) du succès ou non, toujours est-il qu’elles ne peuvent se permettre de perdre de l’argent dans le développement de leur application !

La bonne méthode ? Prioriser les fonctionnalités à implanter dans le produit. L’idée ? Proposer un proof of concept qui répondra aux besoins actuels, et auquel il sera possible d’apporter des évolutions au fil du temps, tout en gardant quelque chose de « propre » et de fonctionnel.

Il s’agit, en fait, de ranger les fonctionnalités dans trois groupes :

  • Les must : les fonctionnalités de base, sans lesquelles l’application n’a pas vraiment de sens. Celles-ci doivent impérativement être proposées dès la V1 !
  • Les should : elles sont pratiques, très bien pensées, apportent une valeur ajoutée… mais ne sont pas indispensables. Elles peuvent n’apparaître, du reste, que dans la V2 de l’application pour créer un petit côté « événement » lors de sa mise à disposition.
  • Les could : il vous reste du temps, de l’argent ? Vous êtes sûr de ne rien avoir oublié ? Alors vous pouvez vous attaquer à ces fonctionnalités !

Pourquoi prendre le temps de classer les fonctionnalités ? Tout simplement parce que vous aurez ainsi un « cadre » technique, et éviterez les dérives qui vous feront passer à côté de vos principaux objectifs business. Pour prioriser correctement chacune des fonctionnalités et savoir dans quelle catégorie les ranger, posez-vous ainsi ces trois questions :

  • Est-elle souvent utilisée / réclamée ?
  • Combien d’utilisateurs vont s’en servir ?
  • Est-ce qu’elle rentre dans le périmètre initial de mon produit ?

La réussite du proof of concept se mesure au travail de réflexion qui a été mené avant même sa sortie — séduire et convaincre les investisseurs, c’est savoir rester humble et accepter de laisser de côté certaines fonctionnalités. Vous souhaitez un développement efficace, reposant sur la méthode Agile ? Gagner en rentabilité ? Passez nous voir au 73, on discutera de votre projet autour d'un café !

Crédits photo : Pexels.com / Unsplash.com (Bench Accounting)


On en parle

Articles similaires

Comment concevoir un service digital qui répond aux besoins de ses utilisateurs ?
Start-up
L'importance d'un bon Product Manager
Agile
Méthodologie Agile : les rôles clés pour réussir