Building a sustainable business should be the aim of all founders. The initial product idea will evolve, take many forms and could even change completely.
A key element that should stay consistent throughout this journey is communication with your targeted customers. From ideation to building the first versions of your product, your audience holds the answers to the majority of your questions.
This is where the traditional minimum viable product (MVP) format has proven to be an efficient way to kickstart this learning process. But over the years, the MVP, this coded version of your product, serves one specific purpose: validation of a range of hypotheses, from product features to acquisition channels.
On the other hand, a new approach has emerged: the minimum lovable product (MLP). It enables you to test your very first assumptions around your idea with a clickable prototype that suffices to illustrate this idea.
There is no right or wrong way whether you should build an MVP or an MLP. There is no actual battle between these two approaches, coded and non-coded.
De l’idée au produit pour 4999€ Par Sébastien Charrier lors de Humantalks Mai 2015
Vous avez une idée. Une idée géniale. Tellement géniale, que vous avez décidé d’en faire un produit. Et vous avez de la chance, parce que ça tombe juste au moment où je présente la recette magique pour transformer de façon certaine une idée en un produit qui cartonne. Cycles courts, feedbacks, métriques, nous verrons tout ce qu’il faut mettre en place pour vous assurer un succès planétaire. Convaincu(e) ? Signez-ici, c’est 4999€.
Si vous avez sorti votre carte bancaire et avez cherché le lien de paiement, vous allez être déçu(e). Mais gardez tout de même votre carte sortie, vous paierez la tournée.
Je vous propose de venir découvrir quelques outils et méthodes qui peuvent vous aider à transformer très vite votre idée en produit, et récupérer aussi rapidement le maximum d’indices possible quant à son succès (ou échec) potentiel. Ce n’est pas une recette magique, et ça ne vous empêchera pas de vous prendre un mur s’il est sur votre chemin. Mais il y a une petite différence entre se le prendre à 10km/h, ou à 130km/h, non ?
If you're at this step, you believe that you don't need to pivot, that you have validated your hypothesis and have product/market fit.
And so now, there are 4 phases to this process:
Phase 1: Get Ready To Sell - You want to activate/acquire customers; build a high fidelity MVP; develop sales; create a roadmap for the product.
Phase 2: Get Out Of The Building - Get out and sell. Get users and customers.
Phase 3: Develop Positioning - This should be done in parallel with phase 2, but you'll want to ask you customers to explain your product to you in their own words and start to leverage that as part of your corporate and product positioning.
Phase 4: Verify Or Repeat - This is when you find out if you are ready to scale marketing and sales spending or if you need to revisit some of your initial assumptions or MVP.
The rationale behind the steps towards building an MVP is to cover the process from research to development. The core areas to be considered remain data material, engagement in personal descriptions, and buy-in from organizations. The steps are:
Finding Users Building a Hypothesis Verification Finding Patterns Constructing Personas Defining Situations Validation and Buy-in Dissemination of Knowledge Creating Scenarios On-Going Development
Note: A project does not need to follow all the steps as long they are aware of the outlines and the consequences.
Alberto Savoia is the former Innovation Agitator and Engineering Director at Google, and Innovation Lecturer at Stanford. Founder of Pretotype Labs. He is also the author of a book that I loved, which is “The Right It: why so many fail and how to make sure yours succeed.” I took the chance to ask Alberto … Continue reading Pretotyping: How To Find The Right Idea To Avoid Business Failure With Alberto Savoia [Lecture]
Customer development is a formal methodology for building startups and new corporate ventures. It is one of the three parts that make up a lean startup (business model design, customer development, agile engineering).
Hypotheses are critical assumptions about how a business will work, and include assumptions about target market, pricing, and competitors.[5][18] Together, hypotheses make up the business model for a startup.[5][18]
Testing hypotheses means that the founder has to “get out of the building” and answer three questions about the business:
Do we really understand the customer's problem or need?
Do enough people outside of the company care about the problem to deliver huge business?
Will people care enough to tell their friends, which will help grow the business quickly?[5][22]
Hypotheses can be tested in several ways. Creating an MVP is one way to quickly test mockups and ideas in the real world, especially with Web and mobile startups.[5][21]
Hypotheses change as a result of testing and customer feedback.[5][17][18] The changed hypotheses are incorporated into new iterations of the startup business model.[5][17][18]
Marc Andreessen defined Product/market fit as "being in a good market with a product that can satisfy that market." According to Andreessen, that is a moment when a product or service has its place in the market, thus enabling traction for the company offering that product or service.
Des applications app web/mobile – avec actions transactionnelles – : Bubble, Glide, …
Une combinaison d’outils via l’automatisation de process : Zappier,…
Un stockage robuste hybride en mode tableur-base de données, mais avec les fonctionnalités d’une base de données (Airtable),
…
Mickael Ruau's insight:
Attention, il n’y a rien de magique non plus….même si on n’a pas à coder des algorithmes complexes, il faut savoir concevoir une application, designer et orchestrer des tâches dans un processus et enfin connaître les possibilités comme les limites de ce type d’outils.
« Attention/ Warning/ Achtung ! Jetez votre code jetable. La plupart des projets innovants prennent le pire des compromis : coder rapidement du quick and dirty, et construire les évolutions sur des mauvaises fondations qui freineront ses évolutions. Notre recommandation est d’utiliser les outils No-code/ Low-code pour tester rapidement un MVP jetable. Une fois le concept validé sur le marché, il faut investir dans une solution pérenne avec les principes de qualité craft. Si votre code est jetable, il faut le jeter !
Dans tous les cas, il aura rendu le service qu’on attend de lui : vous permettre de tester votre innovation sur le terrain à coût très maîtrisé; et ainsi dérisquer l’usage et valider sa proposition de valeur auprès d’utilisateurs/clients.
Un minimum viable product (MVP) n'est pas destiné à créer un produit plus petit et moins cher mais à démarrer le processus d'apprentissage et à tester le business model.
Mickael Ruau's insight:
L'équipe a confondu l'objectif du MVP (customer discovery), avec le processus de construction d'un prototype. Blank a proposé l'alternative suivante à l'équipe, moins chère et qui permettrait de mieux prouver le but de leur MVP : trouver des clients précurseurs qui paieraient pour les données :
Ne serait-il pas moins cher de louer une caméra et un avion ou un hélicoptère, et de survoler les champs d'agriculteurs, récupérer les données à la main et voir si les agriculteurs sont prêts à payer pour ? Ne pourriez-vous pas le faire en un jour ou deux, pour un dixième de l'argent que vous cherchez ? hein ...
La suggestion de Blank a poussé l'équipe à faire marche arrière et à repenser ce que doit tester le MVP ; ce qui a replacé leur attention de la construction d'un prototype à la compréhension de ce qu'il doivent en apprendre. Parce qu'ils se définissent comme une entreprise de services de données, ils ont besoin d'un MVP qui prouve que les données qu'ils offrent aux agriculteurs ont de la valeur avant de dépenser du temps et de l'argent :
"Cela signifie que tout le travail entre l'achat d'un drone, d'un appareil photo, des logiciels et le temps d'intégrer tout cela a été une perte de temps et d'efforts - maintenant. Ils n'avaient pas besoin de tester cela de suite. (Il y a beaucoup de preuves d'existence de drones équipés de caméras.) Ils ont défini le mauvais MVP au départ. Là où ils auraient dû passer du temps en premier, c'est de vérifier si les agriculteurs sont intéressés par des données."
En montrant l'exemple d'une équipe poursuivant ce que la plupart des gens considèrent être un MVP, Blank démontre l'idée fausse qui se cache derrière le MVP - le besoin de créer une version simplifiée du produit et de la soumettre à des clients potentiels.
Depuis la popularisation du MVP (Minimum Viable Product), de nombreux termes similaires apparaissent pour proposer des... MTP - Minimum Testable Product.
Continuous delivery demands the use of hypotheses, not requirements, to deliver what customers want. Developers embrace continuous experimentation and adaption.
A minimum viable product (MVP) is not always a smaller/cheaper version of your final product. Defining the goal for a MVP can save you tons of time, money and grief.
Mickael Ruau's insight:
This team got my attention when they said, “Let us tell you about our conversations with potential customers.” I listened, and as they described their customer interviews, it seemed like they had found, that – yes, farmers do understand that not being able to see what was going on in detail on their fields was a problem – and yes, – having data like this would be great – in theory.
So the team decided that this felt like a real business they wanted to build. And now they were out raising money to build a prototype minimum viable product (MVP.) All good. Smart team, real domain experts in hyper-spectral imaging, drone design, good start on customer discovery, beginning to think about product/market fit, etc.
Lean is Not an Engineering Process They showed me their goals and budget for their next step. What they wanted was a happy early customer who recognized the value of their data and is willing to be an evangelist. Great goal.
They concluded that the only way to get a delighted early customer was to build a minimum viable product (MVP). They believed that the MVP needed to, 1) demonstrate a drone flight, 2) make sure their software could stitch together all the images of a field, and then 3) present the data to the farmer in a way he could use it.
And they logically concluded that the way to do this was to buy a drone, buy a hyper-spectral camera, buy the software for image processing, spend months of engineering time integrating the camera, platform and software together, etc They showed me their barebones budget for doing all this. Logical.
With Git platforms like Bitbucket, GitLab, GitHub, Azure DevOps offered on the cloud, it is now easier than ever to create code repositories on a platform that you prefer. Devbridge can help to choose the right platform in an unbiased way.
Mickael Ruau's insight:
Below, we compare git-flow vs. trunk-based noting key considerations for each.
Philosophy
Git-flowTrunk-based As far as possible from main branch As close as possible to main branch New features started from develop branch Short-lived feature branches started from main branch New release branch derived from develop branch, after stabilized release branch deployed Main branch always in a state ready to be deployed to production Only hotfixes derived from main branch Hotfixes start from main or release branch, need to be cherry-picked back to main
Team composition
Git-flowTrunk-based Lack of seniority within the team Well-composed and experienced team Working with other vendors/third-party Team augmentation model
Product type
Git-flowTrunk-based Complex, mature, monolithic product Microservices Brown-field product Modern single page application (SPA) / Mobile apps Proof-of-concept (POC) / Prototype Distributed system components
Authoring process
Git-flowTrunk-based Governed Team-driven
Deployment
Git-flowTrunk-based Various deployment models used Continuous Deployment practices recommended, such as feature toggles, quality gates, canary testing, self-service automation (e.g.. ChatOps), and monitoring
Release frequency
Git-flowTrunk-based Slower release cadence, pre-determined schedule Teams able to iterate quickly and independently
Dans l'univers des startups, il existe de nombreux termes complexes à comprendre qui peuvent se compléter ou parfois se... MLP - Minimum Lovable Product
Sktch.io is a no-code platform allowing you to build dynamic and interactive websites and web-apps.
Mickael Ruau's insight:
With Sktch.io, not only can you build beautiful responsive websites and web-apps, but you can also integrate dynamic databases and build complex workflows with our visual programming tool, all without writing a single line of code.
Sktch.io accelerates the creation of modern websites and apps. Whether you are a freelancer that is looking for a more productive workflow and powerful tools or a non-technical founder looking to build an MVP, Sktch.io is the right tool for the job!
As pointed out by Eric Ries, a minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort through a cycle of build, measure, learn; that is the foundation of the lean startup methodology.
Le MVP est particulièrement bien adapté lorsque l’on n’a pas ou peu de connaissance du marché et des clients, de pas de vision produit bien définie.
Mickael Ruau's insight:
Le risque…
L’approche MVP peut néanmoins engendrer un résultat ambigu : Le faux négatif. En effet, si un MVP n’est pas suffisamment bien pensé, ou mal présenté, bref, pour de nombreuses raisons, il peut entraîner une réponse négative de la part du groupe de clients ciblés, et ainsi tendrait à faire penser que le produit envisagé n’est en fait pas viable, alors qu’il s’agit plutôt d’itérer dessus pour le perfectionner afin de répondre mieux au besoin. Il s’agit précisément de ne pas s’arrêter à ce qui peut être ressenti comme un échec : un pas de plus permettra peut être de passer du non-viable au viable, soit le MVP proprement dit.
Il peut être judicieux de rappeler la phrase attribuée à Henri Ford : « Si j’avais demandé a mes clients ce qu’ils voulaient, ils m’auraient répondu un cheval plus rapide ». Avoir une vision produit, ce n’est donc pas forcément qu’une option.
I first met Shawn Carolan and his wife Jennifer at the turn of the century at 11,000 feet. I was hiking with my kids between the Yosemite High Sierra camps. Having just retired from a career as an…
Via Oliver Durrer swissleap.com
3 caractéristiques principales et une réponse fermée
Cette expérimentation se caractérise par 3 principaux aspects :
Une période définie (plutôt courte sinon ce n’est plus un POC) Une mise en situation réelle (si les données qui seront manipulées ne sont pas réelles et utilisée au jour le jour, on ne prouve rien du tout) Un périmètre représentatif (si le périmètre évalué est hors du périmètre global du projet, il faudra encore prouver que la solution est aussi adaptée aux éléments du projet ! On n’a donc rien prouvé !)
Le but d’un POC étant de démontrer la faisabilité d’un système, il consiste à répondre à la question « Est-ce que cela peut être fait ? » Avec les les 2 volets suivants : est-ce que la solution retenue est la bonne ? / Est-on capable de la mettre en œuvre ? La réponse est oui ou non, « GO » ou « NO GO« .
To get content containing either thought or leadership enter:
To get content containing both thought and leadership enter:
To get content containing the expression thought leadership enter:
You can enter several keywords and you can refine them whenever you want. Our suggestion engine uses more signals but entering a few keywords here will rapidly give you great content to curate.
Your new post is loading...
![Pretotyping: How To Find The Right Idea To Avoid Business Failure With Alberto Savoia [Lecture] | Devops for Growth | Scoop.it](https://img.scoop.it/vk_vfs0Gb-1gZfwK5sZ-yjl72eJkfbmt4t8yenImKBVvK0kTmF0xjctABnaLJIm9)
