A PM’s Guide to Staying Sane Without a Project Manager
...and building executive presence while you're at it
You were hired to do product management—not project management. But more often than not these days, most PMs are working with less operational resources than ever (#macroeconomics #thedamnmarket #hiringfreezes). And as a result, more folks are taking on more than they were hired for. #classicproducr
In my career, I was lucky to work with some of the best Program and Project managers around. They taught me a thing or two about glue work1. So, when I PM’ed teams without their support, I was ready to go.
The truth is, whether you’re with or without project management support, an important skill in a any product career is knowing how to project manage in a way that doesn’t …
take away from your product management work
ensure people don’t think you’re the project manager2
It’s a fine line to walk but its absolutely possible to do in an efficient way.
The trick? Bring your methodical, customer-centric thinking to project communications. And even more so—use it as an opportunity to strengthen your executive presence while you do it.
Executive presence isn’t about being loud or owning every meeting. It’s about being strategic in how you communicate cross-functional work. It’s understanding incentives, meeting people where they are and bringing authority to swirly situations.
Rather than falling victim to the perils of project management, use it as an opportunity to lead with confidence. How?
Identify your stakeholder’s goals
Create strategic core documentation
Lock in effective ways of working around the project
Let’s dive in 🤿
But first…
I’m hosting THREE product events in April.
Calling all Chicago Product Leaders for a Product Leader Breakfast April 11th.
Join me for my *classic* Product Power Hour April 16th to experience Product Coaching first hand with a group of compassionate PMs.
Join me and Engineering Coach, Sarah Ing, for Product X Engineering Chemistry April 29th, an open coaching hour for PMs and Engineers who need support with cross functional relationships.
Back to regular programming…
Step 1: Identify Goals
Before you start building documentation or timelines, stop and ask:
What do stakeholders actually need to feel confident and informed about this given project?
Just like you would with customers, listen first.
Some leaders want milestone-level visibility. Others need clarity on when to engage. Legal doesn’t care about engineering blockers. Engineering doesn’t need to review contract redlines.
The biggest mistake you want to avoid is guessing what your cross-functional team needs and then over-engineering your documentation.
You 👏 will 👏 waste 👏 all 👏the 👏 time 👏 doing 👏 this.
Instead, ask your team questions like:
“What level of visibility helps you feel informed?”
“What risks are you most concerned about?”
“What context would you want if you were looped in later?”
“How do you want to be informed of changes?”
While you will not be building a solution that meets every stakeholder’s requirements3, it’s helpful to have conversations and identify what a MVP of project communication looks like for the mix of folks that need information from you.
This is also your chance to model strategic thinking and stakeholder empathy—two critical pillars of executive presence.
Remember, you are not a project manager and perfection is the enemy of progress.
Start with something and iterate.
Lean on your experimental product-mindset to evolve as you go.
Step 2: Create Core Documentation
One of the biggest questions that I see too many folks obsess over is what tools to use.
It bears repeating: you are not a project manager and you are not trying to impress people with a beautiful Notion hub they’ll never open.
You’re trying to make the work easier.
My #1 piece of advice? Use whatever tools people already know—Confluence, Google Docs, Slides—whatever gets adopted fastest and maintained with the least effort.
Executive presence means reducing friction, not adding complexity.
It also means organizing information in a way that respects people’s time.
Keep it lean, but impactful with these key components:
Project overview: What this is, and what it isn’t.
Milestones: With a respectful amount of granularity.4
Roles and responsibilities: Who owns what. Especially who needs to be involved in decision making.
Optional (but credibility-building) add-ons:
FAQ: Reduce repeat questions and show you’ve anticipated needs by adding this section to your core documentation.
Decision log: Help onboard new folks and reduce second-guessing when you don’t have the context for decisions from the past. It’ll likely be helpful for the actual decision makers too.
It isn’t about making a perfect plan.
It’s about showing that you’re on top of it, even during pivots.
That’s what people remember.
Step 3: Establish Ways of Working
Documentation isn’t helpful if no one knows when or how to use it.
So create just enough structure around how the work gets done, who updates what, and when conversations happen.
Establish:
A shared understanding of who owns the doc (likely you)
Bonus points for delegating pieces out
A cadence for updates (weekly, biweekly, etc.) and where they happen
The most important components to keep fresh (milestones? risks? dependencies?)
This clarity helps you lead the process without owning all the work—another strong signal of executive presence.
You're showing that you can set expectations and create focus, not just track tasks.
Step 4: Communicate Like a Leader
You can’t just write the plan—you have to socialize it. Product work is storytelling work and this is your time to shine.
Think about how senior leaders stay informed. They’re not reading every doc. They rely on you to distill and deliver what matters most.
Beyond core documentation, try:
Project Slack channels: Pin the doc. Share weekly updates. Make it feel alive.
Biweekly stakeholder syncs:
Ask folks to update status items before the meeting.
Use the time to discuss real blockers or trade-offs.
Have a notetaker so you can focus on facilitating (not multitasking).
Executive updates:
Write short summaries that highlight decisions, risks, and forward momentum.
Share in 1:1s, emails, or exec team meetings—wherever your leaders hang out.
Repeat yourself more than you think you need to.
Like customers, internal stakeholders are busy and distracted.
Great product leaders reinforce strategy with consistent communication.
Boundaries
Last but not least, it’s worth highlighting boundaries. This is where I see PMs edge into burnout and get caught doing two full jobs. Before you dive into project management tasks, take time to set some clear intentions, including do's and don'ts of the role you'll play as a project manager.
Practice meeting efficiency, prioritization and other techniques to keep you focused.
It’s how you keep your sanity and your credibility—without adding “project manager” to your title.
Another reminder…
I’m hosting THREE product events in April.
Calling all Chicago Product Leaders for a Product Leader Breakfast April 11th.
Join me for my *classic* Product Power Hour April 16th to experience Product Coaching first hand with a group of compassionate and validating PMs.
Join me and Engineering Coach, Sarah Ing, for Product X Engineering Chemistry April 29th, an open coaching hour for PMs and Engineers who need support with cross functional relationships.
Hi - I’m Jori and I’m a Product Coach.
If you’re looking for support - drop me a note, I’d love to connect. 🤝
I co-host Product Leadership Breakfast NYC, a monthly product breakfast series for PM leaders. If you live in NYC or find yourself passing through, join us! ☕
I define glue work as all the operational work that holds the projects together.
To be clear, its not bad to be known as a project manager. But if people think you’re the project and product manager, you’re in for a lot of work.
And this goal is a fool’s errand.
This is a negotiation but needs to be driven by your stakeholders.