"Hvis du ikke er flau over den første versjonen av produktet ditt, har du lansert for sent." – Reid Hoffman Hos Splits følger vi denne tilnærmingen til å bygge programvare: få det til å fungere → gjør det riktig → gjør det raskt. Rekkefølgen betyr noe. Her er hva vi har lært når vi sender hver fase:

Få det til å fungere = funksjonell prototype. Det skal være grovt. Det skal være janky. Få det raskt frem for brukerne. Hvordan vi vurderer MVP: 1) List opp alt vi mener kan være viktig eller relevant for prosjektet. 2) Hva er det *absolutte minimum* fra denne listen som vi kan fullføre og ha en funksjonell prototype?

Gjør det riktig = fiks alle ødelagte biter. Gå inn i denne fasen med klare signaler fra markedet: konsistente tilbakemeldinger, økende bruk til tross for åpenbare feil. Nå har du fortjent retten til å investere mer ressurser.

Gjør det raskt = optimaliser ytelsen. Ærlig talt, vi lærer fortsatt om denne fasen. Det meste av Teams er for øyeblikket i «gjør det riktig»-modus 🤷 ♂️ Men her er inspirasjonen som driver oss:

Hvorfor denne tilnærmingen fungerer: Sekvensering er strategi. Det du lærer i dag, former det du bygger i morgen. Hopp videre, og du har ikke informasjonen som trengs for å løse problemer riktig. Handling produserer informasjon. Men *tilsiktet* handling produserer *mer nyttig* informasjon.

Fellen prøver å gjøre det riktig samtidig som du får det til å fungere. NOPE. "Gi deg selv tillatelse til å sende noe du vet ikke stemmer." – @wminshew