Product Leadership in the Digital Age
- Leadership
- 4 min read
Madhushree Roy – Global Product Management, Mastercard
Digital products rarely fail because the technology is weak. Most companies already invest in solid tech stacks, modern tools, and capable engineering teams. The real miss happens elsewhere: building the wrong thing or building the right thing in a way that doesn’t solve the real customer struggle.
That’s why product leadership in the digital age starts with a very specific kind of thinking. It’s less about templates and deliverables and more about decision-making: how problems are identified, how outcomes are defined, and how trade-offs are made across customer value and business goals.
This is where digital product management becomes a business responsibility more than a delivery responsibility.
Key Takeaways:
- Digital products fail more from solving the wrong problem than from weak tech, so product leadership is really decision-making under trade-offs.
- A digital PM’s core job is to connect business goals to real customer struggles through strategy, and then translate that into outcomes, roadmaps, and priorities.
- Strong discovery means turning noisy inputs (feature asks, competitor moves, deadlines) into evidence-backed problem statements with clear “who/what/why”.
- Prioritisation is continuous and context-driven, use frameworks (RICE, MoSCoW, Kano, Value vs Effort) to remove bias and align teams, not to look “scientific”.
- Great execution comes from tight PM–Design–Engineering collaboration, clear delivery artifacts, smart experiments/metrics, and the soft skills to align stakeholders without authority.
What a Digital Product Manager Actually Owns?
A digital product manager works on software-based products delivered electronically through apps, web applications, dashboards, or APIs. The core ownership is the customer problem space:
- identifying the problem worth solving
- defining outcomes that matter
- deciding what needs to be built and why
- using data and user feedback as the main inputs throughout the product’s life
The job sits at a tricky interface: customers, business goals, and technical feasibility are all pulling at the same time. The product manager is expected to connect these, not treat them as separate tracks.
How this role differs from closely related roles
There’s overlap across PM, project management, and program management, but the differences matter because they change what success looks like.
- Traditional product management (physical products):
The responsibility still includes outcomes and value, but the nature of constraints changes. Physical products tend to have clearer timelines (start → middle → finish) and heavy operational constraints such as supply chains, logistics, distribution channels, partnerships, and fixed launch cycles. - Project management:
Project managers focus on execution coordination delivering on time, within scope, and within budget. If the product manager defines what and why, the project manager defines how and when.
Program management: This role typically spans multiple products and cross-team execution. Program managers drive coordination at an organisational level, ensuring teams don’t operate in silos and that broader KPIs are being moved together, similar to an orchestra conductor aligning multiple groups.
What Makes a Product “Digital”?
A digital product is software-based, but that alone doesn’t capture what makes it function like a modern digital product. Digital products tend to have several core properties (not always all, but at least a few of these show up strongly):
1) APIs and integrations
APIs play a foundational role in scalability and partnerships. They allow services to connect, exchange data, and execute functions across systems. In domains like banking and insurance, APIs are often the backbone of innovation, such as instant account opening powered by video KYC capabilities.
2) Platform presence
Digital products typically live on platforms: apps, web platforms, and dashboards. They’re rarely standalone and often support multiple user roles:
- end users
- internal teams
- partners using the platform to access data or perform actions
This multi-user environment changes how the product is designed and measured.
3) Data as fuel
Data enables real-time insights, personalisation, and continuous feedback loops. In digital products, data doesn’t sit on the side, as reporting it actively shapes product decisions and improvements.
4) UX and interactivity
Most digital products include a front-end experience. That makes usability and intuitive interaction a major success lever. UX helps identify friction points and remove them, making the product easier to adopt and repeatedly use.
5) Network effects
More users often create more value. Sometimes it’s direct (more participants improve payments usage), and sometimes it’s indirect (more usage improves recommendation engines and personalisation).
The Core Responsibility: Connecting Business Goals to Customer Problems
A product manager operates between:
- business goals (what the business wants to achieve)
- customer problems (what users struggle with day-to-day)
The bridge between the two is product strategy a clear definition of how solving customer problems will help achieve business outcomes.
And from product strategy flows everything else:
- features
- capabilities
- roadmaps
- prioritisation decisions
Example of the “strategy chain” in action
If a business goal is to increase low-cost deposits (to improve the CASA ratio and net interest margins), the product strategy could becoming the customer’s primary transaction account.
Once that strategy is clear, the customer problems get sharper:
- slow onboarding
- limited visibility into spending
- trust and security concerns
Then product decisions start emerging naturally:
- instant account opening
- no unnecessary balance constraints
- personal finance insights and recommendations
- stronger authentication and security features
This is the flow:
Business goal → Product strategy → Customer problems → Features/capabilities
The PM’s Role Across the Digital Product Lifecycle
Digital products move through three broad phases when being built and scaled:
1) Discovery
This is about identifying and validating problems worth solving:
- finding problems through customer feedback and data
- validating which problems matter
- prototyping and hypothesis testing
- framing the problems clearly for the next stage
Discovery can involve visits, interviews, partner discussions, branch insights, and firsthand observation, especially when the journey is not digital yet.
2) Delivery
This is where prioritisation and execution start taking shape:
- brainstorming ideas
- prioritising based on business goals and impact
- roadmapping and trade-offs
- aligning teams
- building and testing in the market
3) Growth
This is where outcomes are checked against reality:
- monitoring adoption, engagement, retention, monetisation
- tracking whether the intended goals are being met
using metrics and data to guide improvements
The Product Triad That Builds Digital Products
Digital products are shaped by three core groups working together:
Product Management
Owns outcomes and customer value:
- decides what to build, why, and when
- drives viability decisions based on impact
Design
Owns usability and desirability:
- creates prototypes early
- tests hypotheses
- iterates experiences
- ensures accessibility and removes friction
Engineering
Owns feasibility and technical constraints:
- evaluates scalability
- manages technical debt trade-offs
- ensures the product doesn’t break under real-world usage
- assesses feasibility of product and design ideas
A common failure mode is when PMs behave like managers of the other functions. Digital products work better when responsibility is shared, and partners are brought in early:
- designers should be involved during discovery, not late handoffs
- engineers should co-own roadmap feasibility, not be involved only at “build time”
The Full Digital Product Lifecycle: From Conceive to Retire
When the lifecycle is broken down further, the stages become clearer and more actionable:
Conceive
- identify unmet needs
- define success metrics
- validate demand
Plan
- shortlist key problems
- build roadmaps
- define MVP scope
- identify dependencies, risks, resourcing, partnerships
Develop
- operate in sprint cycles
- maintain product backlogs → sprint backlogs
- build iteratively
- test internally with business users and stakeholders
Test
- closed user group testing
- A/B testing
- beta rollouts (sometimes with consent, sometimes observed behaviorally)
Launch
Launch involves much more than marketing:
- defining channels
- internal enablement
- customer support/customer success readiness
- go-to-market strategy (B2B vs B2C, distribution approach)
- pricing decisions
Maximise
- optimise the funnel
- monitor product performance
- expand use cases
- improve targeted metrics (for example, retention)
Retire
- sunset features as markets evolve
- manage regulatory changes
- plan migrations
reduce technical debt
Key PM Skills That Matter Across All Stages
These skills don’t belong to one phase. They show up daily across discovery, delivery, and growth.
Prioritisation
Prioritisation is continuous:
- choosing what gets built next
- selecting what enters a sprint
- deciding which customers’ feedback matters most
- selecting which metrics deserve attention
Every “yes” becomes a “no” somewhere else.
Stakeholder management
A PM works across:
- design and engineering
- customer success and operations
- business and sales teams
- risk, compliance, and privacy teams
The outcome is often delivered through others, which means relationships and alignment become the real work.
Communication
Constant switching is part of the job:
- one moment with technical teams
- next with regional teams
- then with business stakeholders
The narrative changes, but the core message stays consistent: customer value and business impact.
Technical fluency
Technical fluency doesn’t mean writing code. It means understanding:
- how systems talk to each other
- how data can be used
- basics of non-functional requirements like concurrency, latency
- what can cause systems to break
This builds better collaboration because technical teams feel understood.
Empathy and curiosity
Empathy helps understand user needs. Curiosity pushes deeper into why those needs exist. Together, they help uncover motivations, constraints, and real drivers behind behaviour.
RACI clarity to avoid decision paralysis
RACI (Responsible, Accountable, Consulted, Informed) helps prevent:
- unclear ownership
- duplicated effort
- slow decision-making
- “everyone owns it so nobody owns it” situations
It becomes especially useful when multiple product teams and engineering teams intersect, like platform integrations and shared APIs.
Customer Discovery Starts With Translating Inputs Into Problems
Customers might ask for “a new feature”. Stakeholders might say, “The competitor launched this.” Leadership might demand a launch by next quarter.
These are inputs, not problems.
A strong product mindset translates those inputs into:
- the underlying customer struggle
- the unmet job
- the observable behaviour caused by that struggle
Weak thinking jumps straight to building features. Strong thinking steps back and asks:
What problem is behind this request?
A useful reminder: customers are experts in their problems, not in the solution.
Problem Framing: Who, What, Why (Backed by Evidence)
A well-framed problem has three parts:
Who is experiencing the problem
“Everyone” is never a real answer. A useful definition focuses on:
- user type (first-time vs frequent, price-sensitive vs convenience-seeking)
- context (time, situation, environment)
- maturity (new vs experienced users)
Example: food delivery late at night has a very different context from ordering at lunchtime, even if the feature is the same.
What the problem is
Avoid feature language. Don’t describe the solution.
Bad framing: “Users want faster delivery.”
Better framing: “Users feel anxious and frustrated when they don’t know if food will arrive on time.”
That describes the struggle, not the fix.
Why it matters
Link it to business impact:
- cancellations
- reduced repeat orders
- app switching
- trust erosion
- retention decline
Evidence that supports it
Proof comes from:
- user quotes and interviews
- behavioural data and funnel drop-offs
- cancellation reasons
- support tickets
- usage patterns
Choosing Which Problems to Solve: Pain, Frequency, Business Impact
Even after agreeing on valid problems, not everything deserves investment right now.
A problem becomes a priority when it sits at the intersection of:
- pain severity (how painful the experience is)
- frequency (how often it happens)
- business impact (how directly it moves key metrics)
Example:
- late delivery is painful, but frequency may be medium
- unclear ETA creates high anxiety, happens consistently in that context, and drives cancellations and churn
So the focus shifts: reduce ETA uncertainty because it hits all three dimensions strongly.
Lightweight Customer Discovery Methods
These methods don’t require massive budgets or long timelines, but they still generate strong insights.
Customer interviews
Used early to understand:
- motivations
- emotions
- context
- past behaviour (not future intent)
The focus is: what happened, what was frustrating, and what they did next.
Surveys
Used to validate qualitative patterns at scale:
- frequency of the issue
- strength of sentiment
- repeated behaviors
Interviews tell you what’s happening. Surveys help quantify how widespread it is.
Observation
Firsthand experience reveals friction that users may not articulate:
- trying journeys end-to-end
- identifying form fatigue and field overload
- spotting hesitation points
Data analysis
Data reveals:
- drop-offs
- completion time
- cancellation reasons
- funnel behavior patterns
Turning Insights Into Strong Problem Statements
A strong problem statement is:
- human-centered
- specific
- solution-free
- backed by evidence
Example framing:
Late-night food delivery users feel anxious and lose trust when ETAs change multiple times after ordering, leading to higher cancellations and fewer repeat orders.
A common structure:
User experiences [problem] when [context], leading to [negative outcome].
JTBD, Personas, and Why They Matter
A problem statement explains what’s broken. JTBD shows what progress the user wants.
Example JTBD:
When I’m tired after work and it’s late, I want a reliable way to get dinner without uncertainty so I can relax and eat without stress.
JTBD reduces feature obsession and clarifies emotional drivers. It also hints at true competition (what users might do instead).
But JTBD alone isn’t enough because constraints and trade-offs vary:
- some users trade money for certainty
- some trade time for lower cost
- some care more about reliability than speed
That’s why personas matter.
Useful personas include:
- goals
- behaviours
- context
- pain points
- constraints
Avoid personas that are only demographics or fictional backstories with no insight.
From Problem Statements to Product Opportunities and Ideas
A problem statement can create multiple product opportunities in different “value zones” where solutions could exist.
Example opportunities for late-night delivery:
- increase trust in late-night deliveries
- improve transparency during delays
- reduce anxiety after checkout
From opportunities come ideas:
- show ETA confidence ranges
- proactive delay notifications
- reliability scores for restaurants
- restrict listings to high-confidence partners
- compensation for late delivery
At this stage, judgement should be paused. The point is idea generation and exploring opportunity space.
Evaluating Ideas Before Building Anything
Ideas are cheap. Execution is expensive.
So product leaders evaluate ideas with questions like:
- Which customer problem does this address?
- How severe and frequent is that problem?
- Who benefits, and who doesn’t?
- How does it align with business goals?
- What assumptions must be true for it to work?
This prevents building features for edge cases, loud stakeholders, or weak business alignment.
Prioritisation Frameworks: Creating Structure for Trade-offs
Even after evaluating ideas, a team will still have more good ideas than capacity.
Prioritisation frameworks help because they:
- prevent loud voices from dominating
- reduce bias and emotional disagreements
- create structured conversations
- support better judgement through data
RICE as a practical example
RICE = Reach × Impact × Confidence ÷ Effort
- Reach: how many users are affected
- Impact: effect on key business goals
- Confidence: strength of discovery evidence
- Effort: work required, validated with engineering partners
Example: showing an ETA confidence range
- reach: high (everyone sees ETA)
- impact: medium (sets expectations, improves trust)
- confidence: high (validated through discovery)
- effort: medium (front-end/back-end changes, no major algorithm overhaul)
This is how low-hanging, high-leverage work starts to become visible.
Prioritisation Beyond RICE: Fast Alignment vs Deep Rigor
RICE is useful when there’s data, time, and enough clarity to score ideas with discipline. But in many real product situations, teams need quicker alignment, or they are operating with incomplete information. That’s where other frameworks help.
What matters is not picking one “best” model. It’s knowing which model fits the stage you are in, the kind of problem you are solving, and the constraints you have.
MoSCoW: Defining MVP Scope Without Getting Stuck
MoSCoW is a simple method to get fast stakeholder alignment and define MVP scope when there are too many features on the table. The logic is straightforward: take a long list of candidate features and bucket them into four categories:
- Must have
- Should have
- Could have
- Won’t have (for now)
The key strength of MoSCoW is speed. It helps teams agree on what must ship for the product to function credibly and what can wait.
In the late-night delivery example, accurate ETAs fall into ‘must’ because if ETAs are wrong or inconsistent, the value proposition breaks and users lose trust quickly. Proactive delay notifications move into ‘Should’ because they reduce anxiety and improve the experience, but the product still works without them.
Something like restaurant reliability badges often belongs in the cloud because it adds decision-making value, but it comes with assumptions: many users already know which restaurants they order from, and they may not browse restaurants extensively at night. It also comes with potential disputes from restaurants and higher effort to implement in a defensible way.
And then there are ideas like drone delivery, which sit in Won’t due to high effort and regulatory uncertainty.
MoSCoW helps because it pushes the team toward a practical MVP scope and avoids the trap of trying to do everything at once.
Value vs Effort: A Quick Shortcut When Time Is Tight
Another lightweight approach is the value vs effort matrix. It’s a simplified way to think about trade-offs.
- Value covers what a feature can deliver in terms of impact and reach.
- Effort covers implementation cost across technical work, regulatory effort, operational dependencies, and complexity.
It doesn’t aim to be granular or mathematically measurable. The point is quick alignment. When teams are short on time, Value vs Effort helps filter ideas into what should be tackled now versus what needs to wait.
Kano’s Model: Prioritising When You Have No Data
Kano’s model becomes especially useful for greenfield products where there is no precedent, no clean baseline data, and no clarity on effort or impact.
Instead of effort and scoring, Kano focuses on customer satisfaction and breaks features into:
- Basic needs: the must-haves that prevent dissatisfaction
- Performance needs: improvements where “more is better”
- Delighters: unexpected features that create delight
In a personal finance manager context, basic needs might be a single platform where users can initiate investment journeys across products like mutual funds, fixed deposits, PPF, and NPS. Performance needs could include visibility into balances, what to invest more in, and reminders like SIP due dates. A delighter could be showing balances across all banks through account aggregators, where users log in once and see everything.
Kano works well early because it helps teams define the MVP and the early roadmap direction before the product has enough usage signals.
Choosing the Right Framework Depends on Context
A practical way to think about it:
- If time is short and alignment is needed fast → MoSCoW or Value vs Effort
- If the product is new and there is no precedent → Kano
- If there is enough data and time to go tactical → RICE
In most cases, it ends up being a combination. The goal is not framework perfection. The goal is making trade-offs with clarity.
From Prioritisation to Consistency: Product Vision and Product Strategy
Prioritisation helps choose what to do next. But over time, teams need a way to make choices consistently, even when new problems, new data, and new stakeholders show up.
That’s where product vision and product strategy come in.
- Product vision describes the destination: where the product is going and why it exists.
- Product strategy is the route: where to invest, where to avoid, and how to sequence bets over time.
Without strategy, prioritisation becomes reactive. With strategy, prioritisation becomes directional.
Horizon Thinking: Today’s Needs, Tomorrow’s Growth, Future Bets
A simple way to structure product strategy is the horizon model:
- Horizon 1 (Today’s needs): core trust and fundamentals
- Horizon 2 (Tomorrow’s growth): expansion and stronger experiences
- Horizon 3 (Future bets): larger experiments and long-term plays
In the late-night delivery example:
- Horizon 1 might focus on improving core trust: ETA confidence ranges and proactive delay updates (low effort, high impact)
- Horizon 2 could expand trusted experiences: late-night bundles, personalised offers, sorting recommendations by reliability
- Horizon 3 becomes future bets: predictive logistics, dark kitchens for late-night demand, and other long-term experiments
This approach helps teams avoid mixing a long-term bet into a short-term delivery plan without readiness.
Roadmaps: The Communication Tool That Aligns Teams
Strategy needs a way to be communicated across teams: business, operations, tech, design, sales, and more. That tool is the roadmap.
A roadmap functions as a statement of intent. It takes inputs from different teams, aligns them, and communicates what the product is trying to achieve over time.
A roadmap is not:
- a feature list
- a rigid project plan
- a fixed commitment
Markets change. Regulatory constraints change. Engineering constraints change. Priorities change. A roadmap has to be flexible and treated as a guiding document, not a rigid plan.
Theme-Based Roadmaps vs Timeline-Based Roadmaps
Theme-based roadmaps focus on strategic pillars and initiatives without going too granular. This avoids creating false expectations.
Timeline-based roadmaps can be useful internally, but they need to be used cautiously because if they circulate widely, they can set unrealistic expectations. When timeframes are used, they should be broad: quarters, or 0–3 months, 0–6 months, 0–12 months, and sometimes multi-year planning.
In the late-night delivery example, the flow can be expressed as:
- 0–3 months: trust and transparency (ETA confidence ranges, clearer delay messaging)
- Next phase: improving reliability (reliability scoring, auto-restricting unreliable partners)
Later: predict and scale (predictable models, dark kitchens, experiments with future bets)
From Roadmap to Backlog to Sprint: How Delivery Actually Begins
Once the roadmap defines intent, it flows into:
- Backlog: the full list of what could be built
- Sprint planning: selecting backlog items for a sprint cycle
- Delivery cycles: execution and iteration
Backlog sequencing depends on:
- customer impact
- business impact
- risk and uncertainty
- dependencies
- learning value
At this stage, the PM shifts from choosing “what” to enabling teams to build the right thing well.
The PM’s Role in Execution: Clarity, Collaboration, Feedback
Execution succeeds when intent is clear and collaboration is strong.
Clarity comes from tools like:
- PRD and BRD
- well-written user stories
- clear acceptance criteria
Collaboration improves when teams have enough space to explore trade-offs and edge cases. This is where dedicated solutioning calls matter. Grooming sessions alone often don’t create enough time to think through complexity. Solutioning calls with engineering, design, and data teams surface edge cases early and reduce rework later.
Product Review as a Real Stage in Delivery
If delivery workflows skip product review, quality suffers.
One example of this is when engineering peer review becomes the final gate, and UAT becomes rushed or informal. Adding a visible “product review” stage makes product owners accountable for feedback quality and turnaround time and prevents items from silently moving to “done” without proper validation.
PRD vs User Stories: Why They Exist Together
PRDs and user stories serve different purposes.
A PRD is a problem-and-outcome artefact:
- goals and success metrics
- target users and context
- high-level requirements
- risks and open questions
It should not become a technical specification or a UI design document. If it becomes too detailed, it reduces creativity and limits the team’s ability to explore better approaches.
User stories come after solutioning is more stable. Once teams agree on the solution direction and designs are fixed enough to build, user stories help translate that into sprint execution.
A standard user story format is:
As a [user], I want to [do something], so that I get [value].
For late-night food ordering:
As a late-night food ordering customer, I want to see a delivery time range so that I can decide whether I should order or not.
Acceptance criteria then removes ambiguity. For example, “range” needs definition. Is it ±2 minutes, ±20 minutes, or something else? Should it apply only after a certain time? Should it show for all users or only in certain contexts? These constraints belong in acceptance criteria to make “done” unambiguous.
Working With Engineering, Design, and Data Like True Partners
Execution quality improves when teams are involved early, not treated as downstream builders.
Engineering
Engineering should be involved from roadmap stages, so feasibility and tech debt trade-offs are visible early. Treating engineering as a build function creates late surprises and fragile decisions.
Design
Designers contribute far more when they are part of discovery. If they hear customer problems firsthand, they design with context, not instructions. They can also lead research processes, co-own scripts, co-run feedback sessions, and validate hypotheses early through prototypes.
Data
Data should not enter only after launch. Data teams help define what needs to be captured early so success metrics are measurable. They also help refine the north star metric, define experiments, and structure A/B tests properly.
When data requirements are discovered late, teams end up doing additional work only to capture missing signals, slowing down learning and iteration.
Tech Debt: The Cost of Short-Term Speed
Tech debt is unavoidable. Many decisions are made to meet urgent customer demands, especially for high-value customers, but that often creates long-term fragility.
Examples include:
- heavy customization making workflows complex and fragile
- delaying migrations while piling more load on old infrastructure
A PM’s job is to:
- understand the impact
- make it visible to business stakeholders
- prioritise debt reduction alongside customer value
A practical approach is reserving 10–20% of sprint capacity for tech debt items: infrastructure improvements, migration work, stability fixes, and reducing long-term fragility.
Experimentation and A/B Testing: Validating Before Full Rollout
Experimentation reduces risk. Instead of rolling out a feature to everyone, teams test on controlled exposure.
A good A/B test starts with:
- a hypothesis (e.g., ETA confidence ranges reduce cancellations)
- a success metric (cancellation rate)
- decision criteria (what change counts as success)
- controlled exposure with comparable denominators
This avoids misleading comparisons where large and small groups are compared unfairly.
Go-to-Market: Target Users, Channels, Readiness, Pricing
Go-to-market is broader than marketing channels. It includes:
- defining target audience segments
- tailoring communication for first-time users vs churned users vs loyal users
- selecting channels (organic vs paid, cross-sell vs standalone)
- internal readiness: training teams, preparing support, enabling sales and call centers
- sequencing: pilot users → organic launch → paid amplification
Pricing also plays a central role. Pricing decisions depend on the product context: the alternate solutions customers have, internal comparable offerings, market benchmarks, and delivery economics where relevant.
Metrics: How a PM Defines Success Without Confusion
Different teams define success differently unless there is a shared metric system.
Without metrics:
- one team may say success is “features shipped”
- another may say success is “revenue”
- another may call it a failure due to retention drops
Metrics prevent this ambiguity by grounding decisions in evidence. But metrics are only useful when they are well-chosen. Measuring everything creates noise. Measuring the wrong things creates false confidence.
The North Star Metric
A north star metric is the single metric that best captures the value a product delivers to the customer.
A strong north star metric is:
- customer-centric
- hard to grow without real customer value
- difficult to game
- simple enough for the organisation to understand
For late-night delivery, strong options include:
- percentage of late-night orders delivered within the promised ETA range
- repeat late-night orders within 30 days
Cancellation rate is an important metric, but repeat behaviour often reflects trust and retention more reliably.
OKRs and AERR: Aligning at Different Levels
There are two useful metric structures mentioned here, each serving a different purpose.
OKRs
Objectives define what you want to achieve. Key results define how success is measured. OKRs help align teams and leadership quickly on high-level outcomes.
Examples in the late-night delivery context include improving the repeat order rate or reducing cancellations by a defined percentage.
AERR Framework
AERR helps govern performance across the product funnel:
- Acquisition
- Activation
- Engagement
- Retention
- Revenue
Not every stage matters equally for every product situation. In the late-night delivery example, acquisition and activation exist because users already know the app and place orders. Engagement exists because they are repeat users. The core problem is retention: mid-order cancellations and fewer repeat late-night orders.
So the right metrics focus on retention signals such as the percentage of users who place another late-night order and cancellation-related metrics tied to trust.
Funnels, Cohorts, and Leading vs Lagging Indicators
Metrics can also be structured as:
Funnel metrics
Tracking step-by-step behaviour across a journey helps identify friction points: where users drop off, what changed recently, whether the issue affects only certain devices, and what UI or API factors might be causing the shift.
Cohorts
Cohorts help understand behaviour differences across segments and tailor campaigns or offerings accordingly.
Leading vs lagging indicators
Lagging indicators measure outcomes after they happen: revenue, NPS, overall retention. Leading indicators signal future outcomes and guide iteration early, such as behaviour around tracking delays or engagement with notifications, which can predict retention shifts before they show up in end metrics.
The Soft Skills That Decide Whether Any of This Works
Even with strong discovery, clear prioritisation, and good execution systems, product work fails when teams are not aligned.
PMs don’t rely on hierarchy. They influence without authority through:
- clarity (problem statements, roadmaps, metrics)
- credibility (data-driven understanding and consistent decisions)
- trust (transparency, reliability, early alignment)
Risk, Compliance, and Legal as Risk Partners
Risk, compliance, and legal teams are easy to treat as blockers, especially early in a PM career. But they function better as risk partners when engaged early.
Late involvement often creates rework: missing consent flows, missing OTP processes, unanticipated privacy constraints. Early engagement makes risks visible before build work has already been done.
Sales and Business Teams: Clear Boundaries Prevent Fragility
Sales teams focus on customer demands and may push for custom features that reduce scalability and create fragility. Clear roadmaps and expectation management help prevent products from becoming impossible to maintain.
Persuasion: Same Idea, Different Framing
Persuasion matters because different teams care about different outcomes.
- Engineering cares about feasibility, stability, scalability, incident load, and rework
- Design cares about UX clarity, trust, and experience quality
- Risk and compliance care about safety, customer protection, and organisational risk
- Sales cares about retention, adoption, and customer outcomes
The argument must match what the team cares about while staying anchored to the same product intent.
Escalation, Conflict, and Decision Ownership
Escalation is not complaining. It’s a risk management tool.
Escalation is appropriate when:
- a decision is blocked
- risk is increasing
- timeline impact is unavoidable
Effective escalation focuses on impact and options, not emotion. It frames what is blocked, why it matters, and what trade-offs or reprioritisation can resolve it.
Conflict is natural and healthy. Teams disagree because constraints differ. The focus should stay on the problem, backed by customer insights and data, while clarifying decision ownership and acknowledging trade-offs openly. RACI helps reduce confusion about who is accountable and who needs to be consulted.
Closing Thought: Tools Improve Speed, Judgment Still Drives Outcomes
Product teams now have tools that make execution faster: writing documents, generating drafts, and accelerating research workflows. Productivity improves, and teams can do more with less time.
But the part that stays central is judgement: which problems to solve, what trade-offs to accept, what to sequence first, and how to align people across functions with clarity and trust.
That is what product leadership looks like in the digital age.
