If you haven’t read the previous article, Sergii Gudkov, our Product Lead with over 15 years in software development, shared his take on how product managers can approach their professional growth. 

In this article, we’ll focus on what matters most for first-time associate product managers (PdMs). While many assume the role begins with strategy and innovation, the reality is simpler. Your first responsibility is to take someone else’s idea and execute it well. That’s where you prove your value.

So, let’s dive into the harsh truth, debunked myths, and practical tips. Now, we give the floor to Sergii.

Delivery is the key

The best metric of your excellence is how rarely Senior or Group PdMs have to pay attention to your problems and fix them. Master delivering approved solutions flawlessly, and the doors to bigger opportunities swing wide open. Skip this step, and you’ll stay stuck forever.

Everyone has brilliant ideas. I mean everyone. Your engineer has ideas. Your designer has ideas. Even you probably have better product ideas than half the PMs you know.

But only a few people can actually deliver those ideas. The higher you climb, the bigger ideas you’re supposed to deliver. But here’s the twist—the higher you go, the less you actually deliver yourself. You start managing people who deliver. Then you manage people who manage people who deliver. And so on.

There are rumours that at the very top, you’re not managing anyone anymore — just influencing. 

The foundation remains the same: can you deliver? Because if you can’t prove you can deliver small things excellently, why would anyone trust you with the big things?

Let’s break down the key skills and habits that will help you get there.

What you need from Agile

Let’s be honest and skip the fancy terminology. Agile methodologies are your management toolkit for not screwing up deliveries. 

So, what stands (or, at least should stand) beyond the buzzwords of Agile?

1. Scrum: talking is not enough

Sprint planning isn’t about picking random tasks. It’s where you demonstrate that you actually understand what needs to be built and can give realistic estimates.

Most PdMs have, at some point, overlooked early warning signs during standups. Eventually, they ended up explaining to stakeholders why the team missed a deadline. No fun, trust me. I doubt you will be an exception here, but give it a try!

Sohere’s a lesson many learn the hard way: listen, not only talk and updates.

Especially, listen for the stuff that’ll kill your timeline. When that backend engineer mentions “small API delays,” your brain should immediately go, “Uh-oh, how does this mess up my launch date?”

To grow your PdM superpower lies in practising transforming these potential hiccups into proactive conversations.

2. Kanban: spot the trouble before it hits

Some teams don’t use sprints and instead work in continuous flow. That’s fine. Still, it’s your job to spot the bottlenecks and not let them become a disaster. If design review always slows you down, start preparing designs earlier. If QA gets overwhelmed, coordinate with them to prioritise your critical stuff.    

The key insight? These are tools, not religious rules. Pick what works for your situation.  By the way, I haven’t met a team that followed pure Scrum or Kanban. Usually, you have to deal with something in the middle, a weird mix of Scrum and Kanban and, most likely, something else. 

So, don’t overthink. Use what fits your team and context. Yet, having a management framework is just the beginning. You still need to find answers to two key questions?

• What are you building?
• Why would users care about it?

So let’s move to them!

Reading Minds: Understanding Users While Executing

Even if you’re ‘just executing’ others’ ideas, you still need to learn why users would want to use the product. Consider this as learning because even if you disagree, you likely can do nothing with this. So, just learn. 

Here are two practical tips on this:

• Remember, stakeholders are human. They make assumptions and don’t always have perfect user insights. You’re not expected to catch every mistake yet, but if you notice something off, speak up. If you can do that, it may help your career. Just give it a try. You will see if someone is interested in your opinion or not. 
• Keep a short diary of decisions and the reasons behind them. Note down when the team wins or fails and why. Especially write about times when data was ignored or research was stopped because “enough evidence” was found. Later, reviewing these helps you learn what worked and what didn’t.

Competitive Research As Your First Step

Check how competitors handle similar features. As an Associate PdM, you might not have the skills yet to run user interviews or dig into data, but you can steal like an artist explore competitor products. 

Spend some time weekly looking at how others solve the same problems. Notice small details like error messages, microcopy, or how edge cases are handled. When you find something useful, suggest ways to improve your product.

What does it give you?

• You can demonstrate proactiveness, which is very good.
• You improve the product, which is even better.
• You practice an important skill of crafting solutions.
• You boost your mental health: You don’t only execute, you contribute!

Connect the dots to influence business

Every feature you build should connect to business outcomes. You might not set revenue targets, but you need to understand how your work drives results and practice to communicate them. Demonstrating real work results is very motivating for any team. They deliver better, and that’s your job!

For example, you’re implementing onboarding. Don’t just measure completion rates. Instead, understand the chain reaction that drives them. If the company’s goal is revenue growth(and your CEO consistently emphasizes revenue growth), align your metrics with revenue growth. 

How to track success

• Map out this cause-and-effect chain for every feature you deliver.
• Always question the reason behind any tracking: 

1. Talk to your manager about what they want to see tracked
2. Ask peers which metrics helped them in similar cases
3. Check the engineers’ opinion to understand what’s feasible

• Deliver feature by feature and analyse the data step by step. It keeps things manageable and helps you stay connected to the impact.
• Communicate your results. Nothing builds your credibility faster than saying, “The feature I shipped last month increased trial-to-paid conversion by 12%.” (However, this works only if you can explain how).

How and when to escalate

You’re new. You can’t solve everything. And that’s perfectly fine.

Escalation is actually a way of solving issues. You should use it—a lot. Every senior manager I know prefers being informed about problems not before they explode into disasters, but before they even appear. That’s what it’s called risk management.

However, the trick is timing. Sometimes you can give the manager a chance to step in while the problem is still fixable. So here is how you can approach wisely:

Escalate when:-

• You’re genuinely uncertain about business priorities
• Decisions affect scope, timeline, or budget significantly
• You need resources to do something outside your control

Handle independently when:

• The decision is low-risk and reversible
• The impact stays within your feature
• You have clear logic for your choice

Escalation means you are seeking help, you can’t solve the issue, and you need someone else to solve it. Escalation may sound like this: “Hey, I need your help with X.”

However, even when you handle something on your own, report it. Your manager might offer feedback or a better approach. You can say: “Hey, we faced the issue, I did A and B, now we have C.”

How to handle prioritization 

You’ve got approved solutions. Why do you need prioritization? Seniors have prioritized and confirmed everything already. And on the surface, it makes sense — why question what’s already been confirmed? 

Nevertheless, you’ll prioritize implementation details and scope adjustments. However, in practice, things rarely go exactly as planned. Deadlines shift, blockers appear, and full scope delivery often becomes unrealistic. That’s when individual prioritization kicks in to make smart trade-offs in the details.

There are two frameworks that may help with cutting scope off: the Kano Model and MSCW Framework. At first glance, they look similar. Both help sort features into categories, but their logic is different. 

The Kano Model is about user satisfaction. It helps you think in terms of what delights, what’s expected, and what frustrates. With it, you prioritize features that will have the most significant impact on user delight:

• “Must-be” (expected, basic features), 
• “One-dimensional” (more of this feature leads to more satisfaction), 
• “Attractive” (unexpected, delightful features), 
• “Indifferent” (features that don’t significantly impact satisfaction), 
• “Reverse” (features that actually lead to dissatisfaction).

The MSCW framework, on the other hand, is about importance and urgency. It provides a clear way to prioritize deliverables: 

• “Must have” (essential for the project to succeed), 
• “Should have” (important but not critical), 
• “Could have” (desirable but not necessary), 
• “Won’t have” (features that will not be delivered in the current iteration).

So, if your company leans heavily into customer obsession, KANO usually makes more sense. If the focus is more internal on project timelines, stakeholder alignment, or delivery constraints, MSCW might be a better fit.

Then there’s ICE/RICE,  a data-driven framework invented by Intercom, built around scoring ideas based on impact, confidence, and effort. It’s particularly useful when you need to justify why something should be prioritized. 

One thing to keep in mind: no framework works if you don’t stick to it. Tools are only as good as the discipline behind them. And knowing which one to use, based on context, company culture, and what kind of decision you’re facing, is a skill worth developing.

From the KANO Model perspective, it may happen that the MUST-HAVE feature appeared on the bottom of the RICE table. That’s why we have different frameworks, and you have to master which one to pick. Don’t use a hammer for screwdrivers. 

Exploring each of the frameworks is beyond the scope of this article. So, I highly encourage you to learn more about KANO, MSCW, RICE and ICE. Read articles, watch videos, and talk to peers. You’ll eventually build your own sense of when to use which and that’s when prioritization gets much easier.

How to approach own and others’ updates

I’ve already mentioned that talking is not enough. Yet, it also takes time to polish your talking skills as well as active listening. For instance, make sure you give a precise update: 

• Bad status update sounds like ticking the box:  “Making good progress on the checkout feature.”
• Good status covers key points: “Checkout feature: We’re on track. No blockers. API integration complete, frontend 70% done, QA testing starts on Thursday. Risk: Payment gateway approval may delay launch by 2 days. Mitigation: Prepared fallback to current payment flow.”

Every time you give an update, answer these questions:

1. Are you on track or behind?
2. Are there any blockers?
3. What risks exist?
4. How are risks being addressed?
5. What’s completed?
6. What’s in progress?
7. What’s coming next?

Clear updates become even more crucial when problems arise. You have probably heard this advice: “Don’t just report problems — bring solutions.”

Let’s be real. You’re an Associate PM. It’s not actually your job to solve every problem. Everyone would be happy if you just managed to report issues early and clearly.

But here’s a good habit I picked up: when someone gives you bad news, ask about options. If your engineer tells you the API integration is broken, ask: “What are our options here? How long would each take?”

Then report the problem to your boss with the context you gathered. After that, you can ask other team members for their thoughts and add those insights to your follow-up message.

Why does this help? Your boss will likely ask those same people anyway. You’re just doing some prep work that saves everyone time and gives better context.

You’re not solving the problem—you’re making it easier for the person who can actually solve it. That’s a smart way without overstepping.

When Associate PdMs usually screw up

1. Re-engineering solutions

Imagine you receive a set of approved requirements, but along the way, you spot “improvement opportunities.” The natural temptation is to add complexity or new features to make things “better.”

This is where many associate PdMs stumble. Your role is to deliver the approved solution, not to redesign it midstream. Document improvement ideas for later, but deliver what was approved first. Remember your priorities! I’ve seen associate PdMs destroy timelines by quietly expanding scope “to make it better.” Better execution beats better features every time.

2. Forgetting the broader ecosystem

You focus only on your manager and forget everyone else who needs coordination. Engineering needs requirement clarity. Design needs feedback. QA needs test scenarios. Marketing needs launch details.

Create a stakeholder map for every project. Who needs what information, when, and how they prefer getting it.

So… what’s next?

Great execution is the foundation of product leadership. When you deliver consistently and tie your work to real impact, people notice. Meanwhile, you sharpen your judgment along the way.

Spotting problems early, making smart calls, and shaping better solutions prepare you for your next senior roles. There are no small features, only small thinking about features. So remember:

• Deliver clearly
• Measure impact 
• Communicate well

Your future product leadership career starts with how well you execute today. Master that first, and everything else follows.

Article by Sergii Gudkov

Sergii is a Product Lead with over 15 years of experience in software development and marketing. He believes that while there’s no one-size-fits-all approach to product management, it’s essential to share the skills, lessons learned, and successes gained from real-world cases.