Produktupptäckt är processen att förstå dina användare, identifiera deras problem och komma fram till lösningar som du vet kommer att hjälpa dem.
Beroende på kvaliteten på den upptäckt du gör kommer du antingen att bygga upp eller rasera ditt företag. Logiken är enkel. Med en bra produktupptäckt bygger du till slut funktioner som människor behöver och betalar för. En dålig produktupptäckt utgår däremot från ständigt nya funktioner som ingen behöver.
Det här kan verka väldigt överväldigande, särskilt med tanke på mängden information som ingår i produktupptäckt. Men det finns ett bra system på plats för att hantera denna kritiska uppgift med hjälp av en mängd olika verktyg och ramverk.
Så låt oss förstå vad produktupptäckt är och hur man gör det på ett bra sätt.
Vad är produktupptäckt?
Produktupptäckt är processen att förstå användarnas problem och komma fram till genomförbara lösningar för att hantera dem.
Den här processen skiljer sig vanligtvis mycket från hur dina intressenter föreställer sig den. För många av dem handlar det om kreativt tänkande och att en gång ta fram en lista över häftiga idéer för funktioner och sedan bygga produkten utifrån den listan.
Det här tankesättet är fel på två viktiga områden:
- Upptäckt är en oändlig och iterativ process. Du avslutar inte upptäckten, utan avslutar en cykel av den och börjar på nästa.
- Upptäckt handlar inte om att kreativt komma på häftiga idéer. Det handlar om att förstå användarnas behov, ta fram lösningar som kan åtgärda dem och sedan validera att dessa lösningar faktiskt fungerar.
En annan vanlig missuppfattning handlar om relationen mellan upptäckt och leverans. Många intressenter ser dem som två separata faser som kommer efter varandra. I verkligheten arbetar effektiva produktutvecklingsteam med upptäckt och leverans parallellt. Medan ditt team levererar de funktioner som ni upptäckte för två månader sedan genomför ni en upptäckt för nästa uppsättning funktioner.
Bild:
- Diagram med delad väg: ”Upptäckt kontra leverans”. Visualisera denna idé: team arbetar med upptäckt och leverans parallellt. Medan ditt team levererar de funktioner som ni upptäckte för två månader sedan genomför ni en upptäckt för nästa uppsättning funktioner.
- Alt: ”Parallella spår som visar kontinuerlig upptäckt och leverans.”
- Bildtext: ”Produktupptäckt är inte en engångshändelse – den pågår parallellt med leveransen.”
Även om du befinner dig på en marknad där vattenfallsutveckling är normen och upptäckt kommer före leverans är det alltid viktigt att ägna all din uppmärksamhet åt upptäckten, eftersom dess kvalitet direkt påverkar produktens framgång.
Varför upptäckt är en konkurrensfördel
Det korta svaret är följande. Med upptäckt förstår du dina målgrupper och användarnas behov bättre och kommer fram till effektiva lösningar. Effektiva lösningar gör dig till en stark konkurrent på marknaden, eftersom du snabbt får nya kunder och enkelt behåller dem.
För det längre svaret kan vi titta på Marty Cagans Inspired. I boken påpekar Marty att effektiv upptäckt kan hjälpa dig att minska fyra typer av risker:
- Värderisk syftar på risken att människor inte använder din produkt eftersom den saknar betydelse för dem.
- Användbarhetsrisk syftar på att människor har svårt att använda din produkt.
- Genomföranderisk syftar på att ditt team inte kan bygga den.
- Överlevnadsrisk syftar på produktens förmåga att hjälpa ditt företag att överleva och blomstra.
Om vi antar att du kan minska alla dessa risker och att dina konkurrenter misslyckas med en eller flera av dem får du en stark konkurrensfördel och chansen att ta en större del av kakan.
Tiny Speck är ett bra exempel på denna idé. Det var ett spelföretag som utvecklade ett MMORPG-onlinespel som misslyckades totalt. Problemet var att de byggde ett spel genom att helt enkelt kopiera idéer från andra (även kallat fabriksfällan) utan att tydligt förstå spelarnas behov.
Företaget lade snart ner spelet och släppte i stället sitt interna kommunikationsverktyg. Japp, det var Slack.
Samma företag är alltså också ett bra exempel på produktframgång genom noggrann upptäckt. Till skillnad från spelteamet arbetade Slack-teamet med oändliga iterationer av upptäckt och hade en mycket tydlig förståelse för användarnas behov.
Fyra viktiga frågor vid produktupptäckt
Om vi vill förstå kärnan i produktupptäckt utan att gå vilse i detaljerna kan vi titta på dessa fyra frågor som den försöker besvara.
- Finns det ett verkligt problem? Just det, ibland riskerar man att skapa en lösning som letar efter ett problem. Hej, 90 % av alla nystartade företag som drivs av ChatGPT där ute ;)
- Kan vi lösa det? Ibland ligger problemet i lösningens komplexitet. S.T.A.L.K.E.R. är en ukrainsk tv-spelsserie som ställdes inför detta problem. De ville bygga A-life, sitt AI-system som fullt ut simulerade livet för NPC:er och djur i spelet. Men problemet var helt enkelt för komplext att lösa.
- Bör vi lösa det? Ibland finns problemet där, men det är inte tillräckligt stort för att lösas med en produkt. Google Glass är ett bra exempel på detta. Ja, det var häftigt, men att inte ha Google Glass skulle inte göra livet mindre bekvämt för någon.
- Kan vi leverera det effektivt? Den här frågan handlar mer om den operativa sidan av produktutveckling och om din förmåga att skala upp och ge användarna support. YouTube var under sina första år mycket nära att misslyckas på grund av sin oförmåga att skala upp.
Det du egentligen gör under produktupptäckten är att använda olika verktyg och ramverk för att få insikter, så att du kan besvara dessa frågor.
Ramverk för att strukturera produktupptäckten
Man skulle kunna hävda att en erfaren produktchef kan genomföra produktupptäckt utan att använda någon handbok eller något ramverk. Det stämmer. Men det finns en anledning till att vi har ramverk för produktupptäckt. De gör det möjligt att skapa struktur och förutsägbarhet i din upptäcktsprocess.
När det gäller själva ramverken kan vi titta på dessa fem:
Agilt arbete med två spår: Detta är processen att ha två parallella processer i agil utveckling. Du har ett upptäcktsspår som skapar funktionsidéer och ett leveransspår som utformar och bygger dem.

ProductBoard och Jira är vanligtvis de verktyg jag använder för att hantera detta ramverk.
Möjlighetslösningsträd: Vi kommer att prata lite mer om detta längre fram. Kort sagt låter detta ramverk dig skapa ett träd där roten är det centrala resultatet. Från denna rot skapar du möjligheter att lösa problem som grenar. Sedan skapar du grenar med möjliga lösningar för varje möjlighet.
Miro har utmärkta mallar för möjlighetslösningsträd som du kan använda.
Upptäcktssprint: Detta ramverk är inspirerat av Googles skapelse, designsprinten. Det möjliggör snabba iterationer kring lösningar. Du får ungefär två veckor på dig att genomföra användarintervjuer, komma fram till en lösning, bygga prototypen och testa den.
Kontinuerlig produktupptäckt: Till skillnad från de tre föregående, där du har iterationer med en tydlig början och ett tydligt slut, har kontinuerlig produktupptäckt inget slut. Du genomför helt enkelt ändlösa omgångar av intervjuer med din målgrupp, skapar kontinuerligt lösningar och testar dem.
Här är en jämförelse sida vid sida av dessa ramverk.
| Ramverk | Organisationens storlek | Upptäcktstakt | Riskbenägenhet |
|---|---|---|---|
| Agilt arbete med två spår | Mellan till stor | Pågående | Måttlig |
| Möjlighetslösningsträd | Liten till medelstor | Ad hoc eller cyklisk | Låg till måttlig |
| Upptäcktssprint | Nystartat företag till medelstor | Tidsbegränsade insatser | Högre |
| Kontinuerlig produktupptäckt | Omogna produktteam | Veckovis/dagligen | Låg |
Vilket ramverk du väljer beror på dig. Alla team drar inte lika stor nytta av samma ramverk. Använd tabellen ovan för att välja ett som passar teamets storlek, arbetstakt och tolerans för osäkerhet.
Roller & teamsamarbete
Det finns en vanlig missuppfattning (och en stor fallgrop) att produktupptäckt bara handlar om produktteam. Även om det främst är en aktivitet för produktteam kommer en bra upptäcktsprocess även att involvera andra teammedlemmar och intressenter. Så här bidrar varje teammedlem till produktupptäckten:
- Produktchefer: De leder upptäcktsprocessen, samordnar teammedlemmarna och prioriterar lösningar och insikter.
- Användarupplevelsedesign: De deltar i användarundersökningar, skapar designkoncept och klickbara prototyper samt genomför användbarhetstester.
- Utveckling: De bedömer lösningarnas genomförbarhet och pekar ut risker i produktleveransen.
- Intressenter: De bidrar med det övergripande strategiska sammanhanget och affärssammanhanget.
Som vi kan se är varje teammedlems deltagande viktigt. Så om din ledning frågar om scrumteamet bör delta i produktupptäcktsprocessen är ditt svar ett bestämt ja!
Processen för produktupptäckt
Att förstå dina kunders behov och ta fram validerade lösningar för dem påminner oss om en tratt där de översta lagren är mycket större än de nedersta.
Så är det faktiskt inom produktupptäckt. Du börjar med en mängd insikter, klagomål och kommentarer från din målgrupp och slutar med bara ett par validerade lösningar som du vet kommer att skapa värde för dina användare.
Så här ser det ut.

Nu ska vi gå igenom processen för produktupptäckt lite mer i detalj och förstå nyanserna i varje del.
Generellt består processen för produktupptäckt av dessa 10 steg.

Nu ska vi titta närmare på varje steg.
1. Gå igenom din strategiska inriktning
Bra funktioner löser användarnas problem. Fantastiska funktioner gör samma sak samtidigt som de följer produktens övergripande strategiska inriktning. Innan du börjar med produktupptäckt är det viktigt att gå tillbaka till ditt strategidokument och påminna dig själv om vart du vill nå på lång sikt och vilken riktning du vill ta.
Det hjälper dig att fokusera dina upptäcktsinsatser på lösningar som ligger i linje med din strategi. Annars riskerar du att fokusera på funktioner som inte tar dig någonstans på lång sikt.
2. Lista dina antaganden
En annan viktig del av upptäcktsarbetet som du behöver hantera innan du kommunicerar med användare är dina antaganden. Du gör sannolikt många antaganden om din marknad eller dina användare, och det är viktigt att dokumentera dem för att säkerställa att din forskning inte bygger för mycket på dina mer djärva antaganden.
För detta kan du skapa en antagandekarta.
| Antagande | Känt/okänt | Viktighet |
|---|---|---|
| Användare kommer att lita på en AI-röst som liknar en DJ | Okänt | Hög |
| Folk använder främst Spotify i passivt läge (lyssning i bakgrunden) | Känt | Hög |
| Användare vill namnge sina DJ-personligheter | Okänt | Låg |
| Poddar ökar tiden som spenderas på plattformen | Känt | Medel |

I kartan här kan du förlita dig på antagandet längst upp till vänster och vara försiktig med antagandena längst upp till höger.
3. Prata med dina användare
Utan detta steg är produktupptäckt bara gissningar. Prata med dina användare – eller riskera att bygga helt fel sak.
Det finns många olika sätt att prata med användare:
- Besöka dem (till exempel genom att gå till ett sjukhus och intervjua läkare).
- Träffa dem på branschmässor (till exempel genom att prata med teknikjournalister på CES).
- Ansluta till Zoom-samtal med dem.
För det sista alternativet kan du använda olika metoder, till exempel plattformar för forskningsdeltagande, kontakta din användarbas eller kontakta din målgrupp på LinkedIn med hjälp av ett rekryterarkonto.
4. Analysera insikter från användare och data
Utöver sammanfattningar av användarintervjuer bör du kontrollera din instrumentpanel för produktanalys och den feedback som dina support- och säljteam har samlat in. På så sätt hämtar du insikter från flera källor. Och i stället för att läsa igenom ändlösa sammanfattningar eller transkriptioner kan du låta en LLM bearbeta allt åt dig.
Här är ett exempel på en prompt du kan använda:
Du är en senior produktchef för programvara med 10 års erfarenhet. Du är mycket bra på att analysera transkriptioner från ditt säljteam och identifiera viktig information som kommer att vara användbar för din produktanalys.
Här är transkriptionen av säljsamtalet
{{sales_transcript}}
Utifrån informationen i säljtranskriptionen ska du identifiera följande information.
Identifiera följande:
1. Viktigaste smärtpunkterna: hänvisa till de mest framträdande problemen och utmaningarna som användaren upplever med nuvarande verktyg och processer.
2. Varför är de intresserade av dig: syftar på anledningen till att företaget letar efter ett nytt verktyg just nu.
3. Produktfeedback: syftar på den feedback som företaget har gett säljteamet om {{your_product_name}} och dess funktioner efter att de har sett demonstrationen.
När du har gått igenom feedbacken och kopplat ihop den med insikter från användarintervjuer och analyser kommer du att börja se trender och gemensamma teman växa fram.
5. Identifiera användarnas problem i dina resultat
Att identifiera problem är inte alltid så enkelt. Visst finns det fall där 80 % av alla användare har sagt att en viss del av deras arbete är besvärlig, men det betyder inte nödvändigtvis att det är ett problem som är värt att lösa. Du bör också förstå problemets ”intensitet”.
Föreställ dig att 70 % av användarna på din sociala medieplattform säger att de irriterar sig på antalet aviseringar och på att de inte kan markera alla som lästa.
När du kopplar ihop deras feedback med analyser som visar att 90 % av dem i genomsnitt får 2–3 aviseringar per dag, kanske du bedömer att detta klagomål inte är tillräckligt ”intensivt” för att prioriteras framför andra punkter på din lista.
6. Ta fram lösningar på dessa problem
Det här steget handlar om att ta fram möjliga lösningar på de problem som du har identifierat genom dina kundintervjuer och din feedbackanalys.
Du kan helt enkelt sätta dig ner med dina design- och utvecklingsteam och brainstorma. Men för att säkerställa att dina lösningar är direkt kopplade till ett större affärsmål eller resultat kan du använda ramverket för möjlighets- och lösningsträd av Teresa Torres. Så här ser det ut för Spotify-användarnas problem ”Jag vet inte vad jag ska lyssna på”.

Genom trädets ramverk såg vi att ett avlägsnande av hindret ”vad ska jag lyssna på” kunde öka antalet dagliga aktiva användare (DAU), vilket gjorde det till ett problem med stor påverkan att lösa.
7. Testa dina lösningar med prototyper
Att analysera användarinsikter och omvandla dem till en lista över möjliga funktioner är bara utgångspunkten. Produktutforskning bygger på den vetenskapliga metoden, vilket innebär att du bör testa och validera idéer innan du lägger till dem i produktplanen.
Du kan validera lösningar i olika skeden av deras livscykel – från att helt enkelt beskriva idén för en användare under en intervju och samla in feedback, till att skapa enkla skisser och be fokusgrupper om feedback på tidiga prototyper. Du kan till och med gå så långt som att bygga och lansera en minsta livskraftig produkt (MVP).
Validering i ett tidigt skede, till exempel genom att diskutera idén i en intervju, går snabbt och kostar lite, men kvaliteten på kundfeedbacken kan vara låg eftersom användarna kan ha svårt att förstå konceptet fullt ut.
Att testa med en MVP ger däremot rikare och mer exakt feedback eftersom användarna kan interagera med produktens faktiska funktioner. Detta tillvägagångssätt är dock långsammare och dyrare på grund av det utvecklingsarbete som krävs.

Med tanke på denna avvägning är klickbara prototyper min favoritmetod för validering, eftersom de både är relativt billiga att skapa och visar riktiga användare en faktisk användarupplevelse för din nya produkt eller funktion.
För att snabba upp skapandet av prototyper kan du använda Figma AI eller de inbyggda AI-funktionerna i andra verktyg för UX-design.
8. Dokumentera testresultaten
När dina tester är slutförda sammanställer du alla lärdomar och resultat i ett enda dokument. Gruppera dem efter lösningen och den hypotes som testas.
På så sätt har du allt du behöver samlat på ett ställe när det är dags att utvärdera en lösning, så att du kan fatta ett välgrundat beslut.
9. Validera eller förkasta dina lösningar
Det är här du går igenom alla resultat från dina tester och beslutar om:
- Du anser att lösningen är validerad och lägger till den i din befintliga produktbacklogg.
- Du förstår att lösningen är på rätt väg men behöver omarbetas. Då tar du tillbaka den till idéfasen för att förbättra den baserat på testresultaten.
- Du underkänner lösningen eftersom den inte löser de användarproblem som den var avsedd att lösa.
Alla tre utfallen är förväntade. När du underkänner en produkt bör du betrakta det som en stor framgång, eftersom du då har undvikit att bygga produkter och slösa tid och resurser på något som inte löser dina användares problem.
More Articles
10. Bygg de validerade lösningarna och börja om
Det sista logiska steget i produktupptäcktsprocessen är att lägga till dina lösningar i din backlogg, prioritera dem och bygga dem.
Det är dock verkligen viktigt att förstå att du inte faktiskt avslutar produktupptäckten här. I stället avslutar du denna iteration och börjar omedelbart på nästa. Framgångsrika produkter är sådana där upptäcktsprocessen aldrig tar slut.
Här kan team fatta rätt produktbeslut baserat på sina lärdomar från användarfeedback, användbarhetstester och A/B-tester.
Verktyg för produktupptäckt
Här är några verktyg som är värda att utforska för att hjälpa dig att ta dig igenom produktupptäckten snabbare och få bättre resultat, organiserade efter vilken fas du befinner dig i.
- Användarundersökningar: Hotjar för sessionsinspelningar, UserTesting för användbarhetstester och Figma för design av användarupplevelser och klickbara prototyper.
- Resekartläggning och visuellt samarbete: Miro är det universella verktyget här. Du kan också överväga att prova dess framväxande konkurrent – FigJam eller andra alternativ till Miro.
- Konkurrentundersökningar: Similarweb för konkurrenters trafikkällor och Builtwith för teknikstackar.
- Produktanalys: GA4 för kanaler och trafik. Amplitude för beteende och viktiga produktmått. När det gäller programvara för värmekartor är HotJar ett populärt alternativ.
- Uppföljning och prioritering: RICE-poängmodellen för enkel prioritering, Aha! eller ProdPad för färdplanering och lagring av produktidéer.
Det här är verktygen jag använder och rekommenderar till mina kollegor. Om du vill ha fler alternativ kan du också ta en titt på vår kurerade lista över verktyg för produktupptäckt.
Om du har lagt märke till det nämnde jag inte några AI-lösningar här. Det beror på att jag vill prata om det separat och mer detaljerat.
Hur AI förändrar produktupptäckten
Produktupptäckt har förmodligen varit det område inom produktledning där AI har tillfört mest värde. Anledningen är att LLM:er är bra på de typer av uppgifter som du vanligtvis hittar inom produktupptäckt. Mer specifikt transkribering, sammanfattning och att ta fram insikter.
Vi tog upp AI:s inverkan på produktupptäckten i ett av avsnitten av vår podcast. Vår gäst, Craig Watson, berättade om sin egen erfarenhet och delade med sig av många värdefulla insikter.
Han påpekar särskilt att AI har varit till stor hjälp för produktchefer inom följande områden:
Att transkribera och sammanfatta användarintervjuer: PM:er behöver inte anteckna under samtalet och lyssna på inspelningarna efteråt. Allt de behöver är att AI-boten deltar i samtalet och spelar in det. Boten omvandlar sedan inspelningen till en transkribering och sammanfattning – och lyfter fram de viktigaste resultaten från intervjun. Bra verktyg för detta är Dovetail, Krisp och GreatQuestion.
Att upptäcka återkommande mönster i kvalitativa data: Det är mycket tidskrävande att lyssna på alla intervjuer och hitta problem eller processer som återkommer. LLM:er kan hantera den här uppgiften mycket väl och gå igenom hundratals intervjuer i jakt på mönster. Enligt min erfarenhet är Dovetail bäst på detta.
Klustring, räkning och poängsättning av feedback: Än en gång skulle det ta produktteam timmar eller till och med dagar att manuellt omvandla kvalitativa data till kvantitativa data. LLM:er behöver bara några sekunder för att räkna och se vilken feedback som är vanligast i datan. De kan också poängsätta med hjälp av den viktade poängmodellen eller RICE.
Trots allt värde du får från dessa automatiseringar rekommenderar Craig fortfarande att man inte förlitar sig för mycket på AI när man genomför produktupptäckt.
”AI kommer inte att ersätta din intuition – den hjälper dig att fatta snabbare, evidensbaserade beslut.”
Jag håller med honom. Låt AI inom produktupptäckt utföra det manuella arbetet åt dig. Men lita inte på AI:s beslutsfattande utan att först kontrollera det själv.
Vanliga frågor
Hur hanterar agila team produktupptäckt?
Agila team kan dra nytta av agilt arbete med två spår, där upptäcktsarbetet pågår parallellt med leveransen. I så fall ansluter agila team ibland till upptäcktsspåret för att hantera uppgifter som att ge återkoppling om teknisk genomförbarhet för lösningsidéer, ta fram designkoncept, bygga prototyper och testa dem.
Bör ingenjörer vara involverade i produktupptäckt?
Absolut! Ingenjörerna är de som så småningom kommer att bygga funktionen. Därför har de värdefull kunskap om idéns genomförbarhet. De kan också identifiera potentiella tekniska risker och implementeringsrisker som är förknippade med den. Slutligen kan de påpeka de tekniska begränsningar som produktteamet behöver ta hänsyn till när funktionen utformas.
Hur minskar produktupptäckt tiden till marknaden?
Det största värdet företag får från produktupptäckt är billig validering av idéerna. På så sätt riskerar du inte att bygga sådant som dina användare inte behöver och avsevärt fördröja tidpunkten då du slutligen släpper den version som människor tycker om och använder. Du förkortar också iterationscyklerna och får tidig återkoppling. Allt detta bidrar även till att påskynda leveransen.
Vad är skillnaden mellan produktupptäckt och produktstrategi?
När du definierar din produktutvecklingsstrategi visar du produktens övergripande riktning och en lista över milstolpar längs vägen. Produktupptäckt är processen att identifiera kundbehov och ta fram validerade lösningar för dem. Vanligtvis syftar produktupptäckt till att skapa lösningar som är anpassade till produktstrategin och för dig ett steg närmare dina milstolpar.

