Павел Семенов | В шляпе заказчика

Презентации очень рекомендую к просмотру – особенно тем, кто из маркетинга и фармы ☝️

Для тех, кто в фарме

Выступая здесь на прошлой неделе, транслировал ту точку зрения, что хотя в силу объективных обстоятельств (регуляторика, рецептурка, ограничения на рекламу и прочее) фарма и отстает во внедрении платформенных решений (которые много где уже настоящее коммодити), они в нее все же проникают и часто с неожиданной стороны.
Мы, например, ждем маркетплейсов, агрегаторов и прочих Уберов на клиентской витрине — а оцифровывается операционка: полевые команды, аудит, управления отчетностью с мест, данные.

Интересно, что тезис этот был мгновенно, в ходе той же сессии, подтвержден выступлениями уважаемых коллег из сферы медицинского косалтинга — компаний MMD и Denis Pharm, в лице Могоммеда Акперова и Ольги Зюкиной (они любезно предоставили свом презентации для канала, найдете их ниже). В первом случае было описано проникнование классических продуктовых техник тестирования гипотез в медмаркетинг, во втором – рассказано о создании платформы для моделирования действий полевых работников.

Так что если вдруг ваша индустрия недооцифрована и вы видите серьезные препятствия, мешающие развивать платформы и цифровые сервисы для конечного потребителя, задумайтесь: а все ли в этом плане сделано для вашей операционки? Возможно, там есть куда копнуть 👇

В будущую среду, 25 марта, выступаю на ежегодной конференции "Фармаслава 2026" — в секции "Диджитал-тренды в фарме".
Расскажу о том, как платформенные технологии начали просачиваться на фарм-рынок с совершенно неожиданной стороны.
Так что всем, кто имеет отношение к фарминдустрии или интересуется ей — рекомендую быть: отличная плотная программа, спикеры из фармкомпаний, маркетинга и медицинского консалтинга.
Шикарная возможность для нетворка!
Москва, отель «Золотое кольцо», старт в 09:30 📆

Вообще этот канал немного про другое

Однако удержаться и не поделиться такой новостью было невозможно, потому что мы очень гордимся этим кейсом 🙂

Для коллег из Rippla мы в 2025 году, всего за 4 месяца, выпустили MVP и вот уже год с лишним, как продолжаем двигать продукт вперед — и позавчера он взял победу в лиссабонском акселераторе от Unicorn Factory, обойдя 150 других претендентов 💪

Так что мы в Redstart очень радуемся, что являемся частью этой победы — и, возможно, сможем помочь одержать будущие победы и вам!

Про уверенность экспертов

В книге "Думай медленно, решай быстро" Даниэль Канеман выразился так: "Беспристрастное признание собственной неуверенности — краеугольный камень здравомыслия, однако большинство людей и организаций ищут совсем другое".

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

Об этом стоит помнить, слушая уверенные речи на этапе оценки проекта 🙂

Не делайте так!

Это скрин с одной из тендерных площадок – из раздела с дополнительными вопросами к исполнителю, на которые тот должен ответить будущему заказчику 💀
Заведомо контрпродуктивная и вредная для проекта позиция, типа "если вы много спрашиваете, вы не профи".

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

Резюме:
- перед стартом проекта обязательно разберитесь, что именно вам нужно или хотя бы какую конкретно бизнес-задачу вы хотите решить;
- уточняющие вопросы от заказчика – это добро, потому что они снижают неопределенность в проекте.

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

Про поиск "своего" подрядчика

Это вопрос мы уже обсуждали, как и вопрос опыта, а сейчас давайте о том, что такое экспертиза и, в особенности, что такое отраслевая экспертиза.

Совсем недавно обсуждали эту тему с коллегами: завязалась жаркая дискуссия и по ее итогам мы сформулировали несколько важных моментов.

1️⃣ Если вдруг подрядчик сделал 5 сайтов для стоматологических клиник, можно ли его считать экспертом по сайтам для стоматологических клиник?
Скорее всего нет. Потому что сайт сам по себе не влияет на то, как работает бизнес такой клиники. При готовом контенте и минимально сформулированных требованиях его сможет сделать кто угодно.

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

Соответственно 👇

Если вы ищете подрядчика для того, чтобы сделать себе лендинг – то никакая нишевая экспертиза вам не нужна. Ищите вариант, который:
🟢 максимально вам понравится визуально;
🟢 подойдет дл решения задачи;
🟢 будет стоить недорого;
🟢 сделают его относительно быстро.

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

Не делегируйте
Раз уж мы заговорили о том, как делать не надо – то вот практический совет

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

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

До тех пор, пока вы не получили MVP, первую итерацию или любую первую технологически законченную версию вашего продукта или проекта – постарайтесь максимально участвовать в этом сами.
Потому что, если вы сформулировали идею и видение, если именно вам в голову пришла идея о том, что этот проект или продукт поднимет ваш бизнес на новую высоту, вам будет правильнее уделить этому максимальное время. Почему?
Ну, хотя бы потому, что вы, как я могу предположить, уделяете достаточно времени тем вещам, которые напрямую влияют на ваш бизнес. А этот проект/продукт как раз и будет такой самой вещью. И ни один наемный сотрудник, даже компетентный, не подойдет к этому так, как к этому подойдете вы.
Другим будет подход. Глубина проработки. Смелость и скорость решений. Качество этих решений.
Поэтому самое последнее, что вы можете сделать, это делегировать кому-то работу над проектом на его начальной стадии. Занимайтесь сами: вникайте, тратьте на это время, потому что это время не пропадет зря. Весь мой опыт работы с различными заказчикам и проектами свидетельствует: успех проекта прямо пропорционален тому, сколько времени лично вы на него потратите 💎

...к предыдущему посту 👇

Энтони Уорнер, британский шеф-повар и популяризатор науки, как-то написал: «Наука непригодна для трансляции лаконичных, четких сообщений и определяется в равной мере тем, что она знает и тем, чего не знает».

В общем-то, то же самое можно сказать о профессионалах и профессионализме.

Уверенность может обеспечить хорошие продажи – но найти верные решения поможет только сомнение.

Так что будьте осторожнее, когда слышите очень уверенные рассказы о том, сколько будет стоить проект, сроки разработки по которому оцениваются больше, чем в 3 месяца 💀

Про опыт
Как его понимает заказчик и что он из себя на самом деле представляет в индустрии проектной разработки

Довольно часто на раннем этапе переговоров, когда определяется формат работы над проектом, мне приходится озвучивать тот тезис, что сейчас невозможно точно знать, сколько времени займет проект и сколько денег он будет стоить. В ответ звучит удивление, мол, как же это так, мы – такие опытные, уже сделавшие много подобных проектов – и не имеем ответа на вопрос 🤔

Я провел много времени, обдумывая этот момент и пришел к выводу о том, что многие заказчики, наверное, не до конца правильно понимают, что такое опыт, по меньшей мере в ИТ и цифровых технологиях.

В нашем деле опыт – это не когда ты заранее знаешь, сколько времени займет работа над проектом или сколько он будет стоить (потому что будущего на самом деле не знает никто). Опыт – это когда ты умеешь отличать верные решения от неверных и умеешь выбирать правильный путь.
И вот длина пути при этом вполне может быть неизвестна. Зато с ходу отмести в сторону неправильное решение и неверный путь – это и есть настоящее проявление реального опыта.
Я бы даже сказал так: максимально ценен не тот, кто скажет вам, как надо делать, а тот, кто скажет, как точно делать не надо.
На старте знать верное направление – важнее, чем знать расстояние.

Вот тут я уже писал подробно, почему ориентирую канал на непрофи.

Если коротко: быть компетентным заказчиком — выгодно.

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

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

Подумал о том, что лучшим способом выйти из комы паузы — напомнить всем (да и самому себе тоже) что это за канал 🙂

Итак 👇

▪️Это канал для непрофессионалов.
▪️Это канал для непрофессионалов, у которых появилась идея сделать что-то цифровое.
▪️Это канал для непрофессионалов, у которых появилась идея сделать что-то цифровое и им срочно нужно это разработать.
▪️Это канал для непрофессионалов, у которых появилась идея сделать что-то цифровое и им срочно нужно это разработать, но они не знают — точно ли надо это делать и если да, то как сделать это так, чтобы не потерять деньги и время.

Здесь мы рассказываем 💬

🔹 как понять, что ваша идея жизнеспособна
🔹 что надо сделать до того, как принять решение о разработке
🔹 как понять, что у вас вообще за проект
🔹 как найти своего подрядчика
🔹 чего не надо делать вообще
🔹 с чего начать
🔹 как продолжить
🔹 и даже как оживить ваш проект, который, казалось бы, не сработал или забуксовал

В общем, надеваем шляпу заказчика — и вперед ✌️

Перечитал пост и показалось, что как-то сложно завернул про итерационность и то, что с ней связано 🤨
Нет такого ощущения? Не думаете, что обычного заказчика волнуют вещи попроще – или даже вообще другие?
Если да – то отреагируйте, плиз, чтобы было понятно, куда держать курс 👋

💯— тема хорошая, но сложновато было
🔥— все супер, побольше бы такого!
❤️— есть темы и поинтереснее

(к предыдущему посту)
Как становится понятно из поста выше – итерационность тесно связана с понятием MVP, как точки зрения планирования на проекте, так и с точки зрения решения клиентских проблем.
Вам, как заказчику, важно это понимать, хотя бы потому, что часто MVP – это и есть первая итерация проекта 🙂

Так что вот отсылки к постам, в которых мы чуть раньше говорили об MVP и о том, почему заказчику важно знать, что это такое:
▪️ раз
▪️ два
▪️ три

Итеративность здорового человека как она есть

Как и было обещано, начинаем разгонять по поводу итерационного подхода 👌

С чего здесь стоило бы начать?
Я думаю, что начать будет правильно с той самой знаменитой картинки – на которой скейтборд превращается в самокат, самокат в велосипед, велосипед в мотоцикл, а мотоцикл – в машину.
Ее лет 15 назад нарисовал Хенрик Книберг, для своей (отличной, кстати говоря) книги Lean From The Trenches.
Вообще обычно с ее помощью иллюстрируют и объяняют, что такое MVP, но как мне кажется, вопрос с итерационностью она тоже проясняет идеально.

В чем тут суть?
На самом деле вовсе не в том, что мотоцикл дешевле машины, а велосипед дешевле мотоцикла, хотя это, конечно, тоже правда.
Идея на самом деле заключается в том, что каждое из нарисованных на картинке решений полностью выполняет свою функцию. В данном случае – доставить человека из пункта А в пункт Б быстрее, чем пешком.
То есть. Когда мы говорим об итерационном подходе, мы в первую очередь имеем в виду, что в каждой своей итерации, начиная с самой первой, конечный пользователь продукта продукта должен получать решение своей проблемы.

Условно, если это приложение по заказу еды, то человек с его помощью должен получить домой еду. Он может заплатить за нее наличными, он может получить обратный звонок от оператора или сам ему позвонить. Много моментов на этапе заказа могут быть упрощены или вообще пропущены. Но самое главное – человек должен иметь возможность выбрать еду, как-то рассказать о своем выборе ресторану и каким-то образом получить ее домой. Все остальное – вторично.
Это уже потом вторая и все дальнейшие итерации будут ориентированы на то, чтобы улучшать процесс заказа, упрощать его и всячески способствовать тому, чтобы бизнес получал больше денег, а клиент – больше удовольствия.

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

Резюме ☝️
В ходе каждой итерации проблема клиента должна решаться целиком.
Поэтому, сокращая сроки и бюджеты, следим за тем, будет ли разрабатываемое решение в ходе промежуточных итераций продолжать решать клиентскую проблему от А до Я 🧐