Your Company Has a Technology Problem. Are You Sure It's Not a Product Problem?.

What We Actually See in Assessments

The Product pillar is one of the five dimensions we assess in every technology due diligence and technology audit. Across more than a hundred assessments, certain patterns appear with enough frequency to be diagnostic. These are not hypothetical. They are findings from real companies, real engineering teams, and real boards who believed they had a technology problem.

The Roadmap That Cannot Be Delivered

In one assessment, a SaaS company had a stated product roadmap representing over a hundred months of engineering work against their available capacity. Every commercial conversation produced a new commitment. Every board meeting added a strategic initiative. Nothing was ever removed or deprioritised. The engineering team was working hard, shipping features, and falling further behind every quarter. Not because they were slow, but because nobody was saying no.

This is not an engineering problem. No amount of hiring, process improvement, or architectural change will close a gap between infinite demand and finite capacity. This is the absence of product leadership: the absence of someone whose job is to decide what not to build.

Activity Without Impact

In another company, 70 to 80 per cent of engineering capacity was tied to customer-driven delivery, building features that individual enterprise clients requested as conditions of their contracts. Strategic initiatives were consistently deprioritised. The product existed to serve existing customers, not to grow the business. The engineering team was fully utilised and the product was going nowhere.

The customer feedback told the story: "it feels like we are doing your testing for you." Features shipped without adequate quality assurance because there was no time; every sprint was consumed by the next customer commitment. This is what happens when sales drives the roadmap: you build what clients ask for, not what the market needs, and quality suffers because there is no capacity for it.

A product leader would have restructured the balance between customer-driven and strategic work. They would have established that at least 30 per cent of engineering capacity is protected for product-led initiatives: features that serve the market, not individual clients. They would have said no to commitments that consumed strategic capacity. The engineering team could not do this themselves because they did not have the authority.

Strategic Investment at Academic Pace

A data analysis platform had positioned AI as a core differentiator in its market narrative. The actual AI investment was a university research partnership with a single researcher, operating on a two-year academic timeline. Meanwhile, competitors were shipping AI features quarterly. The company's AI strategy existed in slide decks but not in production.

Product leadership would have killed or commercialised this initiative two years earlier. The question is not whether the research is interesting; it is whether this investment produces commercial outcomes within a timeframe that matters for our market position?" That is a product strategy question, not a technology question. Without someone asking it, the initiative continued consuming resources without producing results.

Technology Leadership Without a Product Voice

In several assessments, we find organisations where the CTO covers product by default. There is no dedicated product leader. The CTO makes technology decisions and product decisions, attends architecture reviews and customer calls, manages engineers and negotiates the roadmap with sales. They are doing two jobs, and typically doing neither well. Not because they lack capability, but because the roles require different skills and different attention.

A CTO who is spending half their time on product decisions is a CTO who is not spending enough time on technology leadership. The architecture decisions get deferred. The engineering process improvements never happen. The technical debt accumulates because the person who should be addressing it is in a customer meeting. If you recognise this pattern, you do not have a CTO problem; you have a product leadership gap that your CTO is filling with their spare capacity.

How to Diagnose Whether You Have a Product Problem

These are simplified versions of the questions we ask in the Product pillar of our assessments. They are not a substitute for a professional evaluation. Our actual diagnostic is more granular, calibrated to your stage and sector, and interpreted by practitioners who have seen hundreds of technology organisations. But they are a useful starting point.

1. Who Decides What Gets Built?

If the answer is "the CEO," you have a product leadership gap. The CEO should set the company's direction, not decide which features go into the next sprint. If the answer is "the sales team" or "whichever client shouts loudest," you have a prioritisation vacuum: demand is driving supply, and nobody is curating it. If the answer is "the engineers decide," you have technically interesting features that may or may not serve the market.

A product leader owns this decision. Not by dictating, but by establishing a framework that connects what gets built to why it matters commercially, and by making the trade-offs transparent to everyone involved.

2. What Percentage of Engineering Capacity Goes to Strategic Work?

Strategic work is features, improvements, and initiatives that serve the product's future: new markets, new capabilities, competitive positioning, platform investment. Reactive work is bug fixes, customer requests, sales-driven features, and operational maintenance.

If strategic work is below 30 per cent of engineering capacity, the product is running on a treadmill. It serves existing customers but does not evolve. This ratio is one of the most diagnostic numbers in a technology assessment, and most companies cannot answer it because they have never measured it.

A product leader establishes and protects this ratio. They are the person who says "we will not commit more than 60 per cent of capacity to customer-driven work" and makes it stick, even when the sales team pushes back.

3. Can You Articulate Your Target Customer in One Sentence?

Not "companies that need our product." A specific description of who you serve, what problem you solve for them, and why they choose you over alternatives. If this question triggers a debate among your leadership team, you do not have a product strategy. You have a set of opinions.

A product strategy answers three questions: who are we for, what do we do for them, and how do we win? Everything else flows from these answers: the roadmap, the priorities, the trade-offs. Without them, every product decision becomes a negotiation rather than a derivation.

4. Does Your Roadmap Have a Track Record of Being Delivered?

Pull up last quarter's roadmap and compare it to what actually shipped. If the overlap is less than 50 per cent, the roadmap is not a plan; it is a wish list. Either the team cannot estimate, the priorities change too frequently, or unplanned work consumes the capacity that was allocated to planned work.

A product leader addresses all three. They establish a planning framework, typically now/next/later, that provides clarity without false precision. They protect the team from mid-sprint scope changes. They ensure that the roadmap reflects what the team can realistically deliver, not what the board wishes it could deliver.

5. Are Features Moving Commercial Metrics?

This is the question that separates product management from product leadership. A product manager ships features. A product leader ships outcomes. If features are shipping on time and the commercial metrics (revenue, retention, conversion, NPS, unit economics) are not moving, the team is building the wrong things.

This requires instrumentation: analytics that measure feature adoption, user behaviour, and commercial impact. If you do not have this instrumentation, you cannot answer the question, and that itself is a finding. A product that cannot measure its own performance is flying blind.

What the Answers Tell You

If you answered "the CEO" to question one, "I don't know" to question two, triggered a debate with question three, found less than 50 per cent overlap in question four, or cannot answer question five because you lack the instrumentation, you almost certainly have a product leadership gap.

This does not mean your technology is fine. It means that fixing the technology without fixing the product leadership will not solve the problem. The engineering team will continue building the wrong things, just faster.

What Product Leadership Actually Is

A fractional Chief Product Officer is not a product manager with a fancier title. The role operates at the intersection of commercial strategy, customer understanding, and technology capability. The distinction matters because companies that hire a senior product manager when they need a CPO get activity without strategic direction.

A product manager owns a backlog. They write user stories, prioritise features, coordinate with engineering, and ensure that what the team builds matches the requirements. This is execution-level work.

A product leader owns the product strategy. They decide what the product should become, which markets to serve, how to position against competitors, and how to measure whether the product is succeeding. They build the product function: hiring product managers, establishing practices, defining how the organisation makes product decisions. This is leadership-level work.

A product consultant delivers advice. They assess your product, write a report, and leave. The recommendations sit in a slide deck. Nobody is accountable for implementing them.

A fractional CPO delivers leadership. They make decisions, manage people, own outcomes, and build the product function. They are embedded in the organisation, typically two to four days per week, with the authority and accountability of an executive, not the distance of an advisor.

Day-to-day, a fractional CPO establishes:

• Product strategy and vision tied to commercial ambitions, clear enough that every product decision can be derived from it, not debated
• Roadmap discipline using now/next/later, providing clarity without false precision and protecting strategic capacity
• Data-driven prioritisation based on evidence, not opinion or volume. OKRs that drive initiative selection, not OKRs retrofitted to justify what was already decided
• Stakeholder alignment through transparency on trade-offs, not by saying yes to everyone
• The product function itself: hiring product managers, establishing practices, building the team that the organisation needs at its current stage

Why CTO and CPO Together Is Different

Both of our current CPO engagements are dual placements: a fractional CTO and a fractional CPO working in parallel at the same company. This is not a coincidence. It reflects a pattern we see consistently: technology and product problems are tangled, and fixing one without the other produces temporary improvement followed by the same symptoms returning.

The CTO owns technology: architecture, engineering capability, infrastructure, delivery process. The CPO owns product: strategy, roadmap, customer understanding, prioritisation. In a well-functioning organisation, these roles work in tension: the CPO pushes for features the market needs, the CTO pushes back on what the technology can sustain. The negotiation between them produces better outcomes than either would produce alone.

When one role is absent, the other expands to fill the gap, and does it badly. A CTO without a CPO becomes the default product decision-maker, spending half their time in customer meetings and roadmap debates. A CPO without a CTO makes product commitments that the engineering team cannot deliver. Both scenarios produce the same symptom: the team is busy, features ship, and the business does not move.

Having both from one firm is a different proposition. Rational Partners provides CTO and CPO partners who share context, align on priorities, and make decisions together. from hiring a CTO from one firm and a CPO from another. The alignment is built in, not bolted on. The partners already work within the same methodology, the same assessment framework, and the same operating culture.

For companies where the technology and product challenges are genuinely separable (where the engineering is sound but the product needs direction, or vice versa), a single fractional role is sufficient. For companies where both disciplines need leadership simultaneously, the dual placement model addresses both gaps without the coordination overhead of managing two separate advisory relationships.

Related Reading

• Fractional CPO Services - embedded product leadership for companies that need it
• Fractional CTO Services, when the technology side also needs leadership
• First-Time CTO: What Nobody Tells You, for the CTO who is covering product and shouldn't be
• Why Your Tech Team Isn't Delivering - the engineering-side companion to this diagnostic
• Is Your Tech Team Any Good?, ten signs from the People and Process pillars
• Technology Due Diligence Checklist, the full 5P Framework including the Product pillar
• What We Actually Assess in Technology Due Diligence - how we evaluate the Product pillar across 100+ assessments
• Technology Audit, the assessment that identifies whether it's a product problem or a technology problem