This is really a new version of an old problem. But one that could previously be compartmentalised, but now certainly cannot. Your marketing and sales teams used to be able to sit in silos whilst your product and engineering are the delivery and execution people here to just “make stuff work”.

Yet every time I am engaged for solving operational issues, the issue isn’t fundamentally an operational problem. What all businesses want, all of them, is growth. Revenues, big margins, because if they have that they are not as concerned about operating costs very often. The most common scenario I see is that business leaders are distracted by operating costs and issues through lack of visibility and simple inability to identify, measure and enable growth.

We can make your engineering team more efficient, we can make your operating model repeatable, we can add automation to the customer life cycle so its fully self service. None of these are growth vectors. Its difficult to grow if they are not efficient, but they are not the mechanism to enable sales, or high LTV.

There is a persistent myth in B2B SaaS that the best product wins.

It is a comfortable myth, particularly for founders with an engineering or product background. It keeps the focus on what they are best at and defers the harder question: once you have built something good, how does anyone find out about it, understand why it is the right choice, and actually buy it?

The honest answer, in most cases, is: not efficiently, and not at scale.

Distribution is the most undervalued growth lever in B2B software. Not because founders don’t know it matters, but because they consistently underinvest in it relative to product — and because the frameworks most founders use to think about distribution are ten years out of date.

The product bias problem

Early-stage software companies almost always have a product bias. The founding team is usually product or engineering-led. The first hires are developers. The board updates lead with roadmap progress and feature releases. The implicit assumption is that if the product is good enough, growth will just follow.

To take an example.. Google Wave. Launched in 2009, it was technically sophisticated — a real-time collaborative workspace that combined email, messaging, and document editing years before those ideas became mainstream. It was also completely misunderstood by buyers, who couldn’t place it in any familiar category or articulate why they needed it. Google shut it down after eighteen months. The product wasn’t the problem. The distribution and positioning were. The features that eventually went into Google Wave became the foundations of Slack and Notion — both of which spent significant effort on making their value proposition legible before they spent on growth.

In most large B2B Enterprise categories, buyers are not actively scanning the market for the best solution. They are looking for a solution that is good enough, from a vendor they already know or have been referred to, that can be bought without excessive internal friction. The incumbent wins not because it is better, but because switching requires effort and the status quo requires none.

Breaking into that dynamic is a distribution problem, not a product problem.

What distribution actually means

Distribution in B2B SaaS and AI led Product Companies is not the same thing as sales. It is the entire system by which a product reaches its buyers — the channels, the motion, the partnerships, the content, the community, and the positioning that frames the product in the buyer’s mind before the first sales conversation takes place.

Atlassian built a business worth over $50 billion with almost no traditional sales organisation for the first decade of its existence. Its distribution model was product-led: developers adopted Jira and Confluence within their teams, usage spread organically across organisations, and the commercial relationship followed usage rather than preceding it. The product was good — but the distribution insight was that developers, not procurement teams, were the real buyers, and that the path to the enterprise ran through the individual contributor.

HubSpot took a different approach. Rather than selling marketing software, they created and popularised the concept of inbound marketing, built an entire content and certification ecosystem around it, and used that ecosystem as their primary distribution channel. They grew by teaching their methodology — and their software was the natural tool for implementing it. The distribution motion and the product were inseparable.

Both of these are examples of companies that made explicit, deliberate choices about how their product would reach the market. That is what distribution strategy looks like when it is taken seriously.

Positioning is a growth lever, not a marketing exercise

Most software companies treat positioning as a branding problem. They spend time on messaging documents, taglines, and website copy. What they produce is a description of what the product does. This is not positioning.

Positioning, in the sense that actually drives commercial outcomes, is the answer to a specific question in the buyer’s mind: why this, why now, why not the alternative I’m already using?

Veeva Systems is the clearest illustration of this in enterprise software. When they entered the life sciences market in 2007, they were competing against Salesforce — which already had a CRM product that pharmaceutical companies were using. Rather than competing on features, Veeva positioned exclusively for pharmaceutical and biotech companies, built every element of the product around the regulatory and compliance requirements specific to that industry, and refused to serve adjacent verticals. The positioning was so narrow that it felt like a risk. It turned out to be the moat. Veeva went public in 2013 and reached a $40 billion market capitalisation.

Gong is a more recent example. The product records and transcribes sales calls — a capability that several competitors also offered. What Gong did differently was reframe the category. Instead of positioning as call recording software (bought by IT, low price, commodity), they positioned as revenue intelligence (bought by CROs, higher price, strategic). The same underlying capability, reframed for a different buyer with a different business problem, at a meaningfully higher price point.

Bad positioning tries to be relevant to everyone. It produces generic messaging that resonates with nobody and loses to specialists in every vertical it competes in. Good positioning narrows deliberately, names the customer precisely, and makes a specific, testable claim about what success looks like.

That degree of specificity feels uncomfortable. It also converts.

How AI is changing the distribution landscape

The B2B SaaS distribution model that most founders are working from was built for a world where buyers discovered products through Google search, analyst reports, peer review sites like G2, and direct sales outreach.

That world is changing faster than most GTM strategies are adapting.

Buyers are now using AI to research and shortlist. A growing proportion of B2B buyers begin their evaluation process with an AI-generated overview — asking a model to summarise the options in a category, explain the trade-offs, and suggest vendors worth evaluating. If your product does not appear in those answers, you are invisible to a segment of the market that is growing rapidly. This is not an SEO problem. It is a content and positioning problem. The way to show up in AI-generated research is to publish specific, well-sourced, authoritative content that clearly defines the problem you solve, the category you operate in, and the evidence that your product works. Broad positioning and vague messaging will not surface. Precise positioning with documented outcomes will.

AI-powered GTM tools are compressing outbound economics. Platforms like Clay have changed the economics of personalised outbound at scale. What previously required a team of SDRs researching accounts, personalising outreach, and managing sequences can now be done by a much smaller team using AI-powered research and automation. The cost advantage has shifted. The competitive differentiator in outbound is no longer headcount — it is targeting precision. Founders who have not done the positioning work to define their ideal customer profile with real specificity will find that AI-powered outbound amplifies their irrelevance, not their reach.

Vertical AI businesses are building new distribution models from scratch. Harvey, the AI legal assistant, has reached a valuation of over $3 billion by doing something that most AI businesses avoid: committing to a single vertical. Harvey is not an AI productivity tool for knowledge workers. It is AI for lawyers — trained on legal reasoning, integrated into legal workflows, and sold to law firms and in-house legal teams. The specificity of the positioning is the distribution advantage. It determines which conferences to attend, which publications to feature in, which partners to build, and which customer success stories to tell. Everything compounds because everything is aimed at the same buyer. Abridge has done the equivalent in clinical documentation for healthcare. Cursor has done it for developer tooling. Each of these businesses has won early traction not by being the most capable AI model in absolute terms, but by being the most precisely positioned product for a specific job that a specific buyer needs to get done.

What this means for founders and investors

For founders, the implication is straightforward, if uncomfortable: distribution strategy deserves the same rigour as product strategy. That means making explicit choices about channels, motion, and ideal customer profile — and treating those choices as strategic, not operational.

It also means doing the positioning work before you need it. Most founders revisit positioning after growth stalls. Monday.com is often cited as a product success story, but its real competitive advantage over Asana and Basecamp was a deliberate decision to position for non-technical business teams — and then to spend aggressively on distribution to that specific audience. The positioning decision came first. The growth followed.

For investors, the distribution question is one of the most reliable signals of business quality at early stage. A portco that can clearly articulate who its customer is, how they find out about the product, what makes it the obvious choice over alternatives, and what the unit economics of customer acquisition look like — that is a business with a foundation for growth. One that cannot answer those questions clearly, regardless of how good the product is, has a distribution problem that will eventually show up in the numbers.

AI enabled an entirely new landscape

Search is now split between the model providers and the traditional search engines and its entirely different search terms that users are looking to answer questions. This is enabling a level of autonomous integration with abilities to trigger connectivity to solutions and services which previously had barriers to engagement.

Take APIs often behind walled gardens, as providers need to ensure security, payments and limitations on consumption. Well you have to find out if the provider has API services to integrate with, do they have all the fields you need to build the integration what sort of service is offered? Are there throttling limits which would put a cap on the number of transactions per day? What is the commercial value for you? What is the commercial value for the other party?

Or lets consider middleware providers, the newer crop like n8n or the older providers like Mulesoft and Zapier who promised a lot of value but so often hit a wall of limited value with only 70-80% (if you were lucky) of the automation you need supported by their existing service whilst the rest is a bespoke build that you have to both work out, and then implement and maintain. For industries with complex toolchains, who rely on any number of point based solutions this is really a pain point.

There is no doubt that agentic solutions not only put more power at the fingertips of naive users without a lot of software development knowledge. They also mean that a search based recommendation can quickly be a test demo and an ongoing subscription/revenue for a provider that solves this for the user. Influencing at the point of sale and use in that way for enterprise businesses is very new.

It needs an entirely new and fully integrated approach to marketing, user engagement, technical product and automation.

Distribution trumps product utility

Most growth stage software companies struggle with product teams and leadership myopically focused on adding utility to an existing product. They lack the ability to articulate strategy and attach product development to growth.

The best product does not always win. The best-distributed product, built for a specific buyer, positioned to solve a specific problem, and sold through a motion that fits the way that buyer actually buys — that is what wins.

Distribution is not a function. It is the strategy.

^{Image from Google Nano Banana}

I posted a while back on typical problems with early stage scaling. As an exec consultant you see similar issues at every business. Contexts vary and sometimes scenarios can surprise you. But its rare. If your business is VC or PE backed the race for scale often compounds some issues.

Early stage scale-up pitfalls: What do businesses get wrong first?

• Scaling sales before the product is mature enough.

• Over-hiring and lack of appropriate forecasting.

• Technical debt from an earlier previous PoC that went into production or outsourced firm.

• Poor operating and delivery discipline, lack of delivery management.

• Poor technical roadmap and architectural planning. Often from poor product requirements and lack of tangible user acquisition numbers.

• Key mid level managers/directors level off in roles struggle to deliver.

Key hires at this stage often want to move on as soon as formality sets in. Typical departures are lead/principle engineer and CTO or Head of Engineering roles. These people wear the titles but their skills don’t translate to the new environment. Their capability is formed around project level delivery. They have levelled off.

Product owners who have been involved since the early days can also be a key risk of departure or poaching by a competitor. Their knowledge is often a bottle neck and not documented.

But you need to let these people go. They are brake for progress and are change resistant. These profiles prefer the lack of accountability and want to avoid data driven measures which maturing and scaling a business demands. If small is where they are comfortable, then let them find another role that fits.

Onboarding times can often start to slow at this key transitional stage, organisations often have not invested in considering the pace of new hires and the acceleration of business demands with capital injections.

The hardest roles to hire for at this point are product leadership. Once something is established few product leaders are capable of defining the next stage beyond additional product utility.

Ahead on sales, but behind on product

One of the biggest problems is an unfinished product that has a mature sales team. The biggest gap here is always that the scale-up exec leadership has under estimated the amount of control, effort and utility the product needs to support large enterprise customers. Whose expectations of any vendor may match that of a much larger more established organisation.

Investors often compound the issue by wearing the unrealistic statements of the portfolio company leadership and not challenging on operating maturity early enough. This is most often a combination of lack of operating software technology knowledge, poor due diligence and no one being brave enough to admit that they were wrong, the founder wasn’t transparent or simply didn’t listen to advice. Whatever the reason it’s a difficult scenario to turn around.

Few due diligence reviews take into account end to end automation of the customer product and the context of what it takes to scale beyond the underlying technical solution and obvious commercials. I have seen organisations which claimed to be “ready to scale”, yet didn’t have a customer journey which could let a customer self serve from one end of the solution to the other. Building in this logic for automated billing, invoicing and customer sign ups can be a serious undertaking.

Later stage scale-up challenges: Operational inefficiencies and M&A integration

• Lack of operating business intelligence, need to be more efficient but limited insight to drive improvements.

• Lack of meaningful product roadmap to drive growth.

• Missing product automation which limits operating efficiencies. For example: automated account sign ups, integrated billing etc

• High M&A growth often creates infrastructure and organisational integration issues. Operating overheads balloon.

• People changes become more onerous than system changes.

• Large organisational application inventory with each department using only 20/30% of any one solution.

Mid managers become a necessity and curse, adding headcount to elevate their income and status and trying to take “ownership” which slows down organisational decisions. Bureaucracy can start to bloom at this stage of business, and it takes some vision from the C-suite to ensure operational focus and efficiency.

M&A activities often bring in new layers of politics when founder led businesses brim with frustration that they are suddenly part of a much bigger organisation. You were a business owner and are now an employee working their handover period, subject to targets to get your equity out. Its no wonder these transitions are difficult.

Having an external assessor can help to map the wood from the trees here putting some clarity around organisational targets and mapping a path to get there, it can be a useful facilitation technique. But the more important mechanic to solve problems here is to restructure the organisation so that you limit the influence of legacy cultures on the new organisational structure, and those that remain with the business have clear tactical achievable goals set out from the earliest stage.

Why product leadership stalls in scaling software organisations

Later stage organisations often still have the legacy end to end customer automation which has limited their growth opportunities. They also most commonly level off with product strategy. Most businesses at this stage need a mechanism for distribution beyond standard field sales in the B2B space. Mapping the value chain and dependencies for positioning the product and its technical, operational and marketing channels is often a quick exercise but one that is rarely done. How many software companies would benefit from API services and MCP layers that could query them? Well many certainly could but this is currently often answered with Forward Deploy Engineers.

Again external consultants can help map the strategy and execution here which internal teams often struggle to facilitate being too wrapped up in the day to day.

Why Fractional and Interim Executives often outpace tenured staff

Its impossible as a tenured member of staff or exec leadership to really understand the context you get to witness as a fractional or interim exec. The learning curve is accelerated. It is any wonder to me that people with this experience are not more highly sought after. We have solved problems in multiple scenarios few execs ever get to see once.

Yet still the market focuses on hires from big corporate names they have heard of and wonders why such profiles under perform significantly in scale-up roles. Well the obvious is that the context and thereby skillset is entirely different. If you’re in one role for many years you will lack that context and will not respond to issues fast enough.

Delivering returns depends on ability to identify the right issue and make tactical changes quickly. As a consultant you have to deliver results and learn quickly it is simply how you get paid.

Solving scale-up problems needs to be immediate and tactical. Assessments of those issues and possible solutions should be apparent within an initial conversation with someone experienced. Assessments should be done within days and tactical execution plans should offer short term as well as medium term value.

Most of the problem with consultants has historically been misaligned incentives with large corporate projects, generic skill sets which don’t fit the context and inability of hiring managers to match skills to outcomes.

Its also obvious that if you’re salaried staff stuck in the day to day, running around to hit targets, hung up on politics because its the nature of the environment you are in, its hard to move quickly. Salaried roles will suffer from this, no matter how talented the team or individual.

I will post in future on solving common scale-up problems and hiring, the skills required and the different stages of business and why its so important to get this right.

^{Image generation using Google Nano Banana.}

I set out lately to try and find this out. For the uninitiated this meant sitting down to train my own Reinforcement Learning agent from scratch.

GPU consumption has been a pain point across the industry in the AI boom. GPU capacity is at a premium, and much of the cloud infrastructure we are used to is not fit for the new workload demands.

GPU cluster workloads for machine learning and deep learning are inefficient and fundamentally quite different from previous load balancing workloads at scale. Often suffering from bursty behaviour. The test was to support my own personal projects with a tool to assist with training models and also to help customers projects where appropriate. Since its such a hot topic across the sector with the AI boom right now it seemed an interesting problem to try and answer.

Algorithms compared against Maskable Proximal Policy Optimisation as part of the test. This may well not be the optimum RL approach to use. Nor do my experiments consider a lot of edge cases, failure scenarios etc. An experienced HPC infra engineer and data scientist would best guide this. Although I have had some initial review from people in my network.

Model training was executed in Google Collab notebooks and some scripting assistance from Claude Code/Cowork and Google Flash 2.5 I used synthetic data and a limited defined cluster configuration. I will post the script and details on Github for reference.

I started by considering what the agent can observe:

• What would help a human make a good scheduling decision? Firstly the state of each GPU how much VRAM, utilisation and number of jobs running. So what we consider for server capacity more generally in cloud computing.

• What can the agent do? So this is the state action space. Picking a GPU to send the next job to, or hold it in the queue if no suitable GPU is available.

• Rewards - I decided just to focus initially on job completion, average utilisation and wait time. In server allocation you would want to optimise for roughly 60% to max 80% utilisation. Much more risks performance issues.

Comparing Reinforcement Learning with more standard algorithmic approaches.

Structure of script to train the RL model.

Cell 1

Installs necessary Python libraries (gymnasium, stable-baselines3, sb3-contrib, tensorboard) using pip. - key ones are gymnasium, stable-baselines3 and pandas just for the final results table.

Cell 2

Keep Colab Alive - to prevent Colab timeouts - Contains a JavaScript snippet that sends periodic signals to the Colab backend to keep the notebook environment alive and prevent it from disconnecting due to inactivity.

Cell 3

Import all libraries and frameworks for the colab sheet - imports all the required Python modules and classes, including numpy for numerical operations, gymnasium for the reinforcement learning environment, stable-baselines3 and sb3-contrib for the PPO agent and action masking, pandas for data handling, and various callbacks for training.

Cell 4

Simulates the creation of a list of GPU jobs - Defines JOB_TYPES (configurations for different job categories like training, inference, batch) and the generate_workload function, which creates a synthetic list of GPU jobs with varied requirements (duration, VRAM, GPU count, priority) for the simulation.

Cell 5

Cluster configuration - number of servers/GPU’s and their size/type in the available cluster: Sets up the CLUSTER_CONFIG (describing the available GPUs and their VRAM capacities) and defines the GPU class (representing individual GPUs with methods for job assignment and state management) and the GPUCluster class (managing the collection of GPUs).

Cell 6

GPU Scheduler definition - Implements the GPUSchedulerEnv class, which is a custom Gymnasium environment. This class defines the observation space, action space, how the environment resets, how it progresses one step (step method), and includes helper functions like gini_coefficient for load imbalance and action_masks to restrict invalid actions.

Cell 7

GPU Scheduler environment - Performs a diagnostic check of the GPUSchedulerEnv to ensure it’s properly set up according to Gymnasium standards. It also measures the execution time of a single episode with random actions to gauge the simulation speed.

Cell 8

Defines baseline scheduling policies (first_fit_action for First-Fit and least_loaded_action for Least-Loaded), the evaluate_policy function to measure their performance, and then loads and evaluates the trained PPO (RL) model to compare its performance against these baselines.

Cell 9

Provides a more detailed diagnostic run of the First-Fit policy for a smaller number of jobs (20) and renders the environment state at intervals. This helps in visually understanding how the baseline scheduler performs.

Cell 10

Training the model - Configures and trains the MaskablePPO (Proximal Policy Optimization) agent. It defines mask_fn for action masking, make_env to create the training environment, and sets up callbacks (CheckpointCallback, EvalCallback) for saving models and evaluating performance during training. Finally, it initiates the model.learn() process.

Cell 11

Loads the TensorBoard extension and starts a TensorBoard instance, allowing visualization of the training progress (e.g., rewards, losses, episode lengths) that was logged to ./tb_logs/.

Cell 12

Model comparison and training results - Generates and prints a comparison table of the performance metrics (jobs completed, average wait time, GPU utilization, Gini coefficient, total reward) for the First-Fit, Least-Loaded, and PPO (RL) policies. It also includes a success check for Phase 1 based on how many metrics the RL agent ‘wins’.

Where Reinforcement Learning has an edge over standard algorithmic approaches for workload management.

I started with just a small number of jobs 100 I then scaled this up to 250. Initial results looked promising, 35 min wait vs First-Fit’s 51 min is a 30% improvement. The agent has generalised well from 4 to 8 GPUs without any retraining on the new config.

Least-Loaded collapsed completely — 799 min wait and 0.18 utilisation could indicate a fundamental flaw. On a heterogeneous cluster, sorting by free VRAM causes it to repeatedly try routing large jobs to servers that can’t fit them, stalling the queue. This is exactly the kind of failure that heuristics are blind to and RL avoids.

Could RL be exposing a real weakness in a widely-used heuristic at scale? Well it is already understood that this is one of the limitations of the least loaded algorithmic approach, and engineers who manage infrastructure are skilled in where to apply it. However further validation is required to understand if this is really what is indicated here in terms of results or not.

I did not compare for Fragmented Gradient Descent a standard algorithmic approach in the initial tests. This will be considered in Phase 2.

Outputs and results from Phase 1 after several re-runs supported what was already established, however the issues with least loaded persist.

Right now cloud providers like AWS, GCP and Azure offer instance type selection at job submission time, you pick your tiers and pay accordingly. Workloads and appropriate algorithmic selection to manage them are also retrospective. You forward forecast infrastructure consumption based on what has already been demonstrated in your cloud environments. However what if the future is dynamic priority assignment where the scheduler itself infers urgency from job characteristics and cluster state in real time? Priority and consumption could be dynamically priced as well.

Having experimented enough to learn a bit about the approach I decided to make another experiment using sample cluster traces from the Cloud providers. Stay tuned for Phase 2.

^{Image from the airshow}

Last week I joined the Farnborough Aerospace Conference to assess deeptech innovation and investment opportunities across the aerospace and space technology sectors.

My current focus is looking for projects within Deeptech so it seemed reasonable to consider aerospace as an area of focus.

My impressions of the sector are one which is deeply conservative, despite much of the progress with autonomous flight and drone tech. I was surprised to see so many old technologies still in active use from Fortran and Ade Code to Ardupilot. Even supposedly cutting edge new AI technologies for autonomous drones still dependent on these technologies.

The talent problem holding aerospace back

Skills were also a topic, with the usual conservative focus on “training more young people” which takes years, never solves the real issue as the fallout rate from training is too high across all science and tech sectors. The only thing which ever moves the needle is bringing people in from adjacent skill areas and pushing the door open to outsiders. Industries that recognise that and promote foreigners and pay well, see the most aggressive growth and returns.

Space technology was well represented, but still feels very niche. It is the area with the most potential. Not least because the sector is more open to people with transferable skills. Most of the Spacetech workforce has some background in research, aerospace or associated heavy industry.

Space Technology: The Deeptech sector with the most investment potential

Take always from the presentations were how fragile our reliance on GPS technology especially in aerospace. This is mostly a systemic issue not one of innovation, since alternatives exist.

How space weather events not only currently bring dozens of satellites crashing to earth but how it could also impact the rail network (amongst other things)as well. Network operators are alarmingly disinterested in quite a serious risk to their signalling systems.

It seems NASA is building a permanent base on the moon. This is really an ambitious and ground breaking project and is already driving a lot of innovation. Multiple international space agencies and private companies are contributing with automotive companies like Toyota with their initial designs for pressurised moon vehicles, under part of the phase 2 program supported by the Japanese Space Program.

Image is of the initial concepts for pressurised moon vehicles, supported by JAXA(Japanese Aerospace Exploration Agency) and Toyota.

Worth keeping an eye on NASA’s procurement strategy. Much of this is so cutting edge it simply doesn’t exist yet, and their procurement program is both open to new and established firms.

Image below is of Moonbase Program Manager Carlos Garcia Galan presenting on the approach to Moon Base development. Its a shame the presentation was timed with the start of the arial demonstrations outside. More people should have attended this, it is a generational opportunity.

Before the dawn of LLMs, growth in SaaS startups had begun to slow. Businesses responded by focusing on metrics such as Net Revenue Retention. Now the market is awash with claims about AI productivity gains, and scrutiny of engineering ROI is following fast. Organisations are starting to ask where the returns actually are.

Now the market is awash with how AI may make your teams more efficient, it will quickly shift to how are we measuring this, as organisations start to scrutinise the lack of ROI.

Traditionally most businesses with multiple customers will consider measures of productivity and margins with Revenue Per Head of employees. However for RnD intensive businesses or early stage companies this is inherently unfair.

Once your growth has started to level off and you’re limited to exploiting more from what you have your focus will shift and these metrics become very important. How you report on productivity and engineering efficiency is key to fair assessments by CEO’s, CFO’s and the boards that they report to.

There are multiple layers to measuring productivity. So how do we operationally approach this?

Engineering Efficiency Metrics: What startups and scale-ups should be measuring

On the team level, you have various metrics and reporting around team deliverables, code efficiency, support cases and bug tracking but this doesn’t translate well to something meaningful for execs and investors.

My suggestion is to split reporting as follows:

How to report engineering ROI to your board and investors

Keep the lights on (KTLO)

The minimum tasks required to maintain the current level of service in the eyes of your customers.

For example:

• Maintaining current security posture

• Maintaining current levels of service uptime

• Service and ticket monitoring & troubleshooting

• Addressing functional defects reported by customers

• Regular or routine internal procedures

• Staying up to date with external dependencies

• Browsers, libraries, platforms, web services, partner changes, hardware, etc.

Then the rest is split into the following with the % benchmarks indicated.

Elective investments

Build new stuff (for customers) - 60%

Improve existing stuff (for customers) - 20%

Increase your productivity (not customer visible) - 20%

Elective investments comprise the following:

New Capabilities

• Adding a new product

• Adding a new feature or sub-feature

• Supporting a new platform or partner application

Quality Improvements

• Customer requested improvements

• Better performance and/or utilization

• Iterations to improve adoption, retention, and quality

• Improved product reliability or security

Internal Productivity

• Better developer tooling

• Testing automation

• Code restructuring and re-architecture

• Work to reduce the size of the KTLO bucket in the future

The ultimate goal would be to set the targets annually, and then implement monitoring of investment breakdowns and associated roadmaps across these categories quarterly. Metrics which are listed out in the assessment need to be aggregated to form reporting groups which input into the categories above. Whilst it won’t be possible to hit these benchmarks in the short term, demonstrating gradual improvements towards this will help support investment cases, and any additional headcount demands. Capturing this data must be phased over time. Metrics outlined below would need to be rolled up into reporting groups and would over time give a granular view of value generation and progress in different areas of the business.

The link below to a longer description and article on the approach for a reference.

https://medium.com/engineering-operations/a-framework-for-balancing-and-budgeting-engineering-resourcing-d0cce0e6911c

KPIs for engineering teams: The mid-management reporting framework

Team reporting

Forecast versus actuals - forecast of who is allocated to what across the fixed resource pool you have. How many hours or % is allocated by project, customer, other business or support demands? Tasks should be logged on how many hours were spent(regardless of how effort is forecast) and tracked tasks against projects and team allocation.

Product/customer delivery reporting

Burn down charts - for understanding if work committed to is delivered.

Velocity charts are used to understand the throughput of delivery.

Support Reporting

Numbers of support tickets per customer.

Number of support tickets by case type.

Number of support tickets by product/component area.

Speed of resolution.

This is to understand product, technical debt, and service priorities and whether you are meeting customer SLAs and contractual obligations.

Infrastructure

Bug tracking and resolution - number of issues per customer, product, time to resolution.

DR and failover - time to recovery, speed of resolution - is it within customer SLA’s?

Critical incident recovery and resolution time - how many incidents speed of response and customer impact? Is your business efficient where are the bottlenecks or specific areas of under investment? Are there significant numbers of issues all around one customer?

DORA - Releases

Deployment frequency: How often an organization releases to production.

Change failure rate: How often a change causes a failure in production.

Lead time for changes: How long it takes for committed code to enter production.

Mean time to recovery (MTTR): How long it takes to restore service after an unplanned outage or other incident.

Reliability: A holistic view of a software’s operational performance and stability, including factors like availability, latency, performance, and scalability.

Failed deployment recovery time: How long it takes to recover from a failed deployment.

Whether you meet your customer and contract SLAs is important but there is more to customer and business value than that. Which brings me onto..

Attributing engineering investment to customer value

One area I see is constantly under considered is how support cases and DORA metrics and ultimately investment is connected back to customer value. How you might measure customer value, might be annual customer feedback there are various ways to gather this. LTV, is there a higher risk of customer churn if there is a higher level of support cases? Are those support cases coming from just one or two customers? Will investment in specific areas of engineering correlate to better retention? New customer acquisition or higher LTV? Are support cases connected with limited product offerings or clouded by new feature requests?

This story is important as its hard as an exec to argue with data, this story brings meaning for the whole business, context for the engineers on the coalface, context for the business execs trying to drive value and growth.

Operating reporting done properly it can actively inform key decisions on your technical and product roadmaps, and focus areas for investment.

AI may make you deliver faster but you won’t be measuring your operating mechanics very differently. How do you know what impact AI has on productivity if you’re not measuring it anyway?

I often get a lot of push back from early stage teams who don’t understand the value and effort involved of setting all this reporting up. But my consistent experience is without it the pressure from execs and boards is based on assumptions and undue pressure placed inappropriately without this data and insight to hand. Businesses that invest in basic operating reporting make money more efficiently than ones that don’t its as simple as that.

If you need help implementing this framework inside your business, this is work Ingeniva Consulting carries out for PE and VC-backed technology companies.

Whether you are procuring AI services for your organisation or building products on top of them, the bundling decisions major AI vendors are making right now will directly affect your operating costs, your vendor lock-in exposure, and your long-term procurement strategy.

Why AI vendor bundling is now a procurement risk

Well it does, if you are building products and services which are either consuming or evolving IP in this space. Models vary in quality, consistency and intended purpose. But they are already in many ways commodified.

There is no moat for the model providers and as DeepSeek proved can be built without the extreme funding that went into OpenAI and Anthropic. Token costs will drop, choice and flexibility is key, ripping out integrated services is expensive. Strategies and roadmaps take time and investment to deliver on. Understanding where to position your vendor offerings or which services are the best long term play in terms of procurement and consumption may add or subtract % points from your operating costs.

The industry has converged on a common thesis: Anthropic, OpenAI, Google, and Microsoft all agree that the harness is the product — meaning the infrastructure around the model (agents, memory, orchestration, compute) is becoming as important as the model itself. Pricing and packaging, and its future given the imminent IPO’s is a whole other topic.

How AI providers are bundling services into enterprise platforms

Consumer & Productivity Ecosystems

Rather than charging $20/month solely for text-based chat, consumer-facing premium subscriptions now bundle specialized, vertical tools directly into the base fee.

This makes sense since we have seen the most growth on the direct to consumer side. In order to tackle enterprise spend however where the real margins have traditionally been, bundling is also combined with a more traditional software distribution mechanism.

Examples:

• Google’s Lifestyle Bundling: Google combines its cloud storage, advanced Gemini models, and specialized AI verticals under a single subscription. For instance, the Google One AI Premium Plan bundles “Google Health Premium” (an AI personal fitness and sleep coach) alongside workspace integrations.

• OpenAI’s Feature Compounding: OpenAI continually expands ChatGPT Plus into an all-in-one platform by natively bundling multi-modal capabilities (voice, image generation via DALL-E, advanced coding environments) and a centralized Assistants API / GPT Store.

2. Multi-Model Enterprise Platforms

Platform giants are packaging models as “operating software,” moving away from absolute exclusivity to offer multi-model bundles where different AIs handle distinct tasks.

• Microsoft’s Multi-Model Copilot: To avoid sole dependence on OpenAI, Microsoft bundles Anthropic’s Claude models into Microsoft 365 Copilot alongside GPT-4. GPT for creative generation and Claude for complex spreadsheet math or visually rich PowerPoint slides. [

• Cloud Hyperscaler Aggregation: Platforms like Google Vertex AI and Amazon Bedrock bundle proprietary models with third-party open-weight models (like Meta’s Llama or Mistral). Enterprises pay one cloud bill for model hosting, vector databases, safety guardrails, and compliance tracking.

3. The “Agentic Stack” and Cross-Platform Standardization

Instead of simple inquiry-response prompts, providers bundle infrastructure that allows AI agents to perform end-to-end organizational workflows.

• The Shared Skills Directory: Major providers like OpenAI, Anthropic, and Microsoft have aligned on standardized formats to bundle context folders and executable “skills”. These are packages of metadata and methodologies that can be used interchangeably across enterprise ecosystems to complete multi-step tasks natively.

• Full-Stack Orchestration: API providers like NVIDIA via NIM microservices pack inference code, security guardrails, and connection tools into single software containers.

4. Industry-Specific (Vertical) Bundling

Model providers increasingly partner with telecom, healthcare, and financial institutions to offer tailored bundles which cater for the sector.

• Telco Action Models: Providers like Anthropic collaborate with global networks (e.g., SK Telecom) to offer industry-specific language models. These bundle traditional cloud infrastructure with specialized data embeddings to automate customer service, network routing, and technical support out-of-the-box.

The modular alternative: Unbundled AI components and what they cost

There are broadly 3 layers to unbundling.

1. The Provider: Cloud provider, NeoClouds.. Who is sitting on infrastructure services to spin up that GPU or compute consumption (AWS, Google Cloud, Azure, Cerebras, your own Mac). They facilitate connectivity to a range of different models.

2. The Model Providers: Anthropic, OpenAI, Alibaba Cloud, Gemini (GPT-5.1, Claude Opus, Qwen3).

3. The Tool: Where you type. (IDE, CLI, or a background agent), so Cursor, Windsurf, Copilot, (anyone who forked VS Code at that critical market hype moment).

OpenAI, Microsoft, Google, Anthropic and AWS: Strategies compared

OpenAI — Unbundled Products are distinct (ChatGPT, Codex/Operator, API/SDK) with separate use cases and pricing. Explicitly avoided adding a runtime fee, keeping token-based pricing modular. The Microsoft restructure further decouples distribution.

OpenAI is looking for volume of engagement and consumption. Splitting out product offerings is generally associated with distribution based mechanisms.

Microsoft — Bundled The clearest bundler. Copilot is embedded across the entire M365 suite (Word, Excel, Teams, Outlook, PowerPoint) and positioned as inseparable from the platform. Azure AI Foundry unifies development tools under one roof. Some unbundled signals exist — Foundry Agent Service uses consumption-based billing per tool — but the strategic direction is tight integration.

Well this makes sense given most of Microsofts customer base is large corporates and they have to date always taken this approach to their services. Thus making it difficult for other cloud providers to compete with their offerings.

Google — Mixed NotebookLM and Workspace AI are bundled into existing subscriptions. Gemini is woven across Search, Workspace, and enterprise. However, Vertex AI Agent Engine bills each capability (sessions, memory, code execution, observability) as separate line items — a deliberately unbundled billing model sitting inside a bundled product ecosystem.

Google has only a 14% share of the cloud provider market. They need distribution reach more than Amazon or Microsoft to acquire business who simply add services and revenue to ongoing customer relationships.

Anthropic — Mixed Claude.ai is a standalone interface. Managed Agents bundle compute, state, and orchestration into a single session-hour fee (a bundled pricing unit). The recent announcement on Blackstone/Goldman-backed enterprise JV is a distinct, services-led offering to enable integration with big enterprises an approach very much out of the Palantir playbook. Anthropics offerings really are a core of a modular stack with one grouped pricing tier.

AWS — Bundled Bedrock bundles multi-model access through a single API, and AgentCore adds a runtime primitives layer on top. The co-creation of a Stateful Runtime Environment with OpenAI, delivered through Bedrock, deepens the bundle. The explicit goal is making AWS the default deployment layer — a classic infrastructure bundling play. Bedrock enables access to multiple model providers but this keeps you in the AWS ecosystem. Hard to impossible to change cloud provider anyway once established.

IBM have fallen behind on AI investment. They don’t have the investment of the hyperscalers, or model providers, but are still a major player in terms of big corporate customer base. Providing mainframe systems to big banks, telcos etc is still profitable business. Their offerings are focused on integration.

IBM watsonx - Orchestrate for multi-agent orchestration, IBM Confluent for real-time data, IBM Concert for intelligent operations, and IBM Sovereign Core for operational independence — positioning IBM as the enterprise governance and compliance layer on top of frontier models.

Vendor lock-in risk: What technology and procurement leaders need to know

A lot of organisations want consulting on tooling. At the mid manager level there is a plethora of options, you and your team are busy learning what AI tools to exploit and how to use them. But for you as a technology leader, this just risks increasing your application inventory. Whilst for you as a more specialist vendor or SaaS offering, integration with big strategic players may be essential to enable your distribution. Offerings that already work well with existing enterprise services may have the edge on sales distribution.

AI Procurement strategy: Hidden costs, lock-in risks and how to negotiate

There are some obvious considerations if you are a large org investing in your businesses consumption of AI services.

1. Bundling creates lock-in risk for clients — when customers use multiple integrated services, switching costs increase substantially. Enterprises need independent advice on which bundles suit them and how to avoid overexposure to a single vendor.

2. Gartner predicts over 60% of enterprises will access AI capabilities through bundled subscription services rather than individual point solutions by 2026 — creating a significant advisory gap around vendor selection and contract negotiation. Well this makes sense if they are to survive as service offerings.

Technical leadership should direct and navigate vendor selection, avoid lock-in, and extract ROI from bundles they’re already paying for but underusing.

Most medium to large organisations have a plethora of application inventory but only exploit a proportion of it per individual department or business unit. Given that both the model providers and the infrastructure providers who have funded them will look to claw back those CAPEX costs, it is imperative that organisations start to look forward. Both to limit operating overheads and exploit new models of business that AI offers to enable.

The long tail of AI: Why niche use cases will outvalue general applications

In Chris Anderson’s original framing, the long tail describes how platforms make more aggregate revenue from thousands of niche products than from a few blockbusters. In AI, the equivalent is: the cumulative value of millions of specialised use cases across every industry, function, and workflow vastly exceeds the value of a handful of general-purpose applications. The providers who figured this out earliest are building accordingly.

Vertical specialisation: How AI providers are capturing industry-specific markets

There is growing expectation of a number of smaller, highly specialised players that lead in specific vertical domains and the major providers are racing to either acquire them or become the platform they build on. The strategy is to let the ecosystem build the long tail while the provider captures the infrastructure revenue underneath it.

Well the SaaS market was similar, with investors looking for businesses that took over a specific sector vertical and landed 20% market capture.

Non-AI companies that will be impacted by AI far outnumber their AI-focused counterparts this collective impact is what constitutes the long tail of AI, divided into companies building independent models, leveraging existing models, building on open source, or integrating third-party tools.

Market analyst Benedict Evans consistently cites the lack of moat that the model providers have. But this ignores that they are investing like they are building infrastructure. Cloud providers are hard to compete with due to their size and scale for example. Many investors compare AI to the launch of the personal computer or semi conductors. Being early in this guarantees returns regardless of other player coming along later to chip into your market share.

API-First distribution: How AI providers scale through developer ecosystems

The most powerful long tail mechanism is the developer API. By making models available via API at declining token costs, providers are effectively distributing into every vertical simultaneously through third-party builders — without needing to understand each use case themselves.

Software companies have long used API services for distribution. Inability to consider this as a product construct also limits your returns.

Incumbents are pushing native assistants into every surface so the default experience is “good enough” without leaving the platform — AI in every Google Workspace document, a helper on every Salesforce screen. This embeds the provider invisibly into thousands of workflows at once.

AI Agent runtimes: The infrastructure monetisation layer enterprises should understand

40% of enterprise interactions are expected to be handled by autonomous agents by the end of 2026 — agents that research, negotiate, and buy on behalf of humans. But I struggle with these numbers as we are in the 5th month of the year now and given most interactions to “negotiate and buy” are deterministic how will an inconsistent predictive technology handle this? Each of those agent interactions is a billable token event for the underlying model provider. Well then you’re still paying aren’t you?

Teams that want bundled infrastructure can benchmark their internal operating demands against Anthropic Managed Agents at eight cents per session hour plus tokens — a per-use pricing model that scales directly with the breadth of use cases deployed, not just the number of enterprise seats.

Consumption based pricing may yet be tested as a long tail strategy. Given how much subsidy is flowing into customer acquisition right now. If prices go up significantly the customer churn rate will be high. The business model as it stands isn’t sustainable.

The AI marketplace model: Platform strategy, distribution and lock-in risk

Incumbents are pushing native assistants into every surface, with tighter access, more friction, and more integration hurdles — making dependence on another company’s distribution a real strategic risk for startups. This is the classic platform playbook: create the app store, take a cut of everything sold through it, and make it progressively harder to go around you.

OpenAI’s GPT Store, Anthropic’s Claude integrations, and Google’s Workspace Marketplace all follow this logic — each third-party integration extends the provider’s reach into a niche they would never have addressed directly.

Usage-based pricing: How AI infrastructure monetisation works

AI providers using modern usage-based pricing had 40% higher gross margins and significantly lower churn than those sticking to old models. Usage-based pricing is the financial engine of the long tail — providers collect more as usage deepens across more workflows, without needing to win new customers.

The model here is the infrastructure providers. Amazon long since invented usage based pricing for infrastructure. But the context is different here and DeepSeek proved you can build an LLM for a lot less..

The Forward-Deployed Engineer strategy: Palantir's playbook applied to AI

Both OpenAI and Anthropic are launching enterprise joint ventures where an engagement might begin with engineers sitting with customer and IT staff to build tools that fit into the workflows that staff already use. This is the Palantir playbook applied to AI — get inside a client’s workflows, build something embedded and sticky, then expand use case by use case. Each deployment seeds the long tail within that organisation. It’s also an expensive model. I will break this down in another post.

The AI consulting opportunity: Why vertical specialists will win

Companies implementing AI solutions are still figuring out what their use cases might look like — Accenture generated $3.6 billion in AI bookings in one quarter, and BCG projected 40% of its 2026 revenue would come from AI integration projects. The long tail of use cases is where the consulting opportunity lives — because the model providers are building infrastructure, not solving specific workflow problems for specific industries.

Recent deals with consulting firms and PE backing with OpenAI and Anthropic bare this out.

You cannot out-compete massive tech incumbents on generalised tasks.

What AI Infrastructure investment means for businesses and investors

The model providers are building the rails. They need the long tail to be populated with successful deployments to justify their infrastructure spend. That means there is a structural incentive for them to surface, recommend, and partner with consultants who specialise in specific verticals or workflow categories.

The firms that win consulting work in this environment will be the ones that own a specific problem category well enough that an AI tool — or an AI provider’s sales team — will recommend them by name. If you’re wondering what the next generation of Big4 consulting looks like this might just be the start of it.

AI Data Centre Investment: The infrastructure bets, the constraints, and the risks

In the US 50 states have a current ban on building new data centers, 4 of them permanent ones. In other countries there are local protests to slow down build of what is very power and water hungry infrastructure. A long tail strategy is predicated on view that infrastructure will follow the insane growth of the software driven technologies which demand it. People often point to the first dot com boom and bust. Then too there was a demand for fiber and telco infrastructure which didn’t keep up with what was promised. But fiber doesn’t depreciate as fast as chips do. Invidia H100’s were impossible to get hold of, until they started to age..

I still think LLMs are fundamentally a step on the evolutionary curve. An important one, and that AI is here to stay but certainly not in its current form. The long tail may be won not by the model providers of 2026 but whoever solves and delivers on the more fundamental efficiency driven challenges and value that come after them.

What Quantum Superposition applied to sound waves looks like.. from the Quantum exhibition at the science gallery earlier this year.

• An Early Universe by Alistair McClymont 2025

^{Photo by Jukan Tateisi on Unsplash}

Product market fit is one of the most used terms in startup and B2B SaaS circles — and one of the least well understood. Most early-stage businesses believe they have it before they can prove it, and most mature businesses don't realise when they've lost it.

I have worked with a lot of early-stage start-ups and scale-ups. There are numerous things they get wrong, and most people get the same things wrong.

But what I have noticed through my recent experiences is that, despite the fact that many large orgs have a good customer base and may be comfortably profitable, they don’t understand the fundamental equations that have achieved that.

Early-stage businesses talk of product-market fit. But it’s too obvious when you have it. They struggle because they don’t yet understand the demands of defining a customer, which is always a narrow construct to begin with, and how that relates to a likely volume of sales and, therefore, returns based on solid data.

Mature businesses also struggle here. There are some simple truths you need to understand;

What Product Market Fit really means — and how to quantify customer traction

You need around a 20% market penetration in any one sector or your business will die. 20% of any market or segment is significant. But for mature businesses, the challenge here can be further growth. What do you do when you have already grabbed 20%?

Well in either case, you need to identify other customer profiles which may benefit from the solution. What aspects of the product will you need to adapt, or add in order to serve that customer? What about new markets? How many of those customers are in that market? What factors might impact that segmentation? Where can you get or find a reliable source of data to model this?

The equation is simple:

Specific customer profile within X addressable market = enough market share?

If it doesn’t, then you need to consider your customer profiles and segments.

Common Product Market Fit Mistakes Startups and Scale-ups Make

Pitfall 1: No clear ownership of the commercial model

In a business model that relies on investment rounds, you need to have a handle on forecasting. The earlier the stage the more critical this is.

A lot of Execs will say Oh, we need to coordinate across multiple departments. No, no, you don’t. For late-stage businesses that have reached corporate levels of people, systems, processes, etc., you will have armies involved in generalised management consulting. In Startups and Scale-ups, this has to be owned and led by the Execs.

As an Exec, you should have a model for this. The teams may work with the finer details, but you should work this out. In a business model that relies on investment rounds, it is absolutely essential that you have a good handle on this.

In an investor-backed model, you should have a financial model which outlines the financing rounds and the shareholding dilutions, and what it will take to get you to exit. This is an Excel spreadsheet exercise and a bit of modelling effort to execute.

If you don’t know what you will do with the product, how many sales do you need to generate then how much money will you need to get to the next financing round? How do you know what product you are building? How do you know how the solution will serve that? How do you know what skills and resources you will need to build it? Due diligence will pick this up, or should. Don’t wait for the DD before you consider it.

Pitfall 2: Overestimating your addressable market

A typical pitfall is also not to really scrutinise data from a reputable source. This is essential. The majority of business leaders find out only too late that their market isn’t as big as they thought. Good leadership tackles this head-on and tries to answer the problem.

A couple of example’s of this in action is below:

Product Market Fit is a commercial discipline, not just a product question

Not understanding how small your market actually is and how few customers you actually have to sell to is one of many reasons for business failure.

Product development is not just about solving the user’s problem. Its about finding business value that will not only monetise but will offer sustainable, scalable returns.

Product as a discipline is often poorly defined. You cannot be a product leader and not have some sense of these basic commercial functions. Yet they are so often missing from the conversation.

I often feel in business and more specifically product-led software business that no one articulates the basics to you, and you’re often expected to work this out via osmosis. It’s a specific discipline, and one that, if you haven’t got the experience of building within this particular context, it takes time and practice to get good at it.

Clarity on the fundamentals and owning that is what will give you the best chance of success.

§

If you are working through these questions inside a VC or PE-backed business and need an independent assessment, this is work Ingeniva Consulting carries out at both early and growth stage.