Comments 7
На первом этапе происходит анализ всех материалов, рынка, потребителей и поведения пользователей. Необходимо провести исследование, в ходе которого нужно изучить рынок, изучить конкурентную среду, изучить пользователя и его проблемы, углубиться в суть тех гипотез инсайдов, которые стояли на входе в этот проект. Понять какие конкретно задачи у пользователя не решены, а если решены то, кем и как, возможно на рынке найдутся продукты, которые решают те же самые пользовательские задачи уже довольно хорошо.
Как и кем должна проводиться граница: наши пользователи vs. не наши пользователи, наши проблемы/задачи vs. не наши?
Спасибо за вопрос.
Когда у нас есть идея создать какой либо новый продукт, мы должны убедится что в этом есть как минимум смысл и что он будет востребован на рынке. Для этого перед разработкой проводится исследование где изучается как целевая аудитория так и конкурентная среда.
Допустим мы хотим сделать что-то вроде Trading View и наши пользователи это криптохолдеры и трейдеры (первое что сейчас приходит в голову) но есть точно не наши пользователи, которые вообще не интересуются крипто валютой. Так же и с проблемами, в данном примере мы будем решать проблемы крипто трейдеров и холдеров. Анализ конкурентной среды проводится для того что бы понять чем наш продукт будет отличаться от массы других.
В моем опыте эта граница может быть проведена на воркшопе с командой и/или клиентом. Все зависит оттого в каком формате мы работаем, аутсорс или продуктовая разработка.
Ноль этапах создания цифровых продуктов... Хм...
MVP это продукт с минимальным функционалом решающий пользовательскую задачу.
Можно поподробнее? Кому вы показываете этот продукт? Предлагаете его заказчику проекта или же предлагается попробовать его выставить для продажи?
У меня ощущение, что сейчас уже никого софтом не удивить, и вместо того, чтобы пробовать MVP человек быстрее пойдет искать уже готовый продукт. И фактически нужен не MVP, а "максимально презентабельный продукт". В противном случае никто на него даже смотреть не будет.
Если накоплен опыт, хорошо бы еще раскрыть сценарии ошибок при поднятии стартапов.
Общих фраз масса, но рабочие примеры усваиваются лучше.
Например, сейчас на стартапе, где за прекрасной идеей в процессе разработки MVP были 3 (три) переделки UI. Т.е. заказчик не может остановить перфекционизм и заваливает разработку переделками.
Или еще: scope creep, когда заказчика "несет" и в MVP пытаются впихнуть малозначимые фишки и "рюшечки" UI, тем самым теряя время.
Или, когда MVP фокусируется на UI больше, чем это необходимо для донесения идеи по тестовой группы.
Для заказчиков нужно проводить ликбез - как довести идею про продукта, не растеряв бюджет и не завалив сроки. :)
Вы сами отлично ответили на свой вопрос :) Заказчик может не понимать важность многих процессов, этапов и остальной кухни разработки, но заказчик всегда очень хорошо понимает цифры которые влияют на его бизнес, я считаю что это лучший способ, в данном случае Прожект Менеджеру, объяснить заказчику варианты событий и последствий в рамках формулы: Если мы "вставить нужное условие", То мы получим "вставить нужное последствие" И хорошо подкрепить все это дело статистикой и ресерчами, что бы это были не пустые слова в глазах заказчика. Мой личный опыт и опыт ПМов с которыми работал и работаю, говорит именно так. Но к сожалению никто из нас не застрахован :)
Спасибо за комментарий, похоже было бы действительно не плохо добавить такой информации. Это моя первая статья, надеюсь в будущем буду более информативен. :)
Об этапах создания цифровых продуктов