Every software company has a strategic plan. Most of them also have a separate set of operational problems that the strategic plan doesn’t quite address. And a set of integration challenges that live somewhere between the two. And a leadership team that’s excellent at running their functions and less clear on how those functions connect.
These aren’t separate problems. They’re the same problem described from three different angles.
The frame that resolves all three: your company is a portfolio of six interconnected products. Each one is a process. Each one has an owner. Each one has improvement initiatives in flight — or it should. And all six exist to produce a single outcome.
Once you see it that way, most of the fog clears.
The Portfolio
The six products are: Lead to Cash, Procure to Pay, Application Lifecycle Management, Employee Lifecycle, Customer Lifecycle, Corporate Governance.
Every function in your company touches one or more of these processes. Lead to Cash touches sales, marketing, finance, and CS — every handoff from first contact to collected revenue runs through it. Application Lifecycle touches engineering, product, and product marketing — every decision about what gets built, maintained, and retired lives here. Employee Lifecycle touches HR and every manager in the building. The org chart is how you’ve staffed the portfolio. It is not the same as owning it.
Each product has a job. Lead to Cash produces revenue — the full arc from first marketing touch to collected cash. Procure to Pay produces spend efficiency — every dollar that leaves the building goes through a process, or it doesn’t, and the difference shows up in your vendor spend and your ability to hit synergy targets. Application Lifecycle produces the software — not just the features, but the decisions about what gets built, what gets maintained, what gets retired. Employee Lifecycle produces the team — how people enter, develop, and exit, and whether that process survives the departure of any one person running it. Customer Lifecycle produces retention and expansion — the arc from onboarding through renewal through growth that determines whether the revenue you closed is revenue you keep. Corporate Governance produces alignment — decision rights, reporting cadence, escalation paths, the connective tissue that keeps six products running in the same direction.
Each product produces something specific. If you can’t describe what a process is producing, the process doesn’t have an owner — it has a function head who’s accountable for activity, not outcomes.
Where Improvement Initiatives Live
Here’s the test for any strategic or improvement initiative your company is running: which of the six processes does it land in?
Not which team is working on it. Not which executive sponsored it. Which process does it improve, and who owns that process?
If you can’t answer that, the initiative isn’t scoped. It’s a direction, not a plan. Directions feel like progress until you’re 18 months in and nothing has shipped.
This is where most strategic planning breaks down. The initiatives are real. The intent is real. But the work gets assigned to a team or a project manager rather than to a process owner. Nobody is accountable for the process itself improving — only for the project completing. Those are different things. Projects end. Processes run.
When you connect improvement initiatives to process ownership, a few things happen. First, accountability clarifies — there’s one person whose job it is to make sure this process produces better outcomes, not a project manager tracking deliverables. Second, sequencing gets real — you can see which processes are overloaded with initiatives and which are being ignored. Third, the work becomes cumulative — each improvement builds on the last because it’s going into a process that’s owned and maintained, not a project that closes and gets archived.
The Ownership Structure
The process owner is the product owner. They’re accountable for what the process produces — the outcome, not the activity. They set the improvement agenda for their process, they partner with business systems to implement changes, and they’re the person whose name you write next to the process when someone asks who’s responsible.
Business systems is the implementation layer. They build, configure, and connect the systems that make the processes run. A process owner without a capable implementation layer has a vision and no way to ship it. Business systems without process owners has capacity and no direction. The two are designed to work together, and when they don’t, you get systems that don’t match the process or processes that aren’t supported by the systems.
The COO — when the role is functioning as designed — is the portfolio manager. They’re accountable for how the six products work together, not for how any one of them runs independently. They’re the person who can tell you, at any moment, which processes are healthy, which ones have improvement initiatives in flight, where the handoffs between processes are breaking, and what the overall portfolio needs to produce the singular outcome the business is building toward.
What the COO is not: a second CRO. The pattern of COOs spending the majority of their time in sales meetings is a symptom of a company that hasn’t defined the portfolio manager role. The processes run without executive accountability because the executive with portfolio accountability is busy in pipeline reviews.
The Singular Outcome
All six products, running and improving in parallel, exist to produce one thing.
In a PE-backed software company, that thing is a clean exit at the right number. Not just a financial result — an operating story that holds up in diligence. A company that looks, on any given Tuesday, like a machine that was built to be acquired. Processes owned. Handoffs clean. Improvement initiatives connected to outcomes. No shadow operations, no single points of failure, no processes held together by two people the buyer is going to want to retain.
That outcome doesn’t happen by accident. It happens when the company is run like a product portfolio — with the same intentionality a good product team brings to building something worth buying.
The irony is that most PE-backed software companies are expert at building products. They do it every day, for customers. They know what a product with no owner looks like. They’ve seen what happens when improvement initiatives don’t connect to architecture. They know the difference between a strategic initiative and a wish list.
They just haven’t applied that expertise to themselves.
The Reframe
You already know how to run a product portfolio. You do it for customers. The question is whether you’re doing it for the company itself.
Define the six products. Name an owner for each one. Connect every improvement initiative to the process it lives in. Give business systems the direction and the authority to ship. Give the COO a portfolio to manage, not a sales org to shadow.
Then measure what each process produces, quarter over quarter, against the singular outcome you’re building toward.
That’s not a new operating model. That’s product thinking applied to the thing you’re actually selling — which, eventually, is the company.