Product Manager

Product Manager Mentor. For the PM whose engineering team does not trust them yet.

Half of your PM problems are engineering-partnership problems. Trust with the EM is broken. The Product Trio is a slide, not a working thing. Prioritization is a vote you keep losing. AI is changing discovery and nobody has told you.

You do not need another PM course. You need one person who has sat on both sides of the PM-Engineering line to pressure-test the specific conversation you have on Tuesday.

Book the intro →

Situations you are likely in, and how we tackle them

Engineering does not trust you and you cannot figure out why.

I did the discovery. I wrote the PRD with actual data. I brought it to grooming and the EM sent it back with "why do we care about this?" I have been burning half my week on the same fights that other PMs at other companies do not seem to have. And I know my EM told the VPE something about me last week because his tone in the last standup was different.

You have probably tried

  • Longer PRDs with more data (they got skimmed less)
  • Buying the EM coffee (helped for a week)
  • Reading Marty Cagan (helpful in theory, not in Tuesday morning grooming)
  • Assuming they will come around

How we tackle it

We diagnose whether the trust gap is credibility (they think you do not get engineering), consistency (you moved priorities twice this quarter), or care (they think you do not have their back with the CTO). Different fixes. We rehearse one specific conversation you have been avoiding.

Target: By week 6: named trust gap, one hard conversation delivered, one measurable behavior change per side.

Related reads

The Product Trio is a slide from an article, not a working thing.

Me, the EM, and the designer are supposed to be a trio. Reality: we meet at planning, disagree at grooming, each write our own document. Delivery slips, nobody knows whose fault it is, and my CPO asked me directly last week "how is the trio working?" I lied.

You have probably tried

  • A weekly trio sync that became a status meeting
  • Copying the working agreement from a Marty Cagan blog post
  • Assuming the EM would take the initiative
  • Convincing yourself the designer is the block

How we tackle it

We build the working agreement in writing: discovery cadence, delivery cadence, escalation lanes, who calls the meeting when a call is stuck. Then I coach you through the specific reset conversation with your EM.

Target: By week 4: signed working agreement, weekly rhythm, and an honest answer to the CPO next time.

Related reads

You prioritize by loudest stakeholder. It is not working.

CEO said it Monday. Sales said it Wednesday. Support has a customer escalation. Engineering has tech-debt work I promised them last quarter. Every prioritization call feels like a vote I am losing. And half of my backlog is P0 because the alternative was telling someone no.

You have probably tried

  • A RICE spreadsheet the sales team ignored
  • A "no" that became a "yes" by Friday
  • Talking to your CPO about the pattern (he said "just prioritize")
  • Working weekends to catch up

How we tackle it

We install a prioritization framework that reflects business value (RICE, WSJF, or your own weighted scorecard). We rehearse the "no" conversation with the loudest stakeholder. We give your EM the language to push back with you, not on you.

Target: By week 6: written prioritization framework, one hard "no" delivered without damage, and a working backlog under 5 P0s.

Related reads

You measure success by features shipped. Your CEO measures it by revenue.

My roadmap tracks features. The board asks about outcomes. My engineering team says "we shipped what you asked for." Nothing moves the top-line number and nobody feels responsible. I know the fix is outcome-based roadmaps, and I also know that switching mid-quarter would make things worse before better.

You have probably tried

  • Adding "outcome" columns to the roadmap (still features underneath)
  • Attempting an OKR-based rewrite (paused after 2 weeks)
  • Reading Escaping the Build Trap (nodded a lot, changed nothing)
  • Waiting for a "quiet quarter" to switch (there is no quiet quarter)

How we tackle it

We translate every planned feature into a leading-indicator hypothesis, and every quarter into a lagging outcome. We build the outcome-KPI dashboard your CEO wants and your engineering team can respect. Then we redraw the roadmap in outcomes, not features.

Target: By week 8: outcome-based roadmap, one dashboard your CEO checks weekly, and an engineering team that can answer "why does this matter."

Related reads

AI is changing product discovery and nobody has told you.

I am still running user interviews the old way. My VPE is asking about AI-first workflows. My engineering team wants to prototype in Claude Code before I write the PRD. My CPO shipped an AI feature last month without a PRD at all. The old discovery-to-delivery playbook is breaking and I do not have the new one.

You have probably tried

  • Reading Lenny's AI posts and feeling behind
  • Adding "AI" to your existing discovery framework
  • Waiting for a training that will not come
  • Assuming your CPO will define the new playbook

How we tackle it

We redesign your discovery-to-delivery loop for the AI-forward era. Which discovery signals still matter, which are noise. Where LLM prototyping replaces PRDs. Where the human interview is the new moat. Pragmatic changes, not manifestos.

Target: By week 6: written AI-era discovery playbook for your team, one AI-first prototype delivered, and a defensible answer to your CPO.

Related reads

You want Head of Product but the CPO seat is not opening.

I have led a product area for 2 years. Comp is stuck. The CPO is not going anywhere and the company will not create a VP Product role. Every recruiter DM I get feels like desperation. And staying feels like waiting for something that is not coming.

You have probably tried

  • Asking your CPO about growth (he said "keep doing what you are doing")
  • Reading levels.fyi and getting resentful
  • Applying to random VP Product roles
  • Waiting for a re-org to create scope

How we tackle it

We map three options with year-1 tradeoffs each: wait and expand scope internally, push for the VP title, or run a targeted external search. We build the artifact for each. We rehearse the conversation with your CPO for the one you pick.

Target: By week 8: written 3-path map, one chosen path, and the specific first move on the calendar.

Related reads

The questions I hear most from Product Manager

These are the exact asks from mentees in the last 12 months. Bring one to the intro call and we start there.

How mentoring with me works

  1. Step 1

    Intro session (free, 30 min)

    We understand your situation, background, and the two KPIs we would target. If we are not a fit, we stop here. If we are, we agree the cadence and the first homework.

  2. Step 2

    Session 1 and beyond

    We pick 2 specific KPIs to move over 3-6 months. Small written homework after every session. Everything we discuss stays between us.

  3. Step 3

    Reviews and cadence

    Regular progress reviews with you (optionally with your manager). Weekly or bi-weekly. Onsite in Prague or remote, both work.

Frequently asked

What if my real block is my CPO, not engineering?+

Then we work the CPO. Half of PM asks I get are actually influence-up problems. Nothing on the topic list is off-limits.

What if I only have 4 to 6 sessions before a specific launch or quarterly review?+

Then we compress. Every session ends with an artifact you can act on. Some of the highest-impact engagements are 4 to 6 sessions.

Will you tell me straight if my PRD is bad?+

Yes. If it is bad, I will say so and help you fix it. Direct advice first. Coaching-style questions later.

What if I want to move from PM into engineering leadership eventually?+

Good. That is a growing path and I have coached several PM-to-EM/VPE transitions. We would sequence the moves that build the credibility for it.

You are an engineering mentor. Why do you coach PMs?+

Half of PM problems are engineering-partnership problems. I sat 15 years on the eng side of the trio and have coached both since 2019. That perspective is unusual and useful.

Explore other roles

Why me

Marian Kamenistak

Marian Kamenistak. Ex-VPE at Mews (Series C, R&D scaled 10 to 80+ eng teams). Ex-Manta (acquired by IBM). Ex-Databricks Bay Area. Founder of Engineering Leaders Community (2,000+ members).

3,000+ mentoring sessions since 2019. Prague-based, serving EU + North America.

Ready to start?

Free 30-min intro. No pricing conversation on the first call. We figure out if we can move your specific problem forward. That is it.

Book the intro →Or emailmarian@marian.coach

From the blog

All posts →