Для ответа на пост Андрея мне придется смешать проектную и продуктовую школу мысли.
Дешифруем проблемы продуктово:
1. Продукт находится в минусе - его операционные затраты не покрываются прибылью;
2. Фаундер хочет денег, но не понимает как достичь их через продукт;
3. Аналитик хочет понимать, зачем он описывает фичи, потому что видит их несвязность с ценностью продукта;
4. Дизайнеру не нравится отсутствие вызова в рамках создания продукта: менторство он видит как способ этот вызов получить;
5. Разработчики непродуктивно используются и видят повышение объёма работы как крит;
Фокус на проблеме 1:Смотрим с фаундером и аналитиком метрики и экономику продукта → понимаем, что сжирает или не приносит деньги → оцениваем сложность изменений в этих зонах → решаем, что будет быстро и просто поменять, чтобы пойти в сторону выручки. По условиям задачи мы не знаем, как этот продукт продается/маркетуется и так далее. Мы также не знаем, как обстоят дела с инвестициями - возможно, у компании осталось больше пяти месяцев. Но мы это не будем учитывать в решении (хотя в реальности надо). Скорее всего, тут мы найдем вопрос на ответ 1 и скажем, какие работы и когда приведут нас в плюс по деньгам, но не решим задачу, потому что в команде еще надо наводить порядок.
Далее решаем проблемы 2 и 3 разом. Надо определить, какую ценность пользователям приносит продукт. После этого сажаем рядом аналитика и фаундера, и обсуждаем весь скоуп фичей. Продукт у нас молодой, так что если фича не растит основную ценность - выкидываем, если растит - придумываем ей эксперимент и смотрим, как она выстрелит по метрикам. В дальнейшем мы проводим все фичи по такому пути - отсекаем бесполезные, снимая боль аналитика, а фаундер начинает критически мыслить при анализе фич и реагировать на метрики для понимания успехов и провалов. С дизайнером можно решить проблему так, как он хочет, но это не будет экономически выгодно на данном этапе стройки. Вместо этого добавим его в комитет по фичам как ux-эксперта. В его жизни появится создание пользовательских путей, и вот он уже сам станет автором требований к интерфейсам. Аналитик же сможет заняться более полезными задачами и строить систему метрик для анализа работы решения.
Проблема 5, как ни странно, может быть фантомной. Если разработчики не стоят бизнесу баснословных денег, при этом успевают делать свою работу в срок и с нужным качеством - можно не делать ничего. Скорее всего, с развитием бизнеса поток задач естественным образом вырастет, и можно будет предлагать решать больше задач за больше денег, но это будет в будущем. Надо помнить, что даже поездки на конференции - это польза для HR-бренда компании, что может положительно сказаться при её росте. Вместе с тем, если разработчики стоят дорого, а выхлоп ниже ожидаемого - можно дать им поджопник, уволить недовольных и нанять новых. Как славно, что условия задачи дают нам эту дихотомию :)