TORNAR

El poder del MVP

4 min de lectura

Hi ha molta literatura sobre productes mínims viables (MVP). No crec que pugui aportar noves idees, però compartiré la meva perspectiva basada en una experiència amb un client.

MVP - Un patí primer, després una bici i finalment un cotxe

Un producte mínim viable (MVP) és una versió d'un producte amb les característiques justes per satisfer els primers clients i proporcionar retroalimentació per al desenvolupament futur del producte.

Wikipedia

Posem context. El client era una empresa europea líder en el camp immobiliari—encara que el domini importa poc aquí. L'equip de producte imaginava un producte complex per vendre als seus clients. Per mesurar l'acceptació dels usuaris, vam executar múltiples proves A/B per trobar l'enfocament més exitós. El producte era senzill d'implementar, però decidir quins usuaris haurien de veure què era una altra història. Havíem de considerar la ubicació de l'usuari, la ubicació de cerca, l'última visita, etc. El nombre de variables era gran, així que vam executar les proves durant gairebé mig any per reunir dades significatives.

Aquest tipus d'experiment requereix mètriques adequades, així que vam mesurar tot. Un cop acabada la prova, l'equip d'anàlisi va fer la seva feina—i els resultats ens van decebre. Van quedar molt lluny de les expectatives. Tot i així, una petita part del producte va ressonar fortament amb els usuaris, i un mes després l'equip de producte va construir un nou producte al voltant d'ella.

Ara comença la història real. El nou producte mancava de les regles complexes de l'anterior: sense lògica d'ubicació, sense historial de visites, sense patrons de cerca. Els clients tindrien una secció especial a la pàgina per mostrar els seus productes i compartir-la com volguessin. Com que la part orientada a l'usuari ja existia de la prova anterior, era hora de fer-lo real i començar a vendre.

Vam tenir una reunió per definir l'arquitectura i el pla d'implementació. Dos equips d'enginyeria, el cap de tecnologia i el propietari del producte—unes 14 persones en sales virtuals a través de països—van discutir el millor enfocament i van estimar la finalització. Algú va assenyalar que, com que els clients havien de comprar el producte, necessitaríem involucrar l'equip de comerç. L'equip de productes crearia un nou microservei, i l'equip web consumiria i processaria aquestes dades per habilitar el producte per a cada client.

La complexitat s'acumulava de nou. Les estimacions inicials apuntaven a tres mesos mínim—probablement més, donada la coordinació entre enginyeria, màrqueting i disseny. Escoltant aquestes discussions, vaig preguntar al propietari del producte: "Com vendreu aquest producte a curt termini?" La resposta va desbloquejar un camí més fàcil. Inicialment, un petit equip de vendes contactaria només els clients més importants. Després, avaluarien quins altres clients podrien estar interessats.

Amb aquesta informació, vaig proposar un enfocament poc ortodox. En lloc de construir el sistema complex, coordinar múltiples equips i bloquejar el llançament fins que tot estigués fet—per què no hardcodejar els IDs de clients? Unes poques línies de lògica, i llest. Cada vegada que es vengués el producte, algú enviaria un email a l'equip, i afegiríem l'ID en minuts. Aquesta solució no escala, però no pretenia fer-ho. Com que les vendes es gestionarien manualment al principi, podíem controlar el ritme d'adquisició de clients.

La proposta va ser ben rebuda. Podíem començar a vendre abans i alleujar la pressió sobre els equips d'enginyeria. En només una setmana teníem el producte llest i venut al primer client. Durant els mesos següents, els equips van treballar a un ritme relaxat en la implementació final—una que eliminaria els passos manuals.

Aquesta és la història. Això és el que vaig aprendre:

  • Mantén la implementació el més simple possible. Arribaràs al mercat abans i podràs relaxar alguns terminis.
  • Involucra els equips d'enginyeria aviat en la definició del producte. Diferents perspectives revelen millors solucions.
  • Comparteix la visió completa del projecte amb els enginyers, no només la seva part. El context modela millor arquitectura.

En conclusió: seguiré practicant el que considero un dels trets més importants en un desenvolupador—la mandra. Aquest instint m'impulsa a trobar la forma més simple i ràpida de resoldre un problema.