Ett proof of concept som faktiskt validerar något: en checklista innan ni bygger vidare

De flesta proof of concept-projekt jag ser börjar med rätt instinkt – testa idén innan ni satsar stort – och slutar som en trevlig demo som egentligen inte bevisade något. Skillnaden mellan de två ligger inte i hur mycket som byggs, utan i om ni från början definierade vilken fråga konceptet skulle besvara.

Ett PoC utan en fråga är bara en prototyp

"Bygg en prototyp så vi ser hur det känns" är ett rimligt förstasteg, men det är inte ett proof of concept – det är en skiss. Ett riktigt PoC har en hypotes som kan visa sig fel: "Kan vi hämta och matcha den här datan inom en sekund?", "Förstår en ny användare värdet inom de första två minuterna utan hjälp?", "Håller marginalen om vi automatiserar det här steget?". Om svaret på frågan inte kan bli nej har ni inte ett koncept att bevisa – ni har redan bestämt er.

Tre sorters risk, och varför de kräver olika PoC

Nästan alla idéer bär på en kombination av teknisk risk, marknadsrisk och risk i affärsmodellen. Ett PoC som bara adresserar en av dem kan ändå lämna er blinda för de andra två:

• Teknisk risk – går det över huvud taget att bygga inom rimlig prestanda, kostnad och komplexitet? Här räcker ofta en smal spik: ett skript, ett API-anrop, en isolerad modul utan hela produktens yta runt omkring.
• Marknadsrisk – förstår målgruppen värdet, och är de villiga att ändra sitt beteende för det? Det här kräver riktiga användare i kontakt med konceptet, inte bara ett internt demo för teamet.
• Affärsmodellrisk – håller ekonomin ihop vid den skala ni faktiskt siktar på? En teknisk prototyp som fungerar för tio användare säger ingenting om enhetsekonomin vid tio tusen.

Innan ni börjar bygga, bestäm vilken av de tre som är farligast för just er idé just nu, och scopa konceptet för att svara på den – inte för att visa upp så många funktioner som möjligt.

Snäv scope är en funktion, inte en begränsning

Den vanligaste anledningen till att ett PoC drar ut på tiden är att det gradvis blir en produkt: fler edge-cases, mer polish, "medan vi ändå är inne i koden". Det är förståeligt, men det urholkar hela poängen. Ett bra PoC är medvetet skört utanför den smala väg det ska bevisa – det är okej att det kraschar på ett fel som ligger utanför hypotesen, för ni betalar inte för robusthet ni inte behövde bevisa än.

Vad en beställare eller investerare faktiskt vill se

Ett klickbart flöde imponerar i ett rum. Det som faktiskt flyttar ett beslut är vad flödet bevisade: vilken siffra kom ut, vilket antagande höll eller föll, och vad det betyder för nästa steg. Bygg därför in mätpunkten i konceptet från start – logga det ni faktiskt behöver svaret på – snarare än att försöka läsa av det subjektivt i efterhand.

Checklista innan ni startar ett PoC

• Vilken specifik fråga ska konceptet besvara, formulerad så att svaret kan bli nej?
• Vilken av teknisk risk, marknadsrisk eller affärsmodellrisk är farligast just nu?
• Vad är den minsta möjliga lösningen som kan besvara den frågan ärligt?
• Hur mäter ni svaret – vilken siffra eller observation avgör utfallet?
• Vad händer i vardera utfallet: bygger ni vidare, pivoterar, eller lägger ner idén med vunna lärdomar?

Nästa steg om PoC:n håller

Ett lyckat koncept är inte en produktion – det är ett beslutsunderlag för att investera i en. Se till att ni har en plan för vad som skiljer "koden vi bevisade konceptet med" från "koden vi kan lita på i produktion": ofta är svaret att större delen skrivs om med andra krav på testning, säkerhet och skala.

Funderar ni på ett proof of concept men är osäkra på vad det faktiskt ska bevisa? På Avitus IT hjälper vi er att formulera rätt fråga innan vi bygger något alls. Läs mer om hur ett uppdrag går till eller hör av er direkt via kontaktsidan.