Eureka! Jeg har funnet ut hva vi ikke skal bygge!
Vi bruker produktutforsking til å finne ut hva vi skal lage, men altfor sjelden til å finne ut hva vi ikke skal lage.
I mange organisasjoner forstås produktutforsking (product discovery) omtrent sånn:
«Det vi gjør for å utforske, validere og scope det vi har tenkt til å levere».
Det gjennomføres som en slags avart av konseptutvikling, hvor formålet er å gi en ny idé en mer håndfast form og noen rammer. Det ligger en forventning, noen ganger uttalt, men oftest under overflaten, om at det vi utforsker på et tidspunkt skal lages. Selv om vi alle egentlig kjenner premisset ganske godt: det er i utforskingen vi finner ut om vi skal lage noe, eller ikke.
Uten en felles forståelse av dette, er det fort gjort å snuble i bekreftelsesfella: Vi undersøker akkurat nok til å kunne rettferdiggjøre videre bygging, ikke til å finne ut om vi bør bygge.

Derfor er «ikke bygge» så vanskelig
Det kan være vondt å lande på «ikke». Det kan være sterke følelser eller prestisje knyttet til ideen. Kanskje noen har satt forventningen internt om at dette kommer snart? Skal vi virkelig sette av uker til å utforske og lage noe vi potensielt bare skal kaste? Det er mange grunner til å gå inn i utforsking med mål om å bekrefte at ideen bør lages.
Psykologi gjør dette enda vanskeligere. Mennesker opplever tap omtrent dobbelt så sterkt som gevinster. Tapsaversjon er bygget inn i hvordan vi tar beslutninger. Måles teamet på hva man får shippet, blir det å stoppe etter utforsking å anse som et rent tap. Samtidig blir det å lage noe, selv om det ikke leverer effekt, en gevinst.
I en organisasjon forsterkes dette enda mer. Når team måles på output, gjør man «tap» av features smertefullt, mens å bygge feil ting fortsatt teller som progresjon.
Verdien av å stoppe
Det krever modenhet å verdsette eksperimentering som ikke materialiserer seg i bygging. Verdien er nemlig litt abstrakt. I all enkelhet handler det om to ting:
Den direkte kostnaden du slipper. Hver feature du bygger, koster noe: utvikling, testing, drift, support, vedlikehold og teknisk gjeld. Pluss den økte kompleksiteten i kodebasen, som gir større kognitiv last når teamet skal lage nye ting.
Alternativkostnaden du unngår. Den viktigste, men ofte usynlige: de andre ideene som må vente eller skrotes. Et produktteam vil alltid ha flere ideer på blokka enn de har kapasitet til å lage. Det er sånn det skal være. Når vi sier ja til én ting, sier vi samtidig nei til en haug med andre muligheter. Hver time brukt på én idé er en time som ikke kan investeres i noe annet, med potensielt høyere effekt.
Start med en psykologisk kontrakt
Dette ser relativt enkelt ut i lærebøkene: man henter innsikt, lager en MVP, setter kriterier, tester og vurderer om hypotesene holder vann. Og de fleste du har rundt deg, har lest de samme lærebøkene. Dere er teoretisk enige. Men det er organisasjonskultur, modenhet og psykologi som gjør ting vanskelig for dere.
Derfor trenger du en enkel psykologisk kontrakt med interessentene i og rundt teamet. Still spørsmålet:
«Dersom vi skal utforske denne ideen, aksepterer alle her begge konklusjonene vi kan lande på?».
Svarer noen nei, er det et tegn på at risikoen ligger i beslutningskulturen, og ikke i ideen. Da er det der jobben starter.