Какие у тебя слабые стороны как у Product Manager?

Мои слабые стороны как Product Manager

Любой хороший PM должен быть честен о своих лимитациях. За 10+ лет я научился видеть свои недостатки и работать с ними. Вот что мне нужно постоянно улучшать.

1. Перфекционизм в ущерб скорости

Проблема: Я люблю polished решения и страдаю, когда нужно запустить MVP, который выглядит raw или неполный. Моя склонность — доотполировать feature, что задерживает время до market.

Примеры:

• Когда нужно запустить Feature V в production, я хочу доделать Feature A и Fix Bug B
• Рецензирую design мокапы по 5 раз вместо 2-х
• Хочу больше user testing перед launch, чем позволяет timeline

Как я это исправляю:

• Ставлю себе дедлайн: "launch на этот день, не дальше"
• Пишу definition of done чётко: что обязательно, что nice-to-have
• Remind себе: feedback от реальных пользователей ценнее feedback от интерна

Результат: Огромное улучшение за 2 года. Теперь я запускаю быстрее, итерирую быстрее.

2. Сложность в делегировании

Проблема: Я микроменеджер по природе. Хочу контролировать каждый step, что стрессит мою команду и убивает их autonomy. Мне сложно довериться junior PM в решении кейсов.

Примеры:

• Если junior PM пишет PRD, я полностью переписываю
• Беру в себя часть работы, которая должна быть у Product Designer
• На встречах с чрезмерный detail-oriented — тратим час на выбор шрифта

Как я работаю с этим:

• Сознательно передаю задачи и смотрю без правок первую версию
• Даю feedback только на 20% самого важного, остальное — learnings для них
• Используй rubric для оценки, вместо субъективного мнения
• Каждый квартал пересматриваю: кого я даю полной ownership, кому доверяю больше

Результат: У меня выросла отличная team, потому что я дал им freedom to fail.

3. Недостаточная фокусировка на long-term стратегии

Проблема: Я слишком глубоко увязаю в tacticals (текущие problems), что отвлекает от стратегических вопросов. Когда нужно думать 2-3 года вперёд — я теряюсь в quarterly planning.

Примеры:

• Не читал market reports, пока не появилась crisis
• Не планировал pricing strategy, пока конкуренты не давили
• Focussed на доделку Feature X, вместо anticipate что нужно Feature Z

Как я исправляю:

• Планирую 2 часа в месяц просто для thinking (no meetings, no distractions)
• Читаю industry reports и competitive analysis quarterly
• Веду 18-месячный roadmap (не only quarterly)
• На quarterly review спрашиваю себя: "Did we move towards our vision?"

Результат: Теперь лучше вижу долгосрочные trends и могу быть more proactive.

4. Communication и storytelling

Проблема: Я хорошо объясняю аналитику и cycles, но плохо с narratives. Моя presentation часто скучна, много цифр, мало stories.

Примеры:

• Покажу таблицу с метриками, но не расскажу историю что там произошло
• Презентация для investor лучше бы была с customer story, а я даю только финансы
• Announcements в slack не вдохновляют, просто facts

Как я работаю с этим:

• Беру coaching по presentation skills (2 раза в год)
• Для каждой presentation пишу narrative сначала, потом slides
• Практикую рассказывать истории на retrospectives
• Просматриваю TED talks и хороший presentations (Stripe, Figma)

Результат: Мои презентации стали более engaging, получаю больше engagement от team и stakeholders.

5. Technical knowledge gap

Проблема: Я не дев-инженер, и моё понимание architecture и technical constraints ограничено. Иногда я недооцениваю complexity features, что приводит к неправильной оценке.

Примеры:

• Спросил backend делать realtime sync без понимания что это очень hard
• Не вижу technical debt пока не скажет lead architect
• Presentation для инвесторов про инфра-features был поверхностный

Как я развиваюсь:

• Беру один курс в год по backend/architecture (Scrum.org, Educative)
• На monthly tech talk с инженерами спрашиваю как они бы спроектировали feature
• Читаю technical RFC когда они пишут
• Пытаюсь понять их code на basic level (не deep, но enough to ask questions)

Результат: Теперь инженеры меня better слушают, потому что вижу их perspective. Моя scope creep уменьшилась.

6. Bias towards мои идеи

Проблема: Когда я предлагаю идею, я слишком защищаю её. Иногда это приводит к bias в data analysis или игнорирую red flags.

Примеры:

• Proposed feature Z, потом видел data что нужна feature A — но я продолжал Z
• User research говорит "это не нужно", но я think "нужно дать им больше time"
• Ignore warning signs что feature не adopted потому что я in love с ней

Как я борюсь:

• Назначаю "devil's advocate" в team кто будет критиковать мои идеи
• Set decision criteria ПЕРЕД analysis (не после)
• Если people say no — спрашиваю "почему" глубже instead of arguing
• Документирую каждую большую гипотезу и периодически проверяю была ли я right

Результат: Больше kill плохих идей рано, что экономит ресурсы.

7. Patience с slow team members

Проблема: Я работаю быстро и нетерпеливо с людьми кто slower чем я. Это видно в tone of voice на meetings, что убивает confidence junior team members.

Примеры:

• Перебиваю когда someone объясняет медленно
• Показываю frustration когда designer не understand requirement с first try
• On slack быстро даю feedback без consideration что people может be busy

Как я работаю:

• Практикую active listening (курс на Coursera о communication)
• Перед difficult conversations дышу и напоминаю себе их perspective
• Ask people about их preferred communication (sync vs async, frequency)
• На retro просим team feedback про моё поведение

Результат: Лучше team динамика, меньше anxiety.

8. Work-life balance

Проблема: Я workaholic и трудно disconnect от работы. Checking slack в weekend, thinking about products перед sleep. Это приводит к burnout risk.

Примеры:

• Ответил на email в 11 PM и потом лежу thinking о решении
• Weekends планирую product stuff вместо relaxation
• Vacation не really vacation, потому что check Slack

Как я это улучшаю:

• Set strict working hours: 9-6, потом no work
• Deleted Slack с phone (только на computer)
• Vacation планирую как offline: hiking, nature, no WiFi
• Беру therapy/coaching про work-life boundaries

Результат: Меньше burnout, лучше decisions когда refreshed.

9. Deep expertise vs Generalist knowledge

Проблема: Я generalist — знаю много о многом, но не expert ни в чём. Иногда это limitation когда нужно глубокое understanding (например, про compliance для finance product).

Примеры:

• Делал consumer product, потом B2B, потом marketplace — каждый раз учусь
• Не знаю compliance требования когда запускаем в новой стране
• Less credible с глубоким SME чем с deep specialist

Как я это адресую:

• Хаираю deep specialists и listen их perspective
• Для каждый product area keep learning resources (email list, books)
• Признаю что not expert и ask questions instead of pretending

Результат: Мож work across domains, но с respect к deep knowledge.

10. Impatience с process

Проблема: Я think process часто bureaucratic. Хочу just do, не follow процесс. Это может lead to chaos когда company скейлится.

Примеры:

• Skip meetings потому что think они wasteful
• Don't document decisions потому что "everyone knows"
• Resist company-wide process потому что think it slow

Как я наконец выучил:

• Видел chaos когда company grew и не было process
• Теперь баланс: make process lean, but не skip целиком
• Lead by example: я following процесс и others follow

Результат: Скейлирование became easier когда process был in place.

Как я растю

Мой approach к improvement:

1. 360-degree feedback раз в год

   • Спрашиваю team, boss, peer PMs что я делаю плохо
   • Listening without defending
   • Pick 2-3 areas для focus

2. Coaching

   • Executive coach раз в месяц (мой investment)
   • Specific areas (communication, delegation, strategy)

3. Accountability

   • Рассказываю team что я работаю над
   • Request их feedback
   • Share progress quarterly

4. Learning

   • Books, courses, podcasts (см. предыдущий ответ)
   • Apply directly к своим weakness areas

5. Reflection

   • After каждый major decision или конфликт, рефлектирую
   • Journaling про lessons learned

Финальная мысль

Сладкая точка PM — это self-aware о своих gaps и committed к improvement. Я не perfect и никогда не буду, но я transparent о limitations и работаю на них. Это делает меня better PM и leader.

Когда hiring PM — я больше trust человека кто say "I struggle with X" и show plan для improvement, чем человека кто think they perfect.