Процесс создания продукта - наш подход к созданию продукта
В этой статье покажем, как мы создаем решения на базе нашей платформы, что в себя включает процесс создания продукта и другие вопросы, связанные с продуктом. Пару слов о контексте: у нас есть веб-платформа Falcon Space, которая значительно снижает издержки процесса разработки.
Введение
В этой статье покажем, как мы создаем решения на базе нашей платформы, что в себя включает процесс создания продукта и другие вопросы, связанные с продуктом.
Пару слов о контексте: у нас есть веб-платформа Falcon Space, которая значительно снижает издержки процесса разработки. Если бы мы делали эти решения с нуля, то это стоило бы очень дорого, это сложно было бы поддерживать в виду трудоемкости, требовалось бы гораздо больше людей для сопровождения. Мы идем по пути от заказной разработки к продуктовым решениям. В текущий момент наш основной продукт - платформа, но разработка кастомных решений, хоть и снижает кардинально трудозатраты, но все же не дает масштабироваться. Все так же нужны обученные люди для работы в проектах, и это является узким местом для роста.
Зачем создавать готовые решения?
Это далеко неочевидный вопрос. Ведь решения требуют затрат, мы можем зарабатывать прямые деньги на коммерческих проектах, а вместо этого тратим время на внутренние проекты, на создание решений. Более того, большинство веб-студий и не идут в эту сторону, т.к. высокие затраты, риски, окупится/не окупится - зачем все это, если есть и так заказы и работа на проектах заказчика.
Так зачем создавать программный продукт?
Возможность роста и масштабирования
Узкое место в нашей работе - специалист. Вы не можете на принтере распечатать специалиста в количестве 100 единиц для увеличения количества проектов. Процесс становления специалиста сложен, это долгий путь.
Готовые программисты - это дорого и не то, что нужно (т.к. они будут писать код по своим соображениям и правилам, а это усложняет его поддержку при большом количестве людей).
Продукт дает возможность делать неограниченное количество копий (или работать как Saas сервис).
Для обслуживания нового клиента не нужно подключать пропорциональное количество усилий специалистов. Еще будет лучше, если для сопровождения продукта вообще не требуются специалисты.
Снижение рисков
Создание продукта дает дополнительную степень свободы. Вы можете продавать услуги, а можете продукт. Также вы можете создать новый продукт на базе существующего продукта. Именно так мы и делаем с Falcon Space. На базе созданной платформы мы создаем готовые решения.
Falcon Space - это сам по себе продукт, как инструмент для создания функциональных сайтов с личными кабинетами на базе SQL.
А решения - это уже заточенное под определенную бизнес-задачу сайт с необходимым функционалом, реализованном в рамках платформы.
Мы можем продавать готовые решения, либо делать проекта на базе чистовой платформы. Не будет успеха по продажам решений? Значит будем делать кастомные проекты на базе Falcon Space.
Лучше понимать потребности клиентов
Наш типовой клиент решает примерно ту же задачу - создает продукт для своей аудитории.
Чем больше мы погружаемся в процесс становления продукта, продвижения на рынке, тем лучше мы понимаем потребности нашего клиента, тем ближе мы становимся к нему.
Чем лучше мы знаем проблемы клиента, тем точнее мы можем создавать свой контент для него.
Риски простоя программистов
Некоторые клиенты могут неделями мурыжить и тянуть с оплатами или приемкой. А в это время нам нужно давать нагрузку программистам. Т.е. если для заказчика простой в проекте - это нет никаких проблем, то для команды разработки - это серьезная проблема.
Обычно она решается за счет работы программиста на нескольких проектах. Это снижает скорость отдельного проекта. Заказчик хочет, чтобы работали только над его проектом - в реальности это практически невозможно именно из-за проблем простоев, которые клиент не учитывает и ему до этого нет дела.
Создание внутреннего проекта - отличный способ заполнения вакуума. Есть свободное время - давайте внедрять новую фичу в продукт. У вас должен быть заранее сформирован план по требуемым фичам в продукте.
С чего начинается проработка продукта
Здесь рассмотрим с чего начинается проработка программного продукта.
Мы исходим из того, что не знаем, что нужно потребителю наверняка. Мы просто держим нос по ветру, и идем туда где есть спрос, и мы можем как-то удовлетворить этот спрос. Это значит, что мы не делаем ставку на одно единственное решение.
Мы делаем множество разных базовых решений, которые могут быть интересны нашим клиентам и лучшие из решений мы развиваем вглубь.
Также есть и внешний фактор - продвижение контента, конкуренты. К примеру, наше решение Falcon Marketplace менее функционально, чем CS Cart. Оно скорее является хорошей начальной заготовкой для допиливания решения под свои нужды (т.е. чисто как коробка товарной площадки оно сильно уступает конкуренту).
Некоторые другие решения сложно продвигать в плане контента, т.е. не получается добиться достаточного трафика.
Учитывая все эти многочисленные факторы, мы можем делать ставку на различные продукты.
Далее будем рассматривать создание одного продукта, но помним, что параллельно может создаваться постепенно несколько продуктов.
Рассмотрим ключевые моменты по первым шагам в проработке продукта.
Идея - проблема - потребитель - решение
Сначала нужно определиться с базовыми элементами.
Обычно возникает некая идея, например, а почему бы не сделать доску объявлений для студентов, где они могут предлагать свои услуги, продавать товары и т.д. Далее детализируем проблему и чья это проблема. Есть ли проблема у студентов для оказания услуг или поиска товаров или что-то? Как они сейчас решают свои задачи?
Затем определяем наше возможное решение - создать такую-то площадку с такими-то условиями.
Если вы начинаете спотыкаться на каком-либо вопросе - это уже знак, что проект не выгорит. Здесь не нужно быть оптимистом. Думаю, из-за излишнего оптимизма в начале погорели очень много проектов.
Лучше идею обоснованно откинуть на начальном этапе, нежели это сделать через полгода, когда туда вбухано кучу средств.
Приведу пример. Сейчас у нас возникла идея делать систему учета для лабораторий. Мы проработали структуру проекта с человеком, понимающим в этой отрасли, и поняли, что это долго, дорого и результат совсем неочевиден. Плюс у нас нет текущего спроса на это. Как мы это будем продавать? Этого понимания нету, поэтому пока просто сделаем описание структуры проекта и отложим до лучших времен. Затраты практически нулевые, мы ничего не потеряли.
Концепт продукта
Необходимо определиться с видением своего продукта в виде документа.
Обычно клиентов мы просим создавать концепт продукта на базе нашего шаблона.
Концепт продукта позволяет его предметно обсуждать с другими людьми. Очень напрягают люди, которые начинают описывать свой проект очень неконкретным языком и хотят точную оценку бюджета.
Большой плюс концепта - не нужно каждый раз тратить время на пояснение проекта.
Также вы можете итеративно улучшать его. После каждого общения или просмотра сайтов-конкурентов возникают новые идеи, которые можно отразить в концепте проекта.
Критический анализ и сбор обратной связи
На этом шаге надо посмотреть на все это дело с пристрастием. Не закрываем ли мы глаза на слабые стороны продукта? Что думают потребители про него? Есть ли уже реальный интерес к продукту?
В теории учат, что на продукт надо получить предзаказы, и это является хорошим подтверждением идеи продукта. В реальности это сложно сделать и приходится ориентироваться на менее твердые аргументы.
Если брать нас, то мы ориентируемся на спрос в кастом проектах. Некоторые типы проектов заказывают чаще. Чтобы сделать чище следующий проект подобного типа, мы улучшаем наши наработки, и в итоге это и является для нас решением. И это итеративный процесс. Когда-то мы считали продуктом решением аукцион без главной страницы - просто говорили, что главная страница делается как ленд под проект.
Сейчас мы приходим к пониманию, что в продукте по мере возможности все должно быть доведено до конечного использования (желательно вообще без задействования тех специалистов).
Также имеет смысл учесть всевозможные факторы - платежеспособность, сезонность, стоимость продвижения, запрещенность товаров и услуг к рекламе и т.д. Чем больше факторов вы учитываете в самом начале, тем меньше будет риск закрыть проект на поздней стадии.
Пока вы практически ничего не потратили, вы легко можете отказаться от проекта. Чем дальше - тем сложнее отказываться от проекта.
В итоге по завершению анализа вы должны принять обоснованное решение - делать ли этот продукт. Если да, то почему он будет иметь успех. Если нет, то почему его никто не купит (или почему его сложно сделать).
Задокументируйте свое решение. Возможно через несколько лет ситуация изменится, и вы вернетесь к проекту. Вы будете точно знать, почему вы решили не делать проект. Посмотрев свои записи, вероятно, вы еще раз отложите эту идею до лучших времен.
Детализация концепта
Если вы решились окунуться с головой в проект, прорабатывайте вглубь вопросы.
-
Определитесь с ядром проекта.
Важно разделять ключевые возможности продукта и второстепенные составляющие. Это необходимо, чтобы уменьшить бюджет первой версии продукта.
Сделайте настолько малый продукт, насколько это возможно, но при условии, что он еще будет иметь ценность для потребителя, и он готов платить за него.
Это простая очевидная идея почему-то часто не доходит на среднестатистического заказчика. "Как же я покажу сырой продукт? Его увидят и больше не вернутся" - такой обычно ответ.
Минимальный продукт - это не сырой продукт, а минимальный.
В нем должно быть только самое важное, но выполнено оно должно на хорошем уровне (по крайней мере в глазах потребителя). Если вы хотите делать все и сразу, скорее всего вы вообще не запустите проект. Во-первых, нужно будет в разы больше бюджета и гораздо больше срок. А во-вторых, вы будете постоянно откладывать запуск продукта для внедрения еще 10 очень важных функций.
Свои решения мы публикуем, как только они выполняют базовую функцию. Конечно потенциальные клиенты говорят, что им не хватает в решении. Мы анализируем эту обратную связь и что-то из этого внедряем в продукт постепенно.
Таким образом, разработка начального решения могла занять 1-2 месяца, но его доработка никогда не прекращается. Постепенно появляются новые возможности. В этом плане мы ориентированы на долгосрочную перспективу, а не на желание поставить как можно быстрее полнофункциональный продукт на рынок.
-
Как продвигать программный продукт на рынке
Мы верим в контент. Контент - это статьи, видео, документация, кейсы, демо функционал.
На каждое решение мы создаем целую стопку контента:
- ленд решения - здесь описываем возможности, условия поставки, стоимость, вопросы по решению;
- демо - на демо человек может посмотреть основные возможности решения;
- статья про демо - статья подробно описывает как решать бизнес-задачу с помощью решения;
- документация админа и программиста - описывает как сопровождать систему, какие есть настройки для менеджера сайта;
- презентация решения - небольшой PDF буклет, который можно давать клиенту для печати;
- стандартное КП - Excel файл с типовым КП по решению;
- видео обзор по решению - делаем базовый видеообзор с проходом по демо;
- набор обзоров на внешние площадки для продвижения через вечные ссылки.
Возможности оптимизации контента мы разобрали в другой статье.
Рекламу мы практически не используем. SMM в минимальном виде - только публикация контента в группе. Также имеет смысл писать статьи про решения и на косвенные темы на различных контентных площадках с упоминанием вашего решения.
Важный фактор - внутренняя оптимизация. Все ваши материалы должны по максимуму учитывать факторы поисковой оптимизации.
Определитесь со своим планом продвижения - что вы будете делать, сколько требует бюджета, на какие результаты вы рассчитываете.
-
Ключевой маркетинговый посыл продукта
Считаю очень важным иметь некое ключевое сообщение для потребителя, которое выделяет ваш продукт в лучшую сторону. Если такого сообщения нет, то выбирать будут по цене.
Если брать нашу платформу Falcon Space, то наша главная особенность - это возможность брать готовые решения и глубоко адаптировать их под себя.
Это ключевая идея и отличие. Большинство других типовых решений либо вообще не кастомизируемы в плане бизнес-логики, структуры данных, либо кастомизация предполагает полноценный сложный дорогой цикл разработки.
В нашем случае все доработки делаются в рамках узкого стека SQL + HTML. Большинство решений может поддерживать один специалист, знающий платформу и умеющий писать хранимые процедуры на SQL, а также базово знающий HTML верстку в Bootstrap 4.
Определитесь, в чем ваш главный маркетинговый посыл, что ваш потребитель должен запомнить о вашем продукте в первую очередь.
Тут есть еще один важный момент - это должно быть значимо для клиента. Если вы делаете какую-то особенную штуку, но она не особенно для кого-то имеет смысл, то это не идет в зачет.
Процесс создания продукта - чек-лист подготовки решения
Здесь мы представим небольшой чек-лист готовности решения. Возьмите его за основу и расширьте под свой продукт.
ДЕМО и КОНТЕНТ
- Ленд главной - главная страница имеет законченный лендинг;
- Готовые текста стат страниц - все статичные страницы прописаны;
- Юридические страницы - правила пользования, приватность;
- Кабинет админа под демо - в кабинете админа все доработано;
- Кабинеты юзеров под демо - в кабинетах пользователей нет недоработок;
- Корректные демо данные - в демо все данные выглядят как реальные;
- Ленд описания системы;
- Документация на решение для администратора;
- Дока программиста;
- Локализация (если требуется);
- Презентация PDF по решению;
- Видео на ленде и в демо.
ТЕХ МОМЕНТЫ
- Чек-лист теста демо;
- Страница notfound;
- Страница noaccess;
- sitemap, robots;
- favicon, logo;
- Адаптивность - есть ли страницы с проблемами на мобильных устройствах;
- Метрика - подключена ли Яндекс Метрика;
- Вебмастер - Подключены ли Гугл и Яндекс Вебмастер;
- Форма настройки решения - внедрена ли форма базовой настройки решения;
- Полная чистка по ревизии - проведена ли полная ревизия кода с последующей чисткой.
ПРОДВИЖЕНИЕ
- Ключи - сформировано ли семантическое ядро;
- Статья про демо - написание лонгрида по решению;
- Перелинковка на демо из контента (>20 ссылок);
- Видео по демо;
- Сбор обратной связи через Linked,ВК, ФБ у целевой аудитории;
- Оттачивание презентации в колле;
- Директ на демо;
- Размещение обзоров на внешних площадках.
Некоторые элементы могут быть для вас неактуальные, но я решил оставить все как есть. Возможно это натолкнет вас на смежные идеи, что можно включить в ваш чек-лист по подобию.
Аналитика по программному продукту
Когда решение уже работает - имеет смысл отслеживать его результаты. К примеру, в нашем случае - это количество визитов на сайт, количество регистраций на демо, количество лидов, количество КП и т.д. Имея такую статистику во времени, можно понять развиваетесь вы или деградируете.
Также можно понять проблемные места. Например, лидов много, а КП выставили почему-то мало. Либо лиды не те, либо менеджер плохо сработал.
Периодический анализ показателей дает возможность находить проблемные места.
Не делайте аналитику слишком сложной. Детализируйте ее по ходу развития продукта. Начните с отслеживания базовых параметров и добавляйте постепенно значимые события, которые вы хотели бы увеличить или уменьшить.
К примеру, недавно мы внедрили такой параметр как количество совместных просмотров демо с клиентом. Плюс по каждому такому просмотру фиксируется обратная связь по демо. Одно дело, когда сам клиент посмотрел демо, и совсем другое, когда это происходит в диалоге с менеджером.
Отдельный момент - просчет юнит экономики.
Скажу как есть: я не использую в прямом смысле юнит экономику. Мы пробовали разные подходы для внедрения этого. Но пока в этом мало пользы конкретно для нас. А если нет пользы - мы это не используем. Вполне вероятно это будет для нас актуально, когда мы плотно будем задействовать рекламные каналы, т.е. возникнут ощутимые затраты на рекламный бюджет.
В некоторых проектах вижу такую ситуацию - давайте все подряд использовать, может что-то поможет. Я считаю, что нужно отрезать лишнее, ненужное, что не несет практической выгоды. Чем больше инфраструктура решения, тем выше риски сбоев, тем сложнее поддерживать решение.
Пробовать и экспериментировать с разными возможностями обязательно нужно, но бездумно расширять продукт всем подряд - прямой путь к плохому продукту, низкому качеству и нестабильности.
Работа с рисками программного продукта
Стартап или новый продукт - это всегда большие риски. Большинство продуктов не взлетают. Просто по статистике. И нет оснований думать, что в вашем случае будет по-другому.
Есть такой замечательный эффект - Эффект Да́ннинга-Крю́гера.
Считайте лучше, что ваши шансы успешно внедрить стартап относительно невелики и действуйте исходя из этого понимания.
Как мы это применяем в нашем случае:
- Мы не вкладываем много средств в создание тяжелых решений. Мы делаем небольшие решения и смотрим как на них реагирует рынок.
- Мы делаем решения, которые нам нужны самим. Например, внедряем в решения отчеты БДДС или делаем модуль тестирования (самооценка по знаниям). Это нужно нам самим в работе. Но при этом это становится и частью некоторых решений.
- Мы делаем множество разных решений, т.к. понимаем, что мы мало что понимаем в бизнесе клиента. Мы не специалисты по логистике, не были никогда риэлторами. Мы можем только предполагать, что им нужно и это реализуем в наших решениях. Что-то выстрелит, что-то заморозится. То, что будет иметь спрос - будем развивать.
- Решения можно менять и адаптировать. Это делать относительно недорого в определенных рамках. Если решение сложно менять - оно не сможет долго существовать в долгосрочной перспективе.
Мы не подходим формально к рискам, не формируем четкий список рисков для каждого решения. Есть только общее понимание по ним.
Мы стараемся снизить критичность риска за счет небольших затрат, т.е. инвестиции в каждое решение совсем небольшие (в первую очередь за счет своей платформы и наших наработок в решениях).
Главный риск любого продукта - он никому будет не нужен.
В первую очередь снижайте этот риск.
Вероятность можно снизить за счет раннего привлечения потребителей и плотной обратной связи.
Критичность снижайте за счет лимита вложений на первую версию.
Если будет позитивный фидбек, то можно расширить инвестиции в продукт.
Сколько стоит создание программного продукта
Если вы внимательно прочитали статью, то будет понимание, что этот вопрос неверно поставлен. Нужно оценивать конкретный продукт с конкретным набором возможностей, а не в целом.
В плане наших решений мы не отслеживали точно затраты на реализацию продукта.
Все созданные решения мы финансируем из прибыли по коммерческим проектам.
Если денег и времени хватает, то выделяем время на создание нового продукта или шлифовку существующего решения. Если мы не успеваем где-то по задачам в коммерческих проектах, либо есть риск кассового разрыва - все внимание на коммерческие проекты.
Если вы хотите для своего продукта получить оценку бюджета, то сосредоточьтесь на точном описании первой версии продукта.
Чем точнее она описана, тем точнее будет оценка бюджета и сроков. Помните, что оценка будет очень сильно зависеть от исполнителя. Если это фрилансер - это одна цена. Если это студия, то это 3х стоимость. Если это топовая студия, то 10х бюджет.
Также важен инструмент и способ разработки. Разработка с нуля - очень долго, дорого и много багов. Взять готовое коробочное решение - начальная стоимость невысокая, но дорогая кастомизация.
Один и тот же проект может стоить 250 тыс. руб., а может 2,5 млн рублей.
Крайний случай, вызывающий недоумение, который я видел в плане оценки сметы - это пункт сметы Смена пароля стоил 55 тыс. рублей. Сложно сказать, что они там будут делать с этим паролем, но рамки возможного это меняет.
Уточняйте, что именно вы получаете за тот бюджет, который сформирован на проект.
Также важно учесть множество побочных будущих затрат, которые вы сейчас не осознаете. То, что вы о них не знали, никак не освобождает вас от этих самых затрат.
Какие могут быть дополнительные затраты при создании продукта
- Баги - баги могут быть по вине пользователей, а могут быть внутри продукта. Баги могут проявиться не сразу, а только при определенных событиях в системе.
В плане багов важно понимать, что невозможно никогда быть на 100% уверенным, что багов нет. Но должна быть высокая готовность быстро решать баги. Для этого ваш продукт должен иметь хорошие средства диагностики багов, логирования различных событий, чтобы можно было быстро разобраться с возникающими проблемами.
- Контент. Контент требует денег. Размещение контента требует денег. Одна нормальная статья может стоить 3-10 тр. Размещение статьи сильно зависит от уровня площадки. Топовые СМИ берут по 100-150к за размещение подобных материалов.
- Реклама. Тут все зависит от ваших аппетитов и возможностей. Если есть задача очень быстро слить бюджет, то реклама - это та самая статья расходов, что вам нужна.
Определитесь со стратегией рекламирования вашего продукта - какие каналы, какой бюджет, какие сообщения, как вы будете заменять результаты рекламы.
- Новые идеи. Новые идеи приходят внезапно. И их внедрение требует новых средств. Ваш текущий бюджет не учитывает эти будущие идеи. Следовательно, вам требуется либо отказаться от этих идей, либо готовить запасы для реализации этих идей.
- Операционная работа. Кто будет обрабатывать новые отклики на сайте? Кто делает модерацию контента? Все эти моменты также требуют затрат. Сразу определитесь со всеми активностями и разберите сколько людей какой квалификации требуется для обслуживания этих активностей.
Главная идея по непредвиденным расходам - создавайте в проекте дополнительный буфер по бюджету и срокам. Процесс создания продукта подразумевает множество неопределенностей, которые требуют затрат.
Если вам нечем будет заткнуть дыру в лодке посреди реки, то итог печален и предсказуемым. Берите с собой заплатки, насос, запасную лодку, жилеты. В нашем случае - это запас по времени и финансам.
Заключение
Мы постепенно переходим в продуктовую разработку.
Пока еще очень высок процент дохода именно от доработок в клиентских проектах. Сейчас чаще проект делается на базовой части платформы, а не решении. Но мы выбрали направление и движемся в сторону адаптации и настройки готовых решений, а не создании решений под клиента на базе чистовой платформы.
Сейчас мы сосредоточены на становлении 3 продуктов:
- Falcon Auction - площадка услуг для поиска испоолнителя;
- Falcon Service - сайт с личными кабинетами для клиентов и менеджеров филиалов компании;
- Falcon Rent - площадка аренды недвижимости (или др объектов).
Как говорил один известный человек: Шлифовать, шлифовать и еще раз шлифовать (ну или примерно так).
В итоге мы доведем эти продукты до состояния, когда требует лишь 5% доработок программиста, а 95% это настройка параметров.
Основной посыл статьи простой: создавайте свои продукты, снижайте риски провала, делайте то, что востребовано.
- Шаг 1. Создать концепт проекта
- Шаг 2. Получить оценку бюджета (КП)
- Шаг 3. Заключить договор
- Шаг 4. Создать совместно техническое задание
- Шаг 5. Поэтапная реализация проекта