Hvordan kan man teste en teknisk løsning uten å bygge hele koden først?

Slik løser du det

Bruk en «Wizard of Oz»-tilnærming: Hent data manuelt og legg dem inn i systemet for å simulere funksjonaliteten. Dette lar deg teste brukeropplevelsen raskt og billig før du investerer i utvikling. La oss forklare grundig hva dette innebærer. «Wizard of Oz»-metoden har navnet sitt fra filmen der den mektige trollmannen egentlig bare er en vanlig mann som trekker i spaker bak et forheng. Overført til produktutvikling betyr det at brukeren tror de samhandler med et ferdig, automatisert system, mens det i virkeligheten er et menneske (du) som utfører jobben manuelt i kulissene. Hvorfor er dette så smart? Å bygge ekte programvare, særlig avansert funksjonalitet som automatisering, maskinlæring eller integrasjoner, er dyrt og tidkrevende. Hvis du bygger alt før du vet om kundene faktisk vil ha det, risikerer du å sløse bort måneder på noe ingen bruker. Wizard of Oz lar deg teste selve brukeropplevelsen og verdiforslaget først, med minimal innsats. Dette henger tett sammen med Lean Startup-tankegangen og begrepet MVP (Minimum Viable Product), altså den enklest mulige versjonen som lar deg lære av ekte brukere. Konkret eksempel: si at du vil lage en app som automatisk anbefaler treningsprogrammer. I stedet for å programmere algoritmen, lager du en enkel skjema- eller chatløsning der brukeren legger inn ønskene sine, og så sitter du selv og lager anbefalingen manuelt og sender den tilbake. For brukeren ser det ut som magi; for deg er det en billig test. Steg for steg: definer hva du vil lære, lag et enkelt grensesnitt (kan være et skjema, en e-post eller en melding), utfør «automatikken» manuelt, observer hvordan brukerne reagerer, og mål om de faktisk får verdi. Vanlige fallgruver: ikke prøv å skalere en manuell løsning til mange brukere (det blir for slitsomt), og vær ærlig med deg selv om resultatene. Når testen bekrefter at folk vil ha løsningen, da er det riktig tidspunkt å investere i ekte utvikling.