Кого волнуют баги продукта, если он успешно продается

Изображение ^[1] сайта media.licdn.com

Как утверждает ^[2] венчурный инвестор и программист Лео Половетс, в сегодняшнем мире Saas, API и облачной инфраструктуры проработанная техническая составляющая редко становится причиной успеха или провала программного продукта. Современные технологии теперь позволяют разработать его очень быстро с минимальными затратами. Казалось бы, это как раз то, что нужно стартаперам.

По данным ^[3] CB Insights, только 5% стартапов прогорают по причине слабой технической реализации. Большинство провалов случается в результате неверного позиционирования продукта, отсутствия грамотной маркетинговой стратегии, плохих специалистов по продажам, неверной бизнес-модели. Наличие или отсутствие высококвалифицированных инженеров практически не играет никакой роли, делают вывод исследователи.

Если обратиться к примеру самых успешных технологических стартапов мира (Uber, Airbnb, Snapchat, Pinterest и прочие), мы не увидим сложных программных решений. Зато очевидным преимуществом этих компаний является удачная бизнес-модель. В купе с активным продвижением, эти сервисы смогли стать одними из самых востребованных и дорогих стартапов мира. Но вряд ли они нанимали десятки инженеров, чтобы разработать сервис и подготовить его к запуску, сомневается Половетс.

Однако он признает, что есть компании со сложными технологиями, требующими тщательной и выверенной реализации: SpaceX, Zoox, Rigetti Quantum Computing. Но, по его мнению, эти исключения только подтверждают правило.

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

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

«Продукт — это не программное обеспечение, не сайт, не приложение, которое вы сделали. Продукт — это набор свойств, которые вы продаете потенциальному покупателю». Несколько примеров в качестве иллюстрации привел ^[4] Аркадий Морейнис на лекции в Технопарке:

Пример номер один. Приходит письмо от программиста — он разрабатывает торговую площадку, на которой продавцы могут размещать свои товары: «Я программист, у меня проект уже практически готов, я уже сайт сделал, осталось только две мелочи — подскажите мне, как найти покупателей и продавцов. Все остальное уже сделано. Проект на 95% готов». Вот это как раз распространенная ошибка. Если ты не знаешь, откуда брать покупателей и продавцов, у тебя нет на руках продукта. У тебя на руках есть все что угодно, но только не продукт.

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

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

Джон Эванс из HappyFunCorp обращает ^[5] внимание на проблему качества продуктов, сделанных на скорую руку (Startup Software Quality Problem). Многие проекты разрабатываются под флагом Minimum Viable Product (MVP), что нередко создает стартаперам больше проблем, чем пользы.

«MVP (минимально жизнеспособный продукт) — простейший работающий прототип продукта, которым тестируют спрос до полномасштабной разработки. Такой подход страхует предпринимателя от невостребованности конечного продукта и потери потраченных на разработку ресурсов». (Словарь предпринимателя: MVP ^[6] | Rusbase).

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

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

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

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

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

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

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

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

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

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

Еще один пример от Аркадия Морейниса – ситуация, когда роль ПО второстепенна:

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

Они пошли в ближайший супермаркет и начали ловить тетушек. То есть они буквально подходили к тетушкам, которые ходили закупаться в этот супермаркет и говорили: «У нас есть сервис — за 9,95 долларов в неделю мы можем вам привозить продукты и рецепты на целую неделю готовки».
Они нашли первую тетушку, которая согласилась заплатить им $9,95. После этого они опять же не побежали программировать. Они начали подбирать рецепты, закупать товары, резать, раскладывать по мешочкам и каждую неделю приносить все это тетушке и выслушивать от нее всю обратную связь за прошлую неделю. И получать свои законные $9,95.

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

Пример Netflix

Старт с продуктом в качестве услуги – с этого начинал ^[7] свою деятельность Netfix.

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

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

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

Автор: semen_grinshtein

Источник ^[8]