How to Think Like a Product Manager: From Customer Empathy to Business Strategy

Written By Karl-Jörgen Finér

1.0 Introduction

One of the questions I get asked most often is, "What exactly does a Product Manager do?" The problem is that there isn't a good short answer. Explain it in a sentence and you oversimplify the role; explain it properly and you've probably said far more than the other person was expecting.

This article is my attempt at unpacking the wonderfully simple, yet surprisingly complex, world of Product Management where understanding customers, business, and technology comes together to create value. It's a profession grounded in data, frameworks, and structured decision-making, yet one that relies just as heavily on judgment, communication, and empathy. In many ways, Product Management is as much an art as it is a science, and by the end of this article, I hope you'll understand why. This article is for anyone who’s an aspiring Product Manager, or simply looking to gain another perspective, as it’ll deep-dive into what the role actually involves and what you can expect day to day, based on my experience over the past decade.

Rather than focusing on textbook definitions and well-worn clichés, I’ll concentrate on the aspects of Product Management that I believe matter most in practice. Specifically, I’ll cover:

  • Building a strong foundation: understanding the industry, customers, and technology of the product you manage

  • Developing business cases, and how Product Managers think about and approach the art and science of prioritization

  • The day-to-day reality of Product Management: delivering work and getting the best out of your team

For each of these pillars, I’ll share my perspective on what separates a mediocre Product Manager from a good one, and what ultimately distinguishes a great Product Manager from the rest.

To bring these concepts to life, along the way I’ll use two different products (that I along with millions of others love) as examples throughout the article: Google Finance and Disney+. I am intentionally avoiding retail, despite it being the industry I’ve been in throughout my career, to demonstrate an important point:

You do not need to be an expert in a particular industry to think like a Product Manager and deliver value. What matters is your ability to understand the customer, empathize with their needs, and identify opportunities to improve their experience.

From there, you can begin building solutions and features that create value for the customer while ultimately improving a key performance indicator of the product.

2.0 Building a strong foundation: understanding the industry, customers, and technology

A Product Manager is typically part of an Agile Scrum team, and our good friends at Atlassian define the role as follows:

“A Product Manager is the person who drives the development of a product, defining its strategy, roadmap, and features. They are responsible for identifying customers' needs and the larger business objectives that a product or feature will fulfill, articulating what success looks like for a product, and rallying a team to turn that vision into a reality”. (Mansour, 2026)

A typical Agile team consists of a Product Manager, Developers and QA Engineers, and a Scrum Master. The responsibilities outlined below reflect my own experience of how these roles typically operate in an enterprise Product Management environment.

The Product Manager owns the product backlog, which is a prioritized list of work to be delivered. That work consists of deliverable increments, or in other words, shippable features, enhancements, fixes, and other improvements to the product, whether it's a website, mobile app, or internal tool. At this point, a reasonable person might ask how does someone decide what should be included in the backlog? The key lies in three things:

1.      Understanding the industry in which the business operates.

2.      Empathizing with the customer and understanding their needs, frustrations, and goals.

3.      Combining industry knowledge and customer empathy with an understanding of technology to identify solutions that can effectively address those problems.

While that may sound simple in theory, it is this intersection of business, customer needs, and technology that sits at the heart of Product Management. Every feature, enhancement, or initiative that finds its way into the backlog should ultimately be rooted in an understanding of these three areas. Let’s break this down using product examples of Google Finance and Disney+.

2.1 Google Finance

When I asked Gemini what the purpose of Google Finance is, which referenced Adam Levy’s article on Motley Fool (Levy, 2025), it responded that it exists to "provide users with free, real-time access to global financial market data. It allows investors and consumers to track stock prices, build watchlists and portfolios, monitor currencies and cryptocurrencies, and aggregate financial news and AI-powered market insights."

As an avid investor myself, I can empathize with a Google Finance user. If you are not an investor, then as a Product Manager for a product like this, building empathy starts with understanding what actually matters to investors. So let’s start peeling back the layers.

Investors buy equities and other financial instruments with the goal of generating returns. To break it down, an investment journey can be split into two phases: before and after the investment is made.

Before buying, the focus is on research and decision-making; understanding the company, its industry, its financial performance, and whether the current price represents fair value. After buying, the focus shifts to monitoring - tracking performance, staying informed on relevant news, and continuously reassessing whether the original investment thesis still holds. Understanding this, now looking at the product through the eyes of its users, the overarching user stories could be written as follows:

As an investor, or someone interested in investing, I want to be able to view, analyze, and track investment instruments, so that I can stay up to date with a company's performance and make informed investment decisions.

The second core user story focuses on users who already own investments:

As an investor who owns investment instruments, I want to be able to track my portfolio over time so that I can understand my performance and compare it against other assets and benchmarks, and also ensure my original investment thesis holds.

These could represent two epics within the broader Google Finance product: Investment Research and Portfolio Tracking.

Now comes the part that separates simply documenting requirements from thinking like a Product Manager. The question isn't "What features does Google Finance have?" The question is "What is the customer trying to achieve?"

Thinking about my own investment journey, before purchasing a stock, I first want to understand what the company actually does and how it creates value for its customers. I want to understand the industry it operates in, whether that industry is growing or declining – this will be the leading indicator to what type of multipliers are expected to earnings, PE, revenue etc. I also want to understand whether the company has developed a sustainable competitive advantage; as investors often call it, an economic moat (Gratton, 2025).

From there, I want to review the company's financial performance, valuation metrics, recent news, quarterly earnings, competitors, and anything else that helps me determine whether the current share price represents fair value. Personally, I look for opportunities where I believe the market price is 20% below the intrinsic value of the asset, although every investor will have their own investment philosophy.

If I conclude that the stock is fairly valued or undervalued, I may decide to invest. If I believe it is overvalued however the company is great, I may choose to wait and add the stock to a watchlist, or gradually build a position through dollar-cost averaging.

Once I've made the investment, however, my needs change. Research becomes less important than monitoring. I want to track my portfolio's performance, compare it against benchmarks, stay informed about company news and earnings releases, and be alerted to anything that could strengthen or weaken my original investment thesis.

I also want my portfolio to be easy to manage. When I buy or sell shares, I want those transactions to be reflected accurately. If I reinvest dividends, I want those purchases to be taken into account when calculating my investment performance. If I sell a position entirely, I no longer want it cluttering my active portfolio view, but I still want the transaction history preserved so it continues to contribute to my year-to-date, one-year, five-year, or any other investment horizon when analyzing my historical performance.

Notice how this exercise naturally starts generating potential product features. Company profiles, financial statements, valuation metrics, news feeds, watchlists, price alerts, portfolio tracking, benchmark comparisons, and earnings notifications all stem from understanding what the customer is trying to accomplish.

Rather than starting with features, we started with the customer's problem, and the features followed naturally.

Therefore, if you were to join a team like the Google Finance product team, and you’ve identified what investors are looking for in a product, it will be easy for you to start noticing functionalities that are not present in the product yet, but could be added as either feature enhancements, or new features all-together. Putting myself in the shoes of an investor and using Google Finance, there are a number of small enhancements and larger feature opportunities that immediately become apparent. While none of these ideas may be groundbreaking on their own, collectively they improve the overall user experience and better support the core user journeys discussed earlier.

Feature Enhancements

1.       Allow users to save portfolio views

  • As an investor, I may prefer to sort my portfolio by current market value, alphabetical order, or most recent date purchased. Today, those views cannot be saved, forcing me to repeat the same actions every time I return to the product. Saving custom views would create a more personalized and efficient experience.

2.      Allow users to hide positions with a zero-share balance

  • Once I have completely exited a position, I no longer want it cluttering my active portfolio view. At the same time, I don't want to delete the investment entirely, as doing so removes it from my historical portfolio performance. A simple filter to exclude positions with a quantity of zero would allow investors to maintain a clean portfolio while preserving the integrity of their historical returns.

3. Accurately account for dividend reinvestment

  • Dividend investors often reinvest their distributions back into the same company. Those reinvestments should automatically contribute to investment performance calculations so that portfolio returns accurately reflect the investor's true gains over time.

New Feature Opportunities

1. Investment Valuation Toolkit

  • Long-term investors want to understand not only what a company is worth today, but why. Google Finance could provide a comprehensive valuation toolkit that includes an estimated fair value range, built-in valuation models such as Discounted Cash Flow (DCF) and comparable company analysis, as well as a qualitative assessment of the company's competitive advantage (MOAT). By combining quantitative and qualitative analysis in one place, investors could make more informed investment decisions without relying on external spreadsheets or third-party solutions.

2. Industry and competitor analysis

  • Investing in a company also means investing in the industry in which it operates. A dedicated industry analysis page could explain the industry's current stage in its lifecycle, highlight macroeconomic trends, identify key competitors, and compare companies across important financial and operational metrics. This would help investors understand not only the company itself, but also the competitive landscape in which it operates.

3. Market Pulse Dashboard

  • Investing decisions are rarely made in isolation from the broader market. A Market Pulse dashboard would provide investors with a concise view of key market indicators such as the Fear & Greed Index, VIX, market valuation metrics (e.g., S&P 500 P/E ratio versus historical averages), insider buying activity, and market breadth. Rather than predicting market movements, the dashboard would help investors understand the current market environment and make more informed, disciplined investment decisions.

Screenshot taken from CNN “Fear & Green Index” page on the 25th of July, 2026 (CNN Business, 2026)

Now let’s look at an entirely different product, with different customers, different needs and features, in an entirely different industry – Disney+

2.2 Disney+

Disney+, in their own words, is “the ultimate streaming home for entertainment from Disney, Pixar, Marvel, Star Wars, National Geographic, and Hulu” (Disney+ Help Center, 2026). They provide thousands of titles, from exclusive originals to beloved classics, with the aim of delivering a high-quality, family-friendly streaming experience. As someone who has subscribed to multiple streaming services, including Disney+, I can easily empathize with its customers and what they are looking to get out of the service.

First, what initially drew me to Disney+ was its content. My second consideration was price. I wouldn't care that Disney+ has Modern Family and Mad Men if it cost $50 a month, but $15.99 is a price I'm happy to pay. Because Disney+ offers exclusive content that isn't available on other platforms, such as the series “Welcome to Wrexham” and content from Marvel Studios and Star Wars for example, it has a natural competitive advantage and a sticky subscriber base.

That said, I suspect Disney+ doesn't measure success solely by the number of subscribers. Equally important is how much customers engage with the platform - how many shows they watch, how much time they spend on the service, and how frequently they return. These are the metrics that indicate how invested a customer really is.

If a customer watches the same show over and over again, and that show suddenly becomes available on Netflix, they're much more likely to cancel their subscription. On the other hand, if they're watching multiple shows, spending hours each week on the platform, and regularly discovering new content through Disney+'s recommendations, they're probably not going anywhere.

In fact, highly engaged customers create opportunities for Disney+ to introduce premium subscription tiers or increase prices over time. Disney+ exists to make money, and the more value customers get from the platform, the more valuable those customers become to the business: As a Product Manager, that's ultimately what defines your success - great Product Managers don't just optimize for revenue, they optimize the customer behaviors that eventually create revenue.

Now let's look at what it takes to get the platform to that point. A user story for seamlessly discovering new content could be written as follows:

As a Disney+ user, I want to be shown movies and shows that I'm interested in and haven't yet watched, so that I can enjoy my time at home without having to search the web or manually browse through the app to find something to watch.

The key with this user story is that using Disney+ should feel seamless and effortless. The more time people spend searching for something to watch, the more frustrated they become. The more frustrated they become, the more they start thinking that maybe Disney+ doesn't have such great content after all - perhaps it really does only have Mad Men and Modern Family. At that point, they begin asking themselves whether the $15.99 + taxes monthly subscription is really worth it.

Another user story relates to the viewing experience itself. I've found the show I want to watch - now I expect the viewing experience to be simple, seamless, and comprehensive.

As a Disney+ user, I want to be able to perform all the basic actions of a streaming platform, including playing, pausing, adjusting the volume, navigating between episodes, managing subtitles and translations, and more, so that I can get the most out of my viewing experience.

With every technology, there are features that are considered hygiene factors (must-haves), exciters (delighters), and detractors, as described by the Kano Model (Sapio Research, 2026). Being able to press play, adjust the volume, rewind, and fast-forward are hygiene features. Customers expect them to work flawlessly, and if they don't, they quickly become detractors.

Exciters, especially in a mature product with a well-established interface, can be harder to identify, but they certainly exist. For example, could Large Language Models (LLMs) translate every show into every language, including Estonian, Icelandic, or Welsh? In countries such as Germany, where foreign television is commonly dubbed, could AI-powered voice technologies automatically generate high-quality voice-overs? People with hearing or visual impairments also enjoy consuming content - how can Disney+ make that experience even better?

(Sapio Research, 2026)

A good Product Manager understands what the necessities are, and get the job done. A great Product Manager can identify exciters and recognizes that customer needs differ across markets and cultures. People in the United States and Canada generally prefer not to read subtitles, whereas for Estonians they are second nature. Germans are accustomed to dubbed content. To make your product exciting and cutting edge, a great Product Manager asks “what else is there that would drive value and be exciting for my users”?

The previous user story may have seemed straightforward at first, but the more time you spend analyzing and empathizing with customers, the more opportunities you uncover even in technology that appears mature, saturated, and already well understood.

Similarly to Google Finance, putting ourselves in the shoes of a Disney+ customer quickly reveals a number of opportunities to improve the user experience. Below are a few examples of feature enhancements and new feature opportunities as of 29 June 2026.

Feature Enhancements

  • Allow users to switch episodes directly from the playback screen

    • There are many occasions where I realize I've started the wrong episode. Naturally, I click Back expecting to be taken to the episode list so I can select the correct one. Instead, I am prompted the home screen, I have to search for the show again, open it from the search results, and only then can I browse the available episodes. It is frustrating for me, frustrating for my wife, and my mother doesn't know how to do it at all—she simply switches to Netflix instead. Disney+ already appears to support this functionality under certain scenarios, but it should be part of the standard viewing experience. Better yet, Netflix allows users to switch episodes directly from the playback interface without leaving the video. Reducing this friction creates a smoother viewing experience and lowers the risk of users abandoning the platform.

  • Add a "Previous Episode" button

    • Currently, Disney+ only allows users to skip to the next episode. There have been many occasions where I've fallen asleep while watching a series and my wife has continued watching. The following day, I want to watch the episode I missed, only to discover there is no "Previous Episode" option—only "Next Episode" or "Restart." A simple addition would eliminate unnecessary navigation and improve the overall viewing experience.

  • Allow users to choose their streaming quality

    • While high-speed internet is common in many parts of the world, it is far from universal. I often tether my laptop to my phone when travelling or working in public places where I don't trust the Wi-Fi. In those situations, I'd like the option to reduce video quality and conserve mobile data. Equally, there are users who always want to stream in UHD whenever possible. Giving users control over video quality accommodates both scenarios and creates a more flexible experience.

New Feature Opportunities

  • Smarter "Recommended For You" experience

    • Recommendation engines are one of the biggest drivers of customer engagement, yet there is still room for improvement. At the time of writing, I browsed three rows of recommendations—twelve titles in total—and only one caught my attention. The platform also continues recommending The Office, despite the fact that I've watched it repeatedly. Recommendations should evolve as users' viewing habits change, helping customers discover new content rather than resurfacing what they have already watched. The better Disney+ becomes at content discovery, the more likely customers are to remain engaged and subscribed.

  • AI-powered translations

    • Advances in AI and Large Language Models (LLMs) mean there is little reason every show shouldn't be available in virtually every language. Making the full Disney+ catalogue accessible to speakers of smaller languages would significantly broaden the platform's global reach while creating a more inclusive experience for existing customers.

  • AI-powered dubbing

    • In many countries, subtitles are not the preferred way to consume content. AI-generated voice dubbing could make Disney+'s entire catalogue available with natural, high-quality voice-overs, reducing localization costs while delivering a far better experience for users who prefer dubbed content.

Notice that none of these ideas required inside knowledge of Disney+. They came from something much simpler: empathizing with the customer, using the product, and paying attention to moments of friction. That's often where the best product ideas originate.

Now that we've seen how to understand an industry, empathize with the customer, and translate those insights into product requirements, let's look at the next pillar of Product Management: building business cases and prioritizing what to build.

3.0 How to build business cases & the art of prioritization

3.1 Building business cases

Before diving into business cases and prioritization, it's important to acknowledge something that may seem obvious - neither happens in a vacuum. While Product Managers often identify opportunities based on underperforming KPIs, emerging technologies, or shifts in the industry, they are far from the only source of new initiatives. Business stakeholders regularly bring forward requirements driven by customer commitments or operational needs, often supported by their own business cases. At the same time, leadership, analytics, UX, and other enterprise teams continuously monitor market trends and identify strategic opportunities that become initiatives of their own. As a result, most organizations have a constant pipeline of competing business cases. These are evaluated against the company's strategic objectives by senior leadership, and once approved, are prioritized and distributed across Product teams for delivery.

With that context in mind, let's examine how business cases are built, evaluated, and ultimately prioritized.

When evaluating business cases, and subsequently deciding what to prioritize, it's important to recognize that not every initiative is going to be the next big idea, or even something that will be an enhancement or a new feature. Particularly on enterprise platforms, a significant amount of work happens behind the scenes. Modern applications are made up of numerous microservices that integrate with one another, relying on APIs, encryption protocols, data schemas, and security standards that must be continuously maintained and updated.

As a Product Manager, this means dedicating part of your time to managing technical debt, maintaining platform stability, and delivering compliance and security initiatives. While this work may not generate incremental revenue, it is essential for providing a secure, reliable platform that customers can trust, and keep the product running. A straight-forward framework to think about the initiative mix for a platform can be described by “Run”, “Grow”, “Transform”.

(ClearCost Software, 2021)

One reality that Product Managers sometimes find difficult to accept is that "Run" initiatives are often delivered at the last responsible moment. This isn't because organizations don't care about compliance, security, or technical debt - it's because there are usually other initiatives that generate more immediate customer or business value.

Imagine your backlog contains three initiatives:

  • First will help you achieve your annual sales target.

  • Second will replace a legacy system and unlock new capabilities for future development.

  • Third is required to pass a compliance audit at the end of the financial year.

Assuming all three initiatives are equally sized, the compliance initiative will typically be planned and delivered in time to meet its deadline, but not necessarily any earlier, even if the requirements are ready. Until it becomes the highest priority, the business is usually better served by investing its finite capacity elsewhere. This thinking aligns with Lean principles, particularly “Decide as Late as Possible" while planning ahead, and "Deliver as Fast as Possible" to maximize value and return on investment (Hunt, 2018). In other words, it's a given that the foundations of your product must be secure, stable, and compliant. However, if those foundations are already sufficient for today, and building another floor will help you meet or better yet exceed your business objectives, then that's where your effort is likely to be focused.

With that in mind, let's look at how Product Managers evaluate opportunities for “Grow” and “Transform”, build business cases, and ultimately decide what deserves to be built next.

How to prioritize is an intuitive and highly logical exercise - as a Product Manager you want to deliver the maximum value in the shortest amount of time. The value vs effort matrix captures this idea perfectly. The best projects to prioritize are the so called “low hanging fruits”, that are projected to drive lots of value, and they have small effort associated to them.

Estimating value is an exercise in business casing. A business case becomes more reliable with a higher degree of confidence, when its assumptions are supported by data. At the core of every business case are assumptions that ultimately translate into measurable outcomes. In retail, for example, business cases commonly target KPIs (key performance indicators) such as revenue, margin, conversion, and customer retention.

Some typical examples of business cases include:

  • Improving our checkout flow by introducing features A, B, and C will increase conversion by X%, resulting in $Y of incremental revenue.

  • Introducing "Switch to Save" recommendations for own-brand products will convert X% of eligible purchases, increasing transaction margin by Y%.

Once these assumptions are validated and approved as part of a business case, they become the KPIs against which the initiative is measured after launch.

Google Finance, for example however, is a very different type of product. As a free service, its success is not measured directly through subscription revenue or product margin. Instead, the business case must align with Google's broader strategy and the role Google Finance plays within its ecosystem. Understanding the business, and the purpose of the product, is once again essential.

To reiterate, “Google Finance exists to help investors research, analyze, and monitor investments” without leaving Google's ecosystem. The more useful the product becomes, the less likely users are to rely on third-party tools to complete their investment research. Let’s take three examples of the “proposed” features, and feature set enhancements, that we created from our previous analysis, and see how it fits into this idea:

  • Investment Valuation Toolkit – reducing the need to build valuation models in Excel.

  • Market Pulse Dashboard – allowing investors to view market sentiment, such as the Fear & Greed Index, without leaving Google Finance.

  • Industry & Competitor Analysis – reducing the need to visit external platforms such as Morningstar or other financial research websites.

The value of these features is not measured by direct revenue. Instead, they increase user engagement, encourage repeat visits, and strengthen Google Finance as a destination for investment research. Relevant KPIs might include active users, session duration, return frequency, feature adoption, portfolio creation, watchlist activity, and overall engagement with the platform.

Those engagement metrics also contribute to Google's broader business objectives. The more users rely on Google Finance as their primary investment research tool, the more time they spend within Google's ecosystem. This creates additional opportunities for users to engage with other Google products, including Search, News, Gemini, YouTube, and Android.

Importantly, Google does not need to monetize Google Finance directly for the product to create business value. As users interact with Google services, Google gains a better understanding of their interests through first-party signals, subject to its privacy policies and user controls. Someone who regularly researches financial markets, for example, may also search for financial news, investment books, educational content, or financial services. Those aggregated signals help Google deliver more relevant experiences across its products and improve the effectiveness of its advertising platform. In that sense, Google Finance is not simply a financial tool - it is another touchpoint that strengthens user engagement across Google's wider ecosystem while supporting the company's core advertising business.

To conclude, as a Product Manager, once you understand the business, the role of your product, and the customer it serves, building business cases becomes significantly easier. A great Product Manager starts with empathy, understands the product strategy and its role within the broader portfolio. Subsequently, the Product Manager defines the right KPIs, analyzes the data, and builds business cases grounded in evidence rather than intuition. Because once those KPIs and targets are agreed upon, they become the benchmark against which your success is measured. The key concept here is the following:

The business case isn't just a justification for doing the work - it's the commitment you'll ultimately be held accountable for.

3.2 Estimating effort

As outlined in virtually every reputable literature discussing Agile Methodologies, there are many techniques for estimating effort, including T-shirt sizing, relative sizing, Fibonacci story points, Planning Poker, and others. These techniques are means to an end, and I won't explore them in detail here. The purpose of this article is to demonstrate how to think like a Product Manager, not to provide a guide on effort estimation methodologies, as for example J. Ashley Hunt’s “PMI-ACP Project Management  Institute Certified Practitioner Study Guide” is an excellent source to learn the ins and outs of estimating methodologies (Hunt, 2018). Ultimately, for a Product Manager the goal is to develop a reasonable understanding of the effort required to deliver an initiative in a timely manner so that it can be prioritized effectively and communicated with confidence to leadership. To estimate effort, the Product Manager must understand what needs to be built, and compile requirements. Requirements should be anchored by:

  • What are we looking to build?

  • Why are we looking to build it?

Those are business questions that will have been answered within the business case, covered earlier in the article. To estimate effort, it needs to be understood how the solution will be built – that’s where the development team’s, and potentially other expert input, will be required.

Some conservative product professionals advocate running extensive discovery workshops, defining detailed requirements, producing UI mock-ups and architecture diagrams, along with conducting multiple refinement sessions before estimating how long a project will take, or even deciding whether it should be undertaken at all! The reasoning, as some would argue, for completing such in-depth exercise is to minimize risk. The hard truth is that, in practice, this rarely works. No reasonable Product Manager, or senior business leader, should feel comfortable with investing weeks or even months of effort from the Development Team, UX, Architecture, Security, Engineering, and other teams to fully define and estimate an initiative that may never be built.

On the other hand, a purely textbook interpretation of Agile, where development begins with little upfront definition, no clear understanding of the end solution, and no meaningful timeline, is equally unrealistic in most enterprise environments. Organizations have finite resources, strategic objectives, and KPIs to achieve. While Agile principles provide an excellent foundation, mature product organizations typically adapt them to balance discovery with planning, ensuring they invest enough effort to make informed decisions without overcommitting resources before an initiative has been approved.

As a Product Manager, providing an initial effort estimate is an exercise in balance. The objective at this stage is to define the requirements as clearly and concisely as possible, identify the major risks and unknowns, and estimate the effort with an appropriate level of confidence.

The greater the uncertainty, the wider the estimate should be. For example, an initiative with significant unknowns might initially be estimated at 8 weeks ±50%. As those risks are investigated and requirements become clearer, the confidence increases and the estimate can be refined to something like ±10%.

The goal before starting a major initiative is not to answer every question or commit to a single delivery date. It is to explain

  • what is being built and why,

  • explore how it could be delivered,

  • identify the key risks and unknowns, and

  • outline whether those risks will be accepted, mitigated, or transferred.

By doing so, a Product Manager can provide leadership with a realistic view of the effort, delivery confidence, and associated risks. Importantly so, this information can be provided in quick order, in a matter of days, and not weeks or months. That information is invaluable when evaluating trade-offs across the enterprise, prioritizing initiatives, allocating budgets, and building product roadmaps. If you can confidently communicate those three things, effort, risk, and confidence, you've done your job. Once the value and the effort of the initiatives on the roadmap are estimated, the prioritization can begin:

‍Features that deliver high value with relatively low effort naturally become attractive candidates for implementation, while low-value, high-effort initiatives warrant greater scrutiny. Product Managers could further define value through a structured prioritization framework, such as RICE (Reach, Impact, Confidence, and Effort), to introduce greater objectivity into the decision-making process (McBride, 2016). Frameworks like RICE help compare initiatives consistently, challenge assumptions, and make the rationale behind prioritization transparent.

To conclude, prioritization will always remain as much an art as it is a science. Not every initiative on your roadmap is directly comparable. How do you compare a compliance initiative with a revenue-generating feature? Or technical debt with an AI capability that could differentiate your product in the market? Frameworks provide structure, but they cannot fully make those decisions for you. This is where strategy becomes the deciding factor. Remember the Run, Grow, Transform framework, and the reality that not every initiative is intended to transform the business.

A great Product Manager understands the organization's objectives, the role their product plays within the broader portfolio, and the priorities of the business at that moment in time. That's what separates an average Product Manager from a great one.

Equally important, you don't need the title of Senior Product Manager or Group Product Manager to think like one. If you're an Associate Product Manager today, ask yourself: who is more likely to earn the next promotion - the Product Manager who has the potential to become great, or the one who already thinks, behaves, and delivers like one?

Ultimately, this article has not presented a single framework that guarantees the right answer every time. Instead, it has offered a way of thinking about customer empathy, business cases, effort estimation, and prioritization. There is no mathematically perfect roadmap. The goal is to make thoughtful, evidence-based decisions that maximize value while advancing the organization's strategic objectives. That's where the science of Product Management ends, and the art begins.

4.0 The day-to-day reality of Product Management: delivering work and getting the best out of your team

In this final section, we'll briefly cover the day-to-day mechanics of Product Management and then dive into the interpersonal skills and ways of thinking that make Product Managers effective. Writing user stories, running Agile ceremonies, and managing the product backlog are certainly core responsibilities, but they are only part of the role. Because Agile teams are self-managing and composed of specialists rather than direct reports, leading them requires a different approach than traditional people management.

4.1 Fundamentals of Product Management

Once a business case has been approved, delivery can begin. This is where requirements are refined and broken down into work the Agile team can implement. By this stage, you should already have a solid understanding of what is being built, why it is being built, and a good idea of how it will be delivered. Your Development Lead should also be involved early and aligned on the solution before refinement begins.

The work is typically broken down into the following levels, as defined by Schwaber and Sutherland, 2020, and Atlassian, 2026:

  • Initiative: A large body of work that delivers a meaningful business outcome and often spans multiple teams or releases.

  • Epic: A major feature or capability within an initiative that is too large to complete in a single sprint.

  • Story: A small, deliverable piece of functionality that provides value to the user and can typically be completed within a sprint.

  • Enhancement: A small improvement to an existing feature. In practice, I write enhancements almost identically to user stories, following the same structure and level of detail.

  • Spike: A time-boxed investigation used to reduce uncertainty or answer technical or business questions before development begins.

  • Bug: A defect where the product does not behave as intended and requires correction.

Initiatives and epics should be descriptive and capture the key details from the approved business case. If an initiative consists of multiple epics, they should be broken down into logical, coherent pieces of work that can ideally be delivered independently. For example, if Disney+ approved a broader “Video Player Localization” initiative, then “AI-powered dubbing” and “AI-powered translations” could each be separate epics under that initiative. Wherever possible, the KPIs that define success should be captured at the initiative level and, where appropriate, broken down further into measurable outcomes for each epic. Every story should contribute to an epic, every epic should contribute to an initiative, and every initiative should contribute to a measurable business objective. If you cannot trace that relationship, you should question why the work exists in the first place.

Now let’s briefly look into refinements, and how to write stories, bugs and spikes.

The key to effective refinement of stories is to make requirements as simple, concise, and logical as possible. Include everything needed for successful delivery, but nothing more. I've often seen stories containing only a sentence or two, sprinkled with technical jargon, with the expectation that developers will simply "know" what's required. Even if the requirements are explained during refinement, that story may not be picked up until weeks or even months later. By then, the discussion has long been forgotten, leading to blocked tickets, unnecessary spikes, rework, or features that fail QA or Product Manager sign-off because they don't meet the original intent.

The structure for stories I've found most effective is straightforward:

  • Description

    • Begin with a user story using the format: As a... I want... so that... in the description

  • Acceptance Criteria

    • Capture the expected behaviour using Given, When, Then scenarios.

Using the Disney+ "Previous Episode" enhancement discussed earlier, the ticket could include the following:

Description (User Story)

As a Disney+ user, I want to quickly navigate to the previous episode while watching a series, so that I can easily rewatch an episode without having to leave the playback experience and search for it again.

Acceptance Criteria

Scenario 1(a) – Display the Previous Episode button (not the first episode)

Given a user is watching a TV series
And the current episode is not the first episode of the series
When the playback controls are displayed
Then a Previous Episode button is displayed alongside the existing episode navigation controls.

Scenario 1(b) – Do not display the Previous Episode button (first episode)

Given a user is watching a TV series
And the current episode is the first episode of the series
When the playback controls are displayed
Then the Previous Episode button is not displayed.

Scenario 2 – Navigate to the previous episode

Given the user is watching , for example, Episode 5 of a series
When they select the Previous Episode button
Then Episode 4 begins playing from the start.

‍

Once the user story has been refined, the team will determine whether it should be split into smaller, independently deliverable increments or estimated as a single piece of work. In my experience, estimating individual tickets using Fibonacci story points works well, though some teams prefer linear story points, days or hours, or other estimation approaches. Regardless of the technique used, the same exercise should be completed for every deliverable that ultimately ends up on the product backlog.

When writing bugs, I recommend following a structure similar to the Given, When, Then format, while clearly distinguishing between the Current Behaviour and the Expected Behaviour. This makes it immediately obvious what is happening today, what should happen instead, and gives developers and QA a clear basis for validating the fix.

Let's assume the Previous Episode button has been implemented, but instead of navigating to the beginning of the previous episode, it incorrectly jumps to the end.

Scenario 1 – Previous Episode button navigates to the wrong timestamp‍ ‍

Given I am watching a TV series
And I am on the second or a later episode
When I click the Previous Episode button

Current Behaviour

Then I am navigated to the end of the previous episode.

Expected Behaviour ‍

Then I am navigated to the beginning of the previous episode.

‍ ‍

Spikes typically arise when the “what” and “why” are clear, but there is uncertainty around “how” the requirements should be delivered. When the team cannot confidently estimate the effort because the solution approach is unknown, a spike can be created to investigate options and reduce uncertainty. Spikes should always be timeboxed, with a defined amount of time allocated to understand the problem and determine the best path forward.

Some Product Managers may argue that spikes can also be used when the “what” or “why” are unclear. I disagree. If the problem, objective, or desired outcome is not understood, then the work is not ready for refinement. Those questions should be answered by the Product Manager before bringing the item to the team.

Ultimately, the mechanics of Product Management, initiatives, epics, stories, bugs, enhancements, spikes, and Agile ceremonies, are foundational concepts that are largely consistent across organizations. However, the way those artefacts are documented and managed can vary depending on the team, product, and company culture. The examples provided in this section represent an approach that has worked well in practice, but there is no single "correct" way to structure your work.

What matters most is that the team has clarity - everyone understands what is being built, why it matters, and what success looks like. Also, when someone outside your team enters your work board, or you have a new developer joining the team, it should be easy for them to understand what is being delivered.

With the foundations of requirements, refinement, and delivery covered, the next step is moving beyond the mechanics of Product Management and focusing on the human side of the role - emotional intelligence and enabling high-performing teams.

4.2 of Product Management: Emotional Intelligence and Enabling High-Performing Teams

‍Product Managers own the product backlog and are accountable for what the Agile team delivers. Developers and QA engineers are responsible for how the solution is built and validated. Agile teams are self-managing, made up of highly skilled specialists who rely on one another's expertise. What catches many people not familiar with Agile off-guard is that, despite Product Managers being accountable for the Agile team’s work, Product Managers typically have no direct authority over the team.

Leading without authority is nuanced, and it starts with earning trust. Your first responsibility is to ensure the team is always working on the most valuable initiatives. That means your business case must clearly articulate the what and the why, while your requirements and acceptance criteria must be concise, unambiguous, and cover the important edge cases. Software is unforgiving - it either behaves as expected or it doesn't. When requirements are vague or incomplete, developers are forced to make assumptions, QA uncovers defects late, rework follows, and trust in the Product Manager erodes.

A hard truth is that simply because a business case has been approved, and you are presenting tickets that are ready for refinement, does not mean the team will automatically agree with all of its contents.

Engineers will challenge assumptions, question value, and propose alternative approaches. That's healthy. Your role, as a Product Manager, is not to avoid those conversations, but to lead them. Your job is to create an environment where the best ideas win, regardless of where they come from. The strongest Product Managers understand that they are not the expert in every discipline. They rely on and collaborate with engineers, designers, analysts, systems architects, and business stakeholders to bring their expertise to the table, and their role is to connect those perspectives, make informed decisions, and ensure the team is solving the right problem.

The initiative should define the strategic objective, desired outcome, and expected business value. The solution itself should be a collaborative effort. If the how is debatable, and the team arrives at a better approach that achieves the intended objective, then let the best idea win. A Product Manager should not become attached to a specific solution simply because it was the original idea - the goal is not to prove who was right, but to deliver the right outcome for the customer and the business.

Another hard truth is that you won't always have the answers, and that's perfectly acceptable. Every Product Manager will encounter situations where requirements conflict, edge cases emerge, or the existing product behaves in unexpected ways. Pretending to know the answer, or force an idea, helps no one. Instead, ask questions, investigate with the team, and leverage their expertise to arrive at the best solution together. Saying, "I'm not sure, let's work through it", is not a sign of weakness; it's a sign of confidence, humility, and good judgment. Once the facts are clear, however, make a decision and stand behind it. Product Managers are trusted to make decisions under uncertainty, not to pursue perfect information. Avoid analysis paralysis, be decisive, and remember that while the team is responsible for building the solution, you remain accountable for the outcome – so once you’ve made a decision, own it, and stand behind it.

Once you've earned your team's trust, another challenge emerges - maintaining a healthy, motivated team over the long term. Software development can become repetitive. Stories are refined, estimated, developed, tested, released, and then the cycle begins again. Even after major initiatives are delivered, there is always other tickets waiting. This is where emotional intelligence becomes one of a Product Manager's greatest strengths. Get to know your team. Celebrate milestones. Keep the atmosphere positive, share a laugh, and recognize good work. High-performing teams are built on trust, respect, and genuine relationships, not just processes. As a Product Manager you will have KPIs to achieve and business cases to deliver, but you need an engaged team to achieve them. Working closely with your Scrum Master and Development Lead to foster a positive team culture is every bit as important as building the roadmap itself. Leading without authority is built on trust, and trust is earned through action. A Product Manager who measures outcomes, advocates for their team, and communicates effectively with leadership builds credibility in both directions - earning the confidence of leadership while creating an environment where the team feels supported, motivated, and empowered to do their best work.

4.3 Measuring Outcomes, Advocating for Your Team, and Communicating Effectively With Leadership

There's a common saying among professionals across every industry who practice humility while consistently delivering excellent work: “My results speak for themselves". The hard truth is, they don't.

Over the years, I've met many desk warriors who work tirelessly, solve complex problems, and never receive the recognition they deserve because they don't speak for their work. It is the curse of the competent. If you make your job look easy, people assume it must be easy. I've fallen into that trap myself and, to this day, still find it difficult to talk highly of my own work. Then I remind myself that it isn't about promoting me. As a Product Manager and leader of my team, it is my responsibility to highlight their achievements and give credit where it's due. It's not about gloating - it's about recognizing great work, motivating the team, and demonstrating that what we do creates real value.

Measuring outcomes and communicating them effectively starts, again, with the business case. What did you build? Why did you build it? Which KPIs were you trying to move? Your analytics team - or, even better, your own ability to extract, analyze, and interpret data - is one of your greatest assets.

Suppose your team estimated that an Investment Valuation Toolkit in Google Finance would be used by one million users and generate an additional seven million interactions within the Google ecosystem per week. Measure it, and share the results. You achieved the expected outcome? – great! If not, you have an opportunity to investigate where the customer journey broke down and why your assumptions didn't match reality.

Remember, the business case was approved collectively. When an initiative exceeds expectations, meets them, or falls short, it is the team's shared success or shared lesson. Celebrate success together, and when things don't go as planned, take accountability alongside the team. Finger pointing when something does not go as expected is a big “no-no” in Agile. Ironically, it's when an initiative underperforms that you have the greatest opportunity to demonstrate your ability as a Product Manager.

  • Can you identify where the customer journey broke down?

  • Can you gather meaningful customer feedback?

  • Can you engage stakeholders across the organization and leverage their expertise?

  • Most importantly, can you turn a disappointing outcome into a better product?

‍That's where trust is built, with both your team and your leadership. Great Product Managers don't disappear, or start pointing fingers, when things go wrong; they lean into the problem, learn from it, and lead the team forward. It’s important to note that leadership also has stakeholders to answer to. Whether they proactively receive the information from you or must come looking for it, the outcome is the same -  effective communication is one of the most valuable skills a Product Manager can develop.

When communicating with senior leadership, whether that's a Senior Director, Vice President, or C-suite executive, I believe in concise, tailored communication. Before speaking or writing, I ask myself two questions:

  • What KPIs is this leader accountable for, and

  • What information are they actually looking for?

Once you understand those two things, communicating becomes much easier. Focus on the facts that matter to them, leave out everything else, and get straight to the point. There's a reason it's called an executive summary; executives want the headline, the outcome, the risks, and any decisions that need to be made. If they want more detail, they'll ask for it, or they'll dive into the supporting material themselves.

The same principle applies when communicating with your manager, although the execution is different. I firmly believe that one of my responsibilities is to make my manager's job as easy as possible. Keep them informed through concise, regular updates so there are no surprises around priorities, delivery, or risks. We align on what needs to be done, and the next time we speak, the work is either complete, or well underway. Either way, I will have an update.

One of the best ways to build trust with your manager is to be organized. Don't be the Product Manager who needs constant reminders or lets priorities fall through the cracks. Take notes, maintain a system that works for you, and capture work early. Even if a ticket isn't yet ready for refinement, a partially defined ticket on your board that is visible is far better than a forgotten requirement that resurfaces weeks later. You'd be surprised how often work slips through the cracks, simply because it wasn't tracked properly. If you consistently demonstrate that you're organized, follow through on commitments, solve problems independently, and communicate proactively, your manager will quickly learn that they can rely on you. That's when you've reached an important milestone in your career: you've become a Product Manager who doesn't need to be managed, because you can be trusted to manage yourself.

5.0 Conclusion

The tools, frameworks, and methodologies will evolve. Technology will change. AI will, and has already changed, the way we build products. But the fundamentals won't. Understand your customers. Understand your business. Understand your technology. The rest is execution. Ultimately, what separates great Product Managers from average ones is their ability to create value through customer empathy, sound business cases, thoughtful prioritization, and leading with emotional intelligence.

‍ References

‍ ‍

Karl-Jörgen Finér
Next

The Untold Power of Hollywood, Music, and the American Brand