Hard Skills for Product Managers: Teams, Metrics, and the Quiet Art of Making Good Decisions

In Episode 63 of our Retention Podcast, we sat down with Andrii Mandrika – product leader, mentor, and founder of Hard Skills for Product Managers, a training platform focused on practical product skills and hands-on learning built around real product cases.

Andrii shared how his path took him from software development into product management, and later into teaching and mentoring product teams. We also talked about how the product manager role has been evolving and what it really takes to build strong product teams inside large organizations.

Here are a few highlights from our conversation.

How Cross-Functional Teams Work

Shipping a product takes more than one role. A product manager can’t come up with the idea, write the code, test the feature, push the release, and run the marketing campaign all at once. That’s why product teams are usually built as cross-functional units – small groups that already include everything needed to move an idea into production. Product, design, engineering, QA, sometimes analytics. No endless handoffs, no waiting for another department to pick things up.

Sometimes the product role itself gets split into two. It’s not something you’ll often see recommended in textbooks, but in practice it can make sense when things get busy. 

One person stays focused on the bigger picture – market direction, metrics, long-term strategy. The other works closely with the team day to day, making sure things actually move forward. It’s less about hierarchy and more about breathing room: keeping product leaders from drowning in operational work so they can still think about where the product should go next.

Where “Value Stream” Comes From

The term value stream comes from the SAFe (Scaled Agile Framework) methodology. In simple terms, it describes a flow of value delivered to a specific group of users – and back to the business in return. The idea is fairly straightforward: every interaction in the system should create value for all/any of the involved parties. 

In a marketplace like Rocket, for example, customers get their food, couriers get paid, restaurants get orders, and the company benefits from making the entire system work.

What makes the concept useful is the idea of flow. Work is organized so teams focus on their own stream of value without constantly stepping on each other’s toes. At the same time, everything still connects through the broader business model. The goal isn’t structure for the sake of structure. It is keeping the delivery flow steady – making sure value keeps moving instead of getting stuck between teams or scattered across disconnected initiatives.

When Teams Are Split the Wrong Way

When companies design teams, especially large organizations like banks, a common mistake appears almost immediately: teams get divided in ways that don’t actually reflect how the product works. A classic example is assigning a team to something like the “cart” on an e-commerce site. The problem is that a cart on its own isn’t really a product. It only makes sense as part of the whole buying journey.

That’s why it’s usually more effective to organize teams around complete user scenarios – the entire purchase process, for instance. In banking, a loan can be a real product because users come specifically for it, and both sides get value from the interaction. But a single page inside that flow rarely carries that kind of meaning.

When teams are split too narrowly, real ownership disappears. People become responsible for small fragments instead of outcomes. And once that happens, the product itself starts reflecting that structure. If the organization is fragmented, the product will feel fragmented as well.

Your Product Reflects Your Team Structure

There's a slightly uncomfortable truth in product work: products tend to mirror the teams that build them. When teams grow organically – shaped by internal politics, historical accidents, or simply "this person used to own that feature" – the structure becomes a bit random. And random structures don't just slow things down; they show up in the final product. Disconnected teams produce disconnected experiences. The org chart quietly leaks into the interface.

Of course, there isn’t one perfect way to organize teams. In theory, the cleanest model is simple: one team fully owns one product entity end to end. In practice, especially in large companies built around a single complex product, that’s not always realistic. 

Some organizations rely on feature teams that can jump into any part of the product. That reduces dependency risks, but it can slow down onboarding and blur focus. Others assign tighter ownership areas, which creates clarity but can trap knowledge inside individual teams.

So the real question isn’t which model is “correct.” It’s whether the current structure still works. And recognizing the moment when it stops working is often the real skill.

The Red Flags That Signal It’s Time to Change

The signals are usually pretty easy to spot. Teams are busy all the time, Jira tickets keep moving, tasks get closed one after another – yet no one can clearly explain what all that activity actually leads to. Strategic work slowly turns into a stream of operational tasks. Development continues, features ship, but the numbers that really matter barely move. When growth flattens, and key business metrics stay the same quarter after quarter, that’s not stability. It’s stagnation.

Another warning sign shows up within the team itself. People stop understanding how their work connects to the bigger picture. Tasks get done, but the link to revenue, growth, or product impact feels blurry. Motivation starts fading, and the discomfort spreads quietly. Talented people rarely leave because the work is hard – they leave when they can’t see what the work is for. Once the connection between vision and daily execution breaks, the entire system starts losing energy.

What to Look for When Hiring Product Managers

Hiring always starts with a simple question: what level of product leader do you actually need? At the head, VP, or C-level, strategy and soft skills take center stage – shaping vision, navigating complexity, aligning teams around a direction. At the mid or senior product level, the focus shifts toward harder skills: understanding metrics, building financial models, working with unit economics, forming hypotheses, and deciding what deserves priority.

A useful way to think about it is through four areas of product competence: customer insight, strategy, stakeholder management, and delivery. Some product roles lean toward defining direction and understanding users. Others lean toward execution – turning ideas into something that actually ships.

In interviews, the real task is figuring out which of these strengths the role truly requires. Can the candidate read product metrics and turn them into meaningful hypotheses? Can they make tough prioritization calls when resources are limited? And perhaps most importantly, can they move ideas from discussion into delivery?

Product Managers Don’t Have All the Answers

There’s a popular image of product managers as multi-armed superheroes who somehow know everything: the market, the roadmap, the metrics, the strategy, and the solution to every problem. In reality, that picture is mostly fiction. A good product manager doesn’t walk around with every answer ready. What matters much more is having the toolkit to find those answers – knowing how to analyze competitors, read product metrics, talk to stakeholders, and turn messy signals into clear decisions.

The role is still demanding. Product managers deal with everything from financial models to user interviews to delivery processes, and the list keeps expanding. But the real trick isn’t mastering every possible skill at the same level. Strong product leaders tend to lean into their core strengths while keeping the rest of the toolkit sharp enough to do the job.

And because products are complex systems, context takes time. A new product manager might spot a few quick wins in the first couple of months, but the bigger strategic moves usually appear later. Around the six-month mark, the pieces finally start clicking together – the product, the market, and the internal dynamics begin to make sense as one system.

The Problem with Product Metrics

One of the most common problems in product teams is surprisingly basic: people often don’t know what they should actually be measuring. Some teams fall back on the usual suspects – traffic, conversions, revenue. These numbers look important, but they rarely point to clear product decisions. They describe what’s happening, but they don’t really explain what the team should do next.

The opposite extreme isn’t much better. When everything gets measured, dashboards turn into dense forests of metrics where it’s easy to lose the signal entirely. At that point, the team spends more time navigating the numbers than learning from them. 

A more practical approach is simpler: start by identifying which metrics actually matter for the product and which ones the team already tracks. Once that foundation is clear, the numbers become much easier to interpret – and far more useful.

Turning Product Metrics into Real Decisions

When metrics are structured properly, they stop being just numbers sitting on a dashboard. They become a way to understand how the product actually works as a business. 

Teams can link those metrics to financial models and start running simple “what if” scenarios: what happens if conversion at a specific step grows by three percentage points? How much additional revenue does that generate? How quickly does the change pay for itself? Once you start looking at metrics this way, product decisions become much more concrete.

The old rule still holds true: if something can’t be measured, it’s very hard to improve. And yet many companies still treat metrics more like decoration than a decision-making tool. The result is predictable – money gets left on the table, or value quietly leaks out in places no one is watching. In the end, product management often comes down to two very basic goals: learning how to earn more or learning where to spend less. 

Metrics are what make those choices visible.

Why Product Decisions Need More Than Metrics

Numbers are useful, but they rarely tell the whole story. Metrics can show a pattern – a dip in retention, a spike in engagement – but they won’t explain why it’s happening. That’s where product work gets interesting. Data and experiments reveal what’s going on inside the system. Interviews, surveys, usability tests, and conversations with users reveal the human side of it.

The real skill isn’t choosing one over the other. It’s knowing when to open a dashboard and when to pick up the phone. Metrics give you signals. Qualitative research gives you context. If you rely on only one, you risk optimizing charts instead of improving the product.

In a Nutshell

Product teams work best when they are built around complete delivery. Cross-functional teams allow products to move from idea to release without constant handoffs, but how those teams are divided matters just as much. When ownership is split across isolated features or pages, the product itself starts to feel fragmented. 

Over time, products tend to reflect the structure of the organization behind them. From there, product work becomes a matter of decisions. Product managers aren’t expected to know every answer. What matters is having the tools to find them – through metrics, experiments, and conversations with users. 

The most useful product decisions emerge when structured metrics, financial thinking, and real user feedback come together. That’s usually where product improvements start becoming visible. Conveniently, it’s also the point where product meetings finally become shorter – because the numbers and the users start agreeing with each other.