Når kunden ikke vil ha det du lager - Hva da?

Hva gjør man når produktet man har brukt måneder på å utvikle, viser seg å ikke være etterspurt i markedet? Dette er en situasjon mange har stått overfor, og det er en krevende utfordring.Rune Meierfra Sonat deler en historie fra et prosjekt der målet var å utvikle en bestillingsløsning for større bedrifter. Løsningen skulle effektivisere innkjøpsprosesser, integreres med ERP- og HR-systemer, og sikre kostnadsbesparelser gjennom optimal utnyttelse av innkjøpsavtaler. Alt virket lovende både for teamet og oppdragsgiveren, men til tross for alt arbeidet, uteble interessen fra kundene. Hva gikk galt, og hvordan kunne dette vært unngått?

"Jeg har feilet stort i softwareprosjekter. For noen år siden fikk teamet mitt i oppdrag å bygge en løsning for bestillinger. Dette var en fin og effektiv løsning på web og mobil som skulle effektivisere bestillingsrutinene for større bedrifter og sørge for å utnytte innkjøpsavtalene til kunden maksimalt for å redusere kostnader.

I tillegg skulle løsningen integreres mot ERP-løsningene for å effektivisere fakturahåndteringen og mot HR-systemene for å sikre at riktig brukere hadde riktige tilganger i løsningen. Både oppdragsgiver (som hadde ideen), teamet og jeg selv syntes dette låt som en god løsning, og vi så helt klart at dette ville kunne gi gode effekter i prosessene og ville spare kundene for mye jobb og penger.

Teamet startet arbeidet med å kartlegge hva som måtte gjøres, og vi så fort at det var nødvendig å tilpasse løsningen til tekniske rammeverk og infrastruktur for å sikre samspill med øvrige systemer, sikre at løsningen kunne kommunisere med ERP og HR og sikre gode deployeringsprosesser. I tillegg var sikkerhet i løsningen viktig, og vi måtte selvsagt ha støtte for flere språk. I alt var det veldig mange hensyn som måtte tas, og arkitekturen måtte bygges slik at dette ble hensyntatt.

De første sprintene startet vi å bygge grunnarkitektur, startet arbeidet med integrasjoner og vi hadde god fremdrift. For å teste flyten bygget vi et brukergrensesnitt på web, og så at transaksjonene gikk gjennom og vi gjorde nødvendige forbedringer i kode og deployeringsscript slik at alt rullet og gikk. Vi fulgte også det oppsatte programmet for sikkerhetssjekker, for rapportering av avvik, nedetider og annet som var foreskrevet og etter en stund hadde vi en løsning som vi var ganske så fornøyde med og så tenkte vi at vi burde fortelle kundene om hva vi hadde gjort.

Vi testet med brukere og potensielle kunder, og gjorde geriljatesting med tilfeldige mennesker, for å få innspill på hva de tenkte om det vi hadde laget, eventuelle forbedringspunkter og funksjonalitet de mente burde være i løsningen. Vi fikk mange gode innspill, og løste disse på en god måte. Våre UX-ressurser sørget for at brukergrensesnittet var konsistent og at brukeropplevelsen var effektiv og god. Vi la til funksjonalitet og bygde videre på rammeverket slik at vi fikk bedre integrasjon med leverandører og betalingsløsninger.

Etter hvert nærmet vi oss tidspunktet for å lansere produktet vårt, og vi snakket med både kunder og mulige forhandlere. Responsen uteble. Hva var det som skjedde? Etter lang utviklingstid og mye arbeid, var det tilnærmet dødt, og vi fikk ikke noen kunder. Hva kunne vi gjøre for å komme videre? Alle i teamet syntes vi hadde laget et flott produkt, og vi kunne ikke forstå hvorfor det ikke ble en suksess. Til slutt besluttet vi å legge ned produktet. Samme dag som vi fikk vår første betalende kunde. Å kaste gode penger etter dårlige, var ikke finansieringskilden vår interessert i. Teamet ble oppløst, og alt vi satt igjen med var noen erfaringer fra jobben vi hadde gjort.

Hva kunne vi gjort annerledes?

Historien over er ikke unik, jeg kjenner mange som har vært i samme situasjon, eller som har gjort noe lignende. Noen ganger har man fått mer penger, og greid å gjennomføre allikevel, andre ganger har pengebruken til slutt blitt så stor at man har sløst bort enda mer før resultatet likevel blir at prosjektet avsluttes - bare med en høyere prislapp.

I dette tilfellet er det mye som tyder på at oppdragsgiver ikke hadde sjekket ut behovet for løsningen i markedet før utviklingen ble satt i gang, og at de vi testet med, ikke nødvendigvis vurderte om dette var noe de på et senere tidspunkt ville være villige til, eller i posisjon til, å kjøpe.

Hver problemstilling er unik. Min erfaring med Design sprinter og Design Thinking-prosesser er ofte ganske like uavhengig om du skal utvikle en ny strategi for et produktområde - eller du skal designe en brukervennlig app utleie i boligbransjen. Et Design Thinking-rammeverk består av en rekke aktiviteter gjennom tre faser: Innsikt, strategi og design.

Etter en innledende runde hvor vi sammen med kunden sparrer rundt problemstillingen, setter vi sammen en skreddersydd Design Sprint. Her legger vi opp aktiviteter som løser behovet så smidig som mulig. Slik kan vi lage en prosess som gir konkrete resultater og bygger kompetanse for kunden og sikrer at alle relevante hensyn tas før man beslutter å gå videre med et langt og dyrt utviklingsløp. En bedre innsiktsavdekking ville kanskje lært oss at det ikke var kunder til dette produktet.

Som mine kolleger i These Ways sier det; “Slik sikrer vi at du ender opp med en løsning som ikke bare KAN brukes, men som de ansatte eller dine kunder vil ELSKE å bruke”."

Historien til Rune viser hvor avgjørende det er å teste og validere idéer tidlig i prosessen for å unngå å bygge noe ingen vil bruke. Selv om teamet la ned mye arbeid og utviklet en teknisk solid løsning, manglet det en grundig markedskartlegging. Dette er en verdifull påminnelse om at selv de beste idéer kan feile hvis de ikke er forankret i virkeligheten – og at noen ganger er det like viktig å stoppe i tide som å fortsette.