Алекс Тернбулл, засновник трьох стартапів, в своїй блозі поділився вісьмома правилами, які допоможуть засновникам, які не є програмістами, взаємодіяти зі своїми технічними підкованими колегами.
Одна з найбільш поширених проблем, з якими стикаються підприємці, - це розвиток проекту без технічних навичок. Багато хто думає, що без навичок програмування не варто і братися за власний стартап, але це не так. Алекс Тернбулл, засновник трьох стартапів, не вміє програмувати, але за роки роботи над проектами він накопичив важливий досвід, який вкрай важливий для нетехнічних засновників. У своєму блозі він поділився вісьмома правилами, які допоможуть засновникам, які не є програмістами, взаємодіяти зі своїми технічними підкованими колегами.
Я заснував три SaaS-стартапу. Для кожного з них я не написав жодного рядка коду. Ось, що я б хотів знати з самого початку.
«Вибачте, але поки серед команди засновників НЕ буде програміста, ця розмова не рушить уперед». Намагатися залучити інвестиції, будучи нетехнічних засновником, та ще задача. У ній мене часто завертали ввічливими репліками «у вас немає дечого необхідного для успіху». Дякую за довіру, хлопці.
Незважаючи на те, що у мене був продукт, я не був розробником. І незважаючи на мої зусилля, у мене не було і технічно підкованого співзасновника.
У світі технологій засновники без технічних навичок ризикують бути названі некомпетентними.
Я бачив потенційне відношення інвесторів, співробітників, партнерів, консультантів і навіть товаришів-засновників, у яких не було частки в моєму бізнесі.
Ви не можете побудувати software-бізнес, якщо ви не можете розробити software. Маячня.
Незважаючи на те, що нам належить ще довгий шлях, я чертовски пишаюся тим, як далеко ми зайшли з Groove. Ми зробили це з відданим на аутсорс прототипом, крутий командою і тонною різних активностей. І мною, свідомо нетехнічних засновником.
Все це не спроба викликати жалість і трохи поваги до нетехнічних засновникам в індустрії. Повага заробляють, а в галузі є безліч груп, куди більш маргінальних. Але так я в третій раз став засновником стартапа без технічних навичок і навчився багато чому по дорозі. Пройдені уроки допомогли мені більш ефективно працювати з технічними членами команди, вносити більше цінності в продукт і ставати кращим підприємцем. Сподіваюся, і вам вдасться винести з цього щось корисне.
Примітка: багато з написаного - відмінні навички і для технічних засновників. І багато CTO, яких я знаю дійсно гарні в цих напрямках. Але мій досвід показує, що для нетехнічних засновників, які не можуть внести свою лепту в програмний код, ці навички вкрай необхідні.
Навички, які допомогли досягти успіху нетехнічному засновнику
1. Дослідження і підтвердження
Перед тим, як заснувати свій перший стартап, я почав кар'єру в ролі помічника мого брата - фінансового консультанта. Незабаром після цього я почав впадати в ступор від того, що відсутня інструмент, який би автоматизував роботу по взаємодії з клієнтами. Все, включаючи написання фоллоу-апів, обробки лидов і їх відстеження, доводилося робити вручну. Потім я подумав, що раз у мене є така проблема, то можливо, що і інші страждають від цього. Тому я зробив в PowerPoint презентацію рішення, яке собі уявив.
Я подзвонив фінансовим консультантам свого району, запитуючи, чи не виділять вони мені п'ять хвилин свого часу. Потім я запитав про їх особистий досвід та проблеми і зрозумів, що десятки з них поділяють мою біль. Тоді і тільки тоді я вирішив об'єднатися з моїм технічним співзасновником і зайнятися створенням продукту.
Цей процес я повторював для всіх своїх стартапів. Час, витрачений на ранньому етапі, поверталося до мене сторицею, допомагаючи створювати рішення краще, ніж без попередньої підготовки.
Висновок: без здатності реалізувати прототип, найпростіший варіант підтвердити вашу ідею - поговорити з потенційними користувачами. Ви будете здивовані, як багато людей з радістю поділяться своїм часом і думкою з вами.
2. Створення візуалізацій
Мені пощастило залучити в команду одного з моїх кращих друзів, розробника, який тільки що покинув Yahoo! Перш ніж він приступив до роботи, я спробував сісти і розповісти йому про всі функції, які, на мій погляд, повинні бути в додатку. Після п'яти нескладних хвилин він зупинив мене: «Ми не можемо розробляти функції за списком. Давай організуємо твої думки і зобразимо їх на папері, щоб зрозуміти, як буде виглядати додаток ». Так я і зробив.
Я почав малювати скетчі. Вони перетворилися в каркас додатка. Потім, в кінці кінців, я розібрався з Photoshop і намалював мокап додатки.
Це перекрило прірву між думками в моїй голові і їх розумінням з боку мого співзасновника. Такий підхід дозволив заощадити нам безліч часу на поправках і додаткових ітераціях в майбутньому.
Незважаючи на те, що зараз для створення мокап я відкинув Photoshop і переключився на Balsamiq, це як і раніше мій улюблений спосіб показати команді, що конкретно нам потрібно зробити. Наприклад, я можу вказати на частина сайту, в якій необхідно виправити помилку:
Або я малюю каркас цілої сторінки, щоб команді було простіше зрозуміти її в моєму баченні.
Або, якщо проблема в призначеному для користувача досвід, то я запишу поведінку користувача за допомогою Jing, сервісу для запису того, що відбувається на екрані, і відразу відправлю його команді. Такий підхід куди більш корисним нашій команді, ніж будь-яке пояснення.
3. Давайте зрозумілу зворотний зв'язок
Коли ви говорите, а не показуєте, потрібно описувати ваші побажання настільки детально, наскільки це можливо.
На початку роботи над моїм другим стартапом ми намагалися створити сторінку входу в обліковий запис для користувачів і процес рухався дуже туго. «Форма повинна бути більше і нам потрібно менше навігаційних посилань», - писав я в листі до керівника розробки. Якщо у вас є досвід в розробці продукту, то ви невдоволено трясете головою. «Без проблем», - відповідав програміст і надсилав занадто велике поле, де не вистачало критично важливих посилань. Цей танець ми танцювали днями: спершу я розпливчасто просив про зміни, потім він виконавчо надсилав мої правки.
Нарешті я вирішив, що з мене вистачить. «Господи, чому ми прибрали посилання на домашню сторінку?», - дивувався я. «Ти ж сказав, що хочеш менше посилань», - відповідав розробник. Так і було.
Наступного ранку у нас була довга дискусія, яка мені неймовірно допомогла. Я зрозумів важливість чіткої та зрозумілої зворотного зв'язку. Зрештою, якби хтось надіслав мій пост з блогу з зауваженням «текст повинен бути коротше», я б теж загубився.
Тепер замість «поменше навігаційних посилань» я пишу: «Давай приберемо посилання на розділи« Про нас »,« Контакти »,« Функції »і збільшимо розмір кнопки на 20%». Робота почала відбуватися значно продуктивніше.
Висновок: немає ніякої об'єктивної причини давати розпливчасту зворотний зв'язок. Це уповільнює команду, породжує нерозуміння і шкодить продукту. Виражайтеся ясно, чітко і прямо.
4. попередній продаж
Під час цих розмов, почувши, що агент ненавидить писати фоллоу-апи вручну, я говорив йому: «Просто щоб ви знали: ми розробляємо інструмент, який автоматизує все це. Він буде робити X, Y і Z. Коли він буде готовий, я б хотів показати його вам і отримати зворотній зв'язок. Ви не проти? »Така стратегія дала нам сотні гарячих лидов і десятки платять користувачів в перші тижні запуску.
Висновок: ви можете почати продавати навіть до того, як у вас буде продукт на продаж. Насправді, поки ваш продукт розробляється, це один з найкращих варіантів використовувати свій час.
5. Продажі
Я прийшов до висновку, що моя робота, як нетехнического засновника, найбільше полягає в продажах.
Хочете залучити інвестиції? Потрібно зв'язатися з інвесторами, які бачать сотні Пітч щотижня, і переконати їх, що ваша компанія гідна ставки.
Продати продукт? Вам треба зв'язатися зі своїми користувачами і повністю зрозуміти їхні проблеми, надії і страхи.
Хочете найняти кращих фахівців? Вам потрібно знайти талановитих кандидатів з різним досвідом, зрозуміти їхні цілі і показати їм, чому ваша компанія - найбільш підходяще для них місце.
Хочете підписати договір з вигідним партнером? Треба поговорити з людиною, з яким ви шукаєте угоди, з'ясувати, що він хоче, і переконати його, що ви зможете допомогти.
Хочете ефективно управляти? Треба бути на зв'язку з командою і утримувати набір показників на висоті: щастя, продуктивність, перешкоди, цілі та розпорядок. Список можна продовжувати нескінченно.
Але, крім навчання, важлива і практика. Кожен день, який ви проводите за продажами, стає краще, ніж попередній. Як каже мій особистий досвід і люди, які значно краще ведуть продажу, ніж я, ви завжди зустрічаєте нові виклики, через які опускаються руки. Але з часом ви справляєтеся з ними все краще і процес стає не таким обтяжливим. Продажі - то місце, де ви, як нетехнічний засновник, принесете компанії найбільшу користь, удосконалюючи свої навички.
Висновок: головна робота нетехнического засновника - розвивати бізнес через залучення нових клієнтів, найм і управління. Розвивайте навички взаємодії з людьми завдяки регулярній практиці.
6. чирлідингу
У кожному з трьох моїх стартапів мені доводилося натикатися на людей, які говорили мені, що я нічого не розумію, адже я не розробник. Чесно кажучи, скептики - проблема, з якою стикаються всі засновники. Вони приносять найбільше неприємностей, коли б'ють по проблемі, яка дійсно є. Наприклад, коли говорять, що ви не розробник.
Я навчився бути своїм власним Чирлідери, щоб мотивувати себе пробиватися через стіну скептицизму і фокусуватися на речах, які важливі. А потім я навчився бути Чирлідери для всіх інших.
Коли наші розробники б'ються над серйозною проблемою, яка стримує просування, я не можу допомогти їм з технічного боку. Але в такі моменти я можу бути Чирлідери для наших користувачів, допомагаючи програмістам вирішити проблему завдяки постійній комунікації з клієнтами.
Приклад чірлідерства для користувачів - лист, який я відправив користувачеві, коли наш сервіс виявився тимчасово недоступний.
Тема: Апдейт по статусу Groove
Хотів поділитися коротким апдейтом про роботу нашої команди над вирішенням проблеми з сервером, яка виникала цього ранку. Ми прагнемо налагодити роботу Groove на 100%.
Станом на 15:00, ми успішно провели перезапуск шість з семи серверів, які постраждали від помилки Amazon / Engine Yard:
- Нарахування оплати працює на 100%
- Відправлення та отримання email працюють на 100%
- Сервер з чатом підтримки все ще не працює. Ми намагаємося встановити його і розраховуємо, що чат запрацює протягом години.
- Функція оновлень Groove в реальному часі, яка знаходиться на тому ж сервері, що і чат, також не працює. Ми очікуємо повернути її протягом години. Тим часом, оновлення сторінки оновить листи і всі зміни.
Спасибі, що залишаєтеся з нами, поки ми працюємо над відновленням Groove, і прийміть мої вибачення за сьогоднішню несправність.
Я пришлю свіжий апдейт, як тільки чат і оновлення програми знову запрацюють.
Як завжди, ви можете написати мені прямо на пошту [email protected] з будь-якими питаннями чи побажаннями.
Якщо ділитися з командою кожної маленькою перемогою, це може підвищити їх моральний дух і мотивацію.
Так як я не можу кинутися виправляти баги на сервері, підтримка колективу і користувачів - краще, що я можу привнести в такій ситуації.
Висновок: ваша робота - бути власним Чирлідери і підтримувати свою команду і користувачів. Це буде тримати вас в здоровому глузді, мотивацію команди на належному рівні, а ваші користувачі будуть щасливі і лояльні.
7. Умійте працювати з інструментами розробників
Як і кожен з нас, розробники використовують інструменти, які допомагають їм виконувати їм роботу краще і простіше. Щоб не відволікати людей від робочого процесу і не гальмувати розробку продукту, мені довелося навчитися користуватися цими інструментами.
Кожна команда буде використовувати різні інструменти. Незалежно від переваг вашого колективу, якщо ви знаєте як з ними працювати, це допоможе всій команді.
Коли я знаходжу невеликий баг, я не шлю листа, відволікаючи розробника від роботи. Я пишу докладну інформацію користувача історію і відправляю її в Pivotal Tracker, який направляє мій фідбек в робочий процес розробників без зайвого відволікання.
Висновок: не намагайтеся змусити команду розробників користуватися вашими інструментами. Вони, ймовірно, створені не для програмування. Замість цього, спростите процес взаємодії і зробіть життя вашої команди простіше, навчившись поводитися з їх інструментарієм.
8. Робіть «все інше»
Я навчився бувати в тисячі ролей. Нам потрібно створити таблицю і знайти контакти для підвищення залучення нашого блогу? Це моя робота. Потрібно знайти підходяще додаток, щоб ділиться скриншотами різних версій продукту? Вже шукаю. Розробнику необхідно, щоб я зв'язався з підтримкою Pivotal Tracker і з'ясував, чому у нас не синхронізуються оновлення? Лист вже пішло!
Я не можу собі дозволити не робити все, що в моїх силах, щоб полегшити роботу оточуючих.
Висновок: его тут не місце. Ваша робота - робити абсолютно все, на що нераціонально витрачати час розробників. Інакше ви ризикуєте зростанням вашої компанії.