Nehaj prodajati funkcije, prodajaj prehod

Povzetek

Spletno mesto vaše stranke SaaS ne odpoveduje, ker je grdo. Odpoveduje, ker nikoli ne odgovori na edino vprašanje, ki je pomembno: zakaj bi prešel? Pri agencijskem delu ne morete za vsak izdelek znova zgraditi edinstvenega modela prepričevanja. Namesto tega uporabite isto revizijo s petimi vprašanji, da najdete sprožilec prehoda za vsak SaaS. Nato ta sprožilec uporabite na vsaki strani: funkcije postanejo dokaz, cene postanejo jasnost, pogosta vprašanja postanejo uničevalec ugovorov, dokumentacija API pa prva zmaga razvijalca. Ta okvir spremeni enkratno prenovo v ponovljiv proces. Rezultat: hitrejša dobava, manj popravkov in strani, ki dejansko pretvarjajo.

Vaša stranka nima težave z oblikovanjem. Ima težavo s prehodom. Kupec že ima orodje, delovni proces in ekipo, ki sovraži spremembe. Ne primerjajo funkcij vaše stranke s praznim listom. Primerjajo bolečino, ki jo povzroči ostati, z bolečino, ki jo povzroči oditi. Naloga spletnega mesta ni, da našteje, kaj izdelek počne. Naloga je, da prehod izgleda lažji in bolj vreden od statusa quo. Če tega ne naredi, je spletno mesto ozadje.

Ko delate v agenciji, to močno občutite. Prevzamete SaaS stranko, ustanovitelj reče »potrebujemo sodobno spletno mesto« in vsi domnevajo, da je rešitev vizualna. Ni. Lahko povlečete nagrajeno zasnovo na napačno sporočilo in pretvarjala bo natanko enako kot staro spletno mesto. Toda ko najdete sprožilec prehoda, sporočilo opravi težko delo. Samo najti ga morate hitro – za vsako stranko, vsako četrtletje, v panogah, ki jih še ne poznate. Zato potrebujete okvir, ki ga lahko uporabite prvi dan, brez trimesečne faze odkrivanja.

Pomislite, kaj prehod vključuje: izvoz podatkov, usposabljanje ekipe, učenje novega vmesnika, spreminjanje navad. Spletno mesto vaše stranke mora ta zaporedje narediti neizogibno. Seznam funkcij tega ne more narediti. Jasna slika življenja po prehodu lahko. Ta slika je sporočilo. Vse ostalo na spletnem mestu jo podpira.

Tukaj je okvir: opredelite prehod. Nato vsako stran prisilite, da se zavzema zanj.

Ugovor	Kaj v resnici ščiti	Kaj storiti namesto tega
»Vsaka stranka je drugačna.«	Vaš strah pred predlogami	Poiščite sprožilec prehoda s pomočjo revizije s petimi vprašanji
»Potrebujemo več posnetkov zaslona.«	Strah pred praznimi razdelki	Zamenjajte posnetke izdelkov z dokazi
»Cenik je svetinja.«	Tesnoba finančnega direktorja	Uporabite jasnost za zmanjšanje cenovnega šoka
»API dokumentacija je problem razvijalcev.«	Ograjevanje razvojne ekipe	Obravnavajte dokumentacijo kot prepričljiv medij
»Pogosta vprašanja so dolgočasna.«	Preobremenjen nabiralnik podpore	Uporabite pogosta vprašanja za zaprtje zadnjih trenutkov dvoma
»Nimamo časa za prilagajanje.«	Perfekcionizem pred dobavo	Zgradite ogrodje, ne snežinke

Uporabite to tabelo kot kontrolni seznam na prvem sestanku. Vsak ugovor na njem ni resnična ovira. Je prošnja za drugačen okvir.

»Vsaka stranka je drugačna« je resnična – in nepomembna

Tukaj je premik: izdelek je drugačen, trg je drugačen, vedenje kupca ni. Kupci želijo tri stvari: »Ali to razumem?« »Ali mu lahko zaupam?« »Ali je prehod cenejši od ostanka?« To je univerzalno. Torej ne standardizirajte oblikovanja. Standardizirajte zasliševanje.

Začnite z revizijo s petimi vprašanji. Izvedite jo na prvem uvodnem klicu. Traja dvajset minut in deluje za vsak SaaS.

• Kdo je uporabnik in kdo je kupec? (Redko sta ista oseba.)
• Kaj počnejo danes namesto uporabe izdelka vaše stranke?
• Kaj je ena sama nadležna bolečina v tem trenutnem delovnem procesu?
• Česa se bojijo, da se bo pokvarilo, če preidejo?
• Katera je najhitrejša »zmaga«, ki bi jo dobili takoj po prehodu?

Sprehodite se skozi dve stranki, da vidite, kako deluje.

Prvi je orodje za upravljanje projektov. Uporabnik je vodja ekipe, kupec je prav tako vodja ekipe. Počne isto kot obstoječe orodje. Bolečina? Nihče ne ve, kdo je lastnik naslednje naloge. Strah? Migracija na stotine projektov in izguba vsega statusa. Hitra zmaga? Nadzorna plošča, ki na prvi pogled pokaže lastništvo nalog. Sprožilec: »Nikoli več ne lovite lastnika naloge.« To je naslov.

Drugi je sledilnik potencialnih strank za nepremičnine. Uporabnik je agent, kupec je posrednik. Bolečina? Podvojene potencialne stranke se pojavijo na treh mestih in dobre postanejo hladne. Strah? Agenti ne bodo beležili podatkov. Hitra zmaga? Samodejno bogatenje iz MLS seznamov, tako da agenti končajo v dveh klikih. Sprožilec: »Nikoli ne izgubite potencialne stranke dvakrat.«

Ista pet vprašanj. Dva različna izdelka. Zdaj imate osrednje sporočilo za domačo stran, prvi odstavek razdelka s funkcijami in zadevo e-poštnega zaporedja. Sprožilec prehoda je obnovljiv vir: vsaka stran, vsak razdelek, vsak podnaslov se lahko zavzema zanj. To je vaša začetna črta.

Isti sprožilec vam daje tudi zemljevid spletnega mesta. Stran, ki pojasnjuje sprožilec, je domača stran. Stran, ki dokazuje sprožilec, je razdelek s funkcijami. Stran, ki odstranjuje strah, so pogosta vprašanja. Stran, ki prikazuje stroške prehoda, je stran s cenami. Nenadoma ima celotno spletno mesto eno pripoved namesto odbora po straneh.

Prav tako lahko izvedete analizo konkurence tako, da istih pet vprašanj zastavite o konkurentovem spletnem mestu. To je poceni način, da na prvem klicu pokažete vrednost. Našli boste konkurentov manjkajoči sprožilec prehoda in vaša stranka postane očitna alternativa.

Kaj če je izdelek lepo imeti, ne pa zdravilo za bolečino? Potem je sprožilec prehoda večji: prihranjen denar, izognjeno tveganje ali pridobljen status. Za orodje za skladnost je sprožilec »izognite se globi.« Za varnostno orodje je sprožilec »prestani revizijo.« Za načrtovalnika objav na družbenih omrežjih je sprožilec »vsak teden pridobite dve uri nazaj.« Revizija ga še vedno najde. Nekateri sprožilci so le manj čustveni.

Posnetki zaslona so dokaz z najnižjo vrednostjo na strani

Vzemite najbolj osamljeno vrstico v tabeli funkcij vaše stranke: »Podpora OAuth 2.0.« Kakšno čustvo sproži? Nobenega. Je element kontrolnega seznama za razvijalca, ki ni kupec. Ko pa stranko prosite za stran s funkcijami, vam dajo zid teh elementov. Napolnite stran s posnetki zaslona in počnete nekaj še pogostejšega: prikazujete izdelek namesto rezultata.

Posnetki zaslona imajo svoje mesto. Dober GIF izdelka pri delu je dokaz. Toda večina posnetkov zaslona so portreti izdelkov. Kupci potrebujejo zgodbo prej in potem. Razdelek s funkcijami je najboljše mesto, da jo poveste. Uporabite formulo Funkcija–Korist–Dokaz (FBP). Poimenujte funkcijo, jo povežite s koristjo, nato jo dokažite z dejstvom, procesom ali majhno predstavitvijo. Brez izmišljenih številk – uporabite opazne rezultate, kot je »deluje z Google Workspace« ali »nastavitev v manj kot minuti.«

Izvirni blok stranke:

• Podpora OAuth 2.0
• Nadzor dostopa na podlagi vlog (RBAC)
• SCIM zagotavljanje

Tri alineje dobaviteljskega žargona. Zdaj vsako prevedite skozi FBP.

Funkcija: Podpora OAuth 2.0.
Korist: Ena prijava za celotno ekipo. Nič več odpiranja nalogov IT.
Dokaz: Deluje z Google Workspace in Microsoft Entra.

Funkcija: Nadzor dostopa na podlagi vlog.
Korist: Dajte skrbnikom, urednikom in gledalcem natanko taka dovoljenja, kot jih potrebujejo.
Dokaz: Izvajalcu dodelite samo ogled v manj kot minuti.

Funkcija: SCIM zagotavljanje.
Korist: Samodejno dodajajte in odstranjujte uporabnike iz vašega sistema za kadrovske zadeve.
Dokaz: Sinhronizira se z Okta in Rippling.

Funkcije se niso spremenile. Prepričevanje se je. Vaša stranka bo rekla: »Toda poslovni kupci pričakujejo, da bodo videli besedi OAuth in SCIM.« Res. Dodajte tehnično podvrstico za razvijalce, ki pregledajo stran. Toda to vrstico postavite z majhnimi črkami pod korist. Prvo občinstvo je kupec, ki se odloči, ali bo rezerviral sestanek. Drugo občinstvo je razvijalec, ki preverja polja. Strukturirajte predstavitev funkcij okoli dokazov, ne okoli posnetkov izdelkov, in nehali boste oblikovati polnilo.

Ko uporabite posnetek zaslona, naj prikazuje rezultat, ne zaslon. Za stranko za upravljanje projektov je posnetek zaslona table, kjer ima vsaka naloga jasnega lastnika, dokaz. Za nepremičninsko stranko je posnetek zaslona enega čistega kontaktnega zapisa s samodejno obogatenimi podatki dokaz. Posnetek zaslona praznega stanja nadzorne plošče je oblikovalska prednost, ne prepričevalna.

Tehnične specifikacije postavite v zložljiv razdelek ali zavihek s sredstvi za razvijalce. Uporabnik vidi korist; razvijalec se lahko poglobi. To ohranja stran čisto in revizorja zadovoljnega.

Dober test za vsako trditev o funkciji: ali bi jo kupec ponovil svojemu šefu? »Ena prijava« je ponovljiva. »Podpora OAuth 2.0« ni. Če stran s funkcijami vaše stranke ne prestane pisarniškega testa, še ni prepričljiva.

Cenovne strani so minsko polje. Prav zato bi se jih morali dotakniti

Slišali boste: »Ne dotikajte se cen. Tako že leta.« V resnici govorijo: »bojimo se.« Zmedena cenovna stran ne ščiti prihodkov; pušča jih. Vaša naloga je, da stran spremenite iz pogajanja o stroških v izjavo o jasnosti.

Začnite tako, da zapišete vprašanja, na katera vaša prodajna ekipa odgovarja vsak teden. Zapišite jih dobesedno. »Ali zaračunavate na uporabnika?« »Kaj se zgodi, če znižam paket?« »Ali obstaja pristojbina za nastavitev?« »Ali lahko preizkusim brez kreditne kartice?« »Kakšna je politika vračil?« Postavite jih na stran. Kupec ne bi smel morati rezervirati klica, da bi izvedel, ali za preizkus potrebujete kreditno kartico.

Nato vzemite tri pakete stranke: Basic, Pro, Enterprise. Preimenujte jih glede na situacijo stranke. Kaj vsak paket dejansko naredi za koga? Solo, Ekipa, Organizacija. Ali Ustvarjalec, Studio, Enterprise. Ime ni okras; je prvi trenutek jasnosti.

Tukaj je konkreten primer preimenovane tabele paketov:

Stari paket	Novi paket	Obljuba
Basic	Solo	Za eno osebo, ki potrebuje preprost delovni proces
Pro	Ekipa	Za ekipo, ki potrebuje sodelovanje in nadzorne plošče
Enterprise	Org	Za podjetje, ki potrebuje varnost, SSO in podporo

Nato zgradite primerjalno tabelo. Prekinite vzorec zlaganja vsake funkcije v vsako vrstico. Vsako vrstico začnite z uporabniškim vprašanjem, na katerega odgovarja. »Koliko uporabnikov?« »Koga lahko povabimo?« »Katere varnostne funkcije dobimo?« Kupec bere tabelo, da poišče »ali sem primeren.« Olajšajte to iskanje.

Nazadnje dodajte pogosta vprašanja o cenah. Odgovorite na grdo vprašanje: »Kaj se zgodi z mojimi podatki, če odidem?« Odgovor napišite kot človek: »Izvozite vse z enim klikom, preden se vaša naročnina izteče. Brez pristojbin, brez zaklepanja.« To je prehodni rušilec zaupanja. Večina strank tega ne bo napisala, ker se zdi kot povabilo k odhodu. Ni. Je dovoljenje za nakup brez strahu.

Vaša agencija ima tu vgrajeno prednost: že ste opravili revizijo s petimi vprašanji, zato poznate strah. Strah postavite v pogosta vprašanja. Če potrebujete predlogo za začetek, je vodnik za konverzijo cenovnih strani predloga.

Ne dovolite stranki, da skrije cene. Stran »kontaktirajte nas« je zid. Prehod potrebuje številko za primerjavo. Če je cena visoka, mora stran pojasniti, kaj je vključeno in zakaj je vredno. Če je cena nizka, jo sidrajte glede na stroške statusa quo. Za orodje za upravljanje projektov je status quo tri ločena orodja: aplikacija za naloge, aplikacija za klepet in preglednica. Cena prehoda ne izgleda visoka, če jo primerjate z mesečnim stroškom vseh treh. Primerjavo naredite na strani eksplicitno.

Ko pišete pogosta vprašanja o cenah, ne uporabljajte jezika dobavitelja. Recite »vi« in »vaši podatki.« Cenovna stran, ki ves čas uporablja »nudimo, zagotavljamo«, deluje kot brošura podjetja. Obrnite na »lahko, vaša ekipa.« To je prehod, ki se zgodi v slovnici.

Pogosta vprašanja o cenah lahko preizkusite na enak način kot vse ostalo: preberite jih na glas. Če bi se neznanec za mizo sprostil, je dobro. Če bi dvignil roko za prodajalca, ste dodali trenje.

Dokumentacija, ki jo ignorirate, zapira (ali ubija) posle

Tukaj je razvijalka pri prenosniku. Ocenjuje API vaše stranke. Njen šef je vprašal: »Ali se lahko integriramo s tem?« Želi eno stvar: dokaz, da njena ekipa ne bo zapravila tedna. Ne začne z referenčno dokumentacijo. Začne s hitrim začetkom.

Podjetja, kot so Stripe, GitHub in Twilio, postavljajo standard za API dokumentacijo. Skrivnost ni v tem, da vsak končni dokumentirajo lepo. V tem, da poskrbijo, da prva izvedba traja pet minut. Pokažejo majhen rezultat, ki je videti kot uspeh. To je sprožilec prehoda za razvijalca: takojšen, konkreten napredek.

API dokumentacija vaše stranke je prva stran, ki jo tehnični kupec prebere po domači strani. Če se bere kot telefonski imenik, posel tiho umre. Dokumentacija je marketinško sredstvo, ne tehnična nadloga. Zato naredite to:

Hitri začetek postavite pred vse ostalo. Čas za primer. Vaša stranka gradi API za avtomatizacijo dokumentov. Referenca je gosta tabela vsebine, ki se razteza čez na tisoče vrstic. Razvijalec pristane, zagleda »Avtentikacija« in postane malodušen.

Preoblikujte vrh dokumentacije:

1. Napišite opis v treh stavkih v navadni angleščini. »Pošljite pogodbo, dobite izvršeno kopijo. Ta API spremeni predloge in podatke v podpisane PDF-je.«
2. Prilepite primer kode za kopiranje in lepljenje, ki kliče končno točko peskovnika. Pokažite prvi odziv JSON, ki dokazuje uspeh.
3. Dodajte en primer uporabe, »Računi, ki se sami sestavijo,« in povežite posebne končne točke, ki so vključene.

Celotno referenco premaknite spodaj. Razvijalec, ki kopira prvi odrezek, postane notranji zagovornik. Zagovornik zaprosi za varnostni pregled, ne za zavrnitev. Vaša stranka pristane pred prodajnim klicem. Vodnik za API dokumentacijo vas vodi skozi isti proces.

Primer uporabe je obljuba s potjo. Za stranko za avtomatizacijo dokumentov napišite »Računi, ki se sami sestavijo: pošljite številko naročilnice in v enem klicu dobite oblikovan račun, postavke in PDF.« To ni dokumentacijska stran; je prodajna stran, ki vsebuje kodo.

Vključite vdelani API ključ za peskovnik. V trenutku, ko lahko razvijalec prilepi in vidi uspeh, prehod postane resničen. Brez prodajnega klica.

Dokumentacijska stran hrani tudi SEO. Razvijalci iščejo natančna sporočila o napakah in imena integracij. Napišite strani za te poizvedbe: odstavek za vsako kodo napake, stran za vsako integracijo. Tako dokumentacija postane kanal.

Uporabite stalno stransko vrstico z gumbom »poskusi zdaj«. Dodajte iskalno vrstico, ki indeksira primere kode. Bolj gladko kot je iskanje, bolj kompetentno podjetje izgleda. In ne pozabite na kratek video, krajši od 90 sekund, ki prikazuje delujoč primer, ne pregled podjetja.

Pogosta vprašanja niso vsebina za podporo. So konverzija za zadnjo oviro

»Nihče ne bere pogostih vprašanj« – to boste slišali, dokler se ne spomnite, kdo jih bere: kupec v tihi sobi, ki okleva postaviti vprašanje. Pogosta vprašanja so stran, kjer se posli sklepajo zasebno. Tako jih obravnavajte.

HubSpot, Slack in Zendesk to delajo prav. Njihovi razdelki s pogostimi vprašanji in pomočjo so organizirani, iskalni in jedrnati. Ta struktura je bistvo. Signalizira usposobljenost. Iskalna pogosta vprašanja dajo kupcu misliti: ti ljudje so razmišljali o mojem problemu.

Tukaj je najcenejša izboljšava, ki jo lahko danes naredite na spletnem mestu katere koli stranke: reorganizirajte obstoječa pogosta vprašanja v štiri vedra glede na fazo nakupa: Začetek, Cene in plačila, Varnost in skladnost, Prehod in migracija. Nato prepišite en odgovor za vsako vedro.

Naredimo vedro prehoda. Trenutni odgovor na »Kako težka je migracija?« pravi: »Naše orodje za uvoz podpira CSV in API.« To je seznam funkcij. Prepišite ga kot obljubo plus seznam korakov:

»Vaše podatke bomo uvozili namesto vas. Pošljite CSV, izvedemo suhi zagon, vi preverite vzorec, mi pa prestopimo v 30-minutnem oknu. Če je karkoli narobe, takoj vrnemo nazaj.«

Zdaj primerjajte dva odgovora. Kateri sklene posel? Prvi opisuje mehanizem; drugi opisuje varen proces. To je ista struktura kot stran s funkcijami: korist plus dokaz.

Pojdite dlje: vzemite vsako vprašanje, na katero podpora odgovori dvakrat na teden, in odgovor napišite, preden se odpre naloga. To je neusahljiv vir vsebin za vstopne strani. Ko pogosta vprašanja prenehajo biti odlagališče in postanejo orodje za prepričevanje, celotna zgodba ostane poenotena. Del pristopa od znotraj navzven, ki ga uporabljate za vse ostalo.

Organizirajte z mislijo na iskanje. Iskalna pogosta vprašanja, ki najdejo odgovor v enem pritisku tipke, delujejo kot funkcija izdelka. Točno to je signal usposobljenosti, ki ga želite.

Ne prisilite kupcev, da odpirajo ločen center za pomoč. Pogosta vprašanja postavite na stran, ki je sprožila vprašanje. Če se vprašanje o ceni pojavi na cenovni strani, tam odgovorite. Če se vprašanje o varnosti pojavi na cenovni strani, odgovorite tudi tam. Odgovor sodi na točko dvoma.

Vedro varnosti je tam, kjer se IT odloči, ali bo orodje blokiral. Na vprašanja, kot je »Kje so shranjeni podatki?«, odgovorite s posebnostmi. Če rečete »v EU,« povejte regijo. Če rečete »šifrirano v mirovanju,« poimenujte standard. Jedrnat odgovor je močnejši od povezave do bele knjige.

Vsak odgovor na pogosta vprašanja mora biti čim krajši in se končati z naslednjim korakom: »Prijavite se z računom peskovnika« ali »Pogovorite se s podporo.« Odgovor brez naslednjega koraka je slepa ulica.

Ni časa? Zgradite ogrodje, ne snežinke

Zadnji ugovor je tisti, ki ga verjetno čutite prav zdaj: »Ampak imam štiri stranke in rok v ponedeljek.« Pošteno. Če vsak projekt obravnavate kot portret po meri, boste vedno v časovni stiski. Namesto tega zgradite en sam večkrat uporaben rezultat: Zapis o prehodu. Izpolni se v 90 minutah in oriše vsako stran.

Zapis o prehodu – ena stran, šest vrstic:

1. Delitev uporabnik/kupec: kdo se pojavi, kdo plača.
2. Trenutno vedenje: kaj počnejo danes namesto tega.
3. Ena sama bolečina: en stavek, nadloga.
4. Strah: česa se bojijo, da se bo pokvarilo pri prehodu.
5. Hitra zmaga: prva vidna izboljšava po prehodu.
6. Dokaz: logotipi, rezultati ali varnostne drže, ki odstranijo strah.

Prinesite to na prvi uvodni klic. Izpolnite ga, ko postavljate pet vprašanj. Ko se vrnete za svojo mizo, imate okvir sporočila. Naslov domače strani je hitra zmaga. Uvod strani s funkcijami je bolečina. Srednji stolpec cenovne tabele je kupec. Pogosta vprašanja so seznam strahov. Hitri začetek API dokumentacije je hitra zmaga za razvijalce.

To ogrodje ne naredi vsakega spletnega mesta enakega. Naredi vsako spletno mesto prepričljivo na enak način. Še vedno oblikujete glas vsake stranke, vendar nehate premalo oblikovati sporočilo. Če je sporočilo že določeno, lahko prvi osnutek vsake strani naredite v enem dnevu. Pravi izdelek agencije je proces, ne pik.

Tukaj je premik: ne prenavljate več spletnih mest. Repozicionirate jih. In ker okvir prehoda preživi v panogah, lahko zaračunate strategijo, jo dostavite v ponovljivi obliki in predate sredstva, ki dejansko pretvarjajo. Vaš naslednji začetek bi se moral začeti z revizijo s petimi vprašanji, ne z desko razpoloženja.

Uporabite zapis za zgodnje postavljanje pričakovanj strank. Ustanovitelj vidi, da spletno mesto ni umetniški projekt; je prepričevalni dokument. To prepreči povratno informacijo »samo naredi, da bo bolj izstopalo« in pogovor usmeri k rezultatom. Zapis delite z marketinško ekipo stranke, da lahko kasneje pišejo nove strani, ne da bi znova izumljali sporočilo.

Ko predstavite spletno mesto, začnite z zapisom o prehodu, ne z oblikovanjem. Stranke bolj odobravajo strategijo kot estetiko. Dobili boste manj prošenj »lahko povečamo logotip«, ker ste jim dali razlog, da stran ocenjujejo glede na sporočilo.

Prehod je strategija. Vse ostalo je dekoracija.

Iz tega vzemite eno stvar: ne naročajte nove prenove, dokler ne odgovorite na vprašanje o prehodu. Večina spletnih mest SaaS odpoveduje, ker obiskovalci nikoli ne najdejo razloga, da bi zapustili svoj trenutni delovni proces. Spletno mesto ne odpoveduje, ker je logotip premajhen ali gradient zastarel.

Vaš naslednji uvodni klic bi morala biti revizija s petimi vprašanji. Če ustanovitelj ne more artikulirati prehoda, ga priganjajte. Če ga lahko artikulirate, ima vsaka stran svojo nalogo: strani s funkcijami ga dokazujejo, cenovne strani ga upravičujejo, strani s pogostimi vprašanji ga branijo, dokumentacija API pa ga prikazuje. Dostavili boste boljši izdelek hitreje. In imeli boste okvir, ki ga lahko uporabite pri vsaki stranki, za vedno.

Spletno mesto, zasnovano okoli prehoda, se sčasoma tudi izboljšuje. Zdaj imate hipotezo – sprožilec – in jo lahko preizkusite s termografijo, posnetki sej ali A/B testi. Okvir spremeni prenovo iz dogodka v eksperiment.

Ne potrebujete 40-stranske strategije. Potrebujete šest vrstic in pripravljenost, da rečete ne stranem, ki ne služijo prehodu. Ta jasnost je tisto, za kar vam stranke plačujejo.

Nehajte prodajati funkcije. Prodajajte prehod. To je vsa strategija.