Under början av 2015 satte vi en deadline för när vi skulle ha en första prototyp av en ny produkt vi jobbade med. Datum blev i februari – knappt två månader senare. Vi tog beslutet om en deadline tillsammans i teamet eftersom vi ville ha ett mer konkret mål att arbeta mot; tvinga oss att leverera något, nästan oavsett vad.

Jobbsök, som alla våra produkter handlar om, är extremt komplext. Människor är olika, deras behov varierande och arbetsmarknaden komplex.

Verktyget vi bygger utgår från olika övningar man som användare ska göra. Övningarna skiljer sig lite beroende på målgrupp, scenarier, branscher med mera. Vi hade tidigare säkert ett femtiotal övningar på skisstadiet och försökte hitta gemensamma nämnare mellan vissa av dem och jämförde och utvecklade för att komma fram till vad som var mest effektivt.

Att sätta en deadline tvingade oss att begränsa oss till en enda övning. Istället för att fortsätta skissa och utvärdera tog vi bara en av övningarna och satte igång.

Övningen handlar om att beskriva sig själv när man söker ett jobb på annons. I korthet gick den ut på att användaren identifierar nyckelord i en jobbannons, blir ombedd att komplettera med annat som kan vara viktigt i rollen, och slutligen välja ut några av de saker man kommit fram till. Hypotesen här, är att det man till slut väljer ofta är något annat än de första sakerna man angav. I så fall kan vi med bara dessa enkla steg få en användare att komma till en första “insikt”: De första saker du tänker på när du ska beskriva dig själv i förhållande till en annons är inte alltid de bästa.

Det duger inte

Vi genomförde som vanligt användningstester och testade dessutom “på riktigt” själva (det vill säga låtsades se övningen för första gången). Vi upptäckte många konkreta problem i användningen, typ: “vad gör man nu?” och “det här går inte”, men sådant får man alltid i tidigt skede, det är helt naturligt och bra.

Det som var värre var den generella responsen. Eller bristen på känslor i responsen. Testarna visade visserligen att övningen i stort var vettig och på nåt sätt funkade (eller skulle kunna funk). Men som startup måste vi först och främst hitta indikationer på om vi på det stora hela är på rätt spår eller inte. Löser vi ett verkligt problem eller inte? Är det ett behov folk faktiskt har? Annars kan vi lägga år på att bygga nåt som ingen vill ha.

Vi fick inte direkt nån negativ respons, men heller ingen positiv ‒ och det här är viktigt. Vi är på jakt efter nån form av genuint intresse, förståelse eller vill ha-känsla. Om vi inte får det måste vi omedelbart ifrågasätta idén.

Så slutsatsen var till slut: nej, det här håller inte. Övningen i sig är inte intressant nog och man kan inte se behovet av den, och inte heller hur den skulle passa in i något större som man skulle ha ett behov av.

En maquette är till för att skrotas

Vi skrotade alltihop och började om från början (vilket får bli ett annat inlägg). De tre viktigaste slutsatserna jag drog från det här var att vi måste fokusera mer på resultat istället för övningar; att vi måste ha ett annat sätt för att angripa komplexiteten av behov; och att alltid vara beredd att skrota en prototyp.

  1. Vi insåg att vi hade fokuserat på aktiviteter istället för resultat. Vi har hela tiden skissat på olika aktiviteter, övningar, frågor, som ska ta användaren vidare. En slutsats från prototyp 1 var att vi måste lägga mycket mer fokus på resultatet, det vill säga det som användaren förväntas komma fram till, och hur det presenteras.
  2. Vi hade tagit fel angreppssätt för att hantera komplexiteten i jobbsök. Vi försökte begränsa till en för liten del; en del som blev så liten att den inte blir relevant från ett kundperspektiv. Vi byggde en övning där man utgick från en annons, gjorde enkla kompletteringar och slutligen valde ut några punkter att använda för att presentera sig. Det finns en poäng med det och testpersoner var helt med på den poängen. Men det räcker helt enkelt inte. Jag tror att vi hade fått bättre resultat i testerna om vi gjort en övning med ett angreppssätt än just jobbannonser. Om man till exempel istället för att identifiera de egenskaper som efterfrågas i annonsen, kan ange ett antal av sina generella styrkor, kompetenser, drivkrafter och favorituppgifter, så hade kunnat leda längre. Även om man istället inte hade fått ha några andra steg än det. Det här resonemanget kan förstås tyckas lite teoretiskt och abstrakt, men det blir faktiskt helt olika angreppssätt. Kanske kan man säga att en lärdom blev att försöka hantera komplexiteten genom att bejaka den snarare än att begränsa den.
  3. För att röra sig snabbt framåt måste man också vara beredd att kasta bort de saker som inte funkar. På franska finns ordet maquette, som kanske bäst översätts till “modell”. Det är egentligen ett bättre ord än en prototyp. En prototyp är en föregångare, den upplevs lätt som något man tar med sig och bygger vidare på. En maquette är bara tillfällig och det är bara en av många man gör innan man börjar med något mer stabilt.

Så att skrota en misslyckad prototyp är inte i sig ett misslyckande. Tvärtom.

Jag vill påskynda utvecklingen mot ett mer flexibelt, öppet och dynamiskt arbetsliv. Jag är entreprenör, föreläsare och digital affärsrådgivare. Från att ha jobbat i stora organisationer som PwC, Socialstyrelsen och Försvarsmakten, driver jag nu ett litet team där kultur och samhörighet byggs med digitala verktyg. Utan kontor och med spridning över fyra kontinenter samarbetar vi helt online. Vill du prata mer? Du hittar mig på bland annat LinkedIn eller så kan du hitta en tid i min lunchkalender.
  • Christophe Bram

    In the French lexicon of software development, the difference between prototype and maquette, is that with the maquette there is no intention to use it to build a real product. The maquette is a quick and dirty way to test an idea, and designed to be thrown away.
    In that same lexicon, a prototype, on the other hand, is built with the hope that it will be used as the base of the product.

  • Pingback: How we Build New Products - Our new Product Development Life Cycle - Labs()