Лекція 7 - Як створити продукт, який полюблять користувачі (Кевін Хейл)

Отже, коли я говорю про створення
продуктів, які були б до

вподоби користувачам, я
конкретно маю на увазі:

«Як нам створити продукт, який мав би
пристрасно налаштовану міцну

клієнтську базу, продукт, який користувачі
хотіли б бачити успішним,

так само, як і компанію, яка
стоїть за його створенням?».

Зараз нам доведеться розібрати
великий масив інформації,

тому намагайтеся робити якомога менше
записів – краще намагайтесь слухати.

Я надішлю посилання на
слайди через свій Твіттер,

і перейшовши за цим посиланням,
ви зможете їх коментувати.

Тому ставте ваші питання, і якщо
ми до них не дійдемо,

то я відповім
на них після лекції.

Що ж, друзі, за останні декілька
тижнів ви багато чули про

зростання, але на мою думку,
зростання – це доволі просто.

Це взаємодія двох понять або змінних:
показника конверсії та «текучості» .

Розрив між цими показниками
досить чітко вказує

на те, як швидко
ви будете зростати.

Більшість людей, особливо ділових,
намагаються розглядати

цю взаємодію у вкрай математичний,
обчислювальний спосіб.

Сьогодні я хочу поговорити про
це у більш людський спосіб,

тому що коли у стартапі ви взаємодієте
зі своїми користувачами,

на початковому етапі ця взаємодія є
досить тісною, і я вважаю,

що існує інший спосіб розгляду
цього, з точки зору того, як

ми створюємо наші продукти.
Ми розглянемо багато

прикладів на цю тему а також
їх гарне втілення у життя.

Моя філософія, пов‘язана з усім,
що я викладаю про стартами

полягає в тому, що найкращий шлях
заробити мільярд доларів –

зосередитись на цінностях,
які допомагають тобі отримати

той самий перший долар, залучити
того самого першого користувача.

Якщо ви це засвоїте, все
решта вийде саме по собі.

Це, так би мовити, питання віри.

Я став партнером в YC, ставши
випускником (їхньої) програми.

Я брав участь в програмі взимку 2006 року
(це була лише друга програма)

і створив продукт під назвою
Wufoo. Wufoo – це онлайн

конструктор форм, що допомагає
створювати форми зворотного зв’язку,

онлайн-опитування, а також
найпростіші форми оплати.

Загалом, це СУБД-додаток,
який виглядає так, ніби його

дизайн розробила компанія Fisher-Price.

Однак цікаво те, що через
те, що додаток був справді

простим у користуванні, ми мали
клієнтів в усіх галузях та на

ринках, які тільки можна
собі уявити, включаючи

більшість компаній
зі списку Fortune 500.

Я керував компанією на протязі
п’яти років, коли в 2013 році

нас придбала компанія Survey
Monkey. На той час ми були

досить цікавим придбанням.
Тоді ми були лише командою з

десяти людей і в той час, коли ми
отримували фінансування тут,

в Кремнієвій долині через
компанію Y Combinator, компанія

фактично керувалась із Флориди.

У нас не було офісу,
всі працювали з дому,

і ми цікаво відрізнялися
від інших компаній.

Кожна цятка тут
представляє собою стартап,

що вийшов на ІРО або
був кимсь придбаний,

цятка далеко ліворуч – це ми.

Нижня частина вказує на суму
фінансування, яку вони отримали,

а вертикальна вісь – це
теперішня вартість компанії.

Як ви бачите, середній стартап
отримує 25 млн. доларів

інвестицій і повертає
своїм інвесторам 676%.

У Wufoo всього було
інвестовано 118 тис. доларів,

повернення склало 29,561%.

Таким чином, багато людей
цікавиться чим Wufoo

відрізняється від інших компаній,
або чим відрізняється

наше керівництво компанією.
Багато уваги ми приділяли

самому продукту. Нам не було
цікаво розробляти програмне

забезпечення, яким люди
би просто користувались, яке б

нагадувало, що ти працюєш
в офісі, тому що це по своїй суті

лише робота з базою даних.

Ми хотіли отримати продукт,
який би люди полюбили, з

яким хотіли б мати справу,
ми просто фанатіли від того,

як ми підійшли до цієї ідеї і майже
підвели під неї наукову базу.

Тому ми сказали собі: «Відносно
стартапів з точки зору

створення продуктів, які полюблять
користувачі, цікавим є наступне:

кохання та інші щирі почуття –
те, чого нам дуже складно

добитися у реальному житті.
А у стартапі ми маємо

добиватися їх на більш
масштабному рівні».

Тому ми вирішили
розпочати з питання:

«Як працюють відносини у
реальному світі, і як ми можемо їх

застосувати при веденні
бізнесу та створенні продукту.”

Ми з вами розглянемо
дві наступні метафори:

залучення нових користувачів,
немов ми намагаємося

ходити з ними на побачення,
та існуючих користувачів,

немов ми з ними є
щасливим подружжям.

Коли йдеться про побачення,
багато з того, що

ми виявили, стосується
перших вражень.

Кожен з вас часто розповідає про початок
нового етапу в ваших взаєминах.

Ви розповідаєте мені про
ваш перший поцілунок,

як ви познайомились, як освідчились.

Це ті речі стосовно взаємин,
про які ми говоримо

знову і в основному
передаємо їх з вуст у вуста.

Так само відбувається
і з компаніями.

Люди – створіння, які постійно
будують відносини.

Ми не в змозі не створювати
та не одушевляти те, з чим ми

знову і знову взаємодіємо.
Чи то автомобілі, якими ми

кермуємо, чи одяг, який ми
носимо, чи інструменти або

програмне забезпечення, які ми
використовуємо, врешті-решт

ми надаємо їм характеристики,
відзначаємо їх індивідуальність,

а також очікуємо, що ці речі
будуть певним чином

поводитися – у такий спосіб
ми взаємодіємо з ними.

Перші враження є важливими для
початку будь-яких відносин,

тому що про них ми говоримо
знову і знову, чи не так?

Є щось особливе в тому, як ми ставимося
до історії про початок наших відносин.

Наведу приклад.

Якщо ви на першому побаченні
з кимось, гарно вечеряєте,

але помічаєте, як ваш
візаві копирсається в носі,

ви напевне не підете на ще
одне побачення з ним.

Але якщо ви перебуваєте у шлюбі
з кимось на протязі 20-30 років

та бачите, як він чи вона,
розвалившись у кріслі,

«шукає золото», ви не
телефонуєте негайно адвокату

(ви розумієте, що я маю на увазі) і не кажете:

«У нас тут проблема, вам потрібно
готувати документи на розлучення».

Ви знизите плечима й скажете:
«проте у нього золоте серце».

Таким чином, подібна первісна
взаємодія характерна тим,

що можливість не пройти
далі є вкрай високою.

В роботі з додатками, а також
у більшості онлайн-продуктів

перші враження, як правило,
є досить очевидними: можна

помітити, на що багато компаній
звертають увагу, з точки

зору того, над якими (стандартними)
задачами працюють їх

спеціалісти з маркетингу.
На мою ж думку, люди, які

насправді добре знайомі з
продуктом, знаходять багато

перших моментів, які можна зробити
такими, що запам’ятовуються:

перший лист, що прийшов вам
на пошту, що відбувається

під час вашого першого входу в систему,
посилання, реклама,

перший раз, коли ви стикнулися
зі службою підтримки.

Все це – можливості
принадити клієнта.

Тож, якими ми збираємося
зробити ці перші моменти?

Насправді, ми запозичили
цю концепцію в японців.

Взагалі-то в них є два вирази для відповіді
на питання «чи це якісний продукт?»

після того, як вони ним скористалися.

Ці два вирази є atarimae hinshitsu
та miryokuteki hinshitsu.

Перший означає «притаманна якість»,
тобто фактично функціональність.

Другий означає «приваблююча» якість.

Візьмемо, наприклад, ручку.

В неї є miryokuteki, якщо вага ручки,
те, як з неї витікають чорнила,

як люди сприймають написане цією
ручкою, приносить задоволення

як тій людині, хто користується
ручкою, так і тим, хто

сприймає результат та підносить
оцінку продукту на новий рівень.

Почнемо з деяких прикладів.

Це посилання на вхід в Wufoo,
на ньому є динозавр, і мені

здається, що він прикольний.
У нього є додаткова функція:

коли ви наводите на нього,
виникає спливаюча підказка,

що не містить інформації про
те, як увійти в систему, або про

те, що відбудеться далі –
там просто написано: «RARRR!».

На ранньому етапі роботи з
юзабіліті сайту, ми помітили, що

цей ефект змушує людей
посміхнутися, без жодних зусиль,

при чому абсолютно всіх.
Думаю, дуже часто, коли ми

оцінюємо продукти, ми
не замислюємося над тим,

які емоції з’являються на
обличчях тих, хто з цим взаємодіє.

Це стартова сторінка Vimeo, і вона
здалась мені особливо привабливою.

Вона дає зрозуміти, що коли ви
зберетеся відправитися з

ними у подорож, то вона буде
незвичайною – це їх стиль.

Якщо ви шукатимете слово
«пукати», під час прокручування

вгору та вниз, виникають
звуки схожі на пукання.

Тут є щось несхоже на інші сайти,
немов він взаємодіє з вами,

він трохи чарівний, і цим і відрізняється.
Цим хочеться поділитися з іншими.

Необов’язково робити це
за допомогою дизайну.

Це форма реєстрації на Cork'd, соціальної
мережі для любителів вина.

На ній написано: «Адреса електронної
пошти – це також

ваше ім’я під час входу в систему, і
вона має бути справжньою.

Ім’я – це те, як вас
називає ваша матуся.

Прізвище – те, як вас звуть люди,
з якими ви служили в армії.

Пароль – це те, що ви самі
в змозі запам’ятати,

але інші не зможуть підібрати.

Підтвердження паролю -
введіть його ще раз,

вважайте це просто за тест».

Англійською звучить як вірш.

Заповнюючи форму ви відчуваєте,
що люди, які стоять за

цим сайтом вам подобаються, напевно
і їх продукт мені сподобається.

Тепер подивіться на іншу
звичайну форму для реєстрації:

що така форма говорить про сервіс,
яким буде його обличчя.

Що мене розчаровує, зокрема
в Yahoo, - це те,

що їх сервіс усюди працює з
однією формою реєстрації.

Вважаю, що Flickr вигадали один
з найкращих закликів до дії.

Він звучить як «Давай до нас!»

Це сторінка реєстрації Heroku.

Думаю, це одна зі старих версій.

Видатним тут є (і до цього
починаєш звикати) те,

що масштабувати бекенд-сервіси
тут не складніше,

ніж перетягувати повзунки.

Масштабування на цьому сайті
є справді дуже простим.

А це сайт спеціально для аудиторії
повної вивчаючих інформатику,

гадаю вам сподобається.

Це Chocolat, редактор коду.

І в них є лише один заклик до
дії: коли час вичерпано,

все залишиться як є, тільки
шрифт зміниться на Comic Sans,

цим вони наче говорять:

«Гей, ми знаємо, хто наші
користувачі, хто наші клієнти.

Це люди, які звертають на це увагу».

Це Hurl, веб-сайт для
тестування НТТР-запитів:

іноді місця, де з’являються помилки –

це можливості для
формування першого враження.

Якщо ви наштовхнетесь
на помилку 404,

то ось що побачите.

Часто ми створюємо насправді
красиві маркетингові матеріали,

але коли вам насправді потрібно
лише створення документації,

ми заощаджуємо на
дизайнерських рішеннях.

Це трапляється дуже часто.

MailChimp – це компанія,
яка знається на цьому.

Вони переробили всі
свої довідники так,

щоб вони виглядали як
обкладинки журналів,

і раптом – фактично після
цього нововведення –

коло читачів розширилося,
а кількість звернень в службу

підтримки щодо оптимізації
поштової розсилки зменшилась.

Щодо документації, Stripe – бізнес,
що базується на API,

не має UX. Взагалі UX – лише
документація, але навіть в

документації є можливості залучити
та здивувати користувачів.

Що мені подобається в Stripe,
так це їхні шикарні приклади,

але коли ти заходиш у додаток,
справжній головний біль для

більшості людей –
витяг авторизаційних

даних та ключів
для вашого API.

Що зробив Stripe:

«Коли ви заходите у додаток,
ми автоматично поміщуємо

ваші авторизаційні дані у
приклади, тому вам потрібно

скопіювати та вставити їх у
форму лише однин раз замість

того, щоб намагатися
їх запам’ятати.”

Коли в Wufoo захотіли
запустити третю версію API,

ми вирішили: «Добре, в решті
решт він досить добрий,

і ми хотіли б, щоб люди створювали
проекти на його основі».

Ми намагались вигадати, як
оформити його запуск так,

щоб це демонструвало
нашу індивідуальність,

тому що багато людей часто
організовують щось на кшталт

конкурсу серед розробників
додатків на базі API і роздають

переможцям iPad’и і iPhon’и; це зробить
вас схожими на інших.

Однією з дивних рис нашої
компанії є те, що наші

співзасновники просто схиблені
на Середньовіччі, і всі ми

відправляємось до Середніх віків кожного
року на річницю заснування компанії.

Тому ми сказали собі, що нам треба
щось зробити в цьому дусі.

Ми зв’язалися з хлопцями
з armor.com і спитали:

«Можете на замовлення
виготовити бойову сокиру?».

Ми сказали, якщо виграєте
конкурс програмування,

отримаєте її.

В результаті, люди хотіли
говорити про це з іншими.

Вони хотіли розказати,
що беруть участь

в нашому конкурсі,
щоб заявити іншим:

«Я програмую за зброю».

Добре те, що в решті
решт ми отримали

більше 25 додатків, якість яких,
і таку кількість ми не змогли

б собі дозволити при нашому
бюджеті та нестачі часу.

У нас з’явилися додатки для
iPhone і Android, плагін для

Wordpress, при цьому все, що
ми зробили – змінили те, як

люди сприймали
історію знайомства з

одним з наших сервісів.

Ні, ми не будемо цілий день
розглядати ці приклади.

Підводячи риску, скажу,
що вам просто

слід підписатися на
Little Big Details.

Взагалі, цей ресурс містить
велику кількість скріншотів

програмного забезпечення,
які демонструють, що в цих

програмах все влаштовано як треба,

і їхні творці чесні з
користувачами й клієнтами.

Що стосується довгострокових
відносин, або шлюбу,

єдиним дослідженням, яке в решті
решт нам вдалося прочитати,

були матеріали Джона Готтмана.
Він брав участь в передачі

«This American Life», згадується в
книгах Малкольма Гладуела і т. ін.

Він працює в Сіетлі й вивчає шлюби,
а також має особливий талант –

він може подивитися 15-хвилинний
відеозапис з парою,

яка свариться з якоїсь причини та
передбачити з точністю 85%,

чи залишиться подружжя разом,
чи розлучаться на протязі

чотирьох років. Якщо тривалість
відео збільшити до години,

і він попросить їх обговорити
їхні надій та мрії, точність

прогнозу збільшується до 94%.

Той самий відеозапис демонстрували
експертам в галузі

шлюбних відносин, подружжям,
що знаходяться в успішному

шлюбі, соціологам, психіатрам,
священикам і іншим.

Вони не можуть навіть
випадково передбачити,

чи залишиться подружжя
разом, чи ні.

Тобто Джон Готтман розуміє
щось надто важливе про те,

як відносини працюють у
довгострокових умовах – те, як ми

сваримося у короткостроковому
періоді, може визначити

зовнішній вигляд всієї системи.
Один з дивовижних факторів,

який він виявив полягає не
в тому, що пара у щасливому

шлюбі взагалі не свариться,
виявляється, що сваряться усі, і

всі ми сперечаємося щодо
одних і тих самих речей:

щодо грошей, дітей,
сексу, часу і іншого

(до «іншого» можна
віднести, наприклад,

ревнощі і родичів з
боку чоловіка/жінки).

Щоб було більш зрозуміло,
можете співставити кожен з цих

пунктів з проблемами, з
якими ми стикаємося в службі

технічної підтримки під час
створення нового продукту:

гроші – це проблеми на
кшталт «коштує дуже дорого»,

або «у мене проблеми з кредитками»;

діти – клієнти наших користувачів;

секс – продуктивність,
як довго ви працюєте,

і як швидко усе відбувається;

інше – я говорив про ревнощі
й родичів, тому в нашому

випадку це конкуренція й
партнерські програми, все те

дивне, що відбувається в компанії, і
про що вам будуть писати.

І причина, з якої мені подобається
говорити про це саме з

точки зору технічної підтримки,
полягає в тому, що під час

вивчення воронки конверсії,
технічна підтримка – це те,

що відбувається між
кожним з кроків;

це причина, з якої люди
не переходять на

новий рівень воронки: те,
що перешкоджає конверсії.

І ось поки ми роздумували
над всіма цими ідеями і

розвивали компанію, ми
зрозуміли, що як правило

створення нового бізнесу
або команди розробників

пов’язане з великими проблемами.

Вони пов’язані з відсутністю
циклічного зворотного зв’язку.

В справжньому житті, люди розлучаються
через наслідки своїх дій.

Це результат природного
процесу створення компаній,

зокрема, технічними
співзасновниками.

До старту продукту є час
для блаженства, нірвани і

можливості. Все що ви
робите – ви робите правильно.

Кожен рядок, написаний
вашою рукою, яка здається вам

«рукою Бога», і будь-який код, написаний
вами, здаються ідеальними;

ви вважаєте це геніальним.

Після запуску продукту ви
потрапляєте у справжній світ,

з’являються усі ці нові задачі,
що треба розв’язати;

усе, чому треба дати раду.

Технічні співзасновники,
зазвичай, намагаються повернутися

на первісний етап, і ми
дуже часто бачимо, як компанія

надовго відкладає все те,
що робить стартап справжнім

бізнесом й перекладають
роботу на інших.

Нам здається, що ці
задачі вторинні, що в

нашій компанії є інші люди,
які можуть цим зайнятися.

З іншого боку ми розмірковували
над тим, як нам створити

таке програмне забезпечення,
яке буде містити цінності, про

які часто не говорять, -
відповідальність, надійність,

помірність та скромність.
Пам’ятаючи про це, ми почали

працювати шляхом розробки
та вдосконалення свого

продукту через підтримку клієнтів

(англ: SDD – Support Driven Development).

Цей метод є досить простим,
але водночас і ефективним.

Вам не має потреби витрачати
купу паперу для нотаток, все,

що необхідно – це організувати
роботу так, щоб кожен

здійснював ефективну
підтримку клієнтів.

Таким чином, ви можете
налагодити сталий процес

зворотного зв’язку з користувачами.

Як правило, ті, хто розробляє ПЗ
(програмне забезпечення) і ведуть супровід.

Таким чином, отримуємо
багато переваг.

Одною з них є формування
відповідальності розробників та

дизайнерів ПЗ за
супровід (підтримку програм).

Ми, звичайно, не перші
дійшли такої думки.

Пол Інгліш зробив
багато для того,

щоб втілити цю ідею
в систему KAYAK.

Він встановив гарячу лінію для служби
супроводу сайту на поверсі,

де працювали розробники,
і вони просто приймали

телефонні дзвінки напряму. Люди
часто ставили йому питання:

«Чому Ви сплачуєте розробникам –
інженерам по 120 000 доларів

і більше за роботу, яку інші люди
можуть виконувати за меншу платню?»

Він відповів: «Розумієте, коли
розробник ПЗ отримує дві-три

скарги щодо певної проблеми,
то він ліквідує цей недолік і

дзвінки з цією
проблемою припиняються.»

Це досить ефективне і
елегантне рішення проблеми.

Джон Готтман говорить про
те, що є чотири причини

розриву стосунків між людьми.
Він називає їх чотирма

вершниками: критика, зневага,
захисна поведінка і блокування.

Критика в основному проявляється
в тому, коли люди

концентруються не на певній
проблемі, а говорять, наприклад:

«Ви ніколи не прислухаєтеся
до користувачів»,

«Ви ніколи про нас не думаєте».

Зневага виникає, коли хтось
цілеспрямовано хоче когось образити.

Захисна реакція - це

коли людина намагається
знайти собі виправдання.

Блокування, на думку
Джона Готтмана,

є найгіршим явищем, яке
може трапитися у стосунках.

Досить часто ми не дуже
переймаємося критикою та

зневагою під час здійснення
технічної підтримки.

Захисну реакцію ми можемо
споглядати досить часто на

етапах розвитку підприємства.
Проте блокування – це те

явище, яке досить часто
з’являється в стартапах.

Ми отримуємо певну кількість
відгуків і часто вважаємо,

що немає необхідності відповідати.

Така реакція є найгіршою на
початковому етапі розвитку,

також це пояснює
досить великий відсоток

«швидкоплинності» на ранніх
етапах розвитку стартапу.

Ось як підтримка зворотнього зв’язку
з клієнтами працювала в Wufoo.

Ми мали 500,000 тис.
користувачів в системі,

5 мільйонів людей використовували
форми та звіти Wufoo,

навіть самі того не розуміючи,
проте всі ці люди отримували

підтримку від 10 осіб, які
працювали в нашій компанії.

Як правило, для підтримки по кожному питанню призначалася одна людина.

В результаті, накопичувалося
біля 400 звернень в тиждень,

а це приблизно 800
електронних листів.

З 9 ранку і до 9 вечора
час очікування відповіді

користувачами займало від
7 до 12 хвилин, а з 9 вечора до

опівночі на це могло бути
витрачено не більше години,

а на вихідних ми відповідали
не пізніше 24 годин.

Ми працювали в такому режимі, дотримуючись
цих часових норм, постійно.

Ще одним зразком якісної
підтримки зворотнього зв’язку з

клієнтами є онлайн компанія
бронювання житла у будь-якій

точці світу Airbnb. Коли вони
переїхали до Нью-Йорку, то

запропонували клієнтам
цікавий крок – зробити професійну

фотосесію інтер’єрів. Засновники
самі обходили і справді

робили фото приміщень,
допомагали клієнтам їх найкраще

здати в оренду. Проте ця ідея
не з’явилася зненацька, я

пам’ятаю Джо, засновника компанії,
на перших етапах розвитку цієї справи.

Він безперервно здійснював підтримку
клієнтів 24 години на добу.

Варто звернути увагу, що ріст компанії
почався з того моменту,

коли їм вдалося поєднати попит
capacity per day) з пропозицією,

або іншими словами, коли
вдалося інтегрувати телефонні

дзвінки і їх систему
підтримки клієнтів.

В Wufoo ми постійно експерементуємо
з системою підтримки.

Тому що ми приділяємо дуже
багато уваги цьому аспекту.

Ми зрозуміли, що є певний розрив
між функціональними можливостями

системи, які клієнт шукає,
і їх відгуками в системі.

Контент та реакція, яку ми отримали від
людей, допомагала ним. Особливо онлайн.

Оскільки, клієнти досить часто не
розуміють невербальне спілкування.

І ми усвідомили, що поки не існуватиме
функції розпізнавання обличчя,

ми будемо завжди відділені
від наших користувачів.

Ми не були експертами в
програмуванні додатків по

розпізнаванню облич,
отже нами було

знайдене інше
рішення цієї проблеми.

По-перше, ми додали підпункт
меню, в якому клієнт міг

обрати опис свого емоційного
стану. Ми не очікували,

якогось надзвичайного результату
від цієї ідеї, але з’ясувалося,

що 75,8% наших клієнтів
активно використовували цей

підпункт на рівні з підпунктом, в якому
слід було вказати тип браузера,

яким вони користуються. Зміст
полягає в тому, що ми

показали нашим користувачам,
як нам важливо знати не

тільки про технічні проблеми,
які нам слід усунути, а також і

їх почуття, що вони відчувають під
час користування нашим продуктом.

Це так само важливо як і всі інші технічні
деталі, щоб знати як виправити їх.

Ми розставили пріоретити опираючись на
емоції людей, що користувались системою.

Деякий час потому стало
помітно, що клієнти почали більш

прихильно ставитися до нас –
це стало цікавим побічним

ефектом для нашої компаніі.
Це якось було просто відчуття

на підсвідомому рівні, але
ми провели певний аналіз

текстових повідомлень за
конкретний період і усвідомили,

що в простому листуванні є
лише три способи вираження емоцій:

знак оклику, слова, написані
курсивом і CAPS.

Звичайно, ці можливості не могли в повній
міри виразити ті почуття,

які користувач хотів передати.
Отже, маючи чіткі категорії в

меню, люди виражають свої
емоції більш раціонально,

тим самим полегшуючи
нашу роботу.

Надзвичайно важливим є те,
що в результаті ви створююте

набагато кращий якісний продукт.
Це доведено багатьма дослідженнями,

наприклад, Джаред Спул в
своїй статті щодо розробки

інтерфейсу користувачів стверджує,
що є пряма залежність між тим,

скільки часу компанія розробників
витрачає на пряме

спілкування зі своїми клієнтами
і тим, наскільки вдалим в

результаті стає інтерфейс
певної системи (програми).

Висновки прості: спілкування
повинно здійснюватися

напряму різними способами –
анкетування, оцінювання, інколи –

в реальному часі; кожні шість тижнів
і не менше, ніж дві години.

Якщо ж уникати цих аспектів, то
ваш продукт погіршуватиметься.

Наші працівники відкриті
для прямого спілкування з

користувачами щонайменше
6-8 годин на тиждень.

І який від цього ефект? Це змінює
процес розробки продукту (ПЗ).

Джаред Спул пропонує по –іншому поглянути
на те, як ми створюємо продукти.

Уявіть, що на цьому спектрі (на слайді вище)
відображається весь обсяг знань,

які необхідні, для
користування додатком.

Крайнє значення зліва,
відмічено червоним, - повна

відсутність знань, а крайнє
праве – всі необхідні знання.

А ці дві поперечні лінії відображають
ваше спілкування з клієнтами.

Лінія зліва показує поточний
рівень знань клієнтів,

а лінія справа - той рівень, до
якого ви хочете їх підвести.

Проміжок між цими двома
лініями, відповідно до Дж. Спула,

і називається «прірвою
знань» (knowledge gap).

Є два способи її позбутися: ви
або надаєте користувачеві

більше знань, або зменшуєте
кількість цих знань для

користування цим додатком.
Досить часто, ми, як

розробники, прагнемо
додати певних функцій,

але це в свою чергу призводить до
збільшення цієї «прірви знань».

Наша компанія сконцентрувалася
на інших аспектах.

Зокрема, 30 % нашого час ми
приділили розробці внутрішніх

інструментах для допомоги
системи підтримки.

Проте ще більше часу ми
приділяли тому, щоб

користувачі допомагали
самі собі. Наприклад, ми

створювали спливаючі вікна

з тими питаннями, які
задавали нам найчастіше.

Під час натискання на посилання
Help замість переходу на

сторінку з загальною інформацією,
ви можете потрапити на

конкретну сторінку з запитаннями, які
найбільш стосувалися ваших проблем.

Ми постійно змінювали дизайн
нашої документації, постійно

проводили тестування в
режимі A (альфа) і B (бета).

Одна з таких змін (ітерація)
зменшила навантаження

на нашу службу
підтримки на 30 % за ніч.

Тобто, за ніч зменшилась кількість роботи на 30%,
для тих хто займався розробкою продукту.

Отже, що ж відбувається,
коли всі безперервно із

відповідально працюються в технічній
підтримці клієнтів щотижня?

Я говорив про це на самому початку
лекції, що розвиток (ріст) –

це змінна, що залежить від конверсії

(відповідність попиту і пропозиції)
і «плинності» (в бізнесі).

На слайді можна побачити криву
росту Wufoo за перші п’ять років.

Цікаво, що ми не витратили
жодної копійки на рекламу і

маркетингові послуги,
весь цей розвиток

забезпечували самі
користувачі - наші клієнти.

Різниця між кількістю нових
користувачів і тих, хто

відмовився від наших послуг
є надзвичайно малою,

і це дуже важливо. Багато хто
забуває, що немає жодної

різниці між зміною конверсії
на 1% і зменшенням

«плинності » на 1%. Вони
врівноважують ріст вашої компанії.

Однак, легше робити літери,
значно дешевше

Багато разів ми відкидали це надовго і жаліли, що недоопрацювали деякі проекти та сервіси

Проте, цей графік не той, за
який ми досить ретельно

слідкуємо в Wufoo, навіть не з
тих, якими я пишаюсь.

Ось один з тих, з яких
я гордий (слайд на екрані).

Навіть маючи такий
чудовий графік росту.

Ось те, що нам дозволило
розвинутися, залишаючись

маленькою командою з надзвичайною
внутрішньою культурою.

І це вимагало від нас виконання
великої кількості завдань,

націлених на те, щоб реалізувати
потреби наших користувачів.

Джон Готтман помітив, що є і інший
різновид поведінки в стосунках,

що призодить до розлучень. Є люди,
які живуть разом по 10-15 років,

а потім зненацька
подають на розлучення.

Жоден з показників не може
прямо вказати на те,

що ця ситуація трапиться.
Готтман проглянув данні і зрозумів:

«Між цими людьми не
існує пристрасті, немає вогню.»

Стосунки, в певному сенсі
слідують другому закону

термодинаміки: в замкненій
енергосистемі все тяжіє до

руйнування, тому вам
доводиться докладати

зусиль, щоби все повернути
до початкового стану.

Багато хто вважає, що
виражати свою турботу перед

клієнтами слід різними
шляхами, наприклад, створюючи,

блог чи розсилку новин.
Ми поглянули на показники і

зрозуміли, що багато клієнтів
і гадки не мають, які

можливості ми можемо
їм запропонувати.

Отже, ми створили новий
інструмент, який називається

Система оповіщення Wufoo
(Wufoo Alert System).

Вона дозволяла нам відмічати
в часі кожну нову функцію,

запропоновану користувачам,
і кожен раз, коли вони

відкривали додаток, ми дивилися
на різницю в часі між

моментом їх авторизаціїї
або останнім під’єднанням і

моментом введення нових
функцій, після чого користувачі

отримували таке
вибулькуюче вікно :

«Привіт, поки тебе не було, в
Wufoo з’явилися чудові можливості.»

Це нововведення було
найчастіше обговорюваним,

і саме про нього я найбільше чув,
коли спілкувався з користувачами.

Вони говорили, що їм дуже
подобається ця функція, оскільки

оплачуючи одну і ту
саму суму, користувачі

могли отримати від
сервісу максимум користі.

Окрім того, що кожний клієнт
здійснював підтримку, сплачуючи гроші,

то вони ще й дякували нам.
Так відбувалося головним

чином тому, що ми ставили
знак рівності між змінними

«стриманість» і «сором’язливість».
Кожної п’ятниці ми

збиралися разом і писали на
звичайних листівках слова

вдячності нашим клієнтам.
Знаю, що багатьом могло би не

подобатися робити такі речі,
але це була наша традиція, що

зіграла найбільшу роль в
створенні дружньої команди і в

роботі над тим, що для нас
є дійсно важливим. Всі постійно

пам’ятали, що є нашою метою і
навіщо ми докладаємо зусиль.

То були найпростіші листівки,
написані від руки

слова, ще ми додавали наліпки
із зображенням динозавра.

Цікаво, що ця практика закріпилася
за нами з перших днів

створення нашої комапанії.
Кріс, Райн і я намагалися

зрозуміти, що необхідно зробити,
щоб показати нашим

клієнтам, як ми цінуємо їх.
Під час різдвяних свят Кріс

розповів, як декілька років
тому його мама змусила його

написати листи вдячності всім
родичам. Він також додав, що

йому це не дуже сподобалося,
але наступного року

він отримав дуже класні подарунки,

і в результаті ми вирішили спробувати
втілити у життя цю ідею.

Таким чином, першій рік ми
написали власноруч різдвяні

листівки всім нашим користувачам.
Настав другий рік, нас

було лише троє, а клієнтів
занадто багато. Тоді ми почали

міркувати, як можна виправити
ситуацію і на очі потрапила

книга під назвою “The Ultimate
Question” (основне питання) і

в ній автор говорить про
необхідність зосередження на

користувачах, які приносять
найбільший дохід. Він

стверджує, що якщо якісно їх
обслуговувати, то справа буде

розвиватися. Тоді ми розмірковували,
що це дійсно може

спрацювати. І ми написали
тільки тим користувачам,

які нам платили найбільше.

Так підійшов січень і нам написав один
з наших найдавніших користувачів:

«Вітаю, мені дуже сподобалася
та листівка минулого року і я

просто хочу, щоб ви знали,
що я ще не отримав свою другу

листівку цього року і чекаю її
з нетерпінням. Я знаю, що ви

не забули про мене. Дякую».
Бляха, це повідомлення нас

дуже спантеличило. Отже,
ми потрапили в дуже скрутне

становище. Поміркувавши, ми
дійшли висновку, що слід

припинити це робити лише
один раз на рік, і вирішили

робити це щотижня. Навіть
якщо ми не охопимо всіх своїх

користувачів, то сама ця
звичка нам багато чого дасть.

Я багато чого розповів про
ті моменти, про які багато

розробників воліють не
замислюватись і тому наприкінці

хотів би поділитися більш
точними даними. Є цікава стаття, а

також і книга, написана Майклом
Трісі і Фредом Вірсемою і

випущена декілька років
тому Harward Business Review,

в якій розповідається про
напрямки лідерства на ринку.

Вони стверджують, що існує
лише три способи досягнення

лідерства на ринку і в залежності
від того, як ви збираєтеся його досягти,

ви повинні зорганізувати роботу в
своїй компанії певним чином:

краща ціна, створення кращого продукту
або кращого загального рішення.

Для досягнення створення
кращої ціни ви зосереджуєте

увагу на логістиці як
Wal-Mart I Amazon.

Якщо хочете виготовляти
найкращий продукт,

зосереджуватися на наукових
дослідженнях, найяскравіший

тому приклад – Apple. Найкраще
загальне рішення означає,

що ви повинні наблизитися
до клієнтів. Можемо помітити, як

цим шляхом крокують елітні бренди,
а також готельний бізнес.

Серед цих трьох шляхів домінування
на ринку мені подобається третій –

єдиний, який може реалізувати
кожен на будь-якому етапі

становлення своєї компанії. Він майже
не вимагає капіталу для старту.

Як правило він лише вимагає
помірності і вихованості.

Як результат, ви можете досягти
успіху на своєму ринку ким

би не були ваші конкуренти.

На цьому я завершую,
дякую за увагу.

Так, давайте перейдемо до запитань.

Як ви створюєте один продукт, який у
результаті полюблять всі категорії користувачів?

Що робити, коли у вашого продукту
багато різних користувачів?

Деякі користувачі будуть любити
одне, інші - інше. Я погоджуюсь.

Тут є цікава тонка грань.

Зазвичай, я раджу людям
зосередитися на тих, кому ваш

продукт подобається більше,
особливо на ранніх стадіях.

Яка б це не була ніша, саме на них
я повністю зосереджу увагу.

Думаю, Бен Сільверман з Pinterest почав свій бізнес
з роботи з блогерами зі сфери дизайну.

Підлаштовувати свій продукт
під таких користувачів, і в

підсумку ви визначите
універсальні цінності, які

будуть розділяти та інші.
Тому просто починайте

послідовно опрацьовувати
такі групи одну за одною.

Є безліч прикладів того, як
компанії допускали помилки,

у спробі «зробити
свій додаток дотепним».

Гумор впровадити дуже складно.

Якщо хочете реалізувати щось дотепне,
доведеться налагодити функціонал.

Як з японським поняттям якості:
якщо немає atarimae,

не намагайтеся
придумати щось смішне,

так як це дасть
протилежний ефект.

Так що, без сумніву, ми в Wufoo
прагнули в першу чергу

зробити сервіс
максимально простим у

використанні, інше було
вже не так важливо.

Як зберегти баланс між одержимістю
в роботі над продуктом

та іншими завданнями
як маркетинг і т.д.?

Скільки треба концентруватись на продукті,
але й не забувати про маркетинг,

про службу підтримки клієнтів. Бо коли дуже
концентруєшся на продукті,

можна забути про
інші важливі сфери.

На чому саме ви концентруєтесь,
щоб зробити класний продукт?

Гаразд, питання приблизно
таке: як віднайти баланс

між створенням продукту,

але не забуваючи про розвиток інших
необхідних навичок, наприклад,

в сфері маркетингу і т.п.

Як балансувати?

Це ніби постійно жонглювати
тоннами речей у повітрі.

Коли ви розробляєте продукт,
завжди слід побачити

зворотний бік медалі -
спілкуватися з користувачами.

Для нас, в Wufoo, способом
спілкування з користувачами

була служба технічної підтримки.

Вони повинні бачити першими,
вдала вийшла функція чи ні.

Такий підхід вплинув на кожного
в компанії, тому що кожен

побував у ролі співробітника
технічної підтримки, і у всіх був

соціальний стимул робити
так, щоб все працювало.

Ні в якому разі не варто
зациклюватися тільки на продукті.

У вас завжди має бути час
приділити увагу продукту і потім

дізнатися, що вам говорять
ваші користувачі - це свого роду

безперервний віртуальний зворотний зв'язок. Так що
будьте обережнішим, якщо у вас його немає.

Моя думка про маркетингу і
продажах: мені здається,

маркетинг і продажі - це податок,
який ми платимо за те, що

не зробили наш продукт
видатним. Сарафанне радіо -

найлегший метод розвитку, і саме
так розвиваються кращі з компаній.

З'ясуйте, як придумати історію,
яку люди хотіли б

розповідати про ваш продукт. Так
людина, яка про неї дізнається,

стане вашим продавцем. Ця людина для
вас - менеджер з продажу.

Як ви приймаєте рішення разом
з командою інженерів

з приводу розвитку продукту
в тому чи іншому напрямку?

Як ви приймаєте рішення разом
з командою інженерів

з приводу розвитку продукту
в тому чи іншому напрямку?

Ми звертаємося до служби підтримки -
це дуже просто, тому

що так ти бачиш, з якими проблемами
люди стикаються найчастіше.

Ми завжди отримуємо від клієнтів
пропозиції щодо поліпшення сервісу.

Не важливо, яким буде ваш
продукт або додаток, люди

обов'язково захочуть від нього
нових можливостей, так що

ви будете в курсі того, що їм
потрібно. Вам, як програмісту,

представникові компанії, треба
не просто слідувати їх

вказівкам - інакше ви були б
рабом - ви повинні з'ясувати,

чого користувачі
хочуть насправді,

дізнатися базову
причину їхніх потреб.

Якщо всі хочуть рухатися в
різних напрямках, хтось повинен

прояснити ситуацію. Крім цього,
створіть зменшену версію

кожної невеликої ідеї, на розробку
якої піде не більше 1-2 тижнів,

щоб можна було її випробувати і
зрозуміти, що виходить, а що ні.

Небезпечно, коли у вас є безліч напрямків
для розвитку продукту,

які вимагають багато часу на
те, щоб у них розібратися.

Можете розповісти історію
про те, яку роль

«Каліф на годину» [англ. The King
for a Day] зіграв для Wufoo?

Так можу. Отже, я не люблю хакатони.

Я думаю, що вони марні (я маю
на увазі ті, що проводяться

усередині компаній), так як ти
витрачаєш 48 годин, старанно

працюючи над тим, що для
тебе цікавіше за все, і 99%

від цього так ніколи і не
доходить до реалізації.

Тому нам прийшла ідея, яку
ми назвали «Каліф на годину».

Вона реалізовувалася
протягом вихідних.

Було так: вибиралася випадкова
людина в компанії, і вона

ставала «каліфом». «Каліф» повинен
був вказувати іншим, що

робити з продуктом. Це
стосувалося всього, що його

турбувало в Wufoo, будь-якої функції,
яку йому хотілося впровадити:

у нього в руках були розробка,
маркетинг, реклама, ресурси

кожного співробітника компанії - все,
щоб реалізувати свої задумки.

І, природно, ми (керівництво)
працювали спільно, щоб

зрозуміти, що ми можемо
зробити за 48 годин.

Ми проводили такий «хакатон»
один-два рази на рік.

Він був величезним поштовхом
і служив для підйому

бойового духу, бо людям найбільше
подобалося розробляти

те, що, як їм здавалося, зіграє
велику роль у розвитку бізнесу.

Так що для нас це був спосіб
виділити час на один із

напрямів розвитку продукту.
Часом у людей, які на тебе

працюють, з'являється тверда
думка з приводу того, як має

розвиватися продукт. Можливість
помінятися місцями -

хороший спосіб
легкої демократизації.

Ви сказали, що всі
працюєте дистанційно.

Але зазвичай це - жахіття.
Як вам вдалося

прийти до успіху
з таким підходом?

Ми всі працюємо дистанційно, і ми
всі працюємо недалеко

від району Tampa Bay. Ми могли
б дозволити кожному

працювати, де йому захочеться,
але зазвичай, поки ми

наймали нову людину і
знайомили її з командою,

вона приймала
рішення переїхати сюди.

Працювати віддалено дуже непросто.

Багато хто любить ідеалізувати
такий підхід, особливо самі

співробітники, але суть в тому, що
офіс дає багато переваг і можливостей,

які вам доводиться компенсувати.
Але у віддаленої роботи

теж є свої плюси. Приміром,
мені не потрібно турбуватися,

що мої підлеглі втратять 2 години
свого робочого часу на дорогу.

Тому головне, що ми
повинні дотримуватися при

дистанційній роботі -
це поважати чужий час.

Ми змогли це здійснити, так як
у нас в Wufoo був тиждень з

4,5 робочих днів; неповний
робочий день у п'ятницю був

відведений на наради тощо.
Ми сказали собі: ніяких нарад з

розвитку бізнесу, ніяких переговорів
з іншими організаціями

[в інші дні]. Всі вони повинні
бути проведені в п'ятницю, в

цей короткий робочий день;

їх заборонено було
проводити посеред тижня.

І крім того один день на тиждень кожен
присвячував технічній підтримці.

Виходить, у співробітника в
нашій компанії було лише три

дні на тиждень для ефективної
роботи, чим би він не займався.

Але, чесно кажучи, я твердо
вірю, що, якщо у тебе є три

повноцінних дні по 8-10 годин, коли
ти працюєш тільки над тим,

що тобі потрібно виконати, ти
можеш зробити море роботи.

Тому ми домовилися, що повинні цінувати
час кожного протягом цих трьох днів.

Ми прийшли до ідеї
п'ятнадцяти хвилин.

Ви можете листуватися або
говорити по телефону з кимось,

але це може тривати
не більше 15 хвилин.

Тому, якщо у вас виникла
складна проблема, яку ви не

можете вирішити за ці 15 хвилин,
вам потрібно негайно відкласти її,

щоб ми обговорили її в п'ятницю.

Потім ви берете наступну
задачу зі свого списку.

Я б сказав, в 90% випадків,
проблема ніколи не піднімалася в

п'ятницю, оскільки зазвичай
люди "спали" з проблемою, а

потім дивним чином говорили:
«А я знайшов рішення!»

Або «Та це зовсім не
така велика проблема».

Більшу частину проблем
всередині компанії не

потрібно вирішувати
прямо тут і прямо зараз.

Виняток становлять, наприклад,
неполадки з обладнанням

або проблеми з виплатами.
Все інше, можна сказати,

недозволена розкіш. Так
що зосередьтеся на своїх

пріоритетних завданнях, наскільки
це можливо: в результаті

використання такого підходу
наша команда з 10-ти чоловік

зробила набагато більше, ніж
величезне число інших компаній.

Але необхідно докласти неймовірних зусиль,
щоб працювати ефективно дистанційно.

Наша команда неймовірно
дисциплінована, і, мушу сказати,

існує небагато таких компаній,
що пройшли YC, які змогли б

повторити те, що зробили ми.
Думаю, всього лише дві

компанії з YC зуміли повторити
нашу техніку підтримки дисципліни.

Вона вимагає більше
роботи зовсім іншого роду.

І часто дозволяє поводитися
трохи менш активно

в плані всього, що
стосується продуктивності.

Як менеджеру розподілити відповідальність
між своїми працівниками?

Як менеджеру розподілити відповідальність
між своїми працівниками?

Ми вийшли на окупність через
9 місяців після запуску, і у нас

була програма участі співробітників
у розподілі прибутку, яка

дає їм простий і ясний стимул
до розвитку. У нас було безліч

варіантів видачі премій, і оцінка
результатів проводилася на

основі того, як виконувалася
технічна підтримка, на основі

виконання своїх обов'язків, і того,
чого кожен прагнув досягти.

Мені не подобається процес
і механізми допомоги

працівникам у підвищенні
продуктивності, тому єдине, чим

ми намагалися допомогти
співробітникам в управлінні

своїми проектами - складання
списку завдань.

Таким списком був звичайний
текстовий файл, до якого ми

відкривали доступ в Dropbox. Там
було вказано ім'я кожного,

і потрібно було кожен раз стежити,
коли хтось оновлював його вміст.

Ми вирішили, що щовечора
ми пишемо туди все, що

сьогодні було зроблено, а в
п'ятницю просто дивимося:

«Ось, що ви обіцяли зробити минулого
тижня; ось, що ви дійсно зробили.

У чому тут проблема? »
І це надзвичайно просто.

Виходить, що стежиш за всім,
що необхідно виконати, і не

потрібно хвилюватися з
приводу управління завданнями.

Кожен сам задає тон тому, як
він хоче, щоб його оцінювали.

А для тих, хто відмінно з усім
справляється, працювати

подібним чином дуже
легко. І якщо виникають

проблеми, то так людей
і звільнити простіше.

Я радий, що мені не довелося
нікого звільняти з Wufoo,

але ми могли дуже швидко
змінити поведінку кожного,

бо дивилися на список
і визначали проблему:

«Дивися, ось так ти поводишся. Ти виконуєш
свою роботу в останню хвилину

перед п'ятницею. Це проблема.
Треба краще управляти своїм часом.

Це факти, які ти нам надав. Все,
що ми повинні зробити, це

вказати тобі на них». І через те,
що всі в компанії це бачать,

створюється соціальний тиск,
який змушує тебе виправитися.

Як наймати співробітників,
які можуть працювати

віддалено, і як
організувати таку роботу?

Як наймати співробітників,
які можуть працювати

віддалено, і як
організувати таку роботу?

Досить просто: дайте їм роботу
по додатковому проекту.

Ви надаєте їм роботу за
контрактом, і, по суті, вони

виконують її віддалено.
Зазвичай проекти, якими такі

кандидати повинні займатися,
тривають близько місяця -

достатньо часу, щоб отримати
гарне уявлення про те, як

люди управляють своїми завдання
і як з ними справляються.

Для нас це було основним
критерієм оцінки;

ми ніколи не наймали людей
лише на підставі інтерв'ю.

Ще один пункт, за яким ми
відбирали співробітників - їх

здатність здійснювати технічну
підтримку, так як не кожен

інженер володіє тими навичками
співчуття, які допомагають

боротися з таким «стресом».
Тому іноді на інтерв'ю я просив

людей за 15 хвилин скласти лист з
вибаченнями про неможливість

зробити щось [для гіпотетичного
клієнта]. Такий спосіб

дозволяє оцінити навички
писемного мовлення здобувача.

[Вони дуже важливі], тому що
в 90% випадків службі

підтримки доводиться повідомляти
клієнтам погані новини,

наприклад: «вибачте, але ми
не підтримуємо дану функцію»,

або «ні, так зробити не вийде»,
або «ця функція недоступна».

Чи були якісь хитрощі та експерименти,
які в нашій компанії не спрацювали?

Я розповім про один випадок.
Дещо з того, чим на ранньому

етапі ми намагалися мотивувати
себе: в цілому, ми розуміли,

що робота в «авральному режимі»
дуже погано позначається

на співробітниках.
У більшості випадків,

жорсткі терміни можуть
бути вкрай виснажливими.

Можливо, ви отримаєте
приріст у продуктивності,

але період відновлення, необхідний
для працівників, завжди

триває довше, ніж час продуктивної
роботи. А в компанії, де

потрібно, щоб кожен знаходився
в технічній підтримці, був

постійно в строю і
постійно працював

над функціоналом, немає
часу на відновлення.

Тому ми придумали організувати
для компанії відпустку за

аналогією з тим, як ми щорічно
заохочуємо своїх користувачів.

Ми вирішили, що якщо організуємо
відпустку для відновлення сил,

то чи зможемо один раз попрацювати в
посиленому режимі перед цим,

а у відпустці здійснювати тільки
технічну підтримку, яка буде

всім під силу. У такому
авральному режимі працювали

спочатку тільки троє засновників:
кожен повинен був

скласти список з 10 завдань
з дуже жорсткими рамками.

Перший, хто виконає свої
сім завдань, перемагає,

останній стає так званим
«невдахою» на відпочинку.

«Невдаха» повинен носити чужий багаж і
подавати напої під час нашої відпустки.

І ми почали працювати, і протягом цього
часу всі були в захваті від цієї ідеї.

Переможець міг обирати
місце наступної відпустки.

Але раптом Райан зрозумів, що погано
розподілив завдання в списку.

Усвідомивши, що програє,
він просто здався.

Так що авральний режим
виявився для нього сумовитим,

бо він знав, що програє, і
втратив всі надії. Тому в підсумку

ми вирішили більше не
проводити таких «авралів».

Ідея хороша, і ми
любимо її обговорювати,

але більше ми ніколи
її не реалізовували.

Гаразд, народ. Щиро дякую!

Переклад на українську: Вадим Єгоров,
Вікторія Ковтун, рев'ювер: Оксана Кузьменко