Ты когда-нибудь пользовался инструментом, который хорош на 80% — и раздражался на оставшиеся 20%? Я организовывал митапы и каждый раз упирался в одно и то же: Mentimeter, Ahaslides — почти хорошо, но всё ещё не идеально. Тогда я подумал: а что если сделать своё? И именно этот вопрос изменил то, как я проектирую продукты и системы.

Архитекторы хорошо понимают, как технически преобразовать требования заказчика в работающее решение. И я уже видел, как будет построен мой SaaS. Но как сделать продукт, который реально нужен людям, за который они будут платить - деньгами, временем, своим ресурсом? Это часто terra incognita, тёмный лес для технарей. Я зашёл в этот тёмный лес. Дорога привела меня в корпоративный продуктовый акселератор.

Здесь я научился главному — находить потенциальных клиентов и разговаривать с ними про них самих. Не про продукт, который я хочу создать, а про их контекст, про их действия в интересующих меня ситуациях. Тогда я провёл 13 интервью и научился делать быстрые прототипы в Figma — показывать идеи тем же людям.

Мой MVP был крайне простым — короткий сбор обратной связи по QR-коду в конце мероприятия с отчётом в Excel. Как же я удивился, когда узнал, что на длинных мероприятиях организаторы хотят собирать обратную связь по каждому блоку отдельно — но видеть общую картину в целом. Это знание было получено до разработки и сразу повлияло на будущее техническое решение.

Тот продукт не взлетел. Но я вынес из него кое-что важнее MVP — привычку спрашивать "зачем" раньше, чем "как".

На новом проекте мне достался внутренний продукт — список контактов сотрудников на раннем этапе развития. Задача простая: переехать с таблицы в Confluence в нормальное веб-приложение. Я занял роль архитектора и тимлида, вся команда — стажёры и джуны.

Сначала я занимался технической стороной. А потом мне стало интереснее другое — сам продукт, его развитие, люди, которые им пользуются. Текущий владелец продукта отходил от дел — я предложил взять эту роль на себя. Так я стал продактом, место тимлида уступил другому.

Начал исследовать пользователей — руководителей, HR, рядовых сотрудников. Искал потребности, формулировал гипотезы и превращал в задачи команде. Наладил демо каждые две недели — и это стало главным источником живой обратной связи. Один из самых драйвовых и интересных проектов за последнее время.

Мне интереснее не строить заборчики вокруг своей зоны ответственности, а понимать, чем живёт продукт — от идеи до реализации. Особенно это полезно разработчикам и архитекторам. Техническая экспертиза отвечает на вопрос "как". Продуктовое мышление — на вопрос "зачем". А комбинация этих двух сил даёт гремучую смесь.

А когда ты последний раз разговаривал с человеком, для которого проектируешь систему?