Problema înainte de produs

Lectură estimată: 4 minute

Estimare pentru text, la un ritm de 180 de cuvinte pe minut. Timpul pentru analizarea codului, exerciții și proiecte se adaugă separat și depinde de ritmul tău.

Problema pe care o vei rezolva: MVP cu izolare și cote

SaaS fictiv: cont A și cont B, fiecare cu documente private. Planul de test permite 100 cereri pe lună. Evenimentul de plată poate fi livrat de două ori.

Rezultatul urmărit

Desenează stările abonamentului, regula cotei și accesul la documente. Testează cererea 100, cererea 101, accesul încrucișat și webhookul duplicat.

Cum recunoști o soluție corectă

Contul B nu vede documentele A. Limita are o regulă explicită la frontieră. Evenimentul duplicat nu prelungește de două ori abonamentul. Plata confirmată vine dintr-o sursă verificată.

Parcurge lecțiile în ordine și păstrează exercițiile în registrul descărcabil. Ultima lecție include atelierul de 40 de minute în care combini conceptele și testezi o variație a situației inițiale. Exemplele comerciale sunt fictive; nu reprezintă rezultate ale unor clienți.

SaaS înseamnă software vândut ca abonament. E atractiv pentru venitul recurent, dar greu: concurezi cu produse mature, ai costuri de infrastructură și suport, iar clienții pleacă imediat ce nu mai văd valoare. Regula de aur: rezolvi întâi o problemă reală și dovedești cererea, apoi scrii cod.

Ce face un SaaS viabil

O problemă pe care oamenii o au repetat (nu o dată), suficient de acută încât să plătească lunar pentru a o rezolva.
Un segment dispus și capabil să plătească — de obicei business (B2B) mai mult decât consumatori (B2C).
Un canal de achiziție pe care ți-l poți permite raportat la prețul abonamentului.
Cost de operare (infrastructură + suport) sub prețul abonamentului, la scară.

Cel mai comun eșec de SaaS: 8 luni de construit în garaj, apoi lansare la zero interes. Inversează: găsești un segment îngust cu o durere acută, vorbești cu 15-20 de oameni din el, le arăți un mockup, și obții precomenzi sau scrisori de intenție ÎNAINTE de a scrie cod serios.

Venitul recurent taie în ambele sensuri

Da, clientul plătește lună de lună. Dar și problema lui e recurentă — trebuie să livrezi valoare în fiecare lună, altfel anulează. Un SaaS nu e „construiește o dată, încasează la infinit". E „livrează valoare constant, sau pleacă".

Nișă îngustă la început

„Software de management de proiecte" — concurezi cu 200 de produse. „Software de management de proiecte pentru agenții de arhitectură din România" — poți fi cel mai bun pentru acel segment, îl poți atinge, și îi înțelegi durerea exact. Extinzi după ce domini nișa.

Exercițiu

Definește segmentul îngust și durerea acută pe care le țintești. Scrie: cine sunt (specific), ce problemă au recurent, cât îi costă acum (bani/timp), ce folosesc în prezent, de ce e nesatisfăcător. Fă o listă de 20 de oameni reali din acel segment.

Greșeli frecvente

Construiești 8 luni înainte să validezi cererea.
Țintești o piață largă și concurezi cu produse mature.
Crezi că venitul recurent înseamnă „încasezi fără să livrezi".
Alegi o problemă pe care oamenii o au o dată pe an, nu recurent.

De reținut

SaaS viabil: problemă recurentă acută + segment care plătește + canal accesibil + cost sub preț.
Validează cererea (interviuri, precomenzi) înainte de cod.
Venitul recurent cere valoare livrată în fiecare lună.
Nișă îngustă la început; extinzi după ce domini.

Pe scurt

Un SaaS pornește de la o durere recurentă a unui segment îngust, validată cu oameni reali. Codul vine după dovada cererii, nu înainte.

Problema SaaS înaintea funcțiilor

Un SaaS rezolvă o problemă repetată printr-un serviciu operat continuu. Înainte de dashboard, stabilește cine are problema, cât de des și cum o rezolvă acum. Pentru un sistem de programări, valoarea poate fi reducerea confuziei, nu numărul de ecrane. Un prototip manual poate testa fluxul fără infrastructură complexă. Nu prezenta o idee sau un portofoliu ca dovadă de cerere și retenție fără date reale.

Exemplu de lucru

Ipoteză: atelierele au reprogramări greu de urmărit.
Flux minim: cerere → confirmare operator → schimbare → istoric.
Date necesare: identificator, interval, status, contact minim.
Validare: folosire într-un pilot autorizat și feedback documentat.
Exclude la început: marketplace, aplicație mobilă și analytics complexe.

Interpretarea rezultatului

Dacă problema apare rar sau soluția actuală este suficientă, construirea unui produs poate să nu fie justificată. Păstrează criterii de oprire. Nu adăuga funcții pentru a evita discuția despre utilitatea fluxului principal.

Exercițiu de consolidare

Scrie o ipoteză falsificabilă și ce observație ar determina amânarea proiectului.

Aplicație practică

Sarcina

Descrie problema unui SaaS înainte de lista de funcții.

Rezolvare orientativă și verificare

Pentru suport clienți: cine pune întrebări repetitive, ce surse există și când trebuie intervenție umană.

Greșeală de evitat

O integrare AI nu este singură o problemă de business rezolvată.