Hva er budskapet med denne artikkelen? La oss starte med en påstand: Valg av teknologi er det minst viktige når du skal utvikle et nytt digitalt produkt eller tjeneste. Veien til et nytt produkt eller tjeneste krever en kombinasjon av strategisk, kommersiell og så teknisk tilnærming.
Bakgrunn
Som privatpersoner må vi forholde oss til en verden der stadig flere tjenester og funksjoner blir digitale, trådløse eller innebygget. Å ringe kontofonen, slå opp i en telefonkatalog eller høre lyden av ISDN-modemet som koblet seg opp, virker å være fra en fjern fortid. De alle fleste løsninger bidrar til å gjøre hverdagen enklere, og gir muligheter som de fleste generasjoner før oss bare kunne drømme om.
Så er det i større og større grad at vi tar med oss disse forventningene, og etter hvert kravene, når vi er på jobb, enten vi er en leverandør eller en kunde. Der det tidligere var nok å levere selve produktet eller tjenesten, øker kravene til det som leveres. «Vi burde ha en portal hvor kundene selv kan sjekke status», «Det burde være mulig å laste ned oppdateringer automatisk», «Det burde komme varsel når man nærmer seg grenseverdier», «Det er så tungvint at informasjonen ligger i ulike system».
En enkel konklusjon å trekke er: «Vi må bare utvikle en digital løsning eller tjeneste – en app – et program – en løsning – en portal – og så kan vi ta mer betalt av kunden. Man lager et fint business case i Excel som viser estimert investering for å få løsningen opp å stå, hvor mange kunder man har og hvor mye kunden er villig til å betale for denne ekstra funksjonaliteten, og vips har man en forventet årlig, gjentagende inntekt som absolutt forsvarer investeringen.
Det fort gjort å kjøre i gang prosjektet, starte programmeringen, ha et stort (og selvsagt viktig og nødvendig fokus på teknologien) og så har man endelig en første versjon av en digital løsning. Løsningen introduseres stolt til mulige kunder.
Men responsen, og bekreftelsene lar vente på seg. Noen kunder uttrykker at det er en god løsning, og de vil gjerne bruke den, men ikke betale ekstra for den. Andre kunder sier at mye er bra, og at hvis bare følgende funksjonalitet var inkludert, ville de kjøpt den med en gang. Det opprinnelige budsjettet dekket utviklingen, og videreutvikling skulle først komme når det var mange nok kunder.
Hva skal vi nå gjøre med løsningen?
Vi i Incrementi har god kunnskap, både faglig men ikke minst gjennom egne erfaringer om hvor det er lett å trå feil, og hva vi burde ha tenkt på. Vi har delt dette inn i tre trinn som er beskrevet under:
Under vil vi vise hvordan de tre elementene – strategi, kommersielt og teknisk – må ivaretas i alle tre ledd.
Trinn 1: Hvordan en MVP blir til
Dette høres ut som en klisje, men det aller viktigste er å starte med det berømte «Hvorfor». Det er ganske enkelt å ha ideer til løsninger som i utgangspunktet både kan være smarte og gode.
Men før man går videre bør man stille disse spørsmålene:
- Løser produktet eller tjenesten et problem for kunden?
- Hvis ja, hva er kunden villig til å betale for det?
- Og ikke minst, hvordan skal man lage en løsning som kunden enkelt kan ta i bruk?
Disse spørsmålene må stilles internt, men selvsagt også til potensielle kunder. Svarene vil gi en god indikasjon på markedet, og danne grunnlag for om det er hensiktsmessig å fortsette. Videre vil svarene danne grunnlag for å utarbeide brukerkrav og user stories. Markedsdimensjonen og kundens røst er hørt. Og her, akkurat her, er det kritisk å ta med det strategiske perspektivet gjennom en god business case.
Jeg skal ikke gå inn på alle elementer som skal med i en business case, men det som er utrolig viktig å ta med seg er at en digital løsning har et svært mye lengre perspektiv enn det tekniske utviklingsprosjektet. For at en digital løsning skal bli vellykket krever det en livsløpstankegang, og det løsningen må passe inn i strategien for hvor man skal være om fem år.
Det må legges en plan for versjoner, videreutvikling og skalering, og det innebærer selvsagt det tekniske, men likeså viktig er det hva dette vil kreve av investering og hvilke økonomiske konsekvenser det vil ha.
Er alt dette på plass og håndtert, da kan man gå videre til å etablere en prosjektorganisasjon for utvikling av løsningen. Foreløpig er mye av arbeidet internt, og et godt underlag gir en oversiktlig prosjektplan. Det kommer få input og krav fra eksterne, og det er mulig med få endringer og justeringer av planen. For å relatere det til DevOps: Det er høy grad av Dev, og liten grav av Ops.
Trinn 2: Hvordan gå fra MVP til Produkt
MVP’en er etablert og lykken er stor når de første pilotkundene sier Ja og signerer. Endelig skal mange ukers og måneders jobb betale seg, og de som har jobbet i prosjektet gleder seg til å høre de positive tilbakemeldingene fra kundene på hvordan den digitale løsningen gjør hverdagen enklere. Prosjektet har en ganske lang backlog av ønsker og viktig funksjonalitet som har blitt oppdaget gjennom utviklingen, men det er planen å begynne på det nå.
Som ventet er det noen mindre utfordringer ved installasjon hos pilot-kundene, dokumentasjonen må virkelig forbedres og så begynner det å komme spørsmål fra kunden.
Hvorfor er det slik, dette var ikke logisk, hva er tenkt her og ikke minst: Her mangler det noe. Tilbakemeldingene fra kundene er kanskje ikke helt som ønsket eller forventet…..Salg jobber videre og de får inn flere potensielle kunder.
Disse potensielle kundene har dette til felles: De synes løsningen ser veldig bra ut, og de vil gjerne prøve den ut, men det er et men: Da må denne og denne funksjonaliteten på plass. Det er helt avgjørende for at kunden skal ta løsningen i bruk.
Og da er man godt i gang med fasen: Fra MVP til Produkt. Utviklingsprosjektet har ferdigstilt MVP’en, og nå er det viktig at organiseringen tar inn over seg at det både er Dev og Ops. Pilotkundene må føle seg ivaretatt og der flere kunder har samme behov til funksjonalitet må den prioriteres opp i backloggen. Det er ganske mye både Dev og Ops på en gang.
Det er avgjørende å finne en struktur som ivaretar en planlagt backlog og hastekrav fra kunden. Det krever en disiplinert prioritering. Dersom noe prioriteres opp, må noe annet prioriteres ned. Og kontekstsvitsjing må holdes på et minimum.
Trinn 3: Skalering
Antall kunder som bruker løsningen er godt over en håndfull. Løsningen inngår i flere kunders daglige drift og det er flere som har signert SLA’er. Det som tidligere var å «forsøke så godt man kan», har nå gått over til formelle krav til driften som må etterleves og planlegges.
Produksjonssetting av nye versjoner må planlegges og kommuniseres, og ikke minst må API’ene være bakoverkompatible. Kravene fra kundene øker og det er fort gjort at backloggen føles uendelig. Noen kunder begynner å bli veldig utålmodige og det er en vanskelig balansere mellom å tilfredsstille eksisterende kunder og krav fra mulig kunder som trenger diverse funksjonalitet for å ta i bruk løsningen.
Det å lage en strukturert road map for versjoner og sørge for at innspill prioriteres og følges opp blir svært viktig!
Kundene trenger forutsigbarhet. Det kan være hensiktsmessig å etablere en enkel form for brukerforum hvor kunder kan ha interaksjon på tvers og utveksle erfaringer. Ikke minst bør den endelige versjonen av dokumentasjonen være «ship shape» og klar til å distribueres.
Hvis dette har fungert fint frem til nå, er det egentlig bare å fortsette reisen som gjør at dette blir et vellykket og bærekraftig produkt. De tre trinnene over og en balanse mellom fokus på strategi, marked og teknologi er som sagt avgjørende for at drømmen om et digitalt produkt eller tjeneste skal bli så enkel som mulig.
Vi i Incrementi har både kunnskapen og erfaringen som skal til for å lykkes og vi tar gjerne en prat for å høre deres erfaringer og utfordringer. Avtal et møte med oss
