"Креш курс ПМ" для розробників
Published on February 15, 2026
Як зміниться роль розробки, якщо 90% коду пише Claude/Codex?
Є гіпотеза, що кожен розробник буде тепер ще й трохи ПМ. Я пройшов цей шлях на Джині в "до-AI" епоху, але можливо щось з цього буде корисно і вам.
1/ Яку проблему ми вирішуємо?
Будь яке обговорення або планування починається з відповіді на питання: шоб шо?
Яку проблему ми хочемо вирішити? Чому ми думаємо, що це проблема? Як ми побачимо що дійсно її вирішали? Як виглядає best case scenario та які наші success metrics?
2/ Від чого ми відмовляємось щоб це зробити?
Потрібен час що вибрати задачу, придумати як її зробити, як ми будемо її вимірювати, чи будемо анонсувати її для користувачів і мільйон інших питань, кожне з яких забирає час.
Не спішіть кидатись робити першу-ліпшу задачу, яка виглядає цікаво або просто doable. Можливо є краща. Opportunity costs завжди з вами, навіть коли код пишеться "миттєво".
3/ Get better at analytics
Яку б задачу ви не обрали було б непогано розуміти як ви будете трекати результати й оцінювати успіх. Як мінімум це код для трекінгу і дашборд для себе (команди).
Навряд чи вам буде цікаво повторити університетський курс стат аналіза, але початитись з ChatGPT/Claude і повтикати в Google Analytics, Metabase чи що у вас є для аналітики це точно хороша ідея.
4/ Реліз != DONE
Ми не робимо фічу заради фічі, ми її робимо тому, що у нас є певна гіпотеза як ця фіча спростить життя користувача, вирішить його проблему або створить потрібну для них функціональність.
Реліз це тільки початок. Початок збору реальних даних і фідбеку користувачів.
Запускаємо -> Оцінюємо -> Continue/Stop/Kill
Continue: фіча працює, супер. Думаємо чи можемо ми зробити її ще краще. Якщо ні то чи можемо ми використати ці learnings для фічі в іншій частині продукта. Або: фіча поки не працює, але є ідеї як спробувати ще раз.
Stop: працює, більше ідей немає що з цим робити, переключаємось на інші задачі.
Kill: Стало гірше, повертаємо як було.
5/ Вчіться тримати кілька задач в голові
ПМ рідко працює над однією задачею, навіть коли для розробника це можливо.
Є задачі на фазі обговорення/ideation, які чекають фідбеку команди, є задачі "в роботі", є задачі які в статусі "тестуємо на продакшн", де ми збираємо метрики і фідбек користувачів.
Найкраща порада тут: автоматизація.
Не тримайте все в голові, виносьте в Notion, Trello, Fizzy, GitHub Issues, whatever works. Будьте релігійно настирними в плана статус-апдейтів по кожній задачі: нові ідеї, скріншоти, аналітика, обговорення, питання.
Тоді для перемикання контексту буде достатньо відкрити відповідну карточку.
6/ Have fun
Ну і головний пункт: чи вам це подобається? Чи є відчуття що ви робите щось корисне?
Прокачати будь який скіл вимагає часу, уваги, мотивації. Якщо робота ПМ більше нагадує тортури ніж продуктивно витрачений час, то краще пошукати інший шлях.