Ogni tanto mi capita di dover spiegare il business model canvas durante qualche corso o in una seduta di brainstorming ad un cliente. Ultimamente dopo aver spiegato il business model canvas introduco, a strettissimo giro di boa il lean canvas (qui una versione online). Di solito avviene quando la prima cosa che mi viene spiegata è la Soluzione che risolverà definitivamente il problema XYZ, quella con la Esse maiuscola.
Starò invecchiando, e di conseguenza la mia pazienza starà (ulteriormente) riducendosi, ma di sentirmi ripete filippiche di quanto siano interessanti, stravaganti, azzardate e brillanti le Soluzioni trovate mi irrita. Non mi interessano le Soluzioni. Ancora meno mi interessano le soluzioni tecniche. Almeno, non mi interessano quanto i clienti/studenti/futuri-zuck vorrebbero.
Quello che più mi interessa è qual’è il vantaggio (inteso come unique value proposition, da non confondersi con il vantaggio competitivo descritto nel libro) che queste presunte Soluzioni riescono a portare. Spiegato possibilmente in due parole e, magari, con obiettivi (associabili anche a delle key metrics) chiari.
Supponiamo che il problema sia “raggiungere un luogo in minor tempo”. Prima ancora di pensare ad una Soluzione geniale [ie. “usiamo un jet”] è necessario, a mio parere, capire bene il perché vogliamo raggiungerlo nel minor tempo. Qual’è il vantaggio che vogliamo veramente ottenere nel risparmiare un po’ di tempo. In base a questo, semplice, principio si può decidere se ha senso investire qualche milione di euro per un jet oppure ne bastano qualche centinaia per una bicicletta. E soprattutto ci permetterà di capire se il problema è generalizzabile o meno, e come costruirci sopra un MVP efficace.
Sapere bene quali sono i risultati a cui si vuole arrivare serve anche a chiarirsi, non poco, le idee sul business in cui ci si vuole addentrare. Avrà senso sviluppare tutte le funzionalità richieste dalla Soluzione? Oppure posso limitarmi a quelle che garantiscono parte del vantaggio immediatamente?
Se Maurya mette lo studio, e la definizione (UVP), delle metriche ottenute (key metrics) come una delle ultime cose da analizzare quando si prepara un lean canvas per me, invece, è una delle prime attività da fare per capire se il dominio del problema è stato veramente studiato a fondo. Saranno proprio le metriche che vogliamo ottenere ad indicare al team di sviluppo come muoversi, e saranno sempre queste ad essere una cartina al tornasole per tutto il processo di validazione del prodotto con gli utenti finali.
La Soluzione sarà, poi, solo uno dei possibili punti di arrivo.