Why Your Product Team's Diversity of Skills Matters More Than You Think—And How It Impacts the Bottom Line

Across established organisations, the teams succeeding aren't necessarily the most technically brilliant or the most steeped in industry regulation. They're the ones which have deliberately established a credible baseline of product management competency—ensuring that every product manager, product owner, and business analyst on the team understands and practices the same fundamentals: structured discovery as a discipline, evidence-based decision-making, customer-centric continuous learning, and rigorous benefit articulation.

‍

The difference? When everyone is operating from the same foundation of product management craft, something powerful happens. Teams make better decisions faster. Customers feel heard. And the business sees measurable returns.

‍

The Mix That Matters—But Not in the Way You Think

Consider what we see in most product organisations at established companies. You have:

‍

Domain Experts – people who've spent years understanding the product, the regulatory landscape, the customer base, and all the edge cases that make things messy and complicated. They are invaluable. They know where the landmines are. They understand the business.

‍

Specialists Transitioning into Product – folks who came from engineering, operations, or business roles and are learning product management as they go. They often bring fresh perspective, less baggage about "the way we've always done things," and a bias toward execution. They ask questions that sometimes reveal simple solutions.

‍

Product-Trained PMs – they have experience with structured product training, read Marty Cagan, studied frameworks like JOBS to Be Done, and understand customer-centric discovery. They talk about hypotheses, discovery outputs, and evidence-based decision-making.

‍

Here's the uncomfortable truth: when these groups don't operate from a shared foundation, they don't create rich debate. They create friction, inconsistency, and decision-making chaos.

‍

A domain expert operating without a structured discovery discipline defaults to assumption: "We've been in this market for 15 years; we know what customers need." A specialist fresh from engineering who prioritizes speed over evidence creates compliance risk and downstream rework. A PM trained in frameworks who designs a beautiful discovery process that doesn't fit your organisation's reality—five geographies, legacy systems, regulatory constraints—burns political capital on approaches that won't stick.

‍

The problem isn't that these people exist. The problem is they don't share a common language for what constitutes good product management. One person defends a decision with "domain expertise." Another with "we ran discovery." Another with "it's on the roadmap." Meetings become political negotiation. Governance slows down because nobody agrees on what information is needed to decide. Requirements get sent back and forth. Rework multiplies. And the best people leave.

‍

More damagingly, the organisation never improves systematically. Without shared fundamentals, there's nothing for new hires to learn. There's nothing to hold people accountable to. You inherit capability chaos and pass it forward.

‍

The Real Cost of "Discovery as a Checkbox"

Here's where this fragmentation shows up most visibly. Many teams had discovered discovery. They have processes. They schedule discovery workshops. But in practice, discovery is a checkbox—something to get through before "real work" (design and building) starts.

‍

One person runs discovery like rigorous customer research. Another treats it as an ideation brainstorm. Another skips it entirely because "we know the market." Some teams produce documented insights that inform every downstream decision. Others produce workshop notes that nobody references again. Some use discovery to validate assumptions before design; others use it to validate designs after they're already decided.

‍

The impact is rework. Lots of it. When engineering starts implementing based on incomplete or misguided requirements surfaced by incomplete discovery, they surface questions the team should have answered weeks earlier. Clarification cycles multiply. Teams build features that aren't quite right. Customer feedback comes late, forcing significant pivots.

‍

Industry research consistently shows that organisations with effective discovery and requirements discipline allocate 20–50% of engineering capacity to rework and production corrections. Errors detected in the design phase cost 10–100x less to fix than those caught after deployment. But the real cost isn't just money—it's momentum, morale, and missed market timing.

‍

What Changes When Everyone Operates from Shared Fundamentals

When your entire product team—from domain experts to newcomers to engineers—operates from a credible baseline of product management competency, the dynamics shift fundamentally.

‍

Discovery becomes a visible, respected discipline. Not optional. Not theatrical. Real. There's a clear difference between the question-asking phase ("What do customers actually need? What problem are we solving? What assumptions are we making?") and the solution-design phase ("Given what we learned, what should we build?"). Everyone understands why discovery matters, and nobody skips it because they think they already know the answer.

‍

Domain experts contribute their market and regulatory knowledge within the discovery process, not as a replacement for it. Newer PMs ask the questions that keep assumptions honest. Engineering participates early, not as implementers receiving specs, but as thought partners understanding the problem before proposing solutions.

‍

Discovery outputs become decision inputs. Rather than discovery being notes in Confluence that nobody references again, the team produces clear, documented insights: validated assumptions, invalidated assumptions, customer problems ranked by pain intensity, and constraints that must be respected. The design team takes these as inputs and owns the solution. There's no ownership confusion; there's clean handoff.

‍

Requirements clarity improves dramatically. When user stories emerge from this discovery work, they include context. Not just "As a user, I want to…" but "We discovered that customers in segment X struggle with Y because of Z. We're building this feature to solve that problem. Here's how we'll know it worked." That context changes how engineers approach implementation. They understand the intent, not just the task. Questions about edge cases and trade-offs have answers, because they were thought through during discovery, not discovered after deployment.

‍

Governance gets smarter. Instead of leadership making budget decisions based on "This feature aligns with our strategy," they're making decisions based on micro-level evidence. Each initiative can articulate the customer problem it solves, the business outcome it drives (revenue, cost savings, risk mitigation, compliance), and how success will be measured. Portfolio-level funding decisions are built from evidence, not allocated top-down hoping things work out.

‍

The Numbers: Impact in Practice

What does this actually look like in financial terms?

‍

One large financial services organisation we studied established shared product management fundamentals across its entire product organisation. Here's what happened in the first year:

‍

Rework Reduction: Engineering capacity previously consumed by rework dropped from approximately 40% to 20%. Approximately £1.7 million in annual cost recovery—capacity now spent on new work instead of fixing problems that should have been caught earlier.

‍

Time-to-Market Acceleration: With clearer requirements and less rework, the average concept-to-launch cycle improved by 22%. That equated to £850,000 in accelerated realised value in the first year alone.

‍

Better Resource Allocation: The structured benefit-modelling discipline revealed that roughly 3–5% of the portfolio budget was being deployed to lower-ROI work simply because the evidence wasn't there to challenge it. When governance teams could see micro-level benefit cases, they rebalanced the portfolio. With a conservative 8% margin uplift on that reallocation they positively impacted revenue by £320,000 in Year 1.

‍

Production error rates fell. Cross-functional collaboration improved by 15%. Average approval cycles (governance decision-making) dropped by 40%, compressing what used to be a two-week waiting game into three days. Team confidence in product direction increased. Senior people began mentoring newer team members. Retention improved. Within six months, 87% of product teams had adopted the new fundamentals.

‍

By Year 3, benefits compound. The organisation has internalised these practices. New hires learn them on day one. Continuous improvement becomes embedded. Three-year cumulative value reached £8.6+ million.

‍

The Real Work: Establishing Baseline Competency

Organisations that see real, sustained improvements don't rely on hoping mixed capabilities will somehow balance each other out. They do the harder work: establishing a credible baseline of product management competency that every team member understands, practices, and upholds.

‍

This isn't about making everyone a clone. Domain expertise is still valuable. Engineering rigor still matters. Strategic thinking is essential. But it's about creating alignment around fundamentals:

‍

Everyone understands what structured discovery is and why it matters. Not as theory. As practice. As "this is how we learn what our customers actually need, and we do this before we design." Domain experts aren't skipping discovery because they've been in the market for 15 years. Engineers understand why discovery happens before code. Specialists from operations learn that execution speed without validation creates the rework that slows everything down.

‍

Everyone articulates benefits at the same level of granularity. Not "this aligns with strategy." But "this solves problem X for customer segment Y, which we know from research creates outcome Z (revenue, cost, compliance, retention), and we'll measure success by metric M." When your entire team is doing this discipline, two things happen: (1) decisions are better because they're grounded in evidence, and (2) the team gets smarter over time, because they learn what actually works.

‍

Everyone knows how to write requirements that engineers can actually implement. Not in isolation, but collaboratively. Not as specifications handed down from on high, but as stories that include context, intent, and the customer problem being solved. When domain experts and newer PMs and engineers all write stories the same way, confusion drops. Rework drops. Collaboration improves because there's no mystery about what's expected.

‍

Everyone participates in the same governance processes and uses the same decision-making framework. Not everyone makes the same decision, but everyone understands how decisions get made. What information is needed. What counts as evidence. When to escalate. When to move forward. This is the structure that prevents the strongest voice from winning instead of the best idea.

‍

Everyone is expected to develop. Domain experts learn discovery discipline. Engineers-turned-PMs learn to think strategically about positioning and competition. All PMs learn how to translate frameworks into your specific organisational context. Ongoing coaching isn't optional; it's how you raise the water level across the team.

‍

What Happens When You Establish Baseline Competency

The shift is immediate and visible.

‍

Governance meetings change. Instead of debating whether a decision was made the "right way," you're debating the evidence itself. "Here's what we learned from customers. Here's what we learned from the market. Here's the benefit model. Here's how we'll measure success." That's a different conversation. It's faster. It's more decisive. It's more aligned.

‍

Rework drops because requirements are clearer. Not because one type of PM writes better stories than another, but because everyone is writing stories the same way, with the same context and rigor. Engineers stop guessing at intent.

‍

Time-to-market improves because discovery is no longer optional or variable in quality. It's structural. It happens consistently. And because it's structured, it's faster. The team knows what learning matters.

‍

New people onboard faster because there's something to onboard to. There's a playbook. There's a standard. There's a community of practice. The newest PM can look at what a senior PM produced and understand the logic, because it follows the same discipline.

‍

Senior people emerge as mentors because there's something to mentor on. Not "here's how I do it" (which creates clones). But "here's what great looks like here, and here's how you get better." Retention improves because the job is intellectually interesting—it's about strategy and discovery, not organisational chaos.

‍

The organisation gets smarter over time. Each initiative builds on the last. The team learns what works in this specific context. They're not reinventing processes with every new hire. They're deepening capability.

‍

The Investment Question

Establishing baseline competency requires investment. It requires leadership to say, "We're going to spend time upskilling our team," even when that's not a feature or a bug fix. It requires designing new processes and ways of working. It requires ongoing coaching so people don't drift back to old habits. It requires patience while the team adjusts.

‍

And then it compounds. Year 1 shows the recovery: rework drops, time-to-market improves, decisions are faster. Year 2 and beyond, the benefits multiply. The team is more efficient. More confident. New people accelerate faster. The organisation responds more agilely to market changes because it has a repeatable discovery process it trusts.

‍

The organisations we studied that made this investment saw £2.8+ million in value creation in Year 1 alone. By Year 3, cumulative value reached £8.4+ million. But the non-financial returns—retention, team capability, strategic clarity, customer satisfaction—often matter just as much long-term.

‍

A Final Thought

The competitive advantage in financial services—or any complex, regulated industry—isn't coming from technology alone anymore. It's coming from how well your product team converts customer evidence, market reality, and organisational constraints into coherent strategy and flawless execution.

‍

organisations with 20+ years of history have deep expertise. Use it. But don't let it become a moat that blocks learning or justifies skipping discovery. Establish shared fundamentals. Invest in upskilling your entire team—not just hiring better people, but making everyone better. Make discovery real, not theatrical. Articulate benefits at a level of detail that forces rigor. Coach continuously so that craft improves across the organisation, not just in individuals.

‍

When your entire product organisation is operating from the same baseline of competency, capability chaos disappears. Decisions get better. Teams execute faster. Customers feel heard. And the business sees it in the numbers.

‍

‍

Is your product team operating from a shared baseline of competency? Or are different approaches, different discovery standards, and different decision-making frameworks creating friction and rework? Let's talk about what product management fundamentals should look like at your organisation. Schedule a conversation with us to explore how establishing shared product management competency could unlock capability and value across your product portfolio.

‍