"Креш курс ПМ" для розробників
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
Ну і головний пункт: чи вам це подобається? Чи є відчуття що ви робите щось корисне?
Прокачати будь який скіл вимагає часу, уваги, мотивації. Якщо робота ПМ більше нагадує тортури ніж продуктивно витрачений час, то краще пошукати інший шлях.
Коментарі
Коментарі закриті.