don't move my cheese avatar

Max Ischenko

Спочатку ДОУ, тепер Djinni. Keep going & підтримуй ЗСУ.

"Креш курс ПМ" для розробників

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

Ну і головний пункт: чи вам це подобається? Чи є відчуття що ви робите щось корисне?

Прокачати будь який скіл вимагає часу, уваги, мотивації. Якщо робота ПМ більше нагадує тортури ніж продуктивно витрачений час, то краще пошукати інший шлях.

Permalink · Коментувати · ♡ Подобається