The sticky note that got every vote

👋 Hey friends,

We ran our end-of-year retro a few weeks ago.

If you've never done a retro before, it's basically a safe space where the team can say what's really going on. What's working, what's not, what's frustrating them, what they wish was different.

We use sticky notes. Everyone writes their thoughts anonymously, puts them on the wall, and then we vote on what matters most.

One sticky note got every single vote.

"We're juggling too many projects without a designer, and it's breaking us."

I stared at it for a minute.

Because here's the thing: I already knew this. The team knew this. We'd been operating without a dedicated design partner for months after some team moves.

But seeing it written down, seeing everyone vote on it, hit differently.

It wasn't one person complaining. It was the entire team saying: we can't keep doing this.

It's not about working harder — it's about having a CRM that actually thinks ahead. HubSpot Smart CRM learns how your team operates and adapts to make everyone more effective. Streamline day to day tasks and track the activity that actually matters to your business. The result? Your team gets back hours every week to spend on growth instead of admin work. Start free. See the difference.

Get Started Free

Most PM content about resource constraints boils down to the same advice: you don't have a resource problem, you have a strategy problem. Just focus harder. Prioritize better. Say no more.

And yeah, sometimes that's true.

But sometimes you genuinely don't have enough people. Sometimes you lose a critical role mid-quarter. Sometimes leadership commits you to initiatives before you have the capacity to deliver them.

And in those moments, the advice to "just focus" feels dismissive.

Because the real problem isn't that you haven't prioritized. It's that you're trying to deliver too much with too little, and your team is drowning.

The sticky note in our retro wasn't a prioritization failure. It was an emotional breaking point.

Here's what was actually happening:

We were running multiple frontend projects simultaneously. The scope of our end-of-year sprint was to tackle some of our customers' biggest UX challenges, important work, high-impact work.

But without a dedicated design partner, everything took longer than it should have.

I was trying to fill the design gap myself, scheduling research calls, running design syncs, making UX decisions I'm not trained to make. Engineering was blocked waiting for design direction. We were shipping things that worked functionally but didn't feel polished.

And here's the part that really compounded it: I typically like to have one dev on each project. It forces us to keep projects small and delivery-focused.

But when you're running multiple projects with limited people and no design support, that model breaks. You're context-switching constantly. No one can go deep on anything. Everything feels half-done.

By the time we hit that retro, the team wasn't just tired. They were frustrated. Because they were working hard but nothing felt like it was moving fast enough.

After the retro, I knew we had to change something.

Not just tweak priorities. Actually change how we were operating.

Here's what we decided:

Instead of spreading across multiple projects, we're focusing on fewer areas and going deeper.

We're making most of our changes additive, building on what's already there instead of redesigning from scratch. This lets us ship with less design dependency.

We're not trying to ship perfect, comprehensive solutions. We're shipping the parts we have the most evidence for, the things we know will solve customer pain, and sequencing follow-ups for later.

This does two things:

Instead of running everything at once, we're doing things one at a time (or close to it).

It's slower in theory. But in practice, it's faster because no one's blocked, and we're not context-switching every day.

Okay, so you've realized your team is overloaded. You know you need to cut back. You've figured out what to focus on.

Now comes the hard part: telling stakeholders the plan has changed.

Here's what worked for us (and what didn't):

We set up a Slack channel with all our key stakeholders. It's basically a public decision log.

Anytime we make a call about scope, sequencing, or what we're cutting, it goes in there with context.

This does a few things:

When we told stakeholders we were narrowing focus, the language that worked was: "Here's why we're confident in these smaller, iterative wins."

We backed it up with:

The times we got pushback? When we didn't have enough evidence. When it felt like we were just cutting things because they were hard, not because the sequencing made strategic sense.

We didn't say "We can't do all of this."

We said "We're going deeper on fewer things to ship higher-confidence solutions."

Same outcome. Different framing. One sounds like retreat. The other sounds like focus.

Deel's free 2026 trends report cuts through all the hype and lays out what HR teams can really expect in 2026. You’ll learn about the shifts happening now, the skill gaps you can't ignore, and resilience strategies that aren't just buzzwords. Plus you’ll get a practical toolkit that helps you implement it all without another costly and time-consuming transformation project.

Get the free report today.

Here's what I've learned about operating under resource constraints:

It's not just a logistics problem. It's a morale problem.

When your team is constantly stretched thin, they start to feel like they're failing even when they're working their hardest.

That retro sticky note wasn't just about workload. It was about people needing permission to say out loud: this isn't sustainable.

And as the PM, your job isn't just to prioritize. It's to protect your team from burning out while still delivering value.

Sometimes that means cutting projects. Sometimes it means sequencing instead of parallelizing. Sometimes it means shipping simpler versions and iterating later.

But most importantly, it means acknowledging the emotional reality of the constraint, not just treating it like a prioritization puzzle to solve.

If you're managing a roadmap with limited resources, here's what helps:

Retros aren't optional. They're where people can safely surface what's not working.

If your team is overloaded but no one's saying it, they either don't feel safe or they think nothing will change.

You're spread too thin if:

These aren't performance issues. They're capacity issues.

When resources are tight, going wider makes everything worse. Going deeper makes everything better.

Ask: Can we ship this in phases? What's the smallest version that solves the core problem? What can we sequence for later?

Don't just communicate the final call. Show your work.

Create a place where stakeholders can see:

This turns "Why aren't we doing X?" into "I see why we're doing Y first."

Stakeholders resist arbitrary cuts. They accept evidence-based ones.

Before you tell someone their project is getting descoped, gather:

Then frame it as: "Here's what we're most confident will deliver value with current capacity."

That sticky note was a gift.

Not because it felt good to see. It didn't. But because it gave me permission to stop pretending we could do everything and start focusing on what we could do well.

Resource constraints aren't just a prioritization problem. They're a morale problem, a communication problem, and a sustainability problem.

Your job as a PM isn't to magically create more capacity. It's to operate within the reality of your constraints while keeping your team intact and delivering value.

Sometimes that means cutting scope. Sometimes it means shipping simpler versions. Sometimes it means telling stakeholders "not yet."

But always, it means acknowledging the human cost of trying to do too much with too little.

Here's the thing: I write this newsletter for you.

Not for engagement metrics. Not to sound smart. But to actually help you do your job better.

And the best way I can do that is by knowing what you're dealing with right now.

So I have two questions:

The stories and tactics that resonate most with you are the ones I want to keep writing about.

See you next Friday,

– Stef

💬 Want to talk product? I'm mentoring on ADPList! If you're managing roadmaps with limited resources, trying to figure out what to cut, or just need to talk through capacity planning, you can book a free session with me right here.

If you like Stef the PM, here are a few other reads worth checking out: