Такой совет я не нашла в руководствах по ведению продукта. Возможно, это какая-то слишком очевидная вещь, но первая демонстрация продукта с реально заинтересованным владельцем компании-интегратора принесла мне 30 задач в бэклог по развитию продукта. www.standora.ru Standora — AI-платформа для проектной документации Ну, то есть не три. Тридцать! Благо, у меня нет жестокого внутреннего критика и я не погружена в иллюзию идеальности собственного продукта. Поэтому, в ходе встречи на 20 минут, где мы прошли несколько раз пользовательский путь от загрузки реального документа, сформированного по итогам одной из встреч, до выпуска документации, я просто полностью в режиме реального времени переняла оптику нашего клиента. Ни один опрос после самостоятельных тестов не дал мне такой полноты картины, как всего одна встреча. Кстати, мы сразу поменяли интерфейс на выходных:

Первая демонстрация в Standora Итак, расскажу, что меня удивляло: Загрузка прошла ок. Был выведен список документов на выбор для генерации. Всего 10 документов. Какой же был нетипичный пользовательский выбор: был запрос на формирование бизнес-требований и границ проекта — документы, которые я вообще никогда не формировала, проводя свои тесты. Мы немного поболтали на эту тему, честно говоря я поняла мотивацию генерировать именно их, так как частично они ложатся в договорную базу и описание проекта. Первая демонстрация в Standora Мой самый ценный документ «Рекомендации по ведению проекта» заказчик всё время пропускал, не смотря, так как, будучи профессиональным ПМ, не нуждался в этом. Теперь мы просто всегда его добавляем в пакет документов в подарок. Я заставила насильно выпустить этот документ. Показала перечень результирующей документации, но самым ценным оказался пункт про состав команды и компетенции команды. Это для меня стало сюрпризом. Я вообще не обращала внимание на этот пункт. Позже эта информация ляжет в новое требование к формированию рекомендаций. Первая демонстрация в Standora Потом мы рассмотрели невозможность возвращаться на другие экраны и поправили её. Отсутствие большого желания возиться с уточнениями (мы формировали 7 уточняющих вопросов для обогащения документации) — мы перенесли это в документы с пометкой «драфт». Первая демонстрация в Standora На всём пути меня сильно радовал уровень удовлетворённости качеством документации, отсутствие выдумок от ИИ. Мы немного поспорили, что один из документов был наполнен избыточно, но тут я сослалась на реально существующие шаблоны в одной из методологий и простое «ну, лишние удалишь». Самым впечатляющим стал показ обследования одного из ТЗ — те самые 68 документов из одного ТЗ, которые полностью охватывали весь жизненный цикл проекта. Я уже поставила эту задачу разработчикам на прошлой неделе и завтра мы её выкатим. Потратили в выходные на мозговой штурм 4 часа. Мне повезло с командой, потому что там супер-талантливые люди, которые придумали какой-то очень крутой новый интерфейс. Я его тут же согласовала, потому что это выглядело как продуктовый люкс в SaaS. Из максимально новоё: заказчик попросил обучить отдел работать на нашем продукте. Ну, это классно! Это интересный запрос. Меня будто бы сначала расстроила идея о том, что продукт слишком сложный и непонятный, но я успокоила себя трендом на повышение «ленности» клиента — даже одна кнопка иногда многовато. Опять же появились новые ценности: я позиционировала продукт как (в первую очередь) помощника аналитика, но демо показало, что главная ценность в том, что STANDORA — это пресейловая машина. И когда ты через час после встречи кидаешь своему клиенту структурированные документы, это резко повышает доверие к компании. Я, конечно, максимально удовлетворена результатом встречи.