Hur man avgör om det är nödvändigt att utveckla en ny funktion.
År 2021 bytte jag från att arbeta som produktdesigner på ett stort företag till att bli en del av start-up-teamet - Logto.
Här hanterar jag både produkt och design. Den här nya rollen är en skarp avvikelse från min tidigare erfarenhet i ett välstrukturerat företag med tydliga processer och samarbetsmetoder. Dessutom har jag förlorat min närmaste samarbetspartner, en produktchef. Därför har jag varit tvungen att ta på mig flera roller, inklusive produkt, design, forskning, marknadsföring och till och med projektledning.
Mitt team och jag befinner oss ofta nedsänkta i de mest utmanande diskussionerna, ofta kretsande kring om vi ska implementera vissa produktfunktioner och definiera deras omfattning.
I dessa situationer blir vi alla engagerat involverade och levererar våra åsikter, med passion och en bestämd attityd. Synsätten verkar som en blandning genererad av en komplex maskin—till skillnad från nedskrivet i dokument sitter de inte i ordning och disciplin.
Detta beror på att "intuition" ofta uppstår innan strukturerat uttryck, vilket resulterar i mängder av virriga diskussioner, vilket leder till filosofiska strider.
Anledningen till att skriva den här artikeln är att organisera de vägledande principerna för beslutsfattande. Dessa principer härstammar från mina personliga erfarenheter och reflektioner av att arbeta i startupmiljön, och de är inget slags mirakelkurer. Jag hoppas kunna ge inspiration och perspektiv för kollegor entreprenörer eller de som är involverade i produkt, teknik eller design.
Den här artikeln är bra för läsning om du befinner dig i följande situation…
✅ Bygga ett startupteam för att utveckla produkter från 0 till 1, tillsammans med GTM (Go-To-Market) strategier, särskilt för internationell expansion.
✅ Utvidga produkter från 10 till 100 kräver upprättandet av en produktplan.
✅ Produktledare eller roller med planeringsansvar lär sig att identifiera möjligheter snabbt.
✅ ICs lär sig att driva nya initiativ inom stora organisationer.
Den här artikeln är INTE bra för läsning om du befinner dig i följande situation…
❌ Oklara projekt initierade uppifrån och ner av ledare eller chefer.
❌ Projekt långt borta från affärsmål som syftar till att validera individuell eller oberoende teampåverkan.
❌ Mycket anpassade produktkrav som i första hand fokuserar på stora kunder.
Från en absolut synvinkel anser jag till och med att fokusera är ett vanligt förnuft, oavsett organisationens storlek, eftersom resurserna är begränsade.
Resurser här handlar inte bara om finansiella resurser utan också tid: i form av tid står både startupteam och stora företag på samma nivå.
I de flesta fall bör vi fokusera på att skapa skalbara, väsentliga funktioner som stämmer överens med våra målgruppers behov och kundpersonor. Produkten bör vara en "smärtlindrare" snarare än ett "vitamin."
Genom att behålla fokus blir det lättare och mer naturligt att upprätthålla en tydlig produktvärdeförslag och förbättra kundförståelsen. Produkten fortsätter att avancera mot sin vision, gradvis utökar problemutrymmet den adresserar på ett hälsosamt sätt och främjar organisk tillväxt.
Vi behöver inte lösa alla problem; vi bör upprätthålla vårt perspektiv och vara modiga nog att säga nej.
Så låt mig skriva om olika typer av "signaler" för om "denna funktion är värd att utveckla."
Detta koncept, "yt-signaler," representerar ytliga signaler som kan fungera som referenser men som fortfarande har en lång väg att gå innan beslut fattas.
Även om jag nyligen njuter av att studera statsvetenskap, är att göra jämförelser en metod som liknar politisk analys, med syfte att få "möjligheter." Att ha denna bredare vy kan erbjuda insikter, så, i vår nuvarande kontext, är det meningsfullt att studera olika produkter.
Men om vi överdrivet förlitar oss på konkurrentanalys, tenderar det att leda till produktbeslut utan strategiskt tänkande. Det är viktigt att överväga varför en konkurrent inte har implementerat en funktion - stämmer den inte överens med deras värderingar, målgrupp, strategiska prioriteringar eller resurser?
Så konkurrentanalys bör ge insikter snarare än absoluta beslut. Det är bara en del av informationsinhämtningsprocessen för att fatta beslut.
Produktpersoner som är skickliga på att förstå användarperspektiv och använda scenariodeduktion kan snabbt verifiera eller upptäcka nya scenarier. Men detta är bara en hypotes och kräver ytterligare arbete i en verklig go-to-market-miljö.
Medan deduktion av rimliga scenarier är värdefullt, kan enbart förlita sig på detta tillvägagångssätt leda till att skapa en "allt-i-ett" eller tungrodd produkt innan man uppnår produkt-marknadspassning, vilket gör efterföljande iterationer och justeringar utmanande.
En enkel analogi är att behandla varje dedukterat användarscenario som ett 0-1 startup-projekt, överväga mini-go-to-market strategier, inkludera marknadsperspektiv och ställa svåra frågor. Denna multidimensionella bedömning går bortom användarbehov och erfarenhet.
Ofta blir högfrekvent användarfeedback en riktlinje för funktionsutveckling och produktdesign. Men denna riktlinje kan ibland vara en fälla. Allt eftersom jag växer och arbetar mer med projekt, bygger jag upp denna typ av ramverk för att hantera och hantera användarfeedback,
Definiera problemet och galet och upprepat omformulera det
Denna process kommer att innebära en hel del överväganden, fram och tillbaka, och debatter, kräver viss tid och ansträngning. Tänk inte att denna process är meningslös, för genom diskussionerna kommer den att divergera och avslöja några "underliggande isberg"-problem. Jag och mitt team brukade enkelt argumentera oändligt om rätt och fel om något och potentiella lösningar, vilket inte är bra. Nu är vi mer i samklang med att identifiera var och en känner problemen och fokuserar på problemlösning. Denna process är mycket värdefull.
Bestämda vs. icke-bestämda
Det är väldigt nödvändigt att definiera om denna funktion/scenario ska gå med ett bestämt eller icke-bestämt tillvägagångssätt. Till exempel är Notion en bestämd produkt; Google Docs är lite bestämd; Microsoft Word är inte bestämd. Som en SaaS-byggare som syftar till att innovera det gamla paradigmet är det bättre att gå med det bestämda tillvägagångssättet. Bestämda produkter delar och filtrerar användare, och de som håller med dem är ivriga att uttrycka sitt stöd. Det är extremt användbart för att hjälpa den tidiga produktfasen att hitta fröanvändare och skapa lättbegripliga historier.
Om du går med ett bestämt tillvägagångssätt, försök att lösa problemet med en enda lösning per scenario. Om en alternativ lösning uppstår (Lösning B för ett givet Scenario A), överväg om Lösning A verkligen adresserar smärtpunkter. Om inte, låt oss återbesöka Lösning A snarare än att bara introducera en annan lösning.
Intercoms produktprinciper har inspirerat detta tillvägagångssätt: "Bygga en produkt som är bestämd som standard men flexibel under huven."
Känn igen att användare kan föreslå avancerade Job-to-be-done
Vissa användare kan föreslå att använda en funktion avsedd för Scenario A att lösa Scenario B. Att identifiera dessa fallgropar är avgörande; lägg inte för mycket energi på ovärda problem.
Den enda situation som förtjänar uppmärksamhet är när Lösning B indikerar ett verkligt behov, inte bara ett alternativ till Lösning A. Detta innebär att Lösning B adresserar ett "nyfött problem" nära relaterat till produktens vision och mission. Denna signal är värdefull när företaget vill växa vidare och upptäcka sin nästa fas av betydande expansion.
Att undvika att komplicera en produkt handlar inte om att ignorera att lösa utmanande problem, utan det är en påminnelse om att förena en "komplex, omfattande" produkt med en "enkel, användarvänlig" upplevelse är orealistiskt i verkligheten. Om du ignorerar hur allt fungerar tillsammans (systemtänkande) och bara fokuserar på att lösa fragmenterade användarupplevelseproblem, är resultatet en dåligt designad produkt.
Komplexa produkter utlöser en kedjereaktion, vilket gör självbetjäning svårt och förlänger tiden det tar att se värdet i produkten.
Att designa verktyg för företag (2B) är något filosofiskt: det handlar om att skapa mentala modeller i samarbete med användare och upprätta en struktur som kan förutse användarbeteende. Komplexitet uppstår ofta från inkonsekventa och ostrukturerade arkitekturer, försök att tillfredsställa krav genom att sätta ihop interaktioner, vilket resulterar i produkter som är "överlevare" snarare än att leverera utmärkta användarresor.
Funktioner som gör en produkt komplex, från krav till lösning, är alla dåliga signaler.
Även om detta kanske inte definitivt hjälper dig att säga nej, är det en avgörande punkt som kräver tydliga kompromisser.
Med andra ord skapar funktioner som inte stämmer överens med en produkts positionering skador och suddar ut produktens image. Till exempel är Logto ett utvecklarverktyg som just nu fokuserar på identitetshantering. Om jag säger, låt oss bygga en marknadsföringsverktygsfunktion, är detta en dålig strategi.
Denna synvinkel härrör från ett företags eller organisations affärsmål. Jag har sett många aktiviteter utförda i en företagssammanhang eller storföretagsmiljö, som:
I ett relativt stabilt drifttillstånd är dessa scenarier värdefulla och bör uppmuntras och stödjas. Men i utmanande uppstartsmiljöer kräver sådana projekt betydande resurser och tid att validera värdet, vilket indikerar ett engagemang för professionell strävan snarare än affärsframgång. Denna punkt understryker en konflikt mellan personliga strävanden, yrkesövertygelser och kommersiella mål.
Även om det är beundransvärt att initiera projekt proaktivt, är det också viktigt att inse att överdriven hängivenhet till något kanske inte ger värdefulla resultat: svinga min hammare för att hitta spikar, sedan använda en linjal för att mäta hur djupa mina hål är och hur stor min radie är - detta kanske inte är avgörande i det stora hela. I verkligheten behöver personen som anställer mig för att hamra spikar bara ett sätt att hänga en bild, och jag behöver inte bevisa hur skicklig jag är på att slå spikar.
Denna abstrakta men viktiga punkt kan bedömas konkret: när du överväger en funktion, fråga om användarna skulle bli betydligt besvikna om produkten inte har den, vilket eventuellt skulle få dem att lämna. Till exempel, överväg vårt produkts Logtos nuvarande positionering för att lösa autentiserings-, auktoriserings- och användar-/organisationshanteringsproblem. Ju mer relaterad en funktion är till dessa aspekter, desto högre prioritet. Om Logto saknade en viss funktion, hur besvikna skulle våra användare bli? Om svaret är ja, tyder det på att prioriteten är hög och det är vår uppgift att ge en utmärkt utvecklarupplevelse till detta problem.
Silicon Valley betonar ofta användarforskning och opportunitetsstorlek för deras praktiska och r rigor. Dessa två aspekter indikerar att en funktion är värd att utforska och utveckla när de ger positiva insikter.
Detta koncept innebär de lågt hängande frukterna som bringar en stor mängd glädje och fördelar utan ansträngning, vilket gör det till en del av produktens personlighet och varumärke.
Mitt i all analys är rationellt tänkande viktigt, men att tillåta utrymme för intuition är också avgörande. Om du är övertygad om att en funktion är framtiden trots brist på rationella data eller marknadsvalidering, är det värt att utforska.
Andra otydliga funktioner, låt dem utvecklas och vi kan observera "signalerna" över tid naturligt.
Under produktutveckling, entreprenörskap och produktjobbintervjuer kan du stöta på många tankeväckande frågor, särskilt i Silicon Valley, som det ämne jag nämnde ovan, bör vi bygga denna funktion?
Medan dessa typer av frågor kanske inte har universella principer, kräver de genomtänkt genomförande och övervägande i konkreta situationer. Men att bryta ner stora och vaga frågor till konkreta svar är en färdighet som byggare raffinerar under sina karriärer och en superkraft för att bygga bra produkter.
Jag hoppas att de tillhandahållna insikterna kan inspirera ditt tillvägagångssätt till produkttänkande i en startup. På Logto uppskattar vi högt att bygga produkter som utvecklare älskar. Vi är glada att chatta och dela våra perspektiv på liknande ämnen.