Вопрос

Мне интересно, как должен происходить "правильный" запуск продукта. Насколько детально нужно проработать архитектуру продукта, сколько интервью нужно провести, с кем и как, как оформить требования и так далее?

На текущий момент у меня есть:

• "запрос рынка", в виде вопросов "а как это можно сделать? как это нет такой возможности?" и личной потребности;
• Proof of Concept доказывающий техническую реализуемость сервиса, в виде скрипта для личного пользования на основе палок и костылей;
• Никак не задокументированое представление об архитектуре будущего сервиса, его функциональности, опасенний о безопасности данных.

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

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

Отдельно про монетизацию

Я вижу, что я пропустил шаги по формированию модели монетизации (как я буду получать деньги за сервис) и проверку гипотезы, что сервис монетизируется. Для меня сейчас это не актуально, сервис "дотационный" из моего кармана =) Но я с удовольствием почитаю рассуждения и ссылки на тему.

Контекст

Для подписчиков на подкасты Patreon формирует RSS-ленту. Ее потом можно загрузить в приложение в телефон и новые выпуски будут автоматически доступны для прослушивания. Но сейчас у авторов есть сложности с выводом денег с Patreon'а, подписчики мигрируют на российский сервис boosty.to. А вот на нем уже нет такой замечательной функции, из-за чего подписчики испытывают фрустрацию. Я один из таких пользователей Boosty.

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

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

Мои текущие знания подсказывают, что начать нужно с формирования требований. Если отталкиваться от ценности для пользователей, то кажется лучшим способом является запись требований в виде User Story. Так ли это? какие есть альтернативы? Какие есть рекомендации по описанию US?

При попытке описать User Story я столкнулся с ощущением, что часть User Story я натягиваю на предполагаемые архитектурные ограничения. Я сомневаюсь, что это правильно, а как подругому - я не знаю. Например, "Как автор подкаста, я хочу синхронизировать списки пользователей и их уровни доступа с Boosty". Ценность для автора - подписчик получает то, за что заплатил, у подписчика есть мотивация платить автору за доступ к контенту. Но сама User Story сформулирована исходя из ограничения, что как-то нужно получать информацию о подписчиках из Boosty. Норм ли такая US?

Для сбора User Story наверно стоит провести интервью, так ли это? Как их проводить? какие есть альтернативы?

После сбора требований, можно переходить к определению функционала MVP и его разработке. Есть ли принципы или критерии, которые помогают определить набор User Story для реализации в рамках MVP (а потом и в рамках новых спринтов)?

Отдельно про монетизацию

Если бы я хотел монетизировать сервис, то я бы попробовал два варианта:

• через авторов подкастов, предлагал бы им инструмент, который повысит вовлеченность аудитории. Несколько тиров с разным уровнем оплаты в зависимости от количества подписчиков. Смысл - подписчикам удобнее потреблять контент -> больше прослушиваний -> больше денег от рекламы авторам. Проверял бы через заход напрямую к паре авторов подкастов, спрашивал готовы ли они поэкспериментировать.
• через подписчиков на подкасты, предлагал бы им за денежку удобство не доступное в Boosty. Проверял бы через лендинг с возможностью подписаться на один определенный подкаст с определенным уровнем доната (который, по "случайному стечению обстоятельств" полностью совпадает с моим =), RSS ленту формировал бы вручную.

Приглашаю покритиковать.

Мотивация

Моя цель - разобраться как происходит продуктовая разработка на примере pet project'а. Я готов попробовать "неоправдано тяжелые" практики и подходы, которые будут полезны при командной работе над "большим" продуктом и не особо нужны для pet project'а. Рассчитываю на поддержку сообщества в виде наставлений, критики, рекомендаций, ссылок на статьи и любого вида обсуждения. Спасибо.