Your Product Business Is One System - Even if Your Organization Isn't
Every function can perform competently and the product business can still underperform.
A president can have a strong engineering organization, a capable sales force, disciplined operations, experienced product leadership and sound financial controls - and still have a product business that underperforms.
The reason is uncomfortable.
Products do not succeed function by function. They succeed - or fail - as a system.
The organization chart may separate Engineering, Sales, Marketing, Operations, Finance, Supply Chain and Product. The economics of the product do not.
A decision made in one part of the company changes what is possible in another. When those decisions are coherent, the product business gains leverage. When they are not, individually reasonable decisions can combine into a poor business result.
Good functions can still produce a bad system
Most companies know how to evaluate functional performance.
Engineering has schedules, quality measures and technical objectives. Operations has cost, capacity and delivery measures. Sales has bookings and revenue. Finance has margin and return expectations. Marketing has demand-generation and launch responsibilities.
Those measures matter. But they can create a false sense of security when management assumes that strong functional performance must add up to strong product performance.
It does not always work that way.
Engineering can deliver exactly what it was asked to build, on schedule, and the product can still disappoint because the original customer problem was not important enough.
Operations can manufacture efficiently while product complexity quietly consumes capacity and working capital.
Sales can execute well against a forecast that was unrealistic before the first salesperson received a quota.
Marketing can run a competent launch around a product whose differentiation is too weak to change customer behavior.
Finance can approve an attractive business case built on assumptions nobody has sufficiently tested.
Nothing in those examples requires an incompetent function. The failure sits in the connections between decisions.
The product is where the decisions meet
Consider a single customer requirement.
It can affect architecture, component selection, development time, tooling, qualification, unit cost, manufacturing yield, service requirements, pricing and ultimately gross margin.
A channel decision can change which benefits matter, how the product must be supported, how much margin is available and how quickly customers can be reached.
A portfolio decision can consume the engineering capacity needed for a more attractive opportunity.
A launch commitment can become a technical constraint months before the customer ever sees the date.
This is why product-business performance cannot be understood by looking at the functions independently.
The product is the place where strategy, customer evidence, technical choices, operations, commercialization and economics become one result.
The visible problem is often downstream
When performance disappoints, organizations naturally look where the problem becomes visible.
If development is late, management examines Engineering.
If revenue misses, attention moves to Sales and Marketing.
If margin falls, Finance and Operations search for cost reductions.
If the portfolio becomes too complex, management starts cutting SKUs.
Sometimes those are exactly the right responses.
But sometimes they are repairs at the point of impact rather than at the point of origin.
Engineering may be late because the business committed before customer evidence and product definition were stable.
Sales may miss because the product never created enough economic reason for customers to switch.
Margin may disappoint because the price, cost and volume assumptions were incompatible long before production began.
Portfolio complexity may return after a one-time SKU reduction because the investment and lifecycle rules that created the complexity never changed.
The location where a problem becomes visible and the location where the problem was created are not necessarily the same.
That is one reason many product problems that look like execution failures are created before execution begins.
A president's job is not to manage every seam
The answer is not to have the president personally coordinate every product decision.
Nor is it to make one function the owner of all the others.
The management task is to make the important cross-functional decisions explicit, establish who owns them, require the evidence appropriate to the size of the commitment, and make sure the economic consequences travel with the decision.
That requires a different set of executive questions.
- What decision are we actually making?
- What evidence supports it, and what remains an assumption?
- What other functions or commitments change if we choose this path?
- What economic result are we expecting, and when?
- Who owns the decision when the evidence conflicts across functions?
- What would cause us to revise, delay or stop?
Those questions force the company to manage the product as a business rather than as a chain of departmental handoffs.
The system matters most before the commitments harden
The earlier a product decision is made, the more options the company usually retains.
Before development begins, a customer assumption can be tested cheaply. A product concept can be changed. A market can be rejected. A channel can be reconsidered. A business case can be revised.
After architecture, tooling, inventory, launch commitments and customer expectations accumulate, the same correction becomes progressively more expensive.
This is why product-business leadership is not simply about improving execution.
It is about improving the decisions that create the conditions under which execution will occur.
Diagnose the system before fixing the function
When a product business is underperforming, the first management question should not be, 'Which department needs to improve?'
A better question is:
Where in the product-business system was this result created?
The answer may still be Engineering, Sales, Operations, Finance or Product.
But it may also be the interaction among them: a weak decision right, an assumption that crossed functions without being tested, a premature commitment, a portfolio tradeoff nobody made explicitly, or an economic consequence that disappeared between approval and launch.
That is the executive advantage of seeing the product business as one system.
It changes the objective from making every function look better to making the business perform better.
Every function can be competent. The system still has to work.