Technology Leadership LeadershipRetail

The retail operating model nobody talks about: technology as a product function

Most retail businesses treat technology as a cost centre. This article makes the case for embedding technology as a product function, and provides a practical blueprint for what a modern retail tech operating model looks like.

· 9 min

Introduction: The cost-centre trap

Open with the observation that in most mid-market retail businesses, the technology function reports into operations or finance, is measured on cost and uptime, and is the last team consulted on strategic decisions. Explain why this operating model made sense historically but is now actively holding retailers back in a digitally driven market.

Frame the article as a practical argument for a different model, not a theoretical one.

Why most retail businesses treat technology as a cost centre

The historical context

Explain how retail technology functions evolved from IT departments managing POS systems and back-office infrastructure. Cover how this legacy shaped reporting lines, budgeting models, and the perception of technology as operational plumbing rather than commercial capability.

The self-fulfilling prophecy

Describe the cycle: technology is seen as overhead, so it is underfunded. Underfunding leads to poor delivery and mounting technical debt. Poor outcomes reinforce the view that technology is a cost, not a driver of value. Show how this cycle persists even when executives intellectually agree that digital matters.

The symptoms in practice

List observable indicators that a retailer is stuck in the cost-centre model: technology leaders absent from board meetings, project-based budgeting with no persistent investment, engineering measured on tickets closed rather than outcomes delivered, and a backlog that grows faster than it shrinks.

The product-thinking shift

What product-oriented technology means in retail

Define the model clearly: technology teams organised around business capabilities (customer experience, fulfilment, merchandising, data) rather than around systems or projects. Teams own a domain, have a persistent roadmap, and are accountable for commercial outcomes.

From projects to products

Explain the practical difference between project-based and product-based delivery. Cover how project-based models create start-stop cycles, knowledge loss, and misaligned incentives, while product-based models build compounding knowledge and continuous improvement.

Technology as enabler, not support function

Articulate the core mindset shift: technology exists to create commercial advantage, not to keep the lights on. Cover what this looks like in practice: technology leaders contributing to commercial strategy, engineering teams prototyping new capabilities proactively, and technical feasibility shaping business decisions rather than following them.

What a modern retail tech operating model looks like

Organisational structure

Describe a practical structure for a mid-market retailer: a small, senior technology leadership team (CTO or VP Engineering, plus leads for platform, data, and delivery), product-aligned squads that include engineering and business stakeholders, and a thin layer of shared services for infrastructure and security.

Governance and prioritisation

Cover how decisions get made: a technology investment committee with commercial representation, quarterly planning aligned to business objectives, and a transparent prioritisation framework that balances innovation, maintenance, and risk reduction.

Metrics that matter

Propose a balanced scorecard that includes commercial outcomes (revenue influenced, conversion impact, operational efficiency), delivery health (velocity, cycle time, deployment frequency), and platform health (technical debt ratio, incident frequency, integration reliability).

Embedding technology in commercial decision-making

The CTO at the leadership table

Argue that the technology leader must be part of the executive team with a direct line to the CEO, not buried under operations or finance. Cover what this enables: earlier input on strategic decisions, better resource allocation, and a technology perspective in M&A and partnership discussions.

Joint planning and shared accountability

Describe how technology and commercial teams should plan together, with shared OKRs or KPIs that prevent the “throw it over the wall” dynamic. Provide a practical example of how a merchandising initiative and a technology capability investment can be planned as a single programme.

Commercial literacy for technology leaders

Make the case that technology leaders in retail need to understand margin, customer lifetime value, inventory economics, and channel profitability. This commercial literacy is what earns a seat at the table and ensures technology investment is directed at genuine business value.

Capability building vs outsourcing

What to own internally

Identify the capabilities that should be built internally: technology strategy, architecture decisions, vendor management, data ownership, and the core product management function. Argue that these are strategic assets that cannot be effectively outsourced.

What to outsource and how

Cover legitimate outsourcing use cases: implementation projects, specialist skills for time-bound needs, managed infrastructure services, and development capacity for peak demand. Emphasise the importance of retaining control of direction and quality.

The partner dependency risk

Warn about the risk of outsourcing too much to a single systems integrator or agency. Describe the pattern where the partner becomes the de facto technology function, creating dependency, knowledge asymmetry, and escalating costs.

Making the transition: a practical roadmap

Start with the narrative

Explain that the first step is not restructuring but building the case for change. This means framing technology investment in commercial terms that resonate with the board and CEO.

Quick wins: embed before you restructure

Suggest low-friction starting points: invite the CTO to board meetings, co-locate a technology lead with the commercial team, introduce outcome-based metrics for one initiative. These create evidence before asking for structural change.

The structural shift

Outline a phased approach to reorganising: define product domains, assign ownership, shift from project to product budgeting, and build the governance framework. Acknowledge that this takes 12 to 18 months to fully embed.

Conclusion: This is a leadership challenge, not a technology one

Reinforce that the operating model shift requires executive sponsorship and cannot be driven by the technology function alone. Encourage technology leaders to build the commercial case, start with small demonstrations of value, and recognise that changing how a business thinks about technology is harder than changing the technology itself.

If you found this useful, these related pieces go deeper on specific aspects:

Next steps

If you are rethinking how technology is structured and led in your retail business, get in touch or review the services to understand how an advisory engagement might help.

Frequently asked questions

What does it mean to run technology as a product function in retail?

It means organising technology teams around business capabilities (such as customer experience, fulfilment, or merchandising) rather than around projects or systems. Product teams own outcomes, not just delivery. They have a persistent roadmap, work closely with commercial stakeholders, and are measured on business impact rather than ticket throughput or system uptime alone.

How do you shift from a cost-centre mindset without increasing the technology budget?

The initial shift is structural, not financial. Start by reframing how technology work is prioritised and measured. Replace project-based funding with capability-based budgets. Embed a technology representative in commercial planning. Measure technology outcomes in commercial terms. Often this reallocation of existing spend toward higher-value work produces better results before any budget increase is needed.

Should mid-market retailers build internal technology teams or outsource?

The answer is usually both, but the balance matters. Own strategic direction, architecture decisions, and vendor management internally. Outsource execution where it makes sense, such as implementation projects, specialist skills you need temporarily, or managed services for commodity infrastructure. The mistake is outsourcing the thinking. If your technology strategy lives in a partner's slide deck, you have a dependency, not a capability.