A Systematization of Methodologies in Startup Thinking

(The Italian translation follows. A special thanks to Jacopo Romei and Stelio Verzera for the fruitful discussion we had on this).

It is some time now I’m coaching or advising companies creating products and services or just facing innovation challenges. I’ve been dealing with several methodologies, which have shown useful at different stages and for different purposes. My inclination to connect the dots did the rest and led me to reflect, describe and consolidate what I’ve done in recent years. This post is just a recap of my experience so far.

Dozens of approaches, disciplines and methodologies exist and is not the objective of the post to push for one or another: each of us has her own way. Here you will find mine.

The problem: start with proven methodologies

Over time I found a disturbing tendency among the many dealing with innovation and startups: many tend to forget how important is to build on proven principles and methodologies. Many believe that talent and natural management can generate results no matter if you actually study, internalize and experiment with proven best practices. Others consider their intuition and their way of seeing things, more interesting, simple or easier to apply. Some are aware of the problem (their inability to eventually progress and innovate), but they don’t implement correctives and don’t experiment, overwhelmed by the rush for getting (many wrong) things done daily.

Systematization of Startup Methodologies - meedabyte

Practice and Adapt

In Japanese martial arts there is a principle I discovered recently, thanks to my inspirational friend and coach Jacopo Romei, that is really worth telling. The principle of Shuhari.

This principle professes the importance of practicing a rule before adapting and overcoming it, in line with your own talents and abilities: a clear and simple example is that of the sport practitioner that follows the dictates of the master (Shu) and then, only after the full internalisation – that makes the canonical practice natural and intuitive, almost automatic – progresses in rethinking the canon itself (ha), to finally transcend it by creating something new (ri).

I found that this philosophy really adheres with what is required today to those who deal with innovation.

A radical principle: agile thinking and rejection of formalism

Without a doubt, if there is a school of thought that more than others is central to everything related to innovation – and therefore also in this systematization – is the agile manifesto. Just a few days ago, while I was debating this formalization effort on the social media, Jacopo again pushed me to note that Agile Thinking mostly refuses formalisms in favour of practice, supported by texts.

Ron Jeffries himself – one of the authors of the agile manifesto – while talking about XP theme (learn more read Kent Beck, Extreme Programming Explained) a few years ago reduced the debate on formalisms to this:

“Sorry. Agile processes are not formal. But do read Kent’s book, mines,and Jim Shore’s.”

So the question is: does it makes sense to formalize at least an overview?

My impression is that the amount of theories and practices that may be useful (I would say essential at times) to those who want to create new solutions to problems, not only allow a schematization attempt but actually make it necessary.

Practice trumps theory, but where to start?

This framing effort is thus to be intended as a rough guide for anyone approaching this processes and contexts and for those like me needing to deal with it from the inside.

Firstly, it is worth clarifying what we are dealing with in details: we are talking about creating innovative products and services, both in the corporate and the startup context. It’s about understanding the key phases and reference subject of study.

It is undoubtedly very difficult to identify the phases in the process, because the principle of permanent adaptation to changing conditions (such as the market) and that of continue iterations can’t be left in favor of a purely linear perspective. However having a clue on the basic steps can give individuals an overview.

Agile

Envisioning and Discovery

The first phase is the one in which we proceed to the definition of the vision (Envisioning) immediately followed by the validation of the value hypothesis (Discovery).

Though it is difficult to identify a methodology that can help you generate disruptive product ideas, this challenge has been taken in many ways and in many contexts. Those of you who participated in a Startup Weekend, or a Service Design Jam, could certainly understand how the methods of co-creation and the tools related to the world of design thinking can play a decisive role. These approaches are great to identify problems worth solving and generating creative solutions. I wrote about co-creation contexts and events here on the blog (this is the post if you want to give a read).

If you put together many points of view, a diverse set of skills, the interaction between people can be a pretty good source of ideas. Analyzing their contexts, problems, points of friction – for example through a stakeholder or actors map (that displays most of the relationships, especially those problematic) is a powerful tool to identify new opportunities for product or services (here you can find some case studies). Then, moving forward on the path of design, specifying actors (personas), actions, relationships and motivations plus touchpoints to produce a preliminary Blueprint Service or Customer Journey is a very valuable source of information to move forward.  This design phase will help you understand what cost structures your service may have (for example related to support processes) or the revenues which may be generated.

Customer Journey

A snapshot of the Customer Journey Canvas from http://thisisservicedesignthinking.com/

The next step, discovery, brings the design concepts to reality to be verified directly on the market, with potential users, thanks to tools like the Customer Development process described by Steve Blank in The Four Steps to the Epiphany.

Indeed, all the first phase of Customer Development, involves Customer Discovery activities. It is based on the analysis of the problem and the description of the solutions (Problem statement, Product Description, Features). The ability to detailing these aspects is the pillar to gather direct customer feedback through interviews. Believe me, it is not uncommon to find startuppers or innovators that can’t answer a simple question: “what problem are you solving”. Some can’t even describe who these customers are and what is the proverbial “Day in the customer life” that is so crucial to understand whether the value proposition you’re offering is worth.

In a low investment phase like the one we see in Europe and Italy these days, you need to keep the process simple: just check and learn fast if there is room in the market for your product. Very soon, think about the numbers and figure out if, once mature, the venture can sustain itself. The much infamous Minimum Viable Product is noting more than a learning tool. This is the Discovery phase, a phase in which each expedient of learning is permitted.

Once the hypotheses validation phase is over (regarding the problem, product and features), with a reasonable demonstration that the product has a market fit, then and only then you can start thinking about maturation and growth.

Customer Discovery

The market fit

Even if there is no single answer to the question: “Did I find the market fit?” however, a consideration can be made. Ways to validate your market fit are that advocated (in different but similar ways) by Steve Blank and Ash Mayura in their books. A great post by Paul Graham (“Do things That Do not scale“) recenty gave some great insights on this exact phase.

The idea is to create products that are priced from day zero with a clear and repeatable sales path: start selling to customers is the fastest way to test your market fit. This is explained in a fairly immediate way in “The Four Steps to Epiphany”, while Mayura’s approach invites you to put these assumptions and estimates from scratch in the Lean Canvas, to understand soon if the pricing and revenue generated can be reconciled with the production costs. Aslo refer to the Business Model Canvas by Alex Osterwalder, which can provide unvaluable support in identifying the cost items and key resources.

Once you have identified your market fit, the most complex part of the work is done: you have a product that solves a problem, you shown that, with a certain pricing, there is a market willing to buy the product. If you have carried on a good analysis phase (via the Service Blueprint and an iteration or two of the Business Model Canvas) you should have identified the support processes and therefore most of the infrastructure and process costs as well. Following this, you will have a goal of a target user base that should lead to the break-even point where your user base turns your service sustainable.

A side note: I am always advising to keep this numbers as much low as possible and aim at a fast and organic break even. A bootstrapped startup is complex to create and bring to the market fit but once there it has a tangible value, built, if you’re good, on the basis of real problems.

Growth

After the market fit, what you need is to generate growth. Eric Ries sufficiently simplified this problem in “The Lean Startup” clearly dividing products in viral and non viral. If you are struggling with a viral product and you are able, or creative enough, to create viral mechanisms then you will not need much marketing. However, being viral is not simple, it depends on the nature of the product (works more in products that have p2p relations in the model), can vary enormously according to small details (it’s definitely non-linear). It also does not apply (or at least marginally) to certain products such as B2B ones, for example.

For all other products the marketing spending will be a must. The difficulty in this case is to get to understand the value of your customers,the Customer Lifetime Value that will be your reference value in considering the effectiveness of a campaign of advertising or marketing.

Assume to advertise through google. Leave a budget and do an experiment for three months: understand how many acquisitions (new customers) you’re able to generate with that budget and then you’re done, if you know your CLV, you just need to compare with your CPA (Cost Per Acquisition).If the result is negative, you are in trouble because acquiring a customer through advertising is costing you more than the value it creates.

With different campaigns the CPA would be more complex to grasp: for example with radio or TV campaigns, compared to Google advertising. You should always try: dropping leaflets from a plane can be measured (just putting a discount code in it) but some generic marketing efforts, such as the participation in conferences, are typically difficult to measure. My advice is to avoid as much as possible what is not measurable or, at least, not measuring it in CPA (for example, the value of being at an industry conference is intangible, it depends on how many hands you’ll shake around).

Maturation

As you can see in the figure, I wanted to stress out the point that, along with growth, you will need to aim at maturity. Maturing, for an organization, a startup or a product it means to apply a coherent strategy and an efficient execution.

In my experience, agile management methods and lean thinking, represent a true philosopher’s stone in this. These methods are there to help at different levels but, at least in my experience, I can identify two decisive ones. The first layer is that of strategic thinking, the one where you must implement a PDCA cycle, which allows to review monthly (or, in general, from time to time) how closer you getting to your objectives. In this context, everyone has their own reasonable preference. One method that I’m exploring now, that seems pretty simple and straightforward, it’s the “Improvement Kata” described in the book Toyota Kata. In a few words, it is to select the most relevant processes, pose long-term objectives in relation to these processes, and to test experiments in which we can track the effectiveness in approaching the objectives (process metrics).

katapattern

A clear example of long-term goal might be: “We want our software releases have zero defects”.

In this case, the process is development and an experiment to test could be, for example, adopting pair programming for a release and actually check with clear metrics (such as the number of defect emerged one month after launch) how much are you improving.

Obviously, once we have our strategies on the table these will dictate the priority of the experiments that will make it to planning, as part of the things to do. In this strategic plan execution phase, once again, we can borrow from Agile approaches. The agile manifesto and some other great books (once again the suggestions comes from Jacopo Romei) such as the already mentioned book by Kent Beck and “Lean Software Development” from the Poppendieck) may serve as an inspiration.

From this point of view, I’m sharing with you my experience in adapting Scrum, following the experiences of others shared on Scrum Alliance and Scrum.org (I’ve been reading several excellent papers and post about experiences adapting Scrum to different contexts). This file contains a brief description of the process, everything is available in CC-BY, you can fork or give comments here: A Scrum Inspired Execution Model for Multi Project / Program – (Innovation, Startups & Services).

Think as an Ecosystem

The last phase of full implementation of a business idea, a product, a startup is that of consolidation. A reasonable amount of trends point out the ability that creating an ecosystem around a product is a key for success. To leave peers from the customer segments to have both a consumption and an active roles of contribution you need to experiment with new exchange currencies, to model the trust and credit generated, you need to talk with the value creators and facilitate the emergence of these kind of markets.

Obviously this is not a per se approach applicable to every business or product but know that the more your product can be a (more or less formal) seen as a platform for user driven value creation the mor eyour future is bright. Community driven development and is widely discussed in this post that introduced for the first time the Platform Design Canvas.

The Platform Design Canvas

Future Proof Design

Thinking as a platform does not mean only to develop infrastructures and markeplaces but it’s also about identifying a reference community and model business touchpoints in line with the community expectations. An emblematic case is that of Twilio, a startup that actually redefined the market for telecommunications APIs. A famous quote by Jeff Lawson, CEO of Twilio reads:

”The art of creating software and building new things was starting to get celebrated at these hackathons. Where there was a hackathon, there was Twilio.”

This quote shows clearly how this company was actually built upon developers expectations (you can figure the amount of feedback that an API provider can get during a Hackaton). Twilio is a half billion, business now, in a market as complex as that of the Telco APIs that never really ramped up before thanks to very unappealing carrier initiatives.

Conclusions

I believe that innovate today is simple, but only for those who want to compete in excellence, study, and personal competence growth. Many of the professionals escaped from the full time employee labor market, because of the contractions that large companies are having by virtue of the tumultuous changes in the market, should jump on these opportunities and start learning again.

Most young startuppers instead, should have a moral obligation to invest some time in studying and training with these methodologies and body of knowledge, to ensure that their valuable time is not wasted creating unnecessary products and services that no one will use, if they will ever see the light.

If you liked the post, you should follow me on twitter here! Now please tweet this!


Traduzione in Italiano. Come riferimento si tenga questa immagine.

Una sistemazione della conoscenza nel mondo Startup

È ormai qualche tempo che mi occupo di coaching come advisor strategico per chi fa innovazione di prodotto e servizio. L’esperienza mi ha dato numerosi  spunti di riflessione. Nel tempo ho incontrato diverse metodologie, che mi sono state utili in diverse fasi e per diversi scopi. La mia abitudine a unire i puntini ha fatto il resto e mi ha portato a riflettere, descrivere e consolidare quanto fatto in questi anni, fino ad arrivare a questo post che cerca di fare un po’ d’ordine.

Ovviamente esistono decine di approcci, discipline e metodologie e non è tra gli obiettivi del post quello di sostenerne uno rispetto ad un altro approccio: ognuno ha la sua strada. Qui trovate la mia.

Il problema: iniziare da metodologie testate e acquisite

Nel tempo ho riscontrato, purtroppo con una regolarità disarmante, una cattiva tendenza tra i moltissimi che si occupano di innovazione di prodotto/servizio (startup):  si tende a dimenticare quanto sia importante basarsi su principi e metodologie testate e di provato successo. Molti credono che il talento e la naturale capacità di management possano generare risultati a prescindere da quanto ci si applic nello studio e nella sperimentazione di best practice consolidate. Altri, seppure coscienti e informati, prescindono dalla pratica e considerano regolarmente la loro intuizione e il loro modo di vedere le cose, superiore, più semplice o più immediato da applicare. Altri ancora sono coscienti della problematica (la loro incapacità di progredire e innovare) ma non mettono in atto alcun correttivo e non sperimentano, travolti dalla giornaliera necessità di portare a termine le cose (a volte sbagliate) da fare.

Pratica e adattamento

Nella arti marziali giapponesi esiste un principio che ho scoperto da poco, grazie all’amico, coach e ispiratore Jacopo Romei e che vale la pena di raccontare in questo contesto. Il principio dello Shuhari.

Questo principio professa l’importanza di praticare una regola prima di adattarla e superarla, in linea coi propri talenti e le proprie capacità: un esempio chiaro e semplice è quello del praticante dello sport che dapprima segue i dettami tecnici del maestro/allenatore (Shu) e poi, solo in seguito alla completa internalizzazione – così elevata dal rendere la pratica canonica naturale e intuitiva, quasi automatica – si procede nel ripensare il canone (ha), per finalmente trascenderlo creando qualcosa di nuovo (ri).

Ho trovato questa filosofia veramente aderente a quello che è richiesto oggi a chi fa innovazione.

Un principio radicale: agile thinking e rifiuto del formalismo

Senza dubbio, se c’è una scuola di pensiero che più altre è centrale in tutto ciò che riguarda l’innovazione significativa e efficiente – e dunque anche in questo quadro di sistematizzazione – è il manifesto agile. Proprio qualche giorno fa, mentre mi confrontavo sui social media rispetto a questo tentativo di formalizzazione, sempre Jacopo mi ha spinto a notare che il pensare Agile non ammette formalismi, e indica nella pratica, supportata dallo studio dei testi, la risposta migliore alla necessità di imparare.

Lo stesso Ron Jeffries – tra gli autori del manifesto agile – che, in un gruppo sul tema XP (per saperne di più leggete Kent Beck , Extreme Programming Explained ) qualche anno fa ridusse la questione formalismi a questo:

Sorry. Agile processes are not formal. But do read Kent’s book, mine, and Jim Shore’s.

La domanda dunque è: ha senso tentare di formalizzare almeno una visione di insieme?

La mia impressione è che la mole di teorie e pratiche che possono tornare utili (direi fondamentali a volte) per chi desidera creare nuove soluzioni ai problemi, sia tale non solo da ammettere un tentativo di formalizzazione, bensì da renderlo necessario.

La pratica vince sulla teoria: ma da dove cominciare?

Questo sforzo di framing è dunque orientato a rappresentare una guida per chi si avvicini a questo campo o per  chi come me c’è dentro e ha bisogno di orientarsi.

Innanzi tutto vale la pena di chiarire di cosa stiamo parlando nel dettaglio: parliamo di creare servizi e prodotti innovativi, in contesti esistenti e consolidati (grandi aziende) o meno (startups). Si tratta di capire le fasi principali e quali discipline studiare e usare in riferimento a esse.

È senza dubbio molto difficile identificare delle fasi nel processo, perché il principio dell’adattarsi al cambiamento delle condizioni al contorno (mercato, etc…) e della iterazione continua non possono di certo essere dimenticati, in favore di una prospettiva puramente lineare. Tuttavia una lettura che individui alcuni step fondamentali può dare una visione di insieme.

Envisioning e Discovery

Una prima fase identificabile è senza dubbio quella in cui si procede alla definizione della vision (Envisioning) subito seguita dalla validazione delle ipotesi di valore (Discovery ).

Benché sia complesso identificare una metodologia che possa realmente aiutare a generare idee di prodotto disruptive , questa sfida è stata raccolta in molti modi e in molti contesti.  Chi di voi ha partecipato a uno Startup Weekend, a una Service Design Jam, ha potuto sicuramente cogliere come le metodologie di co-creazione e i tools legati al mondo del design thinking possono avere un ruolo decisivo nell’identificare problemi che valga la pena risolvere e nel generare creativamente soluzioni. In passato ho avuto modo di scrivere di eventi e contesti di co-creazione qui sul blog (questo è il post per chi volesse approfondire).

Se mettere insieme molti punti di vista, professionalità e persone può essere una fucina di idee degna di nota, analizzare i loro contesti, i loro problemi, i punti di frizione – per esempio mediante una stakeholder o actors map (che visualizzi meglio le relazioni, specie quelle problematiche)  è un potente generatore di nuove opportunità di prodotto o servizio (qui trovate alcuni case study). Continuare poi sulla strada del design, specificando attori (personas), azioni e relazioni, motivazioni, touchpoints arrivando a produrre un preliminare Service Blueprint o Customer Journey è una fonte di informazioni molto preziosa per progredire con la progettazione e per capire megio quali strutture di costo un servizio potrà avere (legate ad  esempio a processi di supporto) o quali revenues si possano generare.

La fase successiva, di discovery, riguarda la semplificazione dei concetti che vengono fuori dalla fase di design, nell’ottica di poterli verificare direttamente sul mercato, con i potenziali utenti, adattando alle proprie esigenze uno strumento come il modello di Customer Development di Steve Blank descritto in The Four Steps To the Epiphany.

In effetti, tutta la prima fase del processo di Customer Development, prevede l’attività di Customer Discovery. Essa è basata sull’analisi del problema e sulla descrizione della soluzioni (Problem statement, Product Description, Features). La capacità di dettagliare tali aspetti è il pilastro su cui si basa la fase di feedback diretto, tramite le interviste. Credetemi: non è raro trovare startupper o innovatori che alla domanda “quale problema risolvi ai tuoi clienti” non hanno risposta. Alcuni vanno in difficoltà anche solo nel descrivere quali sono questi clienti e qual è il proverbiale “Day in the customer life” che tanto è fondamentale per capire se la Value Proposition che si sta proponendo al mercato ha senso e si integra con l’esperienza giornaliera del cliente (utente).

In un quadro di bassi investimenti come quello che vediamo in Europa e Italia è cruciale ragionare in modo semplice: nella prima fase la cosa più importante è apprendere se c’è spazio sul mercato per il prodotto e se questo, una volta maturo, possa sostenersi. Il tanto famigerato Minimum Viable Product non è che uno strumento di apprendimento. Questa è la fase di Discovery, una fase in cui ogni espediente di apprendimento è lecito.

Una volta che la fase di validazione delle ipotesi (prima del problema e poi del prodotto e delle features) termina, e si ha una ragionevole  dimostrazione che il prodotto ha una market fit, allora e solo allora ci si può dedicare alla maturazione e alla crescita.

La market  fit

Pure se non esiste una risposta univoca alla domanda: “ho trovato la market fit?” tuttavia una considerazione può essere fatta. Una prima maniera di validare la vostra market fit è quella che sostanzialmente propongono – in maniera diversa ma guidata dallo stesso principio – Steve Blank e Ash Mayura e che è stata recentemente riportata a galla anche in una meraviglioso post di Paul Graham (“Do things that don’t scale”).

L’idea è creare prodotti che dal giorno zero, abbiano una prospettiva e una ipotesi di pricing e un percorso di vendita: partire vendendo a dei clienti non che il modo più veloce di verificare la vostra market fit. Questo aspetto è spiegato in maniera ragionevolmente immediata in “The Four Steps to Epiphany”, mentre l’approccio di Mayura ci invita addirittura a porre queste ipotesi e previsioni nel Lean Canvas, allo scopo di comprendere fin da subito come il pricing e le revenue generate si possono conciliare  coi costi di produzione. Ovviamente è d’aiuto, in questa fase, fare riferimento anche al Business Model Canvas di Alex Osterwalder, che può fornire un valido supporto nell’identificare le voci di costo e le risorse chiave.

Una volta che avrete individuato la vostra market fit, la parte più complessa del lavoro è fatta: avete un prodotto che risolve un problema, avete dimostrato che, con un certo pricing, esiste un mercato disposto a comprare il prodotto. Se avete fatto bene la fase di analisi (attraverso il Service Blueprint e una iterazione o due del Business Model Canvas) dovreste aver individuato i processi di supporto e dunque la maggior parte dei costi infrastrutturali. A seguito di questi ragionamenti, avrete un obiettivo di massima di user base target per arrivare a una sorta di break-even point dove la vostra user base trasforma il vostro servizio in sostenibile.

Aggiungo una nota: mi sento sempre di consigliare di mantenere il più basso possibile questo numero. Una startup bootstrapped è complessa da creare e da portare alla market fit ma una volta li produce un valore tangibile, costruito, se sarete bravi, sulla base di reali problemi.

La crescita

Dopo la market fit, quello che serve è generare crescita.  Sufficientemente semplice è la visione di Eric Ries che in “The Lean Startup” divide chiaramente i prodotti in virali e non virali. Se siete alle prese con un prodotto virale e siete in grado, creativi abbastanza, per creare meccanismi di viralità vincenti allora non avrete granché bisogno di marketing. Tuttavia, la viralità non è semplice da ottenere, dipende dalla natura del prodotto (funziona di più nei prodotti che hanno relazioni tra pari – p2p – nel modello), può variare enormemente al variare di dettagli. Inoltre non si applica (o si applica molto difficilmente) a certi prodotti: quali i prodotti B2B per esempio.

Per tutti gli altri prodotti il marketing sarà una spesa obbligata. Il difficile in questo caso è arrivare a capire il valore dei vostri clienti, quel Customer Lifetime Value che dovrà essere il vostro valore di riferimento nel considerare l’efficacia di una campagna di pubblicità o marketing.

Con la pubblicità il conto è molto semplice: ipotizziamo di fare pubblicità tramite google. Dededicate un budget e fate un esperimento per tre mesi, comprendete quanti acquisizioni (nuovi clienti) riuscite a generare con quel budget e poi il gioco è fatto; se conoscete CLV della vostra clientela si tratta di fare una sottrazione: CLV – CPA (Cost per Acquisition).  Se il risultato è negativo siete nei guai perché acquisire un cliente grazie alla pubblicità vi costa di più del valore che genera.

Non con tutte le campagne è semplice capire il CPA: sarebbe senz’altro più complesso con campagne alla radio o alla TV, rispetto a una pubblicità su Google. Virtualmente anche lanciare volantini da un aereo può essere misurato (basterebbe mettere un codice sconto nel flyer) ma sforzi di marketing più generici come, ad esempio, la partecipazione a conferenze, sono tipicamente difficili da misurare. Il mio consiglio è evitare il più possibile ciò che non è misurabile, quantomeno non misurarlo in CPA (ad esempio il valore della partecipazione a una conferenza di settore è intangibile, dipende da molte variabili e da quante mano stringerete).

La maturazione

Come potete vedere nella figura, ho voluto stressare il punto che, insieme alla crescita, dovrete puntare alla maturazione. Maturare, per una organizzazione, una startup o un prodotto, significa applicare una strategia coerente e una esecuzione efficace.

Nella mia esperienza, i metodi di management agile e lean, rappresentano una vera e propria pietra filosofale capace di dare chance reali di crescita ai progetti. Questi metodi ci vengono in aiuto a diversi livelli ma, almeno nella mia esperienza, posso identificare due livelli decisivi. Il primo layer è quello strategico dove è d’obbligo implementare un meccanisco PDCA, che permetta di rivedere mensilmente (o, in generale, periodicamente) quanto ci stiamo avvicinando agli obiettivi di lungo periodo. In quest’ambito ognuno ha le sue ragionevoli preferenze. Un metodo che sto esplorando ora, che sembra abbastanza semplice e immediato, è “Improvement Kata” descritto nel libro Toyota Kata. In pochissime parole, si tratta di selezionare i processi più rilevanti, porre obiettivi di lungo periodo relativamente a questi processi, e mettere alla prova esperimenti di cui si possa tracciare l’efficacia nell’avvicinarci agli obiettivi (metriche di processo).

Un esempio chiaro di obiettivo di lungo periodo può essere: “Vogliamo che le nostre release software abbiano zero defects”. In questo caso, il processo è quello di sviluppo e un esperimento per verificare questo obiettivo potrebbe essere utilizzare il pair programming per un mese e verificare effettivamente con una metrica chiara (i defect rilevati nella prima settimana dopo il lancio) quanto state migliorando.

Ovviamente, una volta che avremo le nostre strategie sul tavolo queste detteranno la priorità degli esperimenti che andranno in piano, come parte delle cose da fare, insieme a tutto il resto. In questa fase di execution del piano strategico, ancora una volta, ci potrà venire in aiuto l’approccio Agile. Il manifesto agile e alcuni grandi libri (ancora una volta riporto i suggerimenti datimi da Jacopo Romei quali il libro di Kent Beck già citato e “Lean Software Development”, dei coniugi Poppendieck ) potranno darci lo spunto sperimentale per verificare come questi principi si adattano al nostro contesto e quanto il nostro processo di lavoro possa migliorare incorporando gli stessi.

Da questo punto di vista, condivido con voi la mia esperienza nell’ adattare Scrum, seguendo le esperienze di altri condivise su Scrum Alliance, e Scrum.org (ho letto parecchi ottimi papers e post riguardo ciò che si può fare per adattare Scrum e l’approccio agile a contesti diversi). Questo file contiene una breve descrizione del processo, il tutto è disponibile in CC-BY, non mi soffermo ma chi vuole potrà dare commenti sul file o qui: “A Scrum Inspired Execution Model for Multi Project / Program – (Innovation, Startups & Services)

Scalare e pensare all’ecosistema

L’ultima fase della realizzazione completa di una idea di business, un prodotto, una startup è quella del consolidamento. Una ragionevole quantità di trend indicano nella capacità di creare un ecosistema intorno al prodotto la chiave del successo nel futuro: ogni peer, ogni customer segment può avere ruoli di consumo o ruoli attivi di contribuzione, occorre sperimentare nuove currency di scambio tra gli utenti per modellare il trust e il credito generato, occorre dialogare con i creatori di valore e facilitare l’emergere di questi mercati.

Ovviamente questo non è un approccio applicabile tout court a ogni business o prodotto ma sappiate che più il vostro prodotto si presta ad essere una “piattaforma” (più o meno formale) di creazione di valore e scambio per una community più le prospettive future saranno rosee (il tema è ampiamente trattato questo pezzo in cui ho introdotto per la prima volta il Platform Design Canvas ).

Pensare da piattaforma non significa solo sviluppare infrastrutture e markeplaces ma anche saper individuare una comunità di riferimento e modellare i touchpoints aziendali in linea con le aspettative della stessa. Caso emblematico è quello di Twilio, la startup che ha ridefinito il mercato delle api per le telecomunicazioni. Una famosa citazione di Jeff Lawson, il CEO  di Twilio recita:

”The art of creating software and building new things was starting to get celebrated at these hackathons. Where there was a hackathon, there was Twilio.”

Dando l’idea di come l’azienda abbia letteralmente tirato fouri dagli sviluppatori (avrete idea della quantità enorme di feedback che un produttore di API può ricevere durante un Hackaton) un business che vale mezzo miliardo di dollari, per giunta in un mercato come complesso come quello delle Telco.

Conclusioni

In conclusione, credo che fare innovazione oggi sia semplice, ma solo per chi ha voglia di misurarsi con un approccio di eccelenza, di studio, di crescita competenziale e personale. Molti dei professionisti fuoriusciti dal mercato tradizionale del lavoro dipendente, anche a causa delle contrazioni che il business delle grandi aziende sta avendo in virtù dei cambiamenti tumultuosi sul mercato, dovrebbero cogliere la palla al balzo e mettersi in discussione da questo punto di vista.

I più giovani startupper invece hanno l’obbligo morale di investire tempo, all’inizio della loro avventura di innovatori, nello studio e nell’approfondimento, nell’allenamento a queste metodologie, per far si che il loro prezioso tempo non venga sprecato creando inutili prodotti e servizi che nessuno userà mai, se mai vedranno la luce.

About meedabyte

Strategist, Consultant and Collaborative Pathfinder

2 comments

  1. Pingback: Lean Thinking Your Way Through an EMR Implementation: A Practitioner’s Guide to Planning and Executing a Successful Project | WWW.JUSTINFOHUB.COM

  2. Pingback: The Hacker Ethic of Work | Meedabyte

Leave a comment