Kuinka määrittää, onko uuden ominaisuuden kehittäminen tarpeellista.
Vuonna 2021 siirryin työskentelemästä tuotesuunnittelijana isossa yrityksessä osaksi startup-tiimiä - Logtoa.
Täällä vastaan sekä tuotteesta että suunnittelusta. Tämä uusi rooli on merkittävä poikkeama aiemmasta kokemuksestani hyvin rakenteellisessa yrityksessä, jossa oli selkeät prosessit ja yhteistyömenetelmät. Lisäksi menetin läheisimmän yhteistyökumppanini, tuotepäällikön. Näin ollen olen joutunut ottamaan useita rooleja, mukaan lukien tuotannon, suunnittelun, tutkimuksen, markkinoinnin ja jopa itseprojektinhallinnan.
Tiimini ja minä löydämme itsemme usein syvimmissä haastavissa keskusteluissa, jotka pyörivät usein sen ympärillä, pitäisikö tiettyjä tuoteominaisuuksia toteuttaa ja määritellä niiden laajuus.
Näissä tilanteissa osallistumme kaikki intohimoisesti, annamme mielipiteitämme intohimolla ja oman näkemyksen mukaan. Nämä näkökulmat vaikuttavat olevan kuin monimutkaisen koneen tuottamaa sekoitusta - toisin kuin dokumentteihin kirjoitettuna, ne puuttuvat organisaatiota ja kurinalaisuutta.
Tämä johtuu siitä, että "intuitio" usein ilmenee ennen jäsenneltyä ilmaisua, mikä johtaa loputtomiin jaaritteluihin ja filosofisiin taisteluihin.
Tämän artikkelin kirjoittamisen motiivina on jäsentää päätöksenteon ohjaavia periaatteita. Nämä periaatteet kumpuavat henkilökohtaisista kokemuksistani ja pohdinnoistani startup-ympäristössä, eivätkä ne ole mikään hopealuoti. Toivon voivani tarjota inspiraatiota ja näkökulmia muille yrittäjille tai niille, jotka ovat mukana tuotteessa, tekniikassa tai suunnittelussa.
Tämä artikkeli on hyvä lukea, jos olet seuraavassa tilanteessa…
✅ Rakennat startup-tiimiä kehittääksesi tuotteita vaiheista 0–1, yhdessä GTM-strategioiden (Go-To-Market) kanssa, erityisesti kansainvälistä laajentumista varten.
✅ Laajennat tuotteita vaiheista 10–100, mikä vaatii tuotesuunnitelman luomista.
✅ Tuotejohtajat tai roolit, joilla on suunnitteluvastuu, oppivat tunnistamaan mahdollisuuksia nopeasti.
✅ IC:t oppivat ohjaamaan uusia aloitteita suurissa organisaatioissa.
Tämä artikkeli ei ole hyvä lukea, jos olet seuraavassa tilanteessa…
❌ Epäselviä projekteja, jotka käynnistetään ylhäältä alas johtajien tai esimiesten toimesta.
❌ Projektit, jotka ovat etäällä liiketoimintatavoitteista ja tähtäävät yksilöllisen tai itsenäisen tiimin vaikutuksen validoimiseen.
❌ Tehokkaasti räätälöidyt tuotevaatimukset, jotka keskittyvät pääasiassa suuriin asiakkaisiin.
Absoluuttisesti katsoen, pidän jopa sitä, että keskittyminen on tervettä järkeä, riippumatta organisaation koosta, sillä resurssit ovat rajallisia.
Resurssit eivät tarkoita vain taloudellisia resursseja, vaan myös aikaa: ajan suhteen sekä startup-tiimit että suuret yritykset ovat samalla viivalla.
Useimmissa tapauksissa meidän pitäisi keskittyä luomaan skaalautuvia, olennaisia ominaisuuksia, jotka ovat linjassa kohdekäyttäjiemme tarpeiden ja asiakaspersoonien kanssa. Tuotteen tulisi olla "kipulääke" eikä "vitamiini".
Pitämällä keskittyminen, on helpompaa ja luonnollisempaa ylläpitää selkeä tuotearvolupaus ja parantaa asiakasymmärrystä. Tuote etenee tasaisesti kohti visiota, laajentaen vähitellen ongelma-aluetta, johon se pureutuu terveellisellä tavalla, edistäen orgaanista kasvua.
Meidän ei tarvitse ratkaista jokaista ongelmaa; meidän pitäisi säilyttää näkökulmamme ja olla rohkeita sanoa ei.
Joten, kirjoitan eri tyyppisistä "signaaleista" siitä, onko "tämä ominaisuus kehittämisen arvoinen."
Tämä käsite, "pintatason signaalit," edustaa pinnallisia signaaleja, jotka voivat toimia viitteinä, mutta niillä on vielä pitkä matka ennen päätöksenteon tekemistä.
Vaikka nykyään nautin poliittisen tieteen opiskelusta, vertailujen tekeminen on menetelmä, joka on poliittiseen analyysiin verrattavissa ja pyrkii saamaan "mahdollisuuksia". Tällaisen laajemman perspektiivin omaaminen voi tarjota oivalluksia, joten nykyisessä kontekstissamme on merkityksellistä tutkia eri tuotteita.
Jos kuitenkin liialti luotamme kilpailija-analyysiin, se johtaa helposti tuotepäätöksiin, joilta puuttuu strateginen ajattelu. On oleellista pohtia, miksi kilpailija ei ole toteuttanut ominaisuutta - eikö se ole linjassa heidän arvojensa, kohdekäyttäjiensä, strategisten prioriteettiensa tai resurssiensa kanssa?
Kilpailija-analyysin pitäisi siis tarjota oivalluksia eikä olla absoluuttinen osa päätöksentekoa. Se on vain osa tiedonkeruuprosessia päätöksenteossa.
Tuoteasiantuntijat, jotka ovat taitavia ymmärtämään käyttäjän näkökulmia ja käyttämään skenaarion päättelyä, pystyvät nopeasti varmentamaan tai löytämään uusia skenaarioita. Tämä on kuitenkin vain hypoteesi, ja se vaatii lisätyötä todellisessa go-to-market-ympäristössä.
Vaikka uskottavien skenaarioiden päättely on arvokasta, pelkästään tähän lähestymistapaan tukeutuminen voi johtaa "kaikki yhdessä" tai vaikeaan tuotteeseen ennen tuotemarket fitin saavuttamista, mikä tekee myöhemmistä iteraatioista ja sopeutumisista haasteellisia.
Yksinkertainen analogia on kohdella jokaista pääteltyä käyttäjän skenaariota 0-1 startup-projektina, harkitsemalla pieniä go-to-market-strategioita, tuomalla mukaan markkinoinnin näkökulmia ja kysymällä vaikeita kysymyksiä. Tämä moniulotteinen arviointi menee käyttäjän tarpeita ja kokemusta pidemmälle.
Usein korkean taajuuden käyttäjäpalaute tulee ohjaavaksi periaatteeksi ominaisuuksien kehittämisessä ja tuotteen suunnittelussa. Kuitenkin tämä ohjaava periaate voi joskus olla ansa. Kun kasvan ja työskentelen enemmän projekteissa, luon tällaista viitekehystä käsitelläkseni ja hoitaakseni käyttäjäpalautteen,
Määrittele ongelma ja hulluna ja toistuvasti kehitä sitä uusiksi
Tämä prosessi vaatii paljon mietiskelyä, edestakaisin kulkemista ja väittelyjä, jotka vaativat aikaa ja vaivaa. Älä ajattele, että tämä prosessi on merkityksetön, koska keskustelujen aikana se poikkeaa ja paljastaa joitain "piilotettuja jäävuoria". Tiimini ja minä olimme aiemmin helposti kiistelemässä loputtomiin jonkin asian oikeasta tai väärästä ja mahdollisista ratkaisuista, mikä ei ole hyvä. Nykyään olemme paremmin synkassa tunnistamaan, missä kukin meistä tuntee ongelmat ja keskitymme ongelmanratkaisuun. Tämä prosessi on erittäin arvokas.
Omalaatuinen vs. Epäomalaatuinen
On erittäin tarpeellista määritellä, pitäisikö tämän ominaisuuden/skenaarion mennä omalaatuisella vai epäomaleimaisella lähestymistavalla. Esimerkiksi Notion on omalaatuinen tuote; Google Docs on hieman omalaatuinen; Microsoft Word ei ole omalaatuinen. Saas-rakentajana, joka pyrkii uudistamaan vanhaa mallia, on parempi mennä omalaatuisella lähestymistavalla. Omalaatuiset tuotteet jakavat ja suodattavat käyttäjiä, ja ne, jotka ovat samaa mieltä, ilmaisevat mielellään tukensa. Tämä on erittäin hyödyllistä auttamaan alkuvaiheen tuotetta löytämään siemenkäyttäjiä ja luomaan helposti ymmärrettävää tarinankerrontaa.
Jos valitset omalaatuisen lähestymistavan, yritä ratkaista ongelma yhdellä ratkaisulla per skenaario. Jos vaihtoehtoinen ratkaisu nousee esiin (Ratkaisu B tiettyyn skenaarioon A), harkitse, poistaako Ratkaisu A oikeasti kipupisteitä. Jos ei, tarkastellaan uudelleen Ratkaisu A:ta sen sijaan, että yksinkertaisesti otettaisiin käyttöön toinen ratkaisu.
Intercomin tuoteperiaatteet ovat inspiroineet tätä lähestymistapaa: "Rakennetun tuotteen, joka on oletuksena omalaatuinen mutta joustava pinnan alla."
Tunnista, että käyttäjät saattavat ehdottaa edistyneitä Työ-tulee-lopulta tehtyä
Jotkut käyttäjät saattavat ehdottaa ominaisuuden käyttöä, joka on tarkoitettu skenaarioon A ratkaisemaan skenaarioon B. Näiden ansakuoppien tunnistaminen on ratkaisevan tärkeää; älä sijoita liikaa energiaa arvottomiin ongelmiin.
Ainoa tilanne, joka ansaitsee huomiota, on se, kun Ratkaisu B osoittaa todellisen tarpeen, ei vain vaihtoehtoa Ratkaisulle A. Tämä tarkoittaa, että Ratkaisu B käsittää "vastasyntyneen ongelman", joka liittyy läheisesti tuotteen visioon ja missioon. Tämä signaali on arvokas, kun yritys haluaa kasvaa edelleen ja löytää seuraavan vaiheen merkittävälle laajentumiselle.
Tuotteen monimutkaisuuden välttäminen ei tarkoita vaikeiden ongelmien ratkaisun sivuuttamista, vaan se on muistutus siitä, että "monimutkaisen, kaikki kattavan" tuotteen yhdistäminen "yksinkertaiseen, käyttäjäystävälliseen" kokemukseen ei ole realistista todellisessa maailmassa. Jos jätät huomioimatta, miten kaikki toimii yhdessä (järjestelmäajattelu) ja keskityt vain hajanaisten käyttäjäkokemusten korjaamiseen, tuloksena on huonosti suunniteltu tuote.
Monimutkaiset tuotteet laukaisevat ketjureaktion, joka tekee itsepalvelusta vaikeaa ja pidentää aikaa, joka kuluu tuotteen arvoon pääsemiseen.
Työkalujen suunnittelu yrityksille (2B) on hieman filosofista: se käsittää mielikuvamallien luomisen yhdessä käyttäjien kanssa ja luomisen rakenteen, joka voi ennakoida käyttäytymistä. Monimutkaisuus syntyy usein epäjohdonmukaisista ja jäsentämättömistä arkkitehtuureista, jotka yrittävät tyydyttää vaatimuksia yhdistelemällä vuorovaikutuksia, seurauksena "eloonjäämistaistelijat" tuotteet sen sijaan, että tarjoaisivat erinomaisen käyttäjäpolun.
Ominaisuudet, jotka tekevät tuotteesta monimutkaisen, aina vaatimuksesta ratkaisuun, kaikki ovat huonoja signaaleja.
Vaikka tämä ei ehkä auttaisi sinua sanomaan ehdottomasti ei, se on tärkeä kohta, joka vaatii selkeitä kompromisseja.
Toisin sanoen ominaisuuksien luominen, jotka eivät ole linjassa tuotteen asemoinnin kanssa, vahingoittaa ja hämärtää tuotteen kuvaa. Esimerkiksi Logto on kehittäjien työkalu, joka keskittyy henkilöllisyyden hallintaan tällä hetkellä. Jos sanon, rakentakaamme markkinointityökalutoiminto, tämä on huono strategia.
Tämä näkökulma kumpuaa yrityksen tai organisaation liiketoimintatavoitteesta. Olen nähnyt paljon toimintoja, joita on tehty suuryrityksessä tai suuressa yritysympäristössä, kuten:
Suhteellisen vakaassa toimintatilassa nämä skenaariot ovat arvokkaita ja niitä tulisi kannustaa ja tukea. Kuitenkin haastavissa startup-ympäristöissä tällaiset projektit vaativat merkittäviä resursseja ja aikaa arvon validoimiseen, osoittaen sitoumusta ammattimaiseen tavoitteluun ennemmin kuin liiketoiminnan menestykseen. Tämä kohta korostaa ristiriitaa henkilökohtaisten pyrkimysten, urakehityksen uskomusten ja kaupallisten tavoitteiden välillä.
Vaikka projektien aloittaminen proaktiivisesti on ihailtavaa, on myös tärkeää tunnistaa, että liiallinen omistautuminen jollekin ei ehkä tuota oivallisia tuloksia: heilutan vasaraani löytääkseni nauloja, sitten käytän viivotinta mitatakseni, kuinka syvät reikäni ovat ja kuinka suuri säteeni on - tämä ei ehkä ole olennaista suuressa mittakaavassa. Todellisuudessa henkilö, joka palkkaa minut lyömään nauloja, tarvitsee vain keinon ripustaa kuvan, eikä minun tarvitse todistaa, kuinka taitava olen naulaamisessa.
Tämä abstrakti mutta elintärkeä kohta voidaan konkreettisesti arvioida: kun harkitaan ominaisuutta, kysy, kävisitkö merkittävästi tyytymättömäksi, jos tuotteessa ei ole sitä, aiheuttaen mahdollisesti lähtöäsi. Esimerkiksi, harkitse Logton nykyistä asemaa ratkaistaakseen autentikointi-, auktorisointi- ja käyttäjä/organisaatiohallintaongelmat. Mitä läheisemmässä suhteessa ominaisuus on näihin näkökohtiin, sitä korkeampi sen prioriteetti. Jos Logto puuttuisi tiettyä ominaisuutta, kuinka pettyneitä käyttäjämme olisivat? Jos vastaus on kyllä, se viittaa siihen, että prioriteetti on korkea ja se on meidän tehtävämme tarjota erinomainen kehittäjäkokemus tähän ongelmaan.
Piilaaksossa korostetaan usein käyttäjätutkimuksen ja mahdollisuuksien arvioinnin käytännöllisyyttä ja kurinalaisuutta. Nämä kaksi näkökohtaa osoittavat, että ominaisuus on tutkimisen ja kehittämisen arvoinen, kun ne tarjoavat positiivisia oivalluksia.
Tämä käsite viittaa matalan roikkuviin hedelmiin, jotka tuovat valtavasti iloa ja hyötyjä vaivattomasti, tehden siitä osan tuotteen persoonallisuutta ja brändiä.
Kaiken analyysin keskellä rationaalinen ajattelu on olennaista, mutta tilan salliminen intuitiolle on myös tärkeää. Jos olet vakuuttunut, että ominaisuus on tulevaisuus, vaikka siitä puuttuu rationaaliset tiedot tai markkinavalidointi, se on tutkimisen arvoinen.
Muut epäselvät ominaisuudet, anna niiden kehittyä ja voimme havaita "signaalit" ajan myötä luonnollisesti.
Tuotekehityksen, yrittäjyyden ja tuotehaastattelujen aikana voit kohdata paljon mieltä askarruttavia kysymyksiä, erityisesti Piilaaksossa, kuten aiemmin mainitsemani aihe, pitäisikö meidän rakentaa tämä ominaisuus?
Vaikka tällaisilla kysymyksillä ei ehkä ole universaaleja periaatteita, ne vaativat harkittua toteutusta ja pohdintaa konkreettisissa tilanteissa. Kuitenkin suurten ja epämääräisten kysymysten purkaminen konkreettisiksi vastauksiksi on taito, jonka rakentajat hiovat urallaan ja supervoima rakentaa hienoja tuotteita.
Toivon, että annetut näkemykset voivat inspiroida lähestymistapaasi tuotteen ajatteluun startup-yrityksessä. Logtossa arvostamme suuresti kehittäjien rakastamien tuotteiden rakentamista. Olemme iloisia saadessamme keskustella ja jakaa näkemyksiämme samankaltaisista aiheista.