stepan.rodionov

Привет! Меня зовут Степан Родионов, я основатель сервиса учета финансов Adesk. Как предприниматель я запустил 10 стартапов, из которых «выстрелил» только один, а остальные провалились. Но этот опыт помог мне понять, что стоит за каждым успешным продуктом, — выводами делюсь в статье.

Относитесь к провалам спокойно

Моя юность была спортивной, поэтому мне близка аналогия между спортом и бизнесом. Предприниматели как и профессиональные атлеты на пути к успеху проходят через победы и поражения. Посмотрите на Майкла Джордана, легенду баскетбола: в NBA он провел 15 сезонов, из которых выиграл 6 и проиграл 9. Можно ли считать это провалом? Нет, эти поражения были частью его карьеры и не отменяют шести чемпионских титулов.

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

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

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

Учитесь вовремя останавливаться

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

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

Другая история: мой партнер по американскому проекту около 12 лет делал бизнес с коллегой. Первые 7 лет дело не приносило прибыль, и они работали на обычной работе, чтобы сводить концы с концами. В какой-то момент они приняли серию грамотных решений, и продукт «полетел»: через 3 года компанию купили за 20 млн долларов, а в ноябре 2025 года ее перепродали по оценке 450 млн долларов.

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

На старте не делегируйте

В соцсетях и на YouTube есть мнение, что владельцам бизнеса нужно нанимать управленцев и меньше работать руками, иначе погрязнешь в операционке. Я вижу, как начинающие и опытные предприниматели следуют этим советам, но у них ничего не получается из-за нехватки навыков делегирования. В итоге падает эффективность и срываются сроки: пока они два месяца ждут, как разработчики допилят MVP, меняется ситуация на рынке, и проект становится неактуальным.

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

В 2021 году мы запускали мобильное приложение Adesk для IOS и Android. Тогда я уже был CEO стартапа с миллионной выручкой, и разработка давно перестала быть моей зоной ответственности. Но релиз нужно было делать быстро, и чтобы ускорить процесс, приложение для IPhone я написал сам за две недели, а версию для Android делали разработчики на аутсорсе. В итоге через два месяца оба приложения были готовы.

💡 Вывод такой: если нужно делать быстро — а стартапу нужно делать быстро — то лучше не делегировать, а делать самому.

Не старайтесь сразу сделать все идеально

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

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

В IT проекты делают итерационно. Если бы дом строили как цифровой продукт, процесс выглядел бы так: возвели коробку — заселили людей и запрашиваем обратную связь. Они говорят: «Жить можно, но крышу бы поставить». Делаем крышу и снова спрашиваем: «А теперь как?» — «Окна нужны, а то холодно». Вставляем окна и действуем по аналогии.

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

Зачем мы добавили в сервис финучета выставление счетов

Меня зовут Степан Родионов — я предприниматель и основатель сервиса финансового учета для бизнеса Adesk. В своих проектах я всегда ставлю пожелания клиентов на первое место. Звучит пафосно, но это реально так: я и команда всегда прислушиваемся к пользователям и стараемся сделать сервис еще функциональнее, информативнее и удобнее.

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

На заре развития сервиса мы были особенно открыты к предложениям – хотелось выделиться среди конкурентов, добавить что-то полезное, но незаезженное.

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

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

Главная ошибка разработки или как слить 4 человеко-месяца в трубу

Adesk — это не первый мой проект, поэтому про MVP (минимально жизнеспособный продукт) я, конечно, знал. Но хотелось сделать сразу круто, поэтому мы забили забыли про MVP и приступили к чистовой разработке. Начали продумывать все-все детали, добавлять какие-то фишки, хотя и без них инструмент смог бы выполнять свою главную задачу — формировать счета.

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

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

Продумали даже функцию «Счет просмотрен», чтобы можно было отслеживать, в курсе ли контрагент, что вы ждете от него оплату. 

В итоге сформированные в сервисе счета выглядят так:

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

В общем, допили все до почти идеального вида и торжественно выкатили обновление. Чтобы пользователи точно заметили такую классную и удобную фичу, добавили ее в главное меню сервиса, назвав «Счета». И тут началось…

Реакция клиентов: вместо благодарностей просьбы убрать ЭТО из главного меню

Через несколько дней после выхода обновления в чат поддержки снова стали приходить сообщения. Нет, не от довольных пользователей. Оказалось, что «Счета» люди воспринимают, как банковские счета, поэтому постоянно тыкают туда, видят не то, что ожидали, и нервничают.

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

Конечно, некоторые оценили обновление и стали выставлять счета через Adesk. Но даже они периодически присылали в чат поддержки замечания: то печать не так ставилась, то подпись съезжала.

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

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

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

Мы все еще остаемся клиентоориентированным сервисом — слушаем, что говорят пользователи, стараемся максимально облегчить работу с Adesk, но теперь следуем трем правилам:

1. Проверять, есть ли реальная потребность в том или ином инструменте.

2. Проверять, правильно ли мы проверили в п.1.

3. Начинать с малого: сначала MVP, а уже потом разные украшательства.

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

Часто задумка отваливается уже на первом этапе — во время общения с пользователем. Например, может выясниться, что решить проблему пользователя можно имеющимся функционалом. Если забираем идею в работу, стараемся сделать сначала «пробный», но уже жизнеспособный вариант, а потом допиливаем его по фидбэку от пользователей.

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

В общем, шишек мы тогда набили — не делайте как мы. Лучше сразу следуйте советам, выстраданным мной на собственном опыте — сэкономите кучу времени, нервов и денег.

1. Выявляйте реальные потребности клиентов: зачем это нужно, как собираются использовать. Например, когда запускали в разработку «Согласование платежей», выяснили, что люди не хотят бегать по кабинетам с бумажным счетом или спамить на почту – в этом и была главная потребность.

2. Подбирайте решение, которое закроет максимум юзеркейсов. Но, разумеется, минимально возможными усилиями. Разные красивости лучше оставить на потом — на начальном этапе важно, чтобы разработка выполняла основную задачу и закрывала потребность.

3. Подумайте, всем ли нужна ваша разработка. Возможно, имеет смысл сделать ее дополнительным модулем и подключать по запросу. Так вы и потребность закроете, и раздражать никого не будете.

4. Вкладывайте ресурсы в разработку, только когда убедитесь в востребованности идеи. Грамотно управляйте ресурсами своей компании и временем сотрудников, чтобы потом не писать на vc, как ваша идея провалилась, а вы потратили на ее реализацию 4 человеко-месяца.

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