Product-market fit: sluta bygga det som ingen behöver

Föreställ dig en grundare som sitter framför en potentiell kund.

Produkten fungerar. Demon är genomarbetad. AI-funktionerna gör det de lovar. Kunden nickar, ställer några genomtänkta frågor och säger något som varje grundare har hört:

”Det här är verkligen intressant. Skicka lite information till mig.”

Ännu ett lovande möte. Ännu en affärsmöjlighet i CRM:et. Tre veckor senare, ingenting.

Grundaren lägger till en funktion till, förbättrar onboardingen och skriver om säljpitchen. Kanske behöver produkten bara bli lite bättre. Eller så behövde ingen den från början.

Det här är ett illustrativt scenario, men de flesta grundare känner igen det. Vi förväxlar kundintresse med köpintention, produktanvändning med product-market fit och aktivitet med framsteg. Det är samma förväxling som gör MQL:er till leadteater.

AI gör den förväxlingen dyrare. Att bygga har blivit billigt, så nu kan vi bygga mycket innan någon har gjort ett verkligt åtagande.

I ett nytt avsnitt av Lenny's Podcast gick Rob Snyder, författare till The Power of Pull, igenom sitt ramverk för att hitta product-market fit. Lenny presenterar honom som någon som har hjälpt fler än 50 startups att gå från noll till 1 miljon dollar i ARR.

Hans centrala idé ryms i två meningar. Hitta människor som redan måste få något att hända och inte kommer dit med de alternativ de har. Se sedan om de faktiskt försöker köpa.

Jag tror att det här når långt bortom startups i tidig fas. Det förändrar hur vi bör arbeta med produktledning, go-to-market och de AI-system som kopplar ihop dem.

Din största konkurrent är kundens att göra-lista

De flesta produktteam börjar med problem. De gör kundintervjuer, identifierar smärtpunkter, uppskattar marknadsmöjligheter och bygger lösningar. Sedan översätter marknadsföringen de lösningarna till värdeerbjudanden, och säljet försöker få potentiella kunder att bry sig.

Processen ser logisk ut. Det saknas bara en variabel: prioritet.

En kund kan ha ett verkligt problem, se att din produkt löser det och hålla med om att den ger utmärkt värde. Och ändå inte ha någon avsikt att köpa.

Kunden har femton andra saker att bli klar med det här kvartalet. Den nuvarande nödlösningen är godtagbar. Chefen har krävt något annat. Eller så är problemet irriterande men får inga verkliga konsekvenser.

I Snyders ramverk heter skillnaden mellan intresse och verklig efterfrågan pull. Pull uppstår när en viss person redan försöker åstadkomma något viktigt, måste göra det nu och märker att de alternativ som finns inte räcker.

Den personen försöker redan förändra något. Ingen behöver övertyga personen om att en förändring behövs.

Skillnaden vänder på synen på product-market fit. Frågan flyttas från hur du får fler att köpa till var människor redan försöker köpa något som inte riktigt finns än.

PULL-ramverket: fyra villkor för verklig efterfrågan

Snyder delar upp det i fyra element.

Element	Frågan
P: Project (projekt)	Vad försöker den här personen aktivt åstadkomma?
U: Unavoidable (oundvikligt)	Varför måste personen åstadkomma det nu?
L: List of options (lista över alternativ)	Vilka alternativ överväger personen eller använder redan?
L: Limitations (begränsningar)	Varför räcker de alternativen inte för att få jobbet gjort?

Alla fyra spelar roll. Ett projekt utan brådska blir en trevlig idé för nästa år. Brådska utan begränsningar betyder att kunden förmodligen kan lösa det själv. En bättre produkt utan ett viktigt projekt är bara ännu ett verktyg som någon inte behöver.

Snyder ger ett exempel från Jump, en AI-produkt för mötesanteckningar till finansiella rådgivare.

Finansiella rådgivare måste dokumentera kundmöten och föra register i sitt CRM. Snyder förklarar att kraven på regelefterlevnad gör arbetet oundvikligt. Generiska AI-verktyg för anteckningar kan ge bra sammanfattningar, men de integrerar inte nödvändigtvis med de system som krävs eller uppfyller kraven på regelefterlevnad. Jump täcker just den luckan.

Jämför nu med försäkringsagenter. De lägger också tid på kundmöten, och de tycker kanske inte heller om att skriva anteckningar. Men i exemplet som Snyder beskriver har de inte samma krav på att föra registren i CRM:et. Att inte göra något är ett godtagbart alternativ.

Samma breda smärta. Liknande arbetsflöde. Helt olika köpbeteende.

Det är en viktig lärdom för alla som definierar en ideal kundprofil.

En bransch är inte din kund. Ett företag är inte din kund. En person med ett oundvikligt projekt är din kund.

Och den personens nuvarande prioriteringar betyder mer än ditt noga finslipade värdeerbjudande.

AI har ändrat vad det kostar att ta fel på product-market fit

Här skulle jag bygga vidare på Snyders argument.

I många år var det så dyrt att bygga mjukvara att det tvingade fram en viss disciplin. En större funktion krävde utvecklare, planering, tester och månader av utvecklingskapacitet.

I dag kan en kompetent grundare använda AI-stödd utveckling och ta fram en fungerande prototyp på några dagar. Det är verkliga framsteg, och det skapar en ny fälla: vi börjar använda tempot i genomförandet som bevis på framsteg.

Ett team bygger tio funktioner, lanserar tre landningssidor, automatiserar outbound och tar fram en genomarbetad demo. Veckogenomgången ser produktiv ut. Ändå är den viktigaste frågan obesvarad.

Vem försöker köpa det här, och varför nu?

Kodningen blev snabb. Vägen till marknaden blev det inte. Mer exakt har flaskhalsen flyttat sig. När det blir billigt att bygga blir det relativt sett mer värdefullt att avgöra vad som förtjänar att byggas. När jag skrev om att bygga en SaaS-produkt på 90 dagar var det svåra aldrig koden. Det svåra var att skära bort.

Product-market fit kan inte längre behandlas som en fas som kommer efter produktutvecklingen. Den måste forma utvecklingen från början.

Det betyder att kundsamtal är mer än underlag för produktchefernas research. De är kommersiella experiment som testar om kunden kommer att agera. Och den starkaste signalen är ett köp.

Sluta intervjua folk om din idé. Testa om de försöker köpa.

Snyder rekommenderar att börja med det han kallar en pull-hypotes. Innan du bygger produkten skriver du ner dina antaganden om köparens situation.

Här är ett hypotetiskt exempel från B2B-mjukvaruutveckling. En VP Product är under press att leverera en stor release det här kvartalet. Hennes team använder Jira, dokumentationsverktyg och AI-kodassistenter, men viktiga produktbeslut syns inte konsekvent i implementeringsarbetet. Releasen är i fara, och fler utvecklare löser inte nödvändigtvis samordningsproblemet.

Hypotesen blir:

• Projekt: Leverera en utlovad release utan att kritiska krav går förlorade mellan produkt och utveckling.
• Oundvikligt: Releasen har en deadline som har lovats externt.
• Alternativ: Fler möten, fler produktchefer, bättre dokumentation, befintliga Jira-integrationer och AI-kodverktyg.
• Begränsningar: De här alternativen kan förbättra enskilda uppgifter utan att på ett tillförlitligt sätt hålla beslut, ärenden och implementering i linje.

Lägg märke till vad som saknas. Det finns ingen funktionslista, ingen storslagen produktvision, ingen pitch om AI-magi. Bara en specifik person, ett viktigt projekt och ett skäl till att befintliga metoder inte fungerar.

Det är den sortens hypotes som är värd att testa för en produkt som Teklens, som jag var med och grundade: ett gemensamt Product Brain, ett minne för människor och AI-agenter som kopplar ihop produktsamtal, Jira och kod.

Men det är fortfarande en hypotes. Den relevanta köparen kanske inte ser problemet som brådskande. Teamet kanske redan hanterar det tillräckligt bra. Eller så är den egentliga köparen en CTO som förbereder en revision, snarare än en VP Product som driver en release.

Syftet med discovery-arbetet är att ta reda på det.

Snyder rekommenderar att visa potentiella kunder en enkel beskrivning av projektet, brådskan och begränsningarna, följd av en konceptuell förklaring av hur du skulle kunna hjälpa till. Titta sedan på vad de gör.

Vissa ber om en implementeringsplan, drar in en kollega, kopplar in inköp eller frågar när de kan börja. Andra gratulerar dig till visionen och lovar att höra av sig. Det är väldigt olika signaler.

Ett muntligt löfte om att köpa är uppmuntrande. Ett betalt åtagande är starkare. Faktisk användning och retention är ännu starkare.

Fem säljsamtal kan lära dig mer än fem veckors utveckling

En av Snyders mest användbara rekommendationer är att arbeta i små discovery-cykler. Börja med en hypotes. Hitta relevanta personer. Genomför ett femtal samtal. Gå igenom vad du har lärt dig.

Om ingen försöker gå vidare ska du inte automatiskt boka femtio möten till. Ändra hypotesen. Kanske är problemet verkligt men inte brådskande. Kanske är det fel person som äger det. Kanske räcker befintliga verktyg redan. Eller så har du upptäckt ett annat projekt som betyder mycket mer.

Ett sätt att ta reda på det kallar Snyder för Hail Mary-frågan:

”Finns det något på din att göra-lista som du skulle betala någon för att ta över från dig just nu?”

Det är en enkel fråga, och betydligt mer användbar än att fråga vilka funktioner någon skulle vilja se. Den flyttar samtalet från åsikter om produkten till verkliga prioriteringar.

Människor är generösa med feedback om produkter som de inte har någon avsikt att köpa. De lägger gärna en timme på att rita upp din roadmap. De kommer bara inte att finansiera den.

Snyder är särskilt skeptisk till samarbeten med design partners som ger mycket feedback men lite kommersiellt åtagande.

Jag skulle inte avfärda design partners helt. I komplexa B2B-miljöer kan gemensam utveckling visa begränsningar i integrationer, hur arbetsflödena faktiskt ser ut och organisatoriska krav som annars skulle förbli osynliga. Men det kommersiella testet är fortfarande viktigt. En design partner ska ha ett verkligt projekt, ett definierat framgångskriterium och en trovärdig väg till att bli betalande kund. Annars har du kanske rekryterat en hjälpsam produktrådgivare snarare än en köpare.

Sälj resultatet innan du bygger plattformen

Det finns en annan konsekvens som AI gör särskilt intressant. Du behöver inte alltid en färdig mjukvaruprodukt för att testa efterfrågan. Om en kund behöver få ett specifikt jobb gjort kan du ibland leverera resultatet med en kombination av människor, befintlig mjukvara och automatisering.

Snyder beskriver grundare som börjar med tjänsteliknande erbjudanden innan de utvecklar den underliggande mjukvaran.

Tänk dig ett företag som behöver korta sin cykel för marknadsundersökningar från veckor till dagar. Den första versionen kan bestå av analytiker som använder AI-verktyg, manuella kvalitetskontroller och ett enkelt gränssnitt för rapporter. Köparen får resultatet. Leverantören lär sig vilka steg som går att upprepa. Sedan automatiserar teamet de stegen. Det är den ordning som en forward deployed engineer arbetar i: kartlägg först den verkliga processen, automatisera sedan det som upprepas.

Det vänder på den traditionella ordningen. Den gamla: bygg mjukvara, hitta kunder, hoppas att de använder den. Den nya: hitta ett brådskande jobb, sälj resultatet, leverera det, lär dig arbetsflödet och automatisera sedan det som upprepas.

Det är särskilt relevant för AI-native B2B-företag. Men det finns en risk. Om varje kund kräver en egen implementering har du inte nödvändigtvis hittat en skalbar produkt. Du kanske har byggt ett konsultbolag med utmärkta verktyg. Jag har skrivit om var den gränsen går, och om den ärliga mellanvägen med produkt plus tjänster, i tjänstebyrå vs mjukvaruproduktbolag.

Disciplinen ligger i att skilja den repeterbara kärnan från det skräddarsydda arbetet runt den. Ta betalt för resultatet tidigt. Lär dig vad som går att återanvända. Gör det återkommande arbetet till produkt. Förväxla inte fem orelaterade kundprojekt med product-market fit.

Product-market fit tar inte slut när kunderna köper

En kund som har bråttom att köpa kan ändå säga upp avtalet. Kanske fungerar produkten inte som utlovat. Kanske är implementeringen för komplicerad. Kanske tar köparens akuta projekt slut, och produkten behövs inte längre.

Snyder föreslår att du ser kundens resa i två steg. Före köpet behöver du hitta någon för vilken ett köp är självklart. Efter köpet behöver du hitta ögonblicket då det inte längre skulle vara rimligt att lämna.

Det andra ögonblicket är mer användbart än att fira aktiveringsgrader. En inloggning bevisar lite. En kund som slutför en uppgift som tidigare blockerade verksamheten är en mycket bättre signal.

För en produkt som kopplar ihop krav, ärenden och kod kan det ögonblicket vara när ett team fångar en viktig avvikelse innan den når produktion och sedan löser den med rätt kontext. För ett GTM-system kan det vara när en säljare får en köpsignal att agera på som annars hade försvunnit mellan CRM:et, möten och mejl.

Det här är hypoteser att testa, inte universella aktiveringsmått. Den operativa frågan är:

Vad måste en kund uppleva för att verkligen sakna produkten om den försvann?

Bygg sedan onboardingen baklänges från det ögonblicket.

Driv företaget som en fabrik för kundcase

Mot slutet av intervjun presenterar Snyder en idé som jag tycker är mer användbar än själva PULL-akronymen: se ditt företag som en fabrik som tar fram repeterbara kundframgångar.

Han menar kundresultat som upprepas, kund efter kund. Marknadsföringscase med putsade logotyper och misstänkta procentsatser är något annat.

Varje lyckad kund följer ungefär samma mönster. En viss person har ett brådskande projekt. De befintliga alternativen räcker inte. Personen köper något som hjälper. Det önskade resultatet uppnås. Kunden stannar eftersom lösningen fortsätter att ge värde.

Ditt företag blir ett system för att upprepa det mönstret:

1. Hitta rätt köpare.
2. Förstå det brådskande projektet.
3. Visa en trovärdig lösning.
4. Vinn ett kommersiellt åtagande.
5. Leverera det utlovade resultatet.
6. Nå ett bestående värde.
7. Behåll, lär och upprepa.

Den här mentala modellen samlar produktledning, sälj, marknadsföring och customer success kring en enda definition av framgång. Den förändrar också hur du tänker kring tillväxt.

Om pipeline är flaskhalsen, förbättra hur du hittar liknande köpare. Om kunderna har brådskande projekt men inte köper, undersök erbjudandet, trovärdigheten, den kommersiella processen eller begränsningarna i inköpet. Om de köper men inte stannar, förbättra leveransen och tiden till värde, eller ompröva om den ursprungliga efterfrågan är repeterbar.

Fokus ändras med flaskhalsen. Det är betydligt mer användbart än att be varje avdelning förbättra alla sina KPI:er på en gång.

Där gemensam kontext blir den saknade infrastrukturen

Här ser jag en koppling till de system vi bygger kring Product, GTM och AI.

Tänk dig att en kund berättar för Sälj att den högsta prioriteten är att minska förseningarna i releaserna. Samtalet ger användbara belägg om brådska, befintliga lösningar, hinder, budget och de personer som är inblandade.

I många organisationer stannar den informationen i en samtalsinspelning eller en anteckning i CRM:et. Produkt får en funktionsönskan som har tappat sitt ursprungliga sammanhang. Marknad skapar ett generiskt budskap om smärtpunkter. Customer Success får en checklista för onboarding men inte det affärsresultat som kunden förväntar sig. Sedan ombeds en AI-agent förbereda en uppföljning utifrån de fragment den lyckas hitta.

Alla arbetar. Alla har olika information.

Snyders fabrik för kundcase kräver något mer sammanhängande. Samma belägg från kunden ska ligga till grund för produktbeslutet, det kommersiella löftet, implementeringsplanen och milstolpen för retention. Ingen behöver läsa ett enormt dokument för det. Varje person och varje agent behöver de relevanta beläggen i det ögonblick de fattar beslut.

Det är principen bakom Get Multiplayer: Människor sätter mål, beslutar och godkänner. Agenter förbereder och tar hand om det återkommande arbetet. Gemensamma mål och gemensam kontext håller ihop arbetet.

En agent kan till exempel plocka ut kundens aktiva projekt och alternativ ur ett säljsamtal. En annan kan jämföra de kraven med produktens backlog. En tredje kan förbereda en onboardingplan utifrån det utlovade resultatet.

Men människor måste fortfarande granska beläggen och avgöra vad de betyder. Annars automatiserar du bara antaganden. Snabbare. I stor skala.

Där jag inte håller med: pull ensamt garanterar inte ett bra företag

Snyders ramverk är särskilt användbart eftersom det tvingar fram kommersiell ärlighet. Men det är ingen komplett teori om hur man bygger företag.

En kund kan ha verklig brådska och ändå representera en usel marknad. Kanske uppstår projektet bara en gång vart femte år. Kanske har köparen inget mandat att spendera pengar. Kanske kostar leveransen mer än avtalet. Kanske är problemet extremt värdefullt men finns i för få organisationer.

Stark pull validerar en viss möjlighet. Den validerar inte automatiskt marknadsstorlek, attraktiva marginaler, repeterbar distribution eller försvarbarhet.

I enterprise B2B är skillnaden mellan en person som vill ha lösningen och en organisation som kan köpa den särskilt viktig. Championen kan ha pull. Säkerhet, Juridik och Inköp har ändå sina egna krav.

Därför ser jag PULL-ramverket som ett komplement till en välskött enterprise sales-process, inte som en ersättning för den. Och därför spelar retention lika stor roll som tidig köpintention.

Du behöver tre lager av belägg:

• Efterfrågan: Försöker människor köpa, och har de bråttom?
• Värde: Ger lösningen ett resultat som de bryr sig om?
• Ekonomi: Kan du upprepa det resultatet lönsamt hos tillräckligt många kunder?

Först när de här förstärker varandra börjar en spännande möjlighet likna ett skalbart företag.

En praktisk playbook för product-market fit

Om jag startade en ny B2B-produkt nästa måndag skulle jag organisera den första cykeln kring sju aktiviteter.

1. Välj en person, inte en marknad. Identifiera rollen, ansvaret och situationen där behovet sannolikt är brådskande. ”SaaS för medelstora företag” är för vagt.
2. Skriv en PULL-hypotes. Dokumentera projektet, varför nu, befintliga alternativ och varför de alternativen inte räcker. Håll antaganden åtskilda från bekräftade belägg från kunder.
3. Kom nära arbetet. Observera verkliga arbetsflöden, kundmöten, verktyg och överlämningar. Intervjuer hjälper, men när du ser någon kämpa med en verklig uppgift kan du upptäcka det som personen glömmer att nämna.
4. Genomför fem kommersiella samtal. Fråga om pågående projekt, deadlines, lösningar som har provats och stegen i inköpet. Visa bara så mycket av en föreslagen lösning att du kan testa om de skulle gå vidare.
5. Leta efter handling, inte entusiasm. En betald diagnos, en signerad order, ett kommersiellt åtagande eller en inköpsprocess som kunden själv driver är starkare belägg än positiv feedback.
6. Leverera resultatet och hitta ögonblicket som får kunden att stanna. Arbeta nära de första kunderna. Identifiera händelsen som bevisar bestående värde och gör sedan den händelsen central i onboardingen.
7. Gör lärdomarna till ett repeterbart system. För in validerade belägg i positionering, produktprioriteringar, kvalificering i säljet och onboarding. Hitta nästa flaskhals och förbättra den.

AI kan hjälpa till i varje steg. Den kan analysera samtal, gruppera mönster, jämföra alternativ, ta fram prototyper, förbereda offerter, dokumentera lärdomar och automatisera repeterbart leveransarbete.

Det den inte kan göra är att skapa en brådskande kundprioritet där ingen finns. Därför är människans roll fortfarande avgörande: att bedöma om beläggen motiverar nästa investering.

Bygg mindre. Lär dig vad som förtjänar att byggas.

Jag började med en grundare som hade en genomarbetad demo och en potentiell kund som lovade att höra av sig.

Den vanliga reaktionen är att förbättra produkten, skicka ännu en uppföljning och öka antalet utskick. Ibland är det precis det som behövs. Ibland är det mest värdefulla nästa steget att erkänna att du försöker sälja något som ingen har bråttom att köpa.

Rob Snyder ger oss ett praktiskt sätt att se skillnaden. AI ger oss förmågan att agera på den lärdomen mycket snabbare. Kombinationen fungerar, förutsatt att vi använder tekniken i rätt ordning.

Hitta det brådskande projektet. Bevisa att kunden kommer att agera. Leverera resultatet. Gör det repeterbart.

Hitta först de kunder som är värda att bygga för. Låt sedan AI göra dig snabb.

Om du vill ha en notis i veckan från praktiken om Product, GTM och AI, prenumerera på nyhetsbrevet The Science of GTM.

Baserat på Rob Snyders samtal med Lenny Rachitsky i Lenny's Podcast, An 86-minute guide to finding PMF, publicerat 25 oktober 2026 (lyssna på Snipd). Rob Snyders bok: The Power of Pull, John Murray Business, 2026. PULL-ramverket, Hail Mary-frågan och fabriken för kundcase kommer från Snyder. Tolkningen för Product, GTM och AI och de praktiska tilläggen är mina egna.