Как я вижу проблемы:
1. Нет работы с пользователями. Фаундер придумывает фичи сам, и надеется, что какая-то из них выстрелит.
2. Команда передает мячик друг другу, но не нацелена на результат: поставка ценности пользователю
3. Нет приоритизации фичей по ценности или ожидаемому приросту в выручке — фичи делаются по принципу FIFO (First In First Out)
4. Нет оценки задач и хоть какого-то плана их реализации (что бы то ни было: спринты, календарный план или что-то еще)
Если обобщить, то команда не понимает, что ей реально надо делать и когда.
Чтобы сделать любой проект, нужно всего 3 компонента:
- понятная задача
- ресурсы
- команда
Если задача есть, а ресурсов и команды нет — это стартовая позиция любого стартапа. Задача и команда есть, а ресурсов нет — надо искать ресурсы. Ресурсы и команда есть, но никто не понимает, что делать — надо детализировать задачу. В изначальной задаче люди делают какую-то работу, но не понимают, что делают и куда эта работа должна привести компанию. Поэтому с моей колокольни тут нужно начать с задачи: что надо сделать, когда это сделать и требования к результату.
В задаче заложено 3 уловки:
1. Выглядит так, будто есть проблема в процессах: задачи в чате телеги. На самом деле её нет — команде на текущем этапе развития этот процесс подходит и удобен. Я бы не бежал всех пересаживать в таск-трекер, во всяком случае, пока не разрулим другие проблемы
2. Страдающий дизайнер. Саня верно подметил: у дизайнера проблема — ему скучно. Он видит решением нанять себе команду, но это только одно из решений. Например, еще можно посадить его ближе к аналитику и пусть работают над фичами вместе. И в любом случае, это далеко не первый приоритет.
3. Разрабочики, которые всем довольны. В текущем контексте удовлетворение разработчиков — не приоритетная задача. Нужно найти product-market-fit и выйти в операционную прибыль. Людей в командах можно менять, это не страшно. Страшно остаться без денег через полгода, потому что люди не хотят меняться. Короче, пофиг, делаем дело, с разработчиками решаем по ходу.
🎯 Как я вижу план действий:
1. Разобраться с ценностью: что приносит пользователям наибольшую ценность, какую проблему мы решаем. Для этого нужно пообщаться с пользователями + опросить всех членов команды, в чем смысл продукта на их взгляд.
2. Сформулировать ценность продукта (можно в Lean Kanvas) и завалидировать её через фаундера
3. Собрать в кучу все фичи, которые в работе или в очереди (можно в экселе)
4. Найти и разобрать обратную связь пользователей. Недовольные часто пишут в сервисы и просят что-то улучшить. Сбить пожелания и ОС пользователей с текущими фичами
5. Грубыми мазками набросать Customer Journey Map и разложить все текущие фичи по ней
6. Показать CJM команде и предложить приоритизировать фичи с оглядкой на ценность продукта, которая завалидирована у фаундера
7. Расставить оценки по реализации в измерении, удобном команде (часы, дни, стори-поинты, попугаи — пофиг)
8. Построить примерный план реализации фичей с учетом оценок и презентовать команде. Собрать обратную связь и улучшить узкие места
9. Ввести точки контроля движения (можно взять из скрама, но в целом не принципиально). Хотя бы сделать еженедельную синхронизацию команды по задачам.
Итак, здесь у нас есть база, от которой можно отталкиваться:
1. Приоритизированный бэклог
2. Оценка сроков реализации фичей
3. Команда, которая с этим согласна
4. Люди еженедельно встречаются и находятся в общем инфо-поле
Отдельно надо посчитать юнит-экономику, построить модельку и поиграть с ней. Понять, где деньги выходят из бизнеса, а где входят, на что из этого мы можем влиять. Возможно, если попрощаться с 2 разрабами, денег хватит на год, например. Или куча юзеров отваливаются из-за Х — надо это быстро внедрить. Возможно, команда не успевает и можно недорого часть задач скинуть на аутсорс. Ну и там же прикинуть срок выхода на окупаемость: где примерно находится точка, где бизнесу станет комфортно.