Een nieuw product bouwen

Het product dat een spreadsheet bleef.

De meeste oprichters en productmanagers hebben er een: een idee dat in een spreadsheet is getest, door een leverancier is geprijsd en in de la belandde omdat de eerste versie te duur was om het risico te nemen. Die prijs is bepaald vóór AI. Het loont om hem opnieuw te bekijken.

De eerste versie is de versie die goedkoop werd. Het is ook de versie die ertoe doet.

Een nieuw product sneuvelt op één vraag: gaat iemand het gebruiken? De eerlijke manier om dat te weten is een eerste versie bij echte gebruikers. Twintig jaar lang was juist die eerste versie het dure deel: een team, een kwartaal, een budgetregel die iemand moest verdedigen voordat er bewijs was. Dus bleven de meeste ideeën ideeën.

Dat deel heeft AI veranderd. Het grondwerk, de formulieren, de tests: de kosten van een eerste versie zijn ver genoeg gedaald om de vraag vóór de budgetvergadering te beantwoorden in plaats van erna. Wat niet veranderde: weten wat je bouwt, weten wanneer je stopt, en zo bouwen dat versie twee geen nieuwe start is. Daar zijn we voor.

02 · Wie is eigenaar

Drie manieren om je product met ons te bouwen.

Welk model past, hangt vooral af van één vraag: wie moet over vijf jaar eigenaar zijn van het product? Dat kun je zelf zijn, we kunnen het samen als partners bouwen, of we bouwen het voor de mensen die het gaan gebruiken, zoals we met Yessa doen. In het eerste gesprek zeggen we welk model volgens ons het best bij je idee past.

Model 1 · Jij bezit het

De klassieke route, met een vaste eerste stap.

Een Factory Sprint maakt in vijf dagen een vaste offerte van het idee. Zes weken later draait een veilige MVP op Entry, met de kwaliteitscontroles die jij hebt goedgekeurd. Daarna beslis je, met werkende software in de hand, of je doorgaat. De code is vanaf de eerste commit van jou.

Model 2 · Wij investeren mee

Partners, met gedeelde opbrengst.

Wij leggen engineering in, jij de markt, en de opbrengst delen we. Dit is het model van KlasMastr. Het werkt alleen als beide kanten iets verliezen als het mislukt, dus we kiezen deze partnerschappen zorgvuldig. Doe jij dat ook.

Model 3 · De gebruikers bezitten het

Gebouwd voor een sector, overgedragen aan de sector.

Yessa wordt zo gebouwd dat de dierenartsen die het gebruiken het als coöperatie kunnen bezitten. Het model waar we het trotst op zijn, omdat de software daarmee verantwoording aflegt aan de mensen voor wie hij bestaat.

Het eerste gesprek over de IT-kant van een idee komt vóór het papierwerk. Er hoeft geen formulier aan vooraf.

03 · De eerste versie

De MVP: begin met een skateboard.

Het kleinste ding dat rolt: een heel skateboard, niet één perfect wiel. Een MVP is geen proof of concept. Met een MVP ga je echt de markt op: een minimaal werkend product dat genoeg is voor je gebruikers en nog lang niet je einddoel.

PREVENTVoorkom verspilling. Bouw wat de vraag beantwoordt. De extra’s komen later wel.
DECIDEBeslis zo laat mogelijk. Snelheid laat je de keuzes uitstellen waar je het minst zeker van bent.
DELIVERLever zo snel mogelijk op. Feedback van een gewone dinsdag wint het altijd van een workshop.
LEARNVergroot het leereffect. Elke iteratie moet veranderen wat je gelooft, anders was het verspilling.
04 · Wat we eerst vragen

Onze vier vragen.

We vragen
  • Wie betaalt het in jaar twee, als het lanceringsbudget op is?
  • Wat doet de eerste versie met opzet niet?
  • Wie gebruikt het op een gewone dinsdag, en wat gebruikten ze daarvóór?
  • Wat gebeurt er als het werkt? Wie moet dan ja zeggen?
Wat kan wachten
  • Het businessplan. Eén pagina is genoeg om te beginnen.
  • Je budget. Eerst kijkt een engineer naar het idee, het budget komt later.
  • Een toezegging. Het eerste gesprek komt vóór het papierwerk.
Het eerste gesprek

Kom met je idee. Eén pagina is genoeg.

Eén pagina, of helemaal geen. Je krijgt de eerlijke kijk van een engineer op de IT-kant, vrijblijvend.

Van idee tot product, sinds 2006