HR Tech, Pento Stories

Sådan bygger vi et nyt lønsystem fra bunden

De fleste, på vores team hos Pento, har de seneste år været med til at bygge en masse forskellige apps, websites og andre digitale produkter. Både ting, der er gået hen og blevet en succes, og stadig bliver brugt af mange mennesker i dag, men også ting som aldrig blev til noget. Begge udfald lærer man rigtig meget af, og det er nogle af de erfaringer og værdier vi nu bygger Pento ud fra.

I denne post vil jeg forsøge at fortælle lidt om den strategi vi kører vores produktudvikling ud fra, og hvilke faktorer der spiller ind når vi prioriterer at bygge én feature frem for en anden.

Vores produktstrategi

Grundlæggende, så er der to måder at bygge produkter på. Enten, så sætter du dig ned og beskriver *alt* hvad produktet skal kunne, før du går i gang, eller også bygger du produktet step-by-step, og bestemmer hen ad vejen, hvordan features skal prioriteres og se ud.

Det kommer måske ikke som nogen overraskelse, at vi har valgt den sidste tilgang. Vi kunne have lukket os selv nede i en kælder i 2 år, og være kommet ud med et langt mere komplet produkt end vi har i dag, men det ville have været det forkerte produkt. Et lønsystem er et tungt produkt, og der er rigtig mange ting det skal kunne, for at kunne servicere alle virksomheder i Danmark. Derfor er det fristende at sætte sig ned, lave en liste over alle de ting et lønsystem skal kunne, og så bare gå i gang fra en ende af:

  • Automatisk indberetning til SKAT og ATP
  • Ferie og feriepenge
  • Sygdom
  • Kørsel
  • Udlæg
  • Frokostordning
  • Pension
  • Afstemning
  • Timelønnede
  • Funktionærer
  • Overenskomster
  • … og meget mere

Så snart man har færdiggjort listen, og er færdig, ville man være klar til at sælge produktet – tror man i hvert fald.

Det farlige ved denne tilgang er, at du ender med at bestemme hvordan løsningen skal se ud. Du tror, du ved hvordan den bestemte feature skal bygges – fordi, hey, det er jo bare et helt almindeligt inputfelt. Det står der jo i beskrivelsen! Problemet er, at du i 8 ud af 10 tilfælde vil komme ud for, at din kunde ikke har den samme opfattelse af problemet, som du har. En bogholder, som har arbejdet med løn de sidste 10 år, har selvfølgelig en helt anden opfattelse af hvordan f.eks. feriedata bør gemmes og rapporteres, end du har. Der er dermed en stor risiko for, at du ender med at løse problemet på den forkerte måde, og har derfor ikke givet din kunde nogen værdi overhovedet. Det vender jeg tilbage til.

Netop for at undgå denne fejl, har vi helt fra starten inddraget så mange potentielle kunder som muligt. Vi ved, at det er vores kunder, der har den klart bedste opfattelse af, hvilke problemer vi bør løse. Ikke nødvendigvis *hvordan* de skal løses (det er vigtigt), men det kommer jeg tilbage til. Vores strategi bygger altså på, at vi hele tiden taler med vores kunder, identificerer problemer, kommer op med potentielle løsninger, og får feedback.

Feedback fra kunder

I starten var det nemt for os, at holde styr på feedback fra vores kunder, fordi vi ikke havde så mange. Den seneste tid har vi fået flere og flere virksomheder på Pento, og det har gjort, at vi hurtigt var nødsaget til at komme op med en ny måde at håndtere feedback. Vi fandt tit os selv i en situation, hvor vi havde talt med en kunde, og havde fået en masse god feedback, men ikke var gode nok til at få det registreret nogen steder. Det gjorde, at vi enten glemte det, eller også blev det noget vi nævnte til vores produktmøder: "Der var en kunde der synes det kunne være fedt, hvis...". Problemet var, at vi ikke havde noget data at sammenligne feedback på, så det blev altid et spørgsmål om mavefornemmelse. Det har vi ændret nu.

I dag bruger vi en simpel Google Form til at holde styr på feedback. Hver gang en kunde kommer med feedback (både den gode og den dårlige slags), registrerer vi det i et Google Sheet via vores Google Form:

Screenshot 2017-02-19 13.33.47

Ved at kategorisere feedbacken, kan vi nemmere komme frem til hvor efterspurgt en specifik feature eller ændring er. På den måde undgår vi, at gå efter vores mavefornemmelse, og laver ikke ændringer baseret på en enkelt brugers feedback (med mindre det er bugs og ting, der ikke virker). Ved at bruge Google Forms, kan vi arbejde med dataen i et Google Sheet bagefter, og kan i realtid hele tiden se hvad der bør have vores opmærksomhed:

Screenshot 2017-02-19 13.35.18

Som man kan se på ovenstående, så er det primært efterspørgsel på 1) nye features, 2) vores onboardingside "Kom godt i gang", samt 3) indstillinger for medarbejdere, som vi bør koncentrere os om. Den viden gør, at vi hele tiden arbejder i den rigtige retning, og at vi er sikre på at vi hele tiden optimerer og bruger vores udviklingstid på de rigtige problemer.

En anden ting, man ofte glemmer, er at informere sine (potentielle) kunder om nye features, hvis de førhen har efterspurgt dem. Det vigtige her er, at holde det superrelevant. Derfor bruger vi Intercom til at tagge vores kunder, når de efterspørger features. På den måde kan vi vende tilbage til dem, når vi har lavet det de har efterspurgt. Her er et udpluk af nogle af de ting, der er blevet efterspurgt indtil videre:

Både nuværende og potentielle kunder er i Intercom, så vi kan hele tiden holde styr på, hvor mange potentielle kunder vi kan servicere, hvis vi udvikler en given feature. Sammenholdt med vores Google Sheet, har vi hele tiden et rigtig godt overblik over hvad vores næste skridt bør være, og vi sikrer os, at vores kunder ved hvad vi laver. Vi har rigtig mange virksomheder på vores venteliste, som f.eks. kun venter på, at vi kan håndtere pension. Derfor er det perfekt for os, at vi kan henvende os direkte til dem, så snart det er muligt (vi arbejder på sagen!).

Vi forsøger altså hele tiden at basere vores prioriteringer ud fra data, og ikke mavefornemmelse. Vi taler rigtig meget med vores kunder, og gør en indsats for at omdanne deres tanker og efterspørgsel til noget, vi kan måle og sammenligne.

Prioritering af udviklingsressourcer

Når vi er kommet frem til en liste over features, ændringer eller andet, som vores (potentielle) kunder efterspørger, er det tid til at prioritere dem, så vi ved hvad vi skal gå i gang med først. Her er det ikke altid den feature, der har fået flest "stemmer", der bliver sat i gang først. Her er der flere ting der spiller ind. F.eks. er kompleksiteten vigtig for, om det er noget vi sætter i gang med det samme, eller om vi vil vente lidt. Det er et konstant dilemma, og derfor har vi forsøgt at sætte en ligning op for os selv. Den ser sådan ud:

Efterspørgsel x relevans x kompleksitet

Denne ligning hjælper os med at træffe en beslutning om hvordan vi skal prioritere ny udvikling. Der er tre ting vi kigger på. Efterspørgsel, som er der hvor vi bruger vores Google Sheet, til at finde ud af hvad vores kunder gerne vil have. Relevans, som er en opvejelse af hvor relevant den efterspurgt feature er, for det produkt vi har nu, samt hvor meget den potentielt ville blive brugt (hver dag eller hvert halve år?). Til sidst kigger vi på kompleksiteten. Hvis en feature tager 2 måneder at bygge, er det måske ikke smart at prioritere den foran andre vigtige ting, der kun tager en uge. Omvendt, kan det også være, at det netop er smart at få den lavet med det samme. Hvis en ny feature giver mening på alle tre parametre, er der stor chance for, at den vil ligge øverst på prioriteringslisten.

Kunden kender problemet, men ikke nødvendigvis løsningen

Som jeg har været inde på i denne post, så bruger vi vores kunder rigtig meget, når vi skal prioritere vores udvikling. Der er dog én fejl, som mange begår, når de taler med deres kunder: De spørger til løsningen, og ikke problemet. Du kender sikkert allerede Henry Ford citatet, som tit bliver brugt til at illustrere problemet: "If I had asked people what they wanted, they would have said faster horses". Sådan er det også med softwareudvikling. Især, når du bevæger dig ind i en branche, der består af spillere, som ikke har udviklet deres produkter betydeligt, de sidste mange år.

Derfor forsøger vi altid at spørge ind til problemet, og prøver så sammen med vores kunder at finde den rigtige løsning. Tit er kunden (selvfølgelig) meget påvirket af det produkt han/hun bruger i dag, og kan sommetider have svært ved at forestille sig, hvordan tingene kan fungere anderledes. Præcis, som det måtte have været, da der kun fandtes hestevogne.

For at komme med et eksempel, så skulle vi - rimelig tidligt i processen - finde en løsning til et problem, der vedrører nul-indberetninger. Det er nemlig sådan, at SKAT giver din virksomhed en bøde på 800 kr., hvis du en måned ikke skal have løn, og glemmer at fortælle SKAT om det. I de nuværende lønsystemer, er der mulighed for, at du manuelt kan gå ind og nul-indberette (hvis du altså ved hvor knappen sidder). Mange virksomheder (inklusiv os selv), har prøvet at få denne bøde, så det er helt klart et problem der mangler en bedre løsning. Vi spurgte derfor vores kunder, og de fleste kom med svaret: "Gør knappen mere tydelig." Lidt ligesom: "Kan du gøre hesten lidt hurtigere?".

Vi begyndte at undersøge under hvilke omstændigheder virksomhederne fik denne bøde, og hvorfor de gjorde det. Vi fandt ud af, at det ikke var fordi de ikke kunne finde knappen, men simpelthen fordi de enten ikke kendte til reglen, eller simpelthen glemte at den fandtes. Altså ville løsningen med en mere tydelig knap alligevel ikke afhjælpe problemet. Vi tænkte: "Hvad er der i vejen for, at vi bare automatisk nul-indberetter, hvis du ikke udbetaler løn?". Vi ved jo, fordi vi har dataen i Pento, hvornår du udbetaler løn og hvornår du ikke gør. Vi begyndte at undersøge, om det var muligt at gøre automatisk, og det viste det sig at være. Nu nul-indberetter vi automatisk til SKAT, hvis en virksomhed ikke udbetaler løn. Vi tror dermed, at vi har fundet den rigtige løsning på problemet, og har også siden fået rigtig god respons fra vores kunder, når de får den her e-mail:

Screenshot 2017-02-20 14.56.29

Det er et maraton, ikke en sprint

Når man bygger nye produkter, og hele tiden har kunder, der efterspørger nye features, kan det være svært at holde hovedet koldt. Især, hvis den der store, potentielle kunde bare liiiige skal bruge den der ene feature. Vi forsøger at være så strenge som muligt, og hele tiden basere vores valg på data, som beskrevet tidligere i denne post. Nogle gange kan man godt have svært ved at håndtere sin utålmodighed (vi taler af erfaring), men hvis man vil bygge noget, der er godt, bliver man nødt til, at give det den tid, det tager. Så længe vi i vores kommunikation tydeligt fortæller vores kunder hvad vi kan, og hvad vi ikke kan, så tror vi, at vi gør det rigtige.

Skulle du have spørgsmål til Pento, til vores produktstrategi, til måden vi bygger Pento på, eller noget helt andet, så send os endelig en mail eller fang os på Twitter og Facebook. Er du udvikler, og har du lyst til at være med, så hører vi også meget gerne fra dig.