Cum se iau deciziile de produs într-un startup ca Vuuh?

Când vine vorba de lucratul la un startup, una din principalele avantaje pe care le văd e lanțul de decizie și procesele prin care se iau deciziile, în ideea că ai mai mult de spus în direcția companiei, și de la decizie se ajunge rapid la implementare (care poate fi și un avantaj pentru că livratul nu se măsoară în quarters, dar poate fi un dezavantaj pentru că pot apărea schimbări de direcție din scurt).

Voi povesti pe subiectul acesta din experiența mea de la Vuuh, pentru a oferi niște context despre cum "se fac lucrurile la noi". Scopul nu de a ajunge la vreo concluzie, ci doar despre a povesti high-level despre cum facem noi lucrurile. Concluziile le trageți singuri 😄

Deciziile de produs sunt principalele ca pondere pe care le luăm acum și de asta am decis să fie acesta focusul postării. Fiind într-o etapă de dezvoltare accelerată și vânzare, avem foarte mult feedback de la clienți, pain points, lucruri neoptimizate, idei noi, refactorizări, sisteme noi interne care să accelereze compania și lista continuă.

Cu alte cuvinte, avem o listă interminabilă de lucruri de făcut, toate relativ urgente, dar resurse foarte limitate (ca timp și degete pe taste, de exemplu eu am numai 10 pe care le investesc și să mai scriu câte un articol ca acesta din când în cand 😄).

Așa că, genul de decizii care influențează direcția companiei trebuiesc luate rapid, des și ne obligă să facem o prioritizare "la sânge".

Ce luăm în considerare când luam decizii de produs:

• în primul rând, impactul financiar, în ideea că unele feature-uri sunt pe bază de contract plătit, care aduc bani în firmă, sau e ceva care impactează direct un client de mărime mai mare care cotizează mai mult.
• în al doilea rând, complexitatea ca workload și timp de dezvoltare: cât de complicat e procesul, cât de mult ne-ar lua să implementăm, câtă capacitate de dezvoltare necesită (cu alte cuvinte câte din resursele companiei trebuie să le dedicăm pentru a face asta și pentru cât timp, și cum afectează asta progresul altor proiecte în derulare).
• în al treilea rând, cât de tare doare: adică bug-urile alea care efectiv blocheaza un proces în platformă și nu are work-around, devin prioritatea zero. După aceea, feature-uri promise pe deadline, și după acele task-uri care au impact mai "invizibil" (gen optimizări, investigații pe date sau pe performanță sau un tool nou care facilitează o operațiune care se execută des).

Sunt companii care formalizează aceste dimensiuni fie folosind niște framework-uri cu tabele, note sau puncte cum ar fi Complexity vs Value pentru prioritizare.

Noi suntem la stadiul de discuție prin care stabilim cumva mai "democratic", pentru că discuția despre valoarea unui feature e diferită pentru fiecare în parte (pentru sales ceva contează mai mult decât altceva, pentru development altele, pentru suport altele, etc). E important să stabilim diferențele early in the process și să prioritizăm în funcție de "valoare medie" agreată de toată lumea implicată.

În funcție de asta, discutăm și ne aliniem așteptările, în primul rând ale noastre, dar care eventual devin și așteptările comunicate clienților, pentru că am convenit că dacă nu avem capacitatea de a livra mai mult de atât, comunicăm, și prioritizăm "la sânge" ce putem face. Dacă nu ținem sub control tendința de a vrea să facem totul acum, ajungem să creăm un mediu nesănătos de muncă care duce la burnout. Asta e grija noastră cea mai mare, că o firmă poate funcționa cu motoarele turate la maxim o perioadă scurtă, dar nu e un lucru sustenabil pe termen mediu sau lung.

Periodic, adică o dată pe săptămână, ne "întâlnim" reprezentanții direcțiilor companiei pentru a ne alinia despre ceea ce trebuie făcut în perioada următoare.

Uneori mai apar situații noi și prioritățile se modifică, uneori concluzia e că "mergem înainte cum e deja stabilit". Dar e important pentru noi ca cele patru direcții să fie aliniate și așteptările să fie setate corect pentru partea de dezvoltare: partea de vânzări, partea de suport, partea de enterprise, partea de user success și partea de user experience (PS: sunt mai multe părți enumerate decât oameni implicați, pentru că unele pălării sunt purtate unele peste aletele de aceeași persoană #startuplife).

Dacă nu ati dat subscribe deja la "The Tech Bubble", vă invit să o faceți. E un proiect media despre IT-ul românesc, startup-uri, și nu numai. Voi scrie sămtămânal un articol în fiecare Luni și Joi (sau cel puțin așa încerc) și voi posta câte un episod săptămânal pe canalul de Youtube.