Iga klient soovib kogukonda: ulatuse määramise juhend enne ehitamist

Kokkuvõte

Esimesel käivitamiskõnel ütlevad peaaegu kõik liikmesuskliendid: “me tahame kogukonda” – ja see fraas võib vaikselt laiendada projekti portaali, millel on foorumid, sündmused, kursused ja otseülekannete ruumid, mida keegi käivitamisel ei kasuta. See artikkel annab agentuuridele korratava ulatuse määramise vestluse, et muuta see ebamäärane soov väikeseks ja käivitatavaks liikmesussaidiks. See algab lausetestiga (“liikmed maksavad, sest nad saavad ___”), sunnib kliendi valima ühe ärimudeli, lükkab kogukonna funktsioonid edasi, kuni on reaalne publik, ja käsitleb iga funktsioonisoovi kui muudatustaotlust. Artikkel sisaldab ühte töötatud näidet kliendist, kes tahtis täisväärtuslikku kogukonda ja käivitas selle asemel otsitava arhiivi ning igakuise otse Q&A. See hoiatab ka kaasamise lubamise eest: te võite pakkuda ust, kuid te ei saa sundida inimesi sellest läbi minema. Tulemuseks on tootesari, mitte päästeoperatsioon, ja kliendid, kes tänavad teid selle eest, mida te keeldusite ehitamast.

Esimesel käivitamiskõnel ütleb klient: “Me tahame kogukonda.” Sa noogutad, tipid sõna oma märkmetesse ja tunned, kuidas su teekaart vaikselt kahekordistub. Sest “kogukond” võib tähendada foorumit, privaatset vestlusgruppi, maksumüüri, kursuste raamatukogu, sündmuste sarja, liikmete kataloogi või kõike eelnevat. Kui lased sellel tähendada kõike eelnevat, kulutad kvartali asjade ehitamisele, mida keegi ei kasuta, ja esitad seejärel kliendile arve selle eest, et vaatasid, kuidas nad seda ei kasuta. Lahendus pole nutikam platvorm. See on ausam vestlus, mida peetakse iga kord samamoodi, et su järgmised seitse klienti ei muutuks igaüks ainulaadseks eriprojektiks.

See kirjatükk on üles ehitatud küsimustele, millele me selle töö juures tegelikult pidevalt vastame. Mitte “millist tööriista peaksime kasutama” – see tuleb hiljem – vaid küsimused, mis otsustavad, kas projekt jõuab õigeaegselt välja, jääb kasumlikuks ja jätab kliendile tunde, et teadsite, mida teete.

“Me tahame kogukonda” – mida me tegelikult müüme?

Paluge kliendil lõpetada üks lause enne, kui üldse mainite platvorme: “Liikmed maksavad meile, sest nad saavad ___.” See on kõik. Kui nad ei suuda tühja kohta täita millegi konkreetsega, pole te valmis platvormi valima, lehte visandama ega hinda pakkuma. Kogu liikmesussait – maksumüür, tasemed, funktsioonid, mille te sisselülitatuks jätate – on lihtsalt selle vastuse kohaletoimetamise mehhanism.

See, mida enamik kliente “kogukonda” öeldes tegelikult ostab, jaguneb tavaliselt nelja kategooriasse. Kui me ulatust korratavalt määrame, surume otsuse ühte neist:

Mille eest liikmed maksavad	Osa, mille te tegelikult ehitate	Osa, mille võite julgelt edasi lükata
Sisu (kursused, arhiivid, tööriistad)	Piiratud juurdepääsuga raamatukogu, maksevoog, põhipleier	Otseülekannete ruumid, sündmuste kalendrid, sertifikaadid
Juurdepääs (toode, teenus või tööriist)	Liikme sisselogimine, õigused, konto piirangud	Avalik foorum ja sotsiaalvoog
Ühendus (kaaslased, vastutus, võrgustik)	Üks aruteluruum, profiilid, kutsed	Täismahus kursuste platvorm, sisu ajastatud väljastamine, sertifikaadid
Staatus (siseringi kuulujad, varajane juurdepääs, eksklusiivsed soodustused)	Astmeline juurdepääs, märkide/siltide loogika, lihtsad soodustused	Foorumid, kasutajate loodud sisu, otseüritused

Tabel on ulatuse määramise petuleht, mitte menüü. Klient saab ühe kategooria. Kui nad üritavad kahte liita, peaksite käe tõstma ja aeglustama, sest teie kulud on just kasvanud. Lõks on teha kõik neli ühe kliendi jaoks ja nimetada seda “kaasatud kogukonnaplatvormiks”. See pole toode; see on portaal ja portaalid ei käivitu õigeaegselt.

See tabel on tahtlikult väike. Hetkel, kui lubate liikmesussaidil olla korraga neli asja, olete lõpetanud toote ehitamise ja hakanud juhtima väikest meediaettevõtet. Klient tahab harva meediaettevõtet; nad tahavad korduvat tulu. Hoidke ulatus piisavalt väike, et tulumudel oleks avalehelt nähtav.

Kui klient ütleb samas lauses “kursus” ja “foorum”, küsige, kumb arveid maksab. Kui vastus on “mõlemad”, näete tegelikult klienti, kes veel ei tea, mida nad müüvad. Mõned saavad sellest ulatuse määramise käigus aru ja tulevad selgema pakkumisega tagasi; need, kes ei saa, ütlevad teile, et nad pole valmis. Seda on kasulik teada saada enne ettepaneku kirjutamist, mitte pärast.

Aga nad on juba öelnud “kogukond” sada korda

Siin on vastupidine mõte ja see pole tagasihoidlik kiitlemine: enamik liikmesussaitidest ei peaks üldse kogukonnafunktsioonidega käivituma. “Kogukond” ei ole funktsioon. See on käitumine, mis tekib siis, kui väike rühm inimesi saavad üksteiselt korduvat väärtust, ja ükski platvorm ei suuda seda nõudmisel toota. Sõna on muutunud “tellimistulu” asendajaks, mistõttu iga klient seda ütleb. Olete neile kasulikum, kui tõlgite selle tagasi.

Viige läbi kogukonna reaalsuskontroll enne, kui lasete ulatusel kasvada. Esitage kolm küsimust:

1. Esimesel nädalal, millist täpset käitumist te soovite, et uus liige teeks? (Mitte “kaasa lööma” – “postita tutvustus”, “jäta kommentaar”, “lõpeta esimene õppetund”.)
2. Kes teie meeskonnast veedab esimese kuu jooksul aega selles ruumis, vastates, suunates ja koristades segadust?
3. Kas on juba olemas käputäis inimesi, kellel on see probleem ja kes üksteist tunnevad, või loodate, et võõrad muutuvad meeskonnaks, sest veebisait on olemas?

Kui kõik kolm saavad ebamäärased vastused, ei ehita te kogukonda; te ehitate tühja ruumi ja nimetate seda arhitektuuriks. Praktiline käik on lükata edasi kõik kogukonnafunktsioonid ja käivitada selle asemel liikmesuse skelett. Aruteluruumi saate alati hiljem lisada ja kui lisate selle rühmale, kellel on juba põhjus kohale tulla, on tal võimalus toimida. Kogu küsimus väärib pikemat käsitlust – kogukond peaks tulema pärast seda, kui teil on päris liikmed – kuid ühelauseline versioon on: ärge ehitage amfiteatrit enne, kui publik on olemas.

Mis on kõige väiksem asi, mis võiks töötada?

Kui olete pakkumise klassifitseerinud, kujundage käivitus skeletina. Üks maksevõimalus, üks tase, üks piiratud juurdepääsuga vara, üks suhtlusvoog. Võtke oma platvormi funktsioonide loend ja lülitage kõik muu välja. Jah, platvorm suudab teha otsevideo ruume, liikmete profiile, sündmuste haldust ja analüüsiarmatuure. See ongi probleem.

Klient tuli meie juurde sellega, mida nad nimetasid täielikuks kogukonna visiooniks oma B2B SaaS toote jaoks. Nad olid rääkinud foorumitest, sündmuste kalendrist, ressursiraamatukogust ja “liikmete esiletõstmiste” sektsioonist. Ulatuse määramise käigus panime nad lõpetama lause: “Liikmed maksavad, sest nad saavad ___.” Nende vastus oli otsitav arhiiv asutaja nõuannetest pluss igakuine otse Q&A. Nii et selle me käivitasimegi. Pole foorumit, pole liikmete profiile, pole sündmuste kalendrit. Varsti pärast seda kasutati arhiivi, Q&A-l olid püsikülastajad ja klient küsis privaatset arutelugruppi, sest liikmed rääkisid juba omavahel väljaspool toodet. Grupp ehitati pärast seda, kui tal oli põhjus eksisteerida. See on järjekord, mis töötab.

Kui oleksime ehitanud täieliku visiooni, oleksime käivitanud hilja, rohkemate liikuvate osadega ja ilma võimaluseta öelda, milline neist tegelikult harjumuse lõi. Arhiiv võis osutada reaalsele käitumisele; otse ruum, mida kunagi ei kasutatud, oleks olnud lihtsalt arve. Õppetund on igav, kuid usaldusväärne: mida väiksem on käivitus, seda tõenäolisemalt suudab klient teile öelda, mis tegelikult töötab. Saledam toode annab teile ka ruumi, et järgmist asja hästi teha – lisada tase, avada foorum – teadliku muudatustaotlusena, mitte tormaka lisana, mis käivituskuusse surutakse. Kui otsite korratavat viisi tasemete ja tulustruktuuri üle mõtlemiseks, on see lugu liikmesuse tasemed korduva tulu jaoks, kuid ulatuse määramine tuleb enne.

Mis juhtub, kui taotlused kuhjuvad?

Olgem ausad, kuidas enamik liikmesuse projekte sureb: mitte oskamatuse, vaid “veel ühe asja” tõttu. Klient näeb konkurendi kogukonna demot ja tahab sarnast funktsiooni. Õige vastus pole “jah” ega “ei” – see on “lisame selle edasilükatud nimekirja”.

Muutke edasilükatud funktsioonide nimekiri oma projekti esmaklassiliseks tarnitavaks. Pange see ettepanekusse, hoidke seda nähtaval ja lisage sinna iga ulatusest väljaspool olev taotlus. Andke igale üksusele käivitustingimus. Mitte “kunagi”, vaid “see väljub siis, kui 200 aktiivset liiget on ruumis olnud kuu aega” või “kui klient pühendab kaks tundi töötajate aega nädalas selle modereerimiseks”. Te ei ole raske; te annate funktsioonile põhjuse eksisteerida.

Nii te lõpetate sama liikmesussaiti iga kliendi jaoks uuesti ehitamast: kohtledes iga uut klienti kui juba saadetud skeleti konfiguratsiooni, millel on nimekiri asjadest, mida te teadlikult ei ehitanud. Kui funktsioon on edasilükatud nimekirjas, on see tulevane projekt, mis on ka tulevane tulu. Esitage seda nii ja klient nõustub tavaliselt.

Kuidas hoida klienti süüdistamast meid tühjas foorumis?

Peate ootused seadma selle kohta, mida saate ja mida ei saa kontrollida, varakult ja kirjalikult. Saate tarnida maksevoogu, piiranguid, e-kirja automaatika ja disaini. Te ei saa tarnida seda, et inimesed otsustavad omavahel rääkida. Kliendi “kaasamisprobleem” ei ole ehitusprobleem; see on operatiivprobleem ja see kuulub nende sülle.

See on oluline, sest kliendid hakkavad vaikselt küsima, miks “kogukond” on kolm nädalat pärast käivitamist vaikne. Kui seate piiri algusest peale, saate pidada kasulikku vestlust stiimulite ja külvamise üle. Kui te ei sea, peate siluma platvormi, mis pole katki. Praktiline viis selle vormistamiseks: lisage oma hoolduslepingusse eraldi rida “kogukonna majutamine ja külvamine” või andke kliendile külvamise kontrollnimekiri, mis elab nende projekti käivitamisel. Mõte on teha tööjaotus selgeks. Tööriist ei ole hoidmisstrateegia; liikmesussaitide müüdid on tavaliselt süüdlased, kui inimesed ootavad, et platvorm teeb nende müügi nende eest.

Kui nad siiski insisteerivad kogukonnal, mida me sisse lülitame?

Kui klient läbib reaalsuskontrolli ja tõesti opereerib kogukonda, lülitage sisse täpselt üks aruteluvorm. Mitte kolm. Foorum on teemaline, otsitav ja asünkroonne; otse ruum on vahetu, kaduv ja personalinäljas. Te ei saa mõlemat väikese meeskonnaga hästi modereerida ja selle proovimine õpetab teie kliendile, et “kogukond” tähendab pidevat tegevust, mis on standard, mida te ei tohiks lubada.

Praktiline reegel: üks ruum, üks vorm, üks nimetatud moderaator. Valige vorm, mis sobib käitumisega, mille te reaalsuskontrollis tuvastasite. Kui soovitud käitumine on “esita küsimus ja saa vastus”, alustage foorumiga. Kui see on “tule teisipäeval keskpäeval väljakutsetest rääkima”, alustage otseüritusega. Seejärel seadke kerge mõõdik esimeseks üheksakümneks päevaks: mitte liikmete koguarv, mitte registreerunute arv, vaid nende liikmete arv, kes tegid sihtkäitumist vähemalt kaks korda. Kaks tegevuse mainimist on piisav, et teada, kas ruum on elus või muuseum.

Kuidas seda hinnastada nii, et see oleks tootesari, mitte päästeoperatsioon?

Muutke avastusvestlus ise arveldatavaks tooteks. Looge fikseeritud tasuga liikmesussaitide seadistamise pakett, mis sisaldab ulatuse kõnet, skeleti ehitust (jah, tõesti), makse konfigureerimist ja ühte vooru muudatusi. Kõik, mis on sellest kaugemal – kogukonna disain, kohandatud funktsioonid, modereerimistunnid, integratsioonid – on eraldi töö kirjeldus. See on kogu nipp. Kui pakute iga valikulise funktsiooni muudatustaotlusena, õpib klient äkitselt prioriseerima. Kui pakendate kõik ühte kasvavasse hinnangusse, õpetate neile, et suurem ulatus on tasuta.

Korratav protsess näeb välja selline: küsimustik, mille saadate enne kõnet, üheleheküljeline töö kirjeldus fikseeritud hinnaga, ehitusgraafik, mida teie meeskond on varem teinud, ja mall edasilükatud funktsioonide nimekirja jaoks. Peaksite suutma kliendile öelda käivitamise kuupäeva enne, kui disainimeeleoluplaat on olemas. Saate ka parema vestluse: klient näeb, mida miinimum maksab, mida kogukonna lisad maksavad ja mida nende enda aeg maksab. Kui nad keelduvad skeleti eest maksmast, saate sellest teada enne, kui see haiget teeb.

Osa, mida keegi ei taha kuulda

Iga liikmesussait on panus korduvale käitumisele. Platvorm on lihtsalt ümbrik. Teie töö, inimesena, kes ehitab seda paljudele klientidele, on lasta ümbrik adresseerida ja tembeldada, veendudes samal ajal, et keegi pole registreerunud elavat etendust käsitsi tarnima. Te ei saa kogukonda juhtuma panna. Saate luua tingimused, valida väikseima võimaliku versiooni ja anda kliendile selge nimekirja sellest, mida te ei ehita.

See viimane osa on teie tegelik väärtus. Klient palkas teid, sest nad ei näe, mida välja jätta. Nii et jätke see nende eest välja – enesekindlalt, tahtlikult, kirjalikult. Kui olete ulatuse määranud, muutub tarne peaaegu igavaks: liikmesussaitide käivitused jõuavad tegelikult välja, kui need on väikesed ja otsused tehti ette. Tühjad foorumid ja laialivalguvad kohandatud portaalid on kallid. Skeleton, õigeaegselt, on väärt palju rohkem kui “võimas kogukonnaplatvorm”, mis kunagi päriselt ei käivitunud.