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

Что такое продуктовый подход

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

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

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

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

Разработка без продуктового подхода. Иван начитался статей про то, как молодые предприниматели создают приложения и зарабатывают на них миллионы. И подумал: «А чем я хуже? У меня куча уникальных идей». Иван решил сделать приложение, в котором человек сможет купить парковочное место, когда захочет оставить машину у торгового центра или рядом с домом. Предприниматель бегло изучил рынок и понял, что такого сервиса нет. Вот она, золотая жила! Иван нашел разработчиков, заплатил им и они сделали приложение. Оно хорошо выглядит и интуитивно понятно, но водители не стали его устанавливать. Им просто не захотелось заморачиваться: удобнее искать места по старинке, а не открывать очередное приложение и скроллить бесконечную ленту с похожими вариантами.

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

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

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

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

Рустам Мухамедьянов, руководитель студии WINFOX

Чем продуктовый подход отличается от проектного

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

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

Отличие №1. Забота о пользователях

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

Например, вам нужно, чтобы пользователи вводили номер телефона в формате +7 (ХХХ) ХХХ-ХХ-ХХ. Так номер, который попадает в базу контактов, можно использовать для автоматических рассылок. Если пользователи будут вводить номера в других форматах, система их не идентифицирует — и рассылка не уйдёт. Это ваша задача. Но пользователям по большому счёту всё равно, как вводить цифры. Поэтому важно позаботиться о пользователях: помочь им делать так, как нужно вам, но при этом показать, что и для них это удобно. Хорошее решение — использовать маску ввода. Она исключает ввод данных в неверном формате, а пользователь видит в поле нужный формат телефона данных и вводит цифры в нем. Все довольны. 

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

Отличие №2. Проверка идеи заказчика

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

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

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

Рустам Мухамедьянов, руководитель студии WINFOX

Отличие №3. Быстрый эффект

Проект — это что-то, растянутое во времени. Продукт — это результат. А результат в бизнесе важно достигать как можно быстрее. 

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

При продуктовом подходе не нужно ждать, когда все будет идеально (в реальном мире так все равно не бывает). Вы можете сделать первую версию приложения с базовым функционалом и отдать его пользователям. Да, пока в приложении нельзя оплачивать заказы с помощью Apple Pay и оставлять чаевые курьеру. Зато оно выполняет главную функцию здесь и сейчас — продает ваш товар клиентам. Люди сейчас отдают вам деньги, а вы сейчас получаете доход и развиваете бизнес. 

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

Отличие №4. Оплата за результат

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

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

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

Рустам Мухамедьянов, руководитель студии WINFOX

Отличие №5. Гибкость в принятии решений

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

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

Допустим, вы делаете приложение для управления грузоперевозками, которым будут пользоваться водители грузовиков. Пока вы рисовали прототип, в России приняли закон о системе «Платон». Теперь все водители грузовиков тяжелее 12 тонн должны платить налог за пользование дорогами. И вы подумали: «Было бы здорово, чтобы водители могли оплачивать налог прямо в приложении. Так продукт будет еще полезнее». Вы рассказали об идее разработчикам, они добавили задачу в бэклог — список основных функций и характеристик продукта. Закончив один спринт, разработчики выбирают задачи для следующего спринта из бэклога: они могут поскорее добавить в приложение новую функцию. 

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

Отличие №6. Непрерывное тестирование и улучшение

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

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

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

Рустам Мухамедьянов, руководитель студии WINFOX

Отличие №7. Продуктовый менеджер вместо проектного

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

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

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

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

Коротко: главные отличия продуктового подхода от проектного

Проектный подход	Продуктовый подход
Когда делают проект, думают о том, как это делают	Когда делают продукт, думают о том, для кого это делают
Желание удовлетворить заказчика	Стремление закрыть боли пользователей
Заказчик приходит с готовой идеей и планом: он говорит, что ему надо, и разработчики дают ему это	Разработчики подключаются к проекту на этапе идеи, проверяют ее жизнеспособность, находят оптимальную модель монетизации приложения и способы закрыть боли пользователей
Долгосрочное планирование и реализация	Работа по спринтам: краткосрочные цели, которые можно быстро достичь и сразу получить эффект
Оплата за процесс: формальное выполнение технического задания, соблюдение сроков, написание кода	Оплата за результат: после каждого спринта заказчик получает рабочее решение, за которое заплатил
Тестирование и исправление багов, когда приложение полностью готово	Непрерывное тестирование и улучшение приложения после каждого спринта
Доработка приложения на основе хотелок заказчика	Сбор обратной связи от пользователей, анализ данных и составление списка доработок на основе статистики
Менеджер проекта — связующее звено между разработчиками и заказчиком	Продуктовый менеджер одновременно слушает пользователя, заказчика и разработчика — и выбирает оптимальные решения для всех трех сторон

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

Рустам Мухамедьянов, руководитель студии WINFOX

Почитайте другие главы из книги:

Как составить продуктовую стратегию: чек-лист

Как сделать MVP без знания кода: четыре инструмента

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