Wat je SaaS-MVP wel — en niet — zou moeten bevatten bij de lancering

Het woord "minimum" in minimum viable product is het deel dat iedereen negeert. Oprichters knikken instemmend bij het idee om klein te beginnen, en overhandigen dan een specificatie met veertig schermen, drie gebruikersrollen, een facturatiemotor, een analytics-dashboard en "oh, en het moet met alles integreren." Dat is geen MVP. Dat is een volledig product met het optimisme op het maximum. En het is de allergewoonste reden waarom eerste lanceringen te laat en over budget aankomen, en op de een of andere manier nog steeds dat ene ding missen dat klanten echt wilden.

Ik heb een flink aantal kleine bedrijven en solo-oprichters geholpen hun eerste softwareproduct de deur uit te krijgen. Het technische deel is zelden waar mensen over struikelen. Het moeilijke deel — elke keer weer — is beslissen wat je nog niet moet bouwen. Een MVP is geen kleinere versie van uw droomproduct met functies die willekeurig zijn weggeschuurd. Het is een bewuste gok: het kleinste dat u aan echte gebruikers kunt voorleggen dat bewijst dat het kernidee meer van uw geld en tijd waard is.

Dit is dus de gids die ik wou dat meer oprichters lazen voordat ze hun specificatie schreven. Geen jargon, geen "move fast and break things"-theater. Gewoon een praktische manier om de grens te trekken tussen wat in uw eerste release thuishoort en wat kan — en zou moeten — wachten.

Wat een MVP eigenlijk is (en wat niet)

Laten we de definitie helder krijgen, want de meeste verwarring begint hier. Een MVP is de kleinste, eenvoudigste versie van uw product waarmee een echt persoon dat ene waardevolle ding kan doen dat uw product belooft — en waarmee u kunt leren of ze terugkomen om het opnieuw te doen. Dat is het. Het is een leerinstrument dat toevallig gemaakt is van werkende software, geen uitgeklede lancering van het afgewerkte product.

Het cruciale woord is viable. Een veelgemaakte fout is om "minimum" te lezen en iets zo kaal uit te brengen dat het de gebruiker in verlegenheid brengt — een halve flow die crasht, een aanmelding die naar een leeg scherm leidt. Dat is niet minimum-viable, dat is minimum-kapot. De andere mislukking is het tegenovergestelde: een product zo "compleet" dat het een jaar kostte om te bouwen, tegen welke tijd u uw runway hebt opgebrand om een gok te bewijzen die u in acht weken had kunnen testen.

Dit is de mentale test die ik gebruik. Vraag voor elke functie op de lijst: als we deze zouden verwijderen, zou een gebruiker dan nog steeds het ene kernresultaat kunnen behalen waarvoor het product bestaat? Als het antwoord ja is, is het vrijwel zeker geen MVP. Die vraag alleen al snijdt de meeste specificaties doormidden — en de helft die wegvalt, is de helft die u te laat ging maken.

Vind de ene taak die uw product doet

Voordat u kunt beslissen wat u gaat bouwen, moet u keihard helder zijn over de ene taak die uw product voor iemand doet. Niet de visie. Niet de roadmap. De ene herhaalbare actie die, als ze werkt, iemands dag beter maakt en hem bereid maakt te betalen. De meeste worstelende specificaties zijn juist hier vaag — ze beschrijven een platform, geen taak.

Probeer deze zin hardop af te maken: "Een gebruiker komt naar mijn product om ______, en vertrekt nadat hij ______." Een planningstool: een manager komt om het rooster van volgende week te publiceren, en vertrekt met elke shift ingevuld en het team op de hoogte. Een facturatie-app: een zzp'er komt om een klant te factureren, en vertrekt met een verzonden, traceerbare factuur. Als u die zin niet schoon kunt invullen, bent u nog niet klaar om af te bakenen — u bent nog klaar om na te denken.

Wat elke SaaS-MVP echt nodig heeft

Sommige dingen zijn niet onderhandelbaar, zelfs in de meest sobere eerste versie — niet omdat ze spannend zijn, maar omdat het product zonder hen ofwel niet gebruikt kan worden ofwel u niets kan leren. Beschouw deze als de vloer, niet het plafond. Bouw ze eenvoudig, maar bouw ze goed.

• Een manier om in te loggen. Zelfs één login met e-mail en wachtwoord is prima — maar een echte, veilige, want al het andere hangt af van weten wie de gebruiker is.
• De kernworkflow, van begin tot eind. De ene taak, van de eerste klik van de gebruiker tot het moment dat hij het waardevolle resultaat krijgt — geen doodlopende wegen, geen "binnenkort"-knoppen in het kritieke pad.
• Ergens waar de data daadwerkelijk leeft. Echte opslag, geen wegwerp-prototype, zodat het werk van een gebruiker een verversing overleeft en hij morgen kan terugkomen.
• Een manier voor u om te zien wat er gebeurt. Basale logging of een eenvoudige adminweergave, zodat u, wanneer iets kapotgaat — en dat gebeurt — kunt achterhalen waarom, zonder te gokken.
• Een manier voor gebruikers om u te bereiken. Zelfs maar een e-maillink. Vroege gebruikers stuiten op randen die u niet voorzag; u wilt dat ze het u vertellen, niet dat ze stilletjes vertrekken.
• Het absolute minimum aan vertrouwen: een privacyverklaring, verstandige omgang met data, en niets roekeloos doen met de informatie van mensen.

Merk op wat er niet op die lijst staat: facturatie, fraaie onboarding, instellingenpagina's, mobiele apps, integraties. We komen zo bij het waarom. Het punt van de vloer is dat ze klein genoeg is om af te maken en solide genoeg om van te leren. Een login die werkt, één workflow die levert, echte data, en een manier om gebruikers te observeren en met hen te praten. Dat is een viable product.

Wat u bewust uit v1 laat

Dit is de sectie waar oprichters zich tegen verzetten, dus laat me bot zijn: de meeste dingen die essentieel aanvoelen voor uw eerste lancering zijn dat niet. Ze voelen essentieel omdat een "echt product" ze heeft — maar u bouwt nog geen echt product, u bouwt een vraag. Deze weglaten is geen bocht afsnijden. Het is de hele discipline van een MVP.

Geautomatiseerde facturatie en complexe prijsstelling

U heeft vrijwel zeker geen selfservice-facturatiemotor, gelaagde plannen, proratie en aanmaninglogica nodig in versie één. Als vroege gebruikers willen betalen, kunt u hun geld handmatig aannemen — een factuur, een betaallink, een kort telefoontje. Handmatige facturatie voor uw eerste tien klanten vertelt u iets dat geautomatiseerde facturatie niet kan: of er überhaupt iemand zal betalen. Bouw de machine pas wanneer u hebt bewezen dat er geld te innen valt.

Uitgebreide rollen en rechten

Multi-rol-rechtensystemen — admins, managers, kijkers, gedetailleerde toegangsregels — zijn een heus engineering-moeras, en ze vermenigvuldigen het testoppervlak enorm. Voor een eerste release is één soort gebruiker vrijwel altijd genoeg. U leert de echte rechtenbehoeften door echte teams het ding te zien gebruiken, en die behoeften zijn zelden wat u op papier geraden zou hebben.

Integraties, native mobiele apps en het dashboard

"Het moet met alles integreren" is de zin die stilletjes tijdlijnen verdubbelt. Kies hooguit één integratie, en alleen als die deel uitmaakt van de kerntaak. Native iOS- en Android-apps kunnen vrijwel altijd wachten — een responsieve webapp werkt vandaag op een telefoon. En dat analytics-dashboard dat iedereen wil? Gebruikers kunnen geen data analyseren die ze nog niet hebben aangemaakt. Breng eerst het ding uit dat de data aanmaakt; visualiseer ze zodra er iets te tonen is.

Een eenvoudige methode om de grens te trekken

Het principe kennen is één ding; het toepassen op uw eigen specificatie, waar elke functie als uw oogappel voelt, is moeilijker. Hier is een methode die werkt omdat ze een beslissing per item afdwingt in plaats van alles te laten wegglijden in "essentieel."

1. 1
   Som elke functie op die u heeft bedacht

   Gooi het er allemaal uit — nog niet filteren. Krijg de volledige verlanglijst op tafel zodat niets ongezegd op de loer ligt en halverwege de bouw als een verrassing weer opduikt.
2. 2
   Markeer elk tegen de kerntaak

   Vraag voor elke functie: heeft een gebruiker dit nodig om de ene kerntaak van begin tot eind te voltooien? Markeer het 'kern', 'nuttig' of 'ooit'. Wees eerlijk — de meeste landen in de laatste twee.
3. 3
   Houd alleen 'kern' voor v1

   Uw MVP is de 'kern'-stapel en niets anders. De stapels 'nuttig' en 'ooit' worden niet afgewezen — ze zijn uw roadmap, geparkeerd waar ze thuishoren.
4. 4
   Toets de snede op gezond verstand

   Kijk naar wat overblijft en vraag: kan een echte gebruiker hier echte waarde uit halen met alleen dit? Zo ja, dan heeft u een MVP afgebakend. Als iets de kernflow daadwerkelijk breekt, haal dan precies dat ene item terug — en niets anders.

De discipline zit in stap vier. Er is altijd de verleiding om "gewoon nog één ding terug te halen", en dan nog één, totdat u stilletjes het volledige product opnieuw hebt opgebouwd. Sta uzelf alleen toe items te redden die de kernflow daadwerkelijk breken — niet items die het slechts mooier zouden maken. Mooier is waar versie twee voor is.

Viable betekent nog steeds dat het echt moet aanvoelen

Er is een faalmodus aan de andere kant van de grens, en die is het benoemen waard. In de haast om klein uit te brengen, brengen sommige oprichters iets sjofels uit — en noemen het MVP. Een kernflow die uw werk verliest, een aanmelding die een 404 geeft, teksten vol placeholder-tekst. Dat test uw idee niet eerlijk; het test of gebruikers een kapotte ervaring tolereren, en het antwoord is altijd nee. U zult concluderen dat het idee faalde terwijl in werkelijkheid de uitvoering faalde.

"Minimum" geldt voor scope, nooit voor de kwaliteit van het deel dat u behoudt. Minder functies, elk solide. De ene workflow die u uitbrengt zou afgewerkt moeten aanvoelen — snel, helder en betrouwbaar — zelfs als het het enige is dat het product doet. Een smal product goed gedaan verslaat een breed product slecht gedaan elke keer, vooral wanneer u vreemden vraagt u hun werk toe te vertrouwen.

De MVP is niet de finish — het is de eerste meting

Hier is het deel dat alles herkadert: de lancering is niet het doel. Het doel is wat u leert in de weken erna. Een MVP die uitkomt en u vertelt "gebruikers houden van de kern maar blijven om X vragen" is een daverend succes — zelfs als X een maand extra werk betekent. Een MVP die in stilte uitkomt, waarbij niemand terugkomt, heeft ook zijn werk gedaan: het bespaarde u de andere dertig functies op een fundament te bouwen dat niemand wilde.

Plan dus de eerste weken even bewust als de bouw. Kijk naar wat mensen daadwerkelijk doen, niet wat ze in enquêtes zeggen. Praat met degenen die terugkwamen en degenen die dat niet deden. Laat het echte gebruik — niet uw oorspronkelijke specificatie — beslissen wat in versie twee komt. De roadmap die u eerder parkeerde, is geen belofte; het is een hypothese, en uw gebruikers staan op het punt die te beoordelen.

Veelgestelde vragen