A company strategy deck is not a value-creation plan.

Over the past year, I have worked with private equity firms, boards, MSSPs, MDR providers, and cybersecurity vendors on corporate strategy, product direction, packaging, go-to-market, AI, and operating models. The situations have varied, but the underlying problem is often the same:

Most companies do not lack ideas. They lack the operating system required to turn those ideas into results.

They may have a board strategy, product roadmap, sales plan, AI initiative, and financial target. But these often exist as separate artifacts. Product is not aligned with go-to-market. Packaging does not reflect delivery economics. Sales targets assume demand that has not been validated. The board tracks outcomes without understanding their causes.

In a private equity-backed company, the value-creation plan should be the management system that connects the investment thesis to strategic choices, operating initiatives, accountable owners, leading indicators, and financial outcomes. It is not another presentation. It is how the company runs.

TL;DR

• Most strategy problems become operating problems.
• Product, packaging, sales, and delivery have to reinforce one another.
• Growth problems require diagnosis before more investment.
• AI matters when it changes customer outcomes or company economics.
• The CEO owns enterprise priorities, cross-functional trade-offs, and resource allocation; the board tests assumptions and improves the quality and speed of consequential decisions.

Packaging Exposes the Operating Model

I recently looked at a cybersecurity services portfolio that had grown organically over many years. The company had strong capabilities, valuable customer relationships, and deep domain expertise. It also had a large menu of services that could be combined in many different ways.

The initial question was how to improve the packaging. The deeper issue was the operating model.

Salespeople had too many options. Customers struggled to understand what they should buy. Delivery teams supported exceptions, custom combinations, and unclear boundaries between recurring services, add-ons, and projects. We worked backward from the customer: What problem caused the customer to buy? Which outcomes mattered? What should be included by default? What belonged in a fully managed service, a co-managed model, an add-on, or a paid project?

That led to a simpler product architecture with clearer entry points, packages, ownership boundaries, and upgrade paths. But this was not merely a marketing exercise. Packaging determines what sales sells, what customers understand, what delivery has to support, and where exceptions enter the system. It reveals whether product strategy and delivery economics are actually aligned.

A complicated catalog is often presented as customer choice. In reality, it can be evidence that the company has avoided making strategic decisions.

Diagnose Growth Before Funding It

In another situation, a company wanted to accelerate growth across several market segments. Two segments were underperforming, but for very different reasons.

In the first, the company was generating interest but failing to convert enough opportunities. The market recognized the problem, but the offer, proof, packaging, or sales process was not strong enough. In the second, too few qualified opportunities were entering the funnel. The company occasionally won business, but the market was not consistently responding to the message.

One was primarily a conversion problem. The other pointed toward ICP, positioning, channel, or market attractiveness. They required different responses. More marketing will not fix a broken buying process. More sales capacity will not fix a weak market position. Better enablement will not create urgency where customers do not feel it.

Yet companies often respond to a missed target by demanding more pipeline, hiring more salespeople, changing compensation, or launching another campaign. Sometimes that works. Sometimes it simply adds cost to a weak market thesis.

Before allocating more capital, management and the board have to establish what is actually true.

Operating Leverage Is the Real Test

For MSSPs, MDR providers, and other technology-enabled services businesses, productization is not defined by having a portal, integrations, proprietary technology, automation, or an AI story. The question is whether the delivery model becomes more scalable as the company grows.

The clearest test is what the next customer requires. If each new customer brings more tuning, analyst work, custom reporting, manual integration, and delivery exceptions, growth remains labor-dependent. If that customer can be served through reusable detections, workflows, automation, and product improvements, operating experience begins to compound.

I have seen enormous expertise trapped inside analysts, tickets, scripts, spreadsheets, and customer-specific processes. Productization means turning that knowledge into standard workflows, captured context, response policies, and automation so experts handle the exceptions rather than repeatable work. Done well, customer outcomes, consistency, and margins improve together.

AI should be judged by the same standard. It matters when it removes an economic or customer constraint: less repetitive work, faster product development or implementation, lower service-delivery costs, better sales productivity, or a meaningfully better customer outcome. If none of the underlying numbers move, the company may have an AI initiative. It does not yet have an AI operating model

The Board Needs Causality. The CEO Must Integrate.

I have seen board reporting with dozens of accurate metrics but limited operational clarity. The board can see that growth, gross margin, or retention is below plan, but not why. If gross margin is deteriorating, is it pricing, vendor cost, implementation effort, support burden, utilization, or delivery exceptions? If bookings are weak, is the problem pipeline, conversion, sales capacity, positioning, product competitiveness, or retention? And if churn is creeping into the customer base, why are we losing these customers? Probably one of the harder questions to answer, but just saying that they went with another competitor is not going to help build a sustainable business.

A useful value-creation plan makes those relationships visible. It connects the investment thesis, strategic priorities, accountable executives, leading indicators, financial outcomes, and decisions required.

The board should not run the company. It should help management confront the right facts and make consequential decisions quickly. Strong board members do more than review dashboards. They improve the quality, speed, and accountability of decisions.

The CEO’s role is different. Functional leaders optimize their areas. The CEO has to optimize the whole company. A custom feature may help close a deal but increase delivery cost. A broad portfolio may expand theoretical market size but weaken sales effectiveness. Cost reductions may improve short-term EBITDA while damaging product relevance. More services may increase revenue but make the company less scalable. The CEO’s unique responsibility is to connect market reality, strategic choices, product, go-to-market, organizational capability, operating cadence, and capital allocation. This is true in a high-growth company, a private equity portfolio company, a founder transition, or a turnaround. The urgency differs, but the work is remarkably similar: establish what is true, decide what matters, stop what does not, align the organization, and turn the strategy into measurable value.

These are the situations I find most interesting: a strong company entering its next phase, a cybersecurity business that has outgrown its original operating model, or an organization where product potential and market opportunity have not yet translated into consistent execution.

If you are a private equity sponsor, board member, or cybersecurity CEO working through one of these transitions—or looking for an operator to lead the next phase—I would welcome the conversation.

Strategy sets the direction. The operating system creates the value.

I have argued for a while that MDR has to move beyond alert triage and become a cyber risk reduction service. A recent conversation with an experienced MDR operator added another piece to that thesis. The future may not be one ever-expanding MDR bundle. We may be forcing three different jobs into one category:

1. managing the security data and detection foundation
2. operating the detection and response workflow; and
3. proactively reducing risk.

The second is the MDR service we know today. The third is where I believe MDR ultimately has to go. But the first may be a new service category of its own: the managed security data fabric.

TL;DR

These layers can be sold together, but they do not have to be. An enterprise may want to keep its own SOC while outsourcing the data and detection foundation underneath it. Another company may want a full MDR service. A third may need help driving remediation and proving that its exposure actually went down.

That creates a more flexible model than trying to sell every customer the same MDR bundle.

The Missing Service Under The SOC

Most security teams have a SIEM, data lake, EDR platform, or some combination of the three. Many also have an MDR provider. Yet it is often unclear who owns the quality of the security data layer end to end.

The SIEM vendor provides the product and does not manage the customer’s entire data environment. The MDR provider consumes the data it needs to deliver its service. Internal platform teams keep pipelines running. Detection engineers maintain content. Threat intelligence is purchased from several sources. Asset, identity, cloud, and business context live in still more systems. In smaller environments, an MSSP might own the entire chain, but at what quality and what depth? Do they really understand what assets are used for what purpose, understand infrastructure changes, escalation points, etc?

Everybody owns a piece. Nobody necessarily owns whether the complete foundation is accurate, current, cost-effective, and usable.

A managed security data fabric would take responsibility for that foundation. It could:

• onboard, route, store, and monitor security telemetry (logs)
• normalize schemas and reconcile duplicate or conflicting entities (by the way, ask your SIEM vendor about this)
• maintain asset, identity, cloud, control, and business context
• curate and operationalize threat intelligence
• build, test, tune, and update detection content
• identify missing telemetry and broken detection coverage
• optimize storage, query, and AI consumption costs
• expose trusted context to SIEMs, data lakes, internal applications, and AI agents

This is not just co-managed SIEM under another name. A co-managed SIEM service usually starts with the SIEM as the center of gravity. A managed security data fabric starts with the information and context the security operating model needs, then serves that foundation into whichever SIEM, analytics platform, workflow, or agent the customer chooses.

It also does not have to operate the SOC. It may generate detections, but it does not necessarily triage every alert. It can maintain detection quality without owning 24/7 monitoring, threat hunting, incident investigation, or response.

That boundary is what makes it a distinct service.

Why AI Makes The Data Layer More Important

AI SOC products initially focused on the visible labor problem: too many alerts and too much analyst time spent investigating them. That produced a clear economic pitch. If an agent can resolve a large percentage of alerts, an MDR provider or internal SOC can reduce cost.

But AI does not remove the underlying data problem. In some cases, it makes it more obvious. And that’s another reason supporting the introduction of a managed security data frabric.

An agent that has to query five systems, interpret five schemas, reconcile conflicting records, and determine which source is authoritative may be technically impressive, but it is also expensive and difficult to govern. Replacing telemetry parsers with agents does not eliminate complexity. It moves complexity into a less deterministic layer.

A well-managed security data fabric changes the economics. The expensive work of collection, normalization, deduplication, entity resolution, and context assembly happens before the agent starts reasoning. The agent receives a smaller, cleaner, better-structured set of information through a stable interface.

That should reduce tool calls and token consumption. More importantly, it should improve the quality and consistency of the result, ie the attacks prevented.

Context Has To Be Managed

The word “managed” matters here. Building a context graph once is not enough. Data sources change. Schemas drift. Assets appear and disappear. Identities move. Business owners change. Two systems disagree about the same endpoint. Detection logic decays as products and attacker behavior evolve.

Getting data into one place is not the hard part. Making it trustworthy over time is.

That requires ongoing operational work: resolving conflicts, validating relationships, monitoring source health, testing detections, updating intelligence, measuring coverage, and deciding which source should be authoritative for which field. Some of this can be automated. Some still requires human judgment and customer input.

This is exactly the kind of recurring, technical, difficult-to-staff function that tends to become a managed service. Are there opportunities for automation and AI? Of course, but we are far from having this all automated completely.

The Three-Service Model

Separating the layers makes the future security service stack easier to understand.

1. Managed Security Data Fabric

This service operates the substrate. Its job is to make security data complete enough, clean enough, contextual enough, and current enough for humans and machines to use.

The output is not an investigated alert. It is a trusted security operating layer that makes sure attacks don’t go undetected because of missing detections, threat intel, data sources, or configurations.

2. Managed Detection And Response

MDR consumes that substrate to operate continuous threat monitoring. It owns alert triage, investigation, threat hunting, escalation, containment, and response.

The output is not clean data. It is a threat that was detected, understood, and handled.

3. Managed Risk Reduction

The risk reduction service works further upstream. It connects asset criticality, identity, exposure, control gaps, threat activity, and remediation workflows to reduce the likelihood and/or impact of an incident.

It should identify what matters, route the required action, navigate ownership and change approvals, verify that remediation happened, and show what risk remains.

In the last post, I argued that AI maturity is not about tool count. The real question is whether AI is changing how the company works.

That leads to the next question: if AI is becoming a company operating system layer, what actually belongs inside that layer? The answer is not “a chatbot for every department.” It is a set of shared capabilities that help the company use context, signals, decisions, workflows, and governance more effectively.

The context layer

Every company has operating context, but most of it lives in places AI cannot reliably use: board decks, strategy documents, Slack threads, CRM notes, offsite summaries, and executive memory.

That context matters because it tells the company what good looks like. AI systems need to understand the company’s ICP, strategic priorities, product direction, pricing logic, market narrative, board-level constraints, and risk appetite. Without that, agents can still generate output, but they are not operating from the company’s actual logic.

This is where many AI efforts stay shallow. They automate tasks without encoding the context that should guide those tasks.

The signal layer

A company AI OS also needs signal. That signal comes from the systems where reality shows up:

• Sales calls and win/loss data
• CRM fields and pipeline movement
• Product usage and telemetry
• Support tickets and implementation friction
• Customer success notes and renewal risk
• Roadmap tradeoffs and engineering throughput
• Financial data, margin structure, and cost trends
• Market signals, competitor movement, and regulatory change

The point is not to dump all of this into a model. The point is to make the right signals available, governed, and useful. A company that cannot connect its customer conversations, product reality, and financial outcomes will struggle to make AI operationally meaningful.

The decision layer

The next layer is decision support. This is where AI should help the company reason across functions instead of just accelerating isolated tasks.

For example, sales may hear that a feature is winning deals, support may see that the same feature is causing implementation pain, product may be planning adjacent roadmap work, and finance may care about the gross margin impact. In many companies, those signals never meet in time to shape a better decision.

A useful AI operating layer should help surface those tensions earlier. It should not replace executive judgment, but it should improve the quality and speed of the inputs that judgment depends on.

The execution layer

Once context, signal, and decision support exist, AI can start to push work forward. This is where agents, workflows, and automations become useful.

The execution layer might help:

• Draft follow-ups from customer calls
• Turn product feedback into structured roadmap input
• Identify sales patterns across calls and accounts
• Prepare weekly operating reviews
• Monitor project slippage
• Summarize customer risk
• Suggest next actions for account teams
• Generate board-ready updates from operating data

This is where AI starts to feel less like a productivity tool and more like part of the company’s operating rhythm. But it only works if the earlier layers are in place. Otherwise, execution becomes more automation noise.

The governance layer

The governance layer is often treated as a blocker, but it should be part of the operating system itself. Companies need to define which models are approved, which data sources can be used, what retention rules apply, where human approval is required, and how agent behavior is monitored. The old version of this is a policy page that few people read. The better version is policy that agents can actually access and follow.

That does not remove the need for human governance. It makes governance executable.

The real test

A company AI OS is not a single platform. It is the connective tissue between company context, business signal, decisions, workflows, and governance.

The test is not whether the company has deployed AI tools. The test is whether AI helps the company operate with better speed, clarity, consistency, and control.

If AI only generates more content, it is still a feature layer. If it helps the company sense, decide, execute, and learn, it is becoming an operating layer.

In a previous post, I argued that AI is becoming a company operating system layer. The natural next question is how to tell whether that is actually happening inside a company.

The answer is not how many copilots are deployed, how many employees have access to ChatGPT, Claude, Cursor, or Codex, or how many AI experiments appear on an executive dashboard. Those are adoption signals. They are not operating model signals.

The better question is whether AI is changing how the company actually works.

Start with the workflow, not the tool

One mistake I see in AI maturity conversations is that they start with the wrong question: “How are you using AI?” It sounds reasonable, but it often produces a shallow answer. People list tools. Teams describe experiments. Executives get a dashboard. Everyone feels like something is happening.

A better diagnostic starts earlier. Before asking about AI, you have to understand how the company operates today:

• How does engineering ship?
• How does product decide what to build?
• How does sales learn why it wins or loses?
• How does customer success detect risk?
• How does finance understand cost and margin impact?
• How does governance decide which data AI systems can access?

If those workflows are unclear, inconsistent, or poorly instrumented, AI will not magically fix them. It will usually amplify the fragmentation.

AI activity is not AI operating leverage

Most companies already have plenty of AI activity. Engineers are using coding agents. Marketing teams are generating copy. Sales teams are summarizing calls. Product teams are drafting requirements. Support teams are experimenting with automation.

The problem is that much of this is happening independently. Different teams use different tools. Different people create different prompts. Different functions maintain different versions of the truth. Governance is often a policy page somewhere, not something agents can actually read and enforce. Management may see usage, but not impact.

That is not an AI operating model. It is distributed experimentation. A company can have high AI usage and still have low AI maturity.

What a real diagnostic should look for

A useful AI maturity assessment should not just ask who has licenses. It should look at whether AI is improving the operating system of the company.

That means asking:

• Are existing workflows documented well enough for AI to assist them?
• Are teams using shared patterns, or is every function inventing its own?
• Are the right data sources available, clean, and governed?
• Can the company measure whether AI improves speed, quality, cost, or predictability?
• Do agents know what data they are allowed to use, or are rules trapped in static documents?
• Is AI helping the company learn from customer calls, support tickets, product usage, roadmap decisions, and financial outcomes?

The point is not to create a more elaborate AI dashboard. The point is to understand whether AI is becoming part of how the company senses, decides, executes, and learns.

The board-level question

For CEOs, boards, and investors, the question should not be: “Do we have an AI strategy?” It should be whether AI is creating operating leverage.

A board should be asking:

• Is AI reducing decision latency?
• Is it improving engineering throughput?
• Is it helping sales understand why deals are won or lost?
• Is it improving retention signal?
• Is it exposing risk earlier?
• Is it changing the margin structure of the business?

If the answer is no, the company may still be in the experimentation phase, even if AI usage looks high.

That is why AI maturity is not about tool count. It is an operating model assessment. The companies that get this right will not be the ones with the longest list of AI tools. They will be the ones that turn AI into a repeatable way to improve workflows, decisions, governance, and execution. And last but not least, companies with clean workflows that are ideally already documented, will win in adopting AI quickly.