Hoe te bepalen of het noodzakelijk is om een nieuwe functie te ontwikkelen.
In 2021, ben ik overgestapt van werken als productontwerper bij een groot bedrijf naar het teamlid zijn van de startup - Logto.
Hier ben ik verantwoordelijk voor zowel product als ontwerp. Deze nieuwe rol is een sterke afwijking van mijn eerdere ervaring in een goed gestructureerd bedrijf met duidelijke processen en samenwerkingsmethoden. Daarnaast heb ik mijn naaste samenwerker, een productmanager, verloren. Hierdoor heb ik meerdere rollen op me moeten nemen, waaronder product, ontwerp, onderzoek, marketing en zelfs zelfprojectmanagement.
Mijn team en ik vinden onszelf vaak verwikkeld in de meest uitdagende discussies, meestal rond de vraag of bepaalde productfuncties moeten worden geïmplementeerd en hun omvang moeten worden bepaald.
In deze situaties raken we allemaal gepassioneerd betrokken, geven we onze meningen, met passie en een uitgesproken houding. De standpunten lijken op een mengelmoes gegenereerd door een complexe machine – anders dan opgeschreven in de documenten, missen ze organisatie en discipline.
Dit komt doordat "intuïtie" vaak naar voren komt voordat er een gestructureerde expressie is, wat resulteert in hopen langdradige discussies, leidend tot filosofische gevechten.
De motivatie achter het schrijven van dit artikel is om de leidende principes van besluitvorming te organiseren. Deze principes zijn voortgekomen uit mijn persoonlijke ervaringen en reflecties in de start-up omgeving, en zijn geen magische oplossing. Ik hoop inspiratie en perspectieven te bieden voor mede-ondernemers of degenen die betrokken zijn bij product, engineering of ontwerp.
Dit artikel is geweldig om te lezen als je in de volgende situatie bent…
✅ Een startup team bouwen om producten te ontwikkelen van 0 naar 1, samen met GTM (Go-To-Market) strategieën, vooral voor internationale uitbreiding.
✅ Producten uitbreiden van 10 naar 100 vereist de oprichting van een productroadmap.
✅ Productleiders of rollen met planningsverantwoordelijkheden leren kansen snel te identificeren.
✅ IC's leren nieuwe initiatieven binnen grote organisaties te stimuleren.
Dit artikel is NIET geweldig om te lezen als je in de volgende situatie bent…
❌ Onduidelijke projecten gestart van boven naar beneden door leiders of leidinggevenden.
❌ Projecten ver verwijderd van zakelijke doelen gericht op het valideren van individuele of onafhankelijke teamimpact.
❌ Hoogst aangepaste producteisen voornamelijk gericht op grote klanten.
Vanuit een absoluut standpunt beschouw ik zelfs dat focus behouden gezond verstand is, ongeacht de grootte van de organisatie, aangezien middelen beperkt zijn.
Middelen hier verwijzen niet alleen naar financiële middelen, maar ook naar tijd: qua tijd staan zowel startupteams als grote ondernemingen op gelijke voet.
In de meeste gevallen moeten we ons concentreren op het creëren van schaalbare, essentiële functies die aansluiten bij de behoeften van onze doelgebruikers en klantenpersona's. Het product moet een "pijnstiller" zijn in plaats van een "vitamine."
Door de focus te behouden, wordt het gemakkelijker en natuurlijker om een duidelijke waardepropositie van het product te handhaven en het klantbegrip te verbeteren. Het product vordert gestaag richting zijn visie, waarbij het probleemgebied geleidelijk wordt uitgebreid op een gezonde manier, wat organische groei bevordert.
We hoeven niet elk probleem op te lossen; we moeten ons perspectief behouden en moedig genoeg zijn om nee te zeggen.
Dus laat me schrijven over verschillende soorten "signalen" voor of "deze functie het waard is om te ontwikkelen."
Dit concept, "oppervlakte-niveau signalen," vertegenwoordigt oppervlakkige signalen die als referenties kunnen dienen maar nog een lange weg te gaan hebben voordat ze beslissingen nemen.
Hoewel ik onlangs geniet van het bestuderen van politieke wetenschappen, is vergelijkingen maken een methode vergelijkbaar met politieke analyse, gericht op het verkrijgen van "mogelijkheden." Het hebben van dit bredere perspectief kan inzichten bieden, dus, in onze huidige context, is het zinvol om verschillende producten te bestuderen.
Echter, als we te veel vertrouwen op concurrentieanalyse, leidt het vaak tot productbeslissingen die strategisch denken missen. Het is essentieel om te overwegen waarom een concurrent een functie niet heeft geïmplementeerd – komt het niet overeen met hun waarden, doelgebruikers, strategische prioriteiten of middelen?
Dus, concurrentieanalyse zou inzichten moeten bieden in plaats van absolute besluitvorming. Het is slechts een deel van het informatieverzamelingsproces voor het nemen van beslissingen.
Productmensen die bedreven zijn in het begrijpen van gebruikersperspectieven en scenario deducties kunnen snel nieuwe scenario's verifiëren of ontdekken. Echter, dit is slechts een hypothese en vereist verder werk in een echte go-to-market omgeving.
Hoewel het afleiden van plausibele scenario's waardevol is, kan het vertrouwen op alleen deze benadering leiden tot het creëren van een "alles-in-één" of log product voordat product-marktfit is bereikt, waardoor latere iteraties en aanpassingen uitdagend worden.
Een eenvoudige analogie is om elk afgeleid gebruikersscenario als een 0-1 startupproject te behandelen, rekening houdend met mini go-to-market strategieën, marketingperspectieven in te brengen en kritische vragen te stellen. Deze multidimensionale beoordeling gaat verder dan gebruikersbehoeften en ervaring.
Vaak wordt gebruikersfeedback met hoge frequentie een leidend principe voor functiekeuzes en productontwerp. Echter, dit leidende principe kan soms een valkuil zijn. Naarmate ik groei en meer projecten afrond, stel ik dit soort kader op om gebruikersfeedback aan te pakken en ermee om te gaan,
Het probleem definiëren en gek en herhaaldelijk opnieuw kaderen
Dit proces zal veel overwegingen, heen en weer, en debatten met zich meebrengen, wat enige tijd en moeite vereist. Denk niet dat dit proces zinloos is, omdat het door de discussies zal zich vertakken en enkele "onderliggende ijsberg"-problemen zal onthullen. Mijn team en ik hadden vroeger de neiging om eindeloos te discussiëren over het gelijk en ongelijk van iets en potentiële oplossingen, wat niet goed is. Nu zijn we meer in sync bij het identificeren van waar ieder van ons de problemen voelt en ons richten op probleemoplossing. Dit proces is zeer waardevol.
Bevooroordeeld vs. Onbevooroordeeld
Het is super noodzakelijk om te bepalen of deze functie/scenario met een bevooroordeelde of onbevooroordeelde benadering moet worden aangepakt. Bijvoorbeeld, Notion is een bevooroordeeld product; Google Docs is een beetje bevooroordeeld; Microsoft Word is niet bevooroordeeld. Als een SaaS-bouwer die oude paradigma's wil innoveren, is het beter om voor een bevooroordeelde benadering te gaan. Bevooroordeelde producten delen gebruikers op en filteren ze, en degenen die het ermee eens zijn zijn enthousiast om hun steun uit te drukken. Het is buitengewoon nuttig om het vroege product te helpen seed-gebruikers te vinden en gemakkelijk te begrijpen verhalen te creëren.
Als je voor een bevooroordeelde benadering gaat, probeer het probleem met een enkele oplossing per scenario op te lossen. Als er een alternatieve oplossing opkomt (Oplossing B voor een gegeven Scenario A), overweeg dan of Oplossing A werkelijk pijnpunten aanpakt. Zo niet, laten we Oplossing A opnieuw bekijken in plaats van simpelweg een andere oplossing te introduceren.
Intercom's productprincipes hebben deze benadering geïnspireerd: "Een product bouwen dat standaard bevooroordeeld is maar onder de motorkap flexibel."
Erken dat gebruikers geavanceerde Job-to-be-done kunnen suggereren
Sommige gebruikers kunnen voorstellen om een functie bedoeld voor Scenario A te gebruiken om Scenario B op te lossen. Het identificeren van deze valkuilen is cruciaal; besteed geen overmatige energie aan onwaardige problemen.
De enige situatie die aandacht verdient is wanneer Oplossing B een echte behoefte aangeeft, niet alleen een alternatief voor Oplossing A. Dit betekent dat Oplossing B een "nieuwgeboren probleem" aanpakt dat nauw gerelateerd is aan de visie en missie van het product. Dit signaal is waardevol wanneer het bedrijf verder wil groeien en zijn volgende fase van aanzienlijke uitbreiding wil ontdekken.
Het vermijden van het compliceren van een product gaat niet over het negeren van het oplossen van uitdagende problemen, maar het is een herinnering dat het verzoenen van een "complex, allesomvattend" product met een "eenvoudige, gebruiksvriendelijke" ervaring onrealistisch is in de echte wereld. Als je negeert hoe alles samenwerkt (systeemdenken) en je alleen richt op het oplossen van gefragmenteerde gebruikerservaringproblemen, is het resultaat een slecht ontworpen product.
Complexe producten veroorzaken een kettingreactie, waardoor zelfbediening moeilijk wordt en de tijd om waarde in het product te zien verlengd wordt.
Het ontwerpen van tools voor bedrijven (2B) is enigszins filosofisch: het gaat om het creëren van mentale modellen in samenwerking met gebruikers en het vaststellen van een structuur die gebruikersgedrag kan voorspellen. Complexiteit ontstaat vaak uit inconsistente en ongestructureerde architecturen, die proberen eisen te voldoen door interacties samen te voegen, resulterend in producten die "overlevers" zijn in plaats van uitstekende gebruikersreizen te bieden.
Functies die een product complex maken, van vereiste tot oplossing, zijn allemaal slechte signalen.
Hoewel dit je misschien niet definitief helpt om nee te zeggen, is het een cruciaal punt dat duidelijke afwegingen vereist.
Met andere woorden, het creëren van functies die niet overeenkomen met de positionering van een product schaadt en vervaagt het imago van het product. Bijvoorbeeld, Logto is op dit moment een ontwikkelaarstool die zich richt op identiteitsbeheer. Als ik zeg, laten we een marketingtoolfunctie bouwen, is dit een slechte strategie.
Dit perspectief komt voort uit een bedrijfs- of organisatiedoelstelling. Ik heb veel activiteiten gezien in een ondernemings- of grote bedrijfsomgeving, zoals:
In een relatief stabiele operationele staat zijn deze scenario's waardevol en moeten ze worden aangemoedigd en ondersteund. Toch, in uitdagende start-up omgevingen, vereisen dergelijke projecten aanzienlijke middelen en tijd om waarde te valideren, wat wijst op toewijding aan professionele na,achtervolging dan aan zakelijk succes. Dit punt benadrukt een conflict tussen persoonlijke achtervolgingen, carrièreovertuigingen en commerciële doelen.
Hoewel het proactief starten van projecten bewonderenswaardig is, is het ook belangrijk om te erkennen dat overmatige toewijding aan iets mogelijk niet de moeite waard is: mijn hamer gebruiken om spijkers te vinden en vervolgens een liniaal gebruiken om te meten hoe diep mijn gaten zijn en hoe groot mijn straal is—dit is misschien niet cruciaal in het grotere geheel. In werkelijkheid heeft de persoon die mij inhuurt om spijkers te slaan gewoon een manier nodig om een foto op te hangen, en ik hoef niet te bewijzen hoe bekwaam ik ben in het slaan van spijkers.
Dit abstracte maar vitale punt kan concreet worden beoordeeld: wanneer je een functie overweegt, vraag je dan af of gebruikers significant teleurgesteld zouden zijn als het product het niet heeft, wat mogelijk kan betekenen dat ze vertrekken. Bijvoorbeeld, kijk naar de huidige positionering van ons product Logto om authenticatie, autorisatie, en gebruikers/organisatiebeheerproblemen op te lossen. Hoe nauwer een functie verband houdt met deze aspecten, hoe hoger de prioriteit. Als Logto een bepaalde functie zou missen, hoe teleurgesteld zouden onze gebruikers zijn? Als het antwoord ja is, suggereert het dat de prioriteit hoog is en het is onze missie om een uitstekende ontwikkelaarservaring te bieden aan dit probleem.
Silicon Valley legt vaak de nadruk op gebruikersonderzoek en kansbepaling vanwege hun praktische bruikbaarheid en volledigheid. Deze twee aspecten geven aan dat een functie het onderzoeken en ontwikkelen waard is wanneer ze positieve inzichten geven.
Dit concept impliceert de laaghangende vruchten die moeiteloos een enorme hoeveelheid vreugde en baten brengen, waardoor het een deel van de persoonlijkheid en het merk van het product wordt.
Te midden van alle analyses is rationeel denken essentieel, maar ruimte laten voor intuïtie is ook cruciaal. Als je ervan overtuigd bent dat een functie de toekomst is, ondanks het gebrek aan rationele gegevens of marktvalidatie, is het de moeite waard om het te onderzoeken.
Andere onduidelijke functies, laat ze zich ontwikkelen en we kunnen de "signalen" na verloop van tijd op natuurlijke wijze observeren.
Gedurende productontwikkeling, ondernemerschap en sollicitatiegesprekken voor productfuncties kun je veel uitdagende vragen tegenkomen, vooral in Silicon Valley, zoals het onderwerp dat ik hierboven besprak, moeten we deze functie bouwen?
Hoewel dit soort vragen mogelijk geen universele principes hebben, vereisen ze doordachte uitvoering en overweging in concrete situaties. Maar het opsplitsen van grote en vage vragen in tastbare antwoorden is een vaardigheid die bouwers in de loop van hun carrière verfijnen en een superkracht om geweldige producten te bouwen.
Ik hoop dat de verstrekte inzichten je aanpak tot productdenken bij een startup kunnen inspireren. In Logto waarderen we het enorm om producten te bouwen waar ontwikkelaars van houden. We zijn blij om te chatten en onze perspectieven over soortgelijke onderwerpen te delen.