Планировать финансы можно от продаж, от маркетинга или от продукта. Есть ещё способ, когда все планируют одновременно, а потом пытаются совместить, но акцент всё же лучше делать на чём-то одном.

Как понять на чём? Очень просто: на том, где самое узкое место.

Если вы можете генерировать бесконечное количество лидов, конвертировать в покупку, но не можете всем оказать услугу или предоставить товар, то ваше узкое место в продукте — планируйте максимальное производство с пониманием, что всё что не сделаете, всё купят. Главный риск такого типа — потеря темпов роста и демотивация команды. Продукт классный, но выручка будет запаздывать.

Лидов много, в производстве проблем нет, но продажи буксуют? Отлично, тогда планируем максимальную загрузку по продажам, спускаем план по лидогенерации и требования в продукт. Здесь главный риск в потере качества продукта и возможных кассовых разрывах.

Продавать научились, продукт тоже тянет, но не понимаем где найти лидов? Ну, вы поняли, тогда ваше узкое место в маркетинге и надо выжимать из него максимум, а исходя из возможностей проектировать продажи и продакшен. Здесь риски такие же, как и в планировании от продаж, просто фокус на лиды.

Одного правильного способа нет, выбирать надо исходя из характера фаундера, его целей, вида бизнеса и принятия различных рисков. Но одно могу сказать точно: как-то планировать всё же надо, иначе потом результат невозможно оценить — хороший он или плохой. Ибо сравнивать не с чем и понять где проблема невероятно сложно.

Мысль дня — фаундер у стартапа незаменим. Всех остальных можно уволить и нанять с нуля, а вот основатель нужен в здравом уме и ресурсе для движения вперёд. И если не получается бежать быстро, то лучше притормозить и перестать винить себя в недостаточной скорости. Уже писал про это и не раз, но не устану повторять: свой бизнес — это марафон, а не спринт.

В первую рабочую неделю нового года особенно сложно не перенапрячься. После отдыха сил много, кажется что всё получится быстро и чётко. И первое время так и происходит, но есть риск быстро сгореть. Входите в ритм постепенно, позаботьтесь о себе, поддержите организм. Он у вас один, а вы — одни у вашего стартапа. И вы нужны друг другу.

Заканчиваю обучение на курсе «Технология построения системы продаж» Дмитрия Волошина. Рекомендую всем, кто хочет наконец-то разобраться в продажах и сделать это основным драйвером роста бизнеса.

Дмитрий превосходно систематизирует материал и даже если вы уже имеете опыт построения продаж — всё равно будет полезно. А домашние работы на этом курсе стали для меня основным способом получения практической ценности: я внедрял изменения прямо в процессе обучения.

Основные мысли, которые я отметил для себя:

1. Без правильного описания продуктов и УТП продажи не полетят. Это кажется очевидным, но у многих бизнесов с которыми я работаю на этом этапе серьёзные проблемы. На курсе найдёте практические шаблоны и пояснения как это нужно делать.

2. Юнит-экономика считается для масштабирования. Хотите верьте, хотите нет, но именно на этом курсе я по настоящему понял что же это такое и перестроил то, что я раньше называл «моделью» в полезный инструмент для принятия управленческих решений.

3. Система мотивации продаж — основа. По сути это и есть создание отдела. Без правильной мотивации наложенной на подходящую для текущего этапа ролевую модель не будет роста. И это безумно увлекательно! Придумывание таких систем чем-то похоже на программирование, когда есть простор для творчества, есть баги для исправления и есть больше чем один способ решения.

И есть ещё один неочевидный момент, за который я хочу отдельно поблагодарить Дмитрия. Благодаря его курсам для меня учёба перестала быть чем-то с горьким оттенком школы, оправданий и бессмысленных обязательств. Каждую среду я вставал утром с приятным ощущением предстоящего урока и с удовольствием делал домашние работы. Потому что интересно, потому что видна польза, потому что без давления и с теплом.

Демо разработки — это когда команда показывает что они сделали за спринт. Несколько недель что-то программировали, а теперь собирают всех желающих посмотреть и дать обратную связь. Есть несколько правил проведения демо, которые я осознал на своём опыте.

Каждый программист сам рассказывает про свою работу. Так мы не перекладываем ответственность за код: как реализовал так на демо и отработает. И все вопросы тоже лично к тому, кто делал — чтобы понимал, что это не просто таски в джире, а живые люди, которые будут пользоваться продуктом.

Показывать нужно на реальных данных. Никаких lorem ipsum. Все тексты и картинки на демо такие, как они могли бы быть в реальной жизни. Потому что тем, кто не в контексте так проще понять суть. И на настоящих данных всегда что-то идёт не так: то вёрстка поедет, то вообще всё сломается. В процессе подготовки к демо это всплывёт и, в идеале, будет исправлено.

Показывать нужно на боевом продукте. Если что-то только на тестовой машине разработчика — считай, что этого ещё нет. Лучше сразу приучать, что задача считается сделанной только тогда, когда бизнес начинает получать пользу. Не успели выкатить — не показываем.

Проводите репетиции. Особенно на старте. Есть много неочевидных моментов, которые кажутся простыми, но всплывают уже на первом прогоне. Берите кого-то из команды на послушать и дать обратную связь и только потом собирайте всех желающих.

Больше хвалите. Часто всё хорошее воспринимается как само собой разумеющееся, а недоработки сразу бросаются в глаза. Так уж устроен наш мозг — негатив важнее для выживания. Постарайтесь благодарить публично, а все замечания отправлять лично после демо.

— Как ты мог завалить проект?
— Почему вчера не выкатили релиз?
— Неделю назад было понятно, что не получится.

Знакомые фразы? Бесят? Да, так и должно быть. Потому что все они атакуют прошлое. А у прошлого есть одна интересная особенность — его нельзя изменить. На эти фразы невозможно адекватно ответить, проект уже завален, релиз уже не состоялся. А машину времени ещё не изобрели.

Вместо попыток изменить прошлое лучше поработать с настоящим: первым делом решить текущую проблему. Не ругать, просто выслушать, что случилось, а потом успокоить клиентов, выкатить исправление, да составить план хотя бы, как теперь разгребать, что случилось.

А уже затем можно обратиться в будущее: придумать как сделать так, чтобы проблема не повторялась. Проанализировать ошибку и предпринять меры, чтобы их больше не было.

Заметьте, в обоих пунктах нет попыток изменить прошлое. Да, мы к нему обращаемся чтобы понять что пошло не так, но мы его не атакуем. Если заметите в своей речи подобные атаки — рекомендую от них избавляться, потому что кроме раздражения ничего получить в ответ невозможно. А если такое применяют к вам — попробовать перевести разговор на тему текущей ситуации и будущего.

Этот пост я написал на основе советов из книги «Джедайские техники конструктивного общения» Александра Орлова. Если хотите подробнее разобраться — рекомендую, для меня было очень полезно.

С ростом бизнеса основатель всё больше отдаляется от рядовых сотрудников. Были времена, когда вся моя компания вмещалась в переговорке небольшого офиса, а я знал каждого лично. Более того, в большинстве случаев участвовал в наёме.

Некоторые руководители вместе с ростом начинают считать ниже своего достоинства погружаться в детали. Не работают продажи — ну вот есть же коммерческий директор, поговорю с ним, пусть разбирается. А по его словам всё хорошо. Но роста с нужной скоростью при этом нет. И что делать?

У меня тоже были такие мысли: зачем прыгать через голову директора. Но на самом деле это всё не про правила делегирования, а про эффективную помощь. В итоге я прошёлся по всем этапам формирования отдела продаж сам и проверил, что происходит. Начал с продукта: надо же понять что мы продаём. Взял продакта за руку и пошёл вместе смотреть описания. Оказалось, что УТП у нас мягко говоря хромают. А ведь это влияет на все этапы в воронке продаж! К аналогичному выводу можно прийти если послушать созвоны менеджеров с клиентами, например.

При этом не советую нападать и обвинять сотрудников. Хорошо работает фраза «Давай вместе сядем и подумаем». Помните, что рост стартапа ограничивается ростом фаундера. В моём случае получилась наглядная демонстрация: пока я сам не разобрался как строить системные продажи и не пошёл всё проверять, то ничего само и не росло.

Резюмируя, мысль этого поста: не бойтесь погрузиться в детали, если хотите что-то исправить. Может быть даже в гембу сходите и сами денёк поработайте линейным сотрудником того отдела, где есть проблема. Очень помогает выявить реальные проблемы.

Не забывайте радоваться победам. Звучит странно, но многие забывают про это в гонке за успехом. Я вот часто замечаю за собой: когда что-то получается, то сразу же хочется перейти к следующему шагу, сделать ещё лучше и ещё быстрее.

Но наш мозг хочет поощрений. Не хвалить себя за успешные чек-поинты — прямой путь к выгоранию. Всё начинает казаться само-собой разумеющимся, хотя на самом деле вы приложили много усилий к тому, чтобы всё получилось.

Окей, допустим себя вам не жалко и вы умеете справляться иначе. Но есть же команда: коллеги, подчинённые, партнёры. Им тоже важно понимать, что несмотря на ошибки и неудачи, вы всё же движетесь в правильном направлении. Устройте праздник хотя бы для них. Да хотя бы просто похвалите публично, не обязательно как-то материально поощрять.

Только не делайте это на пустом месте. Обязательно зацепитесь за какую-то точку успеха. Пусть небольшую, но чтобы было ощущение настоящего праздника, а не вечеринки в горящем здании.

Я вот иду сейчас за шампанским, чтобы порадоваться первому реальному шагу на пути к системным продажам в Tproger. Изменения, начатые в прошлом году докатились до менеджеров по продажам и это реально круто. Да, ещё очень многое предстоит сделать, но я очень рад за команду и себя самого. Не просто так я, значит, бонусы получаю :)

Несколько советов по формированию задач после встречи. Например, вы проводите планёрки по понедельникам, разбираете что нужно сделать чтобы прийти к цели. Декомпозируете и в конечном счёте выписываете задачи.

Рекомендую такой формат:

Суть задачи одним предложением.

Кто ответственный. Не обязательно исполнитель, но кто организует.

Срок. Если задачи не выделяются изначально на какую-то итерацию, то, конечно же, нужно обозначить дедлайн. Я обычно живу спринтами и задачи в любом случае на один спринт, так что сроки не указываю.

Образ результата. Что станет итогом, по которому вы поймёте, что задача решена?

Алгоритм действий. По шагам что нужно сделать, это обычно помогает выявить неочевидные зависимости. Например, если нужно от третьего лица забрать какую-то информацию, то это важная деталь о которой стоит знать заранее.

Какие ресурсы нужны. Если это рабочие часы, то указать каких именно сотрудников, если деньги, то прикинуть сколько именно. Можно очень приблизительно, важно понимать порядок и состав.

На что влияет. Задача ради задачи никому не нужна. Хорошо бы указать на какую метрику она влияет, какую гипотезу позволяет проверить и т.п.

Кажется, что пунктов много, но со временем вы привыкните. И не потому что это рутина, а потому что поймёте, зачем это нужно. Например, если образ результата не получается описать, то как мы поймём, что задачу сделали? Никак? Тогда, может быть, и начинать не стоит, а как-то переформулировать?

Или если нужны ресурсы тех людей, которые их не смогут выделить в оговоренный срок. Тоже частая проблема. Задачка на один час, начинаем делать за день до дедлайна. Но внезапно нужен какой-то документ от коллеги запросить. А он в отпуске. И всё, ошибка планирования.

Если вы проводите ретро и разбираете сделанные задачи, то кроме классического квадрата рекомендую отмечать сделана ли задача в целом, что именно получилось сделать, какой результат, выводы и опыт. Про ретроспективы расскажу в отдельном посте, правильно их проводить тоже не с первого раза получается.

Как проводить ретроспективы. Это когда у вас есть какой-то итеративный процесс и вы хотите его постоянно улучшать. Например, спринты в разработке или еженедельное планирование топ-менеджмента. В конце периода проходит встреча на которой вы смотрите как всё прошло и делаете выводы.

Для этого возьмите какую-нибудь доску или листок бумаги, разделите её пополам по вертикали и горизонтали, чтобы получить четыре равные области. Для удалённых команд можно использовать шаблон в Miro, например.

В левом верхнем выписываем то, что помогало вам выполнять задачи и двигаться вперёд. Это будут те вещи, которые нужно отметить и продолжать делать. Например, вы начали декомпозировать задачи прямо на планёрке и это помогла вам распределить их по дням недели и не делать всё в последний момент. Это позитивная практика, которую стоит сохранить.

В правом верхнем — то, что мешало и задерживало движение. Это то, что стоит перестать делать. Например, вы ранее решили встречаться каждый день и обсуждать текущие задачи. Но из-за этого встреч стало слишком много, а декомпозировать вы уже и так научились. Стоит перестать тратить время.

В левом нижнем — то, что стоит делать иначе. Любые нововведения и изменения, в том числе на основе предыдущих двух квадрантов. Как вариант — перестать вносить улучшения в продукт, потому что это отодвигает релиз, а нам важно уже запуститься. Хорошая идея, ведь итерироваться по фидбеку от рынка выгоднее, чем на основе своих фантазий.

И, наконец, в правом нижнем — действия. То, что мы реально возьмём в работу и применим в следующий спринт. Просто рефлексия — это уже хорошо, но какие-то идеи можно внедрить уже сейчас. Отменить встречи, поменять формат, добавить новые практики, сделать одну конкретную задачу, которая сильно поможет всем и т.п.

На каждую зону стоит тратить не больше 5–10 минут, на последнем этапе можно задержаться чуть подольше, чтобы провести обзор всех озвученных мыслей. На встрече один ведущий, который даёт высказаться желающим и поддерживает атмосферу доверия.

А теперь несколько ошибок, которые я совершал на первых ретро. Постарайтесь их не повторять, потому что иначе ничего не получится.

Обвинять друг друга. Ни в коем случае так нельзя делать. Ретро не для того, чтоб найти виновных, а для того чтобы выяснить как мы можем делать работу лучше.

Выводы в стиле «надо делать хорошо, а плохо делать не надо». Это прям классика. Как будто если что-то не успели, то значит надо времени больше заложить в следующий раз. Или лучше стараться. Меньше спать, может быть. Вы и так стараетесь, и так планируете с той точностью, с которой можете. Правильные ответы — декомпозировать, описать образ результата задачи, пойти чему-то научиться, привлечь эксперта и т.п. Какой-то инструмент, который даёт уверенность, что в следующий раз всё будет иначе.

Если у вас нет опыта подобных встреч, то скорее всего обе ошибки вы соберёте. Но это нормально, надо же как-то учиться. Если нужна будет помощь — пишите, могу организовать для вас первые ретро. Обычно так получается быстрее всего перейти к пользе.

Попробовал NVIDIA Broadcast, делюсь впечатлениями. Это такая программа для улучшения видео и аудио на созвонах и трансляциях. Если у вас видеокарта RTX 2060 или выше — смело пробуйте, достойная штука.

Работает как набор фильтров для микрофона, наушников и видео с веб-камеры. Можно отрезать шумы и эхо, причём как свои так и собеседника. Я во время тестов неистово печатал на механической клавиатуре и этого совсем не было слышно. Да и сам голос становится более чёткий, прям почти студийный.

На видео можно размывать или заменять фон, отслеживать лицо прямо как на айпаде, затемнять области по краям и самое интересное: эффект Eye contact. С этим фильтром вы как будто постоянно смотрите прямо в камеру, зрачки автоматически корректируются. Можно читать текст или смотреть на других участников созвона, а всем кажется, что ты смотришь прямо на них! Выглядит это немного крипово, конечно, но меня прям зацепило.

Такие ухищрения помогают мне чувствовать себя более уверенно на созвонах. Если понимаю, что меня хорошо видно и слышно, то как будто и мысли становится более чёткие.

Технически вся магия реализуется через добавление виртуальных устройств на Windows, так что использовать можно в любой программе: Zoom, Meet, Teams, OBS и т.д. И при этом нагрузка на комп заметно ниже, чем через встроенные функции в том же Zoom. Раньше во время звонков с демо экрана у меня всё легонько подтормаживало, теперь проблем нет.

P.S. Петличка на кадре с созвона BOYA M1 Pro, наушники Sony WH-1000XM3.

Теперь официально: получил сертификат об окончании курса по продажам. Очень доволен обучением, узнал много нового и активно применяю сейчас всё это на практике как в своём бизнесе, так и при работе с менти.

Дальше планирую взять небольшой перерыв в своём образовании: сходить в отпуск, подтянуть некоторые моменты в Tproger, начать менторскую работу ещё с одним проектом. А затем, конечно, снова учиться.

Если вы делаете бизнес и вам кажется, что у вас нет конкурентов — остановитесь и задумайтесь, может быть это значит, что и рынка нет. Возможно, проблема клиента, которую вы собираетесь решать не существует и это просто описание какой-то ситуации. А значит и покупать никто не будет. И бизнеса не будет.

А если всё же очень хочется попробовать, то придумайте конкурентов. Посмотрите на продукты-заменители, на какие-то альтернативные способы решения проблемы, которые ваши потенциальные клиенты применяют. Но никогда на питчах не говорите, что конкурентов у вас нет. Очень уж это всё подозрительно выглядит, интерес к проекту сразу падает.

ChatGPT, Notion AI, Midjourney, DALL-E 2 — кажется, что нейросети сейчас на пике ожидания. Как и с любой новой технологией, сначала нам кажется, что она решит все наши проблемы. Но затем мы неизбежно падаем в ущелье разочарования. Выясняется, что тексты не такие уж и крутые, картинки не всегда подходят, а ещё и запросы надо уметь подбирать. И десятки других неожиданных особенностей и вопросов. Постепенно появляется понимание, что новый инструмент хорош для определённых целей. И вот тогда мы сможем наконец-то выйти на плато продуктивности и упростить свою жизнь с помощью ИИ.

И вот этот самый вопрос меня сейчас больше всего волнует: что это за задачи такие, которые я буду решать с помощью популярных нейросеток? Пока что примеряю разное, но это больше похоже на игру. В потоке рабочего дня обратиться к ChatGPT у меня желание не возникает. А ведь рано или поздно должна сформироваться привычка, что определённый класс задач я решаю вот этой новой штукой. Пока что у меня это произошло только с удалением фона на фото/видео. Реально круто и быстро получается, не то что раньше с лассо в фотошопе.

А у вас уже есть какие-то рабочие задачи, в которых вы по умолчанию обращаетесь к ChatGPT? Что-то, что уже стало привычнее решать новым инструментом?

В недавнем выпуске рассылки Refactoring я прочитал интересную статью о том, как уменьшить количество совещаний в IT. По некоторым исследованиям это один из основных отвлекающих факторов для программистов. Автор делится методикой как либо сократить встречу и количество участников, либо вообще отказаться от неё, сохранив бизнес-процесс.

Мне кажется, что похожие приёмы подойдут и для любых других собраний в компании. Кратко перескажу суть, как я её понял.

Есть три типа встреч исходя из их цели: поделиться информацией, принять решения, создать что-то новое. Часто цели комплексные: сначала делимся информацией о том, как прошло, затем что-то планируем, например.

Берём всех участников встречи и распределяем их по матрице RACI.

R — Responsible, кто непосредственно выполняет задачи;
A — Accountable, принимает работу и несёт ответственность за результат;
C — Consulted, оказывает консультативную помощь;
I — Informed, просто хочет быть в курсе решений и хода выполнения.

Основная идея в том, что разным ролям нужны разные части встречи. Обзор выполненной работы, который по сути просто информирует участников, можно составить заранее и разослать для асинхронного просмотра. А на самих встречах ценнее всего обсуждать какие-то действия.

Как это сделать? Начать с составления повестки к каждой встрече. Это такое детальное описание того, что будет происходить по шагам. Относитесь к этому так, как будто вместо вас встречу будет вести какой-то новый человек и ему нужно объяснить, как это сделать. Т.е. прям вот подробно, со всеми необходимыми материалами.

Небольшой лайфхак, как приучить всех писать повестки на уровне компании: разрешите не приходить на встречу, если у неё нет описания. No agenda no attenda — легко запомнить.

Затем дайте людям возможность обсудить повестку: задавать вопросы, дополнять, комментировать. Вот уже часть встречи происходит асинхронно и в ней участвуют только те, кому это нужно.

Кроме того, можно выделить куски над которыми люди должны поработать заранее и не тратить время остальных: обновить статусы в OKR, собрать список сделанных задач и т.п.

Теперь мы можем безопасно сделать встречи более короткими:

— удаляем informed-роли, потому что обмен информацией теперь асинхронный;
— удаляем accountable-роли, им остаётся только одобрить или отклонить готовый док;
— responsible и consulted всё ещё могут собраться и обсудить решение проблем, но теперь это сделать куда проще т.к. большая часть уже оформлена в документе и можно сосредоточиться на отдельных спорных моментах.

Итого главная мысль: собираться и обсуждать лучше только то, что требует обсуждения. Вопросы, переписка по которым затягивается и есть разные мнения. А то, что можно подготовить заранее и просто показать в Google Doc — сделать асинхронно и сэкономить кучу энергии участников встречи, которая либо станет существенно короче, либо вообще отменится, если обсуждать нечего.