сервиса на основе болей нескольких сотрудников . Хотим проверить гипотезу, перед стартом разработки.
Какие варианты вы видите для проверки?
Пока в голове:
1) Интервью с исследованием боли. Поймём на сколько она массовая. Более точно сформулируем гипотезу;
2) Выводы проверим более массовым опросом. Поймём на сколько эта боль проявится на большом слое людей;
3) Как MVP попросим писать мне в лс или в какой-то общий чат запрос, который в будущем будет отрабатываться этим продуктом в будущем. Так скажем воссоздаём интерфейс. А мы с командой будем давать решение. Пока на коленке, но …
Замерим этим число запросов и аплифт потенциального результата.
В чем вопрос, что думаете по плану, который описал выше?
Чем бы вы ещё проверили гипотезу? Возможно, я что-то упустил.
Привет, план отличный. Я бы прекомендовал ещё посмотреть, каким образом боли этих сотрудников отражаются на бизнесе, как ляжет на цифры их решение. Не только скорость решения задач в проекции на бюджет разработки и срок окупаемости решения, а также и на момент текучки, скорости выгорания, времени найма и онбординга новых людей на эти позиции. Насколько решение матчится с бизнес-моделью компании (есть компании, где выжечь людей, уволить и нанять новых - это норма).
Всё правильно, по классике lean startup) Но - если есть возможность, собственный ресурс - я бы предложил не пытаться это выстроить чётко и последовательно. А запустил бы консьерж-MVP сразу, параллельно с исследованиями, корректируя его по ходу накапливания запросов.
Спасибо. Очень ценно. Подумаем. Но решили сначала поговорить, ибо пока чувствуем , что мало данных. MVP - это конечно Франкенштейн, однако, не на столько))))
П1 - как вы на примере одного носителя боли поймете, что проблема массовая? П2 - хватит ли сотрудников в опросе, чтобы результат был значимым?
Не понимая контекста сложно судить, но боли сотрудников не всегда несут за собой общие боли аудитории, хотя решение может быть в целом полезно для компании. Может попробовать посмотреть в сторону RAT вместо MVP? А дальше по результату.
П1 - оно будет не 1. Человек 20-30 отсобесим. Ну это больше глубинка. П2 - найдём.
первое что пришло в голову - устройте брейншторм на тему - приложение уже создано, что дальше. Все счастливы или в результате где-то появится новая боль? - массовая боль или нет по сути с точки зрения экономики компании не особо важно, главное что бы затраты окупились в будущем или снизились потери. Может проще нанять человека, чем затевать разработку. - может проблему можно решить перестройкой процессов? - если вы столкнулись с проблемой, скорее всего вы не первый, решение наверняка уже существует и обрело профессиональную форму, оформить подписку дешевле / дороже разработки. - мир пластичен, все меняется, меняются процессы, программное окружение, будет ли актуально ваше решение через год-два или будет одиноко пылится в репозитории
рад помочь =) Вы потом поделитесь итоговым опытом, было бы интересно.
Обсуждают сегодня