Product prioritisation for supply chain & industrial software
We install the decision system that turns customer requests into scalable product value.
Closeness to your customers is an advantage — it only compounds when every request runs through one decision system. We embed a senior product lead directly inside supply-chain and industrial software teams, backed by a proven operating model and a working toolkit of decision and data tools.
01Who this is for
You’re probably a fit if:
- You run product, engineering, or the business at a software company selling into supply chain, logistics, sourcing, quality/compliance, or industrial customers.
- Your biggest customers’ requests — not your own strategy — are quietly deciding what engineering builds next.
- Nobody can say, with evidence, why the last ten things got built, or whether they actually paid off.
- Sales, customer success, and engineering each look reasonable on their own and still produce a roadmap nobody chose.
- You know you need better prioritisation. A full-time Head of Product feels premature. Generic “product ops” consulting hasn’t fixed it before.
02The problem
Two blockers
Growth-stage and enterprise product organisations accumulate demand faster than they can govern it — customer requests, sales commitments, and enhancement asks become permanent, disconnected product commitments. Separately, the raw material behind good decisions — contracts, cost sheets, specs, purchase orders — often sits fragmented with no shared structure, so decisions get made on partial or stale information.
Left unmanaged, that demand creates three compounding pressures: value that stays useful to one account and rarely repeats, technical complexity and maintenance cost that climbs with every accommodation, and delivery pressure that forces trade-offs on scope, quality, or enablement. Each pressure looks manageable alone. Together, they quietly erode the return on every future product investment.
“The problem is not prioritisation. It is the absence of a decision system.”
03What we do
We embed a senior product lead inside your team and fix how you decide what to build next.
In the first 90 days, here’s what changes:
01 · One intake.
Every request — customer, sales, support, leadership — goes through one visible list instead of five scattered channels.
02 · Three tests before anything gets engineering time
- Strategy test — Does this move us toward a market we’re actually trying to win, or is it a one-off favour for one account?
- Capacity test — Does building this make our next ten builds easier and safer, or does it just add one more thing to maintain forever?
- Value test — Is there a real, named plan for someone to adopt, use, or pay for this beyond the request that raised it — or are we shipping it and hoping?
03 · One decision record.
Every approved request gets a named owner, states what it costs and what it displaces, and carries a review point at three and six months to check whether the original case held.
04 · Protected capacity.
A fixed share of engineering time is ring-fenced by category, and trade-offs are made explicitly at a regular decision review — not by whoever pushes hardest.
Backed by a working arsenal, not just a framework
We bring proprietary decision templates, prioritisation scorecards, and data tools built specifically for this problem — including a data-decoding tool we built and use ourselves, which can turn years of fragmented spreadsheets, specs, and purchase orders into structured, source-linked evidence within days rather than months, when messy data is part of what’s blocking a decision. These are tools we reach for as needed inside an engagement, not separate products you have to evaluate on their own.
The decision templates are a small set of artefacts a request has to pass through before it earns engineering time. Each one exists to answer a single hard question:
- Customer & user evidence
- The short record behind a request: who has the problem, how often it recurs, what it costs them. The test it has to pass — is this a repeated, consequential problem, or just a requested solution?
- Working-backward announcement
- The outcome written as if it had already shipped, before anything is built. If we wouldn’t be proud to publish it, and a target customer wouldn’t understand why it matters, it isn’t ready for capacity.
- Product requirement definition
- The smallest credible experience that delivers the promise and can actually be tested for adoption — not a specification of everything that was asked for.
- Build-forward solution design
- A high-level technical view scored on reuse, reliability, resilience, and resource efficiency, so each build leaves the estate easier to build on rather than harder.
- Launch & value scorecard
- Named buyer, named user, named commercial owner, and the measures that will show whether value exceeded cost — agreed before the work starts, reviewed after it ships.
- Decision record & committee board
- One place where every material commitment, what it displaced, and what was promised is visible — and later reported against, so capacity gets reallocated on evidence.
How we work
We don’t hand over a slide deck and leave. We run the real prioritisation calls, make the real trade-offs alongside your leaders, and hand over a system your team can run without us by the time we leave.
How we get up to speed fast · The diagnosis · First 3–5 weeks
Three concrete working sessions
Problem-space workshop.
Sit down with product, sales, and leadership and agree, concretely, the handful of areas you’re actually trying to win — not a wish list of features. Simple test: can you describe how this creates a repeating loop of value — more customers, more usage, more insight feeding the next version? If not, it’s a request, not a priority.
Tech stack walk-through.
Work with engineering to find what’s genuinely reusable versus what’s quietly getting more expensive to maintain — so “build forward” is a specific list of decisions, not a slogan.
Go-to-market scorecard.
For each priority, agree who’s the buyer, how it actually gets sold or adopted, and who owns proving it worked.
04Mindset
The principles the system is built on
A decision system is only as good as the beliefs behind it. These are ours.
01
Customer proximity is a strength, not a prioritisation mechanism.
Being close to customers is what makes these companies win. The risk is letting a local response become a product commitment before anyone has chosen where value can scale.
02
Think big: fund problem spaces, not requests.
Leadership and product name a handful of spaces where the company intends to win. Every material request maps to one of them — or becomes an explicit, recorded exception.
03
Build forward: capacity is a shaped advantage, not a fixed constraint.
An investment earns full capacity when it makes the next build easier, safer, and cheaper — or when its technical burden is knowingly accepted.
04
Distribution is a product requirement.
Adoption isn’t an afterthought handled at launch. A named commercial owner and a credible route to purchase and use decide investment size, sequence, and go/no-go.
05
Measure the system before the ROI.
In the first months we don’t manage a theoretical return. We manage the quality of the decisions — then use what was committed to learn, improve, and reallocate.
06
Set it up, test it on live work, then scale it.
The system is proven on real decisions in the first 90 days, not designed in a document. What works gets extended; what doesn’t gets adjusted.
Free 60-minute diagnosis
Not ready to commit? Start with a free 60-minute diagnosis.
We’ll walk through how requests currently reach your roadmap, where the biggest leverage is, and whether a decision-system engagement would actually help — no obligation, no proposal pressure. If it’s not a fit, we’ll tell you.
05Evidence
Where this comes from
One illustrative pattern, one place it is already running, and two times the same trade was made at scale.
Illustrative pattern
How this plays out
- Situation
- A supply-chain software company serving 100+ enterprise customers across sourcing, quality, and compliance had most of its engineering capacity absorbed by customer-specific enhancement requests, with no shared way to weigh a customer ask against a platform investment — value that stayed useful to one account, rising technical complexity, and delivery pressure that kept forcing trade-offs on scope and quality.
- Before
- Five informal request channels, no shared record of what got approved or why, engineering permanently behind on customer asks, no way to tell which of the last ten builds actually paid off.
- First 90 days
- One shared intake replaced the five channels; every request had to clear the strategy, capacity, and value tests before getting resourced; leadership could see, in one place, what was being built, what it displaced, and what it was supposed to achieve.
- What’s still to prove
- This is how the engagement is designed, not a measured, delivered result — the real test is always the first 90 days at your organisation specifically.
Where it’s already running
A data-heavy compliance and risk-intelligence software platform
- Situation
- Work arrived through no single channel, priorities shifted constantly under whichever customer pushed hardest, and there was no shared way to say what had been built, why, or whether it worked.
- What changed
- A single proposal process replaced the scattered intake — nothing reaches the roadmap outside it. Every request is weighed weekly against a shared prioritisation framework with a guaranteed answer inside ten business days. A mandatory PRD standard is signed off across every function before anything gets built. Adoption is tracked as the deliverable, not the release.
- Result
- A scalable, repeatable platform-development model and materially clearer accountability and cadence across product, engineering, and delivery.
- Why this matters for you
- This is the model itself, running today — one intake, one test before resourcing, one decision record — inside a live software platform under exactly the kind of customer pressure your roadmap already faces.
Network operations · Ocado
One rule instead of a hundred exceptions
- Situation
- Every site and region wanted its own fulfilment arrangement — direct delivery here, pooled consolidation there — and without a shared rule, network design turned into hundreds of one-off local accommodations instead of one coherent system, with nobody able to see the P&L cost of any single exception.
- What changed
- The ad hoc, site-by-site negotiation was replaced with one decision rule applied across the whole network — supply direct if a single site can consume a bulk order within 7 days; consolidate in-house if the network can but no single site can; use 3PL consolidation otherwise — priced against real unit economics (£0.06 / £0.10 / £0.23 per unit for direct, in-house, and 3PL respectively) across 728 million units a year.
- Result
- Up to 40% lower cost-to-serve, up to 30% lower working capital, and an EBITDA swing worth roughly £10M a year exposed and captured — without a single local exception undermining the model.
- Why this matters for you
- This is what happens when “every big customer gets their own bespoke workflow” is replaced by one shared rule instead — the pressure for local customisation doesn’t go away, but it stops being able to break the system.
Product · Lalamove Indonesia
Turning a thousand bespoke asks into one scalable product
- Situation
- Every business wanted its own delivery arrangement, and distance-based pricing swung roughly tenfold per drop (16,000–160,000 Rp) — the commercial pressure pointed toward negotiating a custom price and workflow for each account, a path that stops scaling past a handful of customers.
- What changed
- Instead of accommodating each account’s version of “custom,” one decision system absorbed the variation for all of them — a single fixed price per drop, a batch minimum, and a routing engine that made the promise hold operationally, backed by a delivery fleet trained to the new standard.
- Result
- Scaled to 30,000 orders a day at 12% net profit — a level no amount of one-off custom pricing could have reached.
- Why this matters for you
- It’s the same trade every roadmap eventually faces — accommodate the next bespoke request, or build the one system that already covers it. Choosing the system is what let this scale.
06About the founder
Led by Charles Chamblas
ProductDataOps is led by Charles Chamblas, a product and digital-transformation leader who has spent his career at the intersection of complex operations and product decision-making — designing global replenishment logic in pharmaceutical supply chains early on, building inventory-network and replenishment systems at Ocado, and leading product and operating-model work in supply-chain and compliance technology.
linkedin.com/in/charleschamblas ↗07How to work together
Three ways to start
| Path | Shape | What it is |
|---|---|---|
| Free 60-minute diagnosis | Free, 60 minutes | A no-obligation call to map how requests currently reach your roadmap and where the leverage is. |
| Data & Evidence Sprint | 2–3 weeks, fixed fee | A fixed-scope engagement that turns fragmented data — spreadsheets, specs, purchase orders — into structured, source-linked evidence, using our data-decoding tools. A lower-commitment way to see how we work. Ask about a data sprint |
| Embedded / Fractional Product Lead (primary path) | 1–4 days/week; 90-day mobilisation, then 3–9 months to embed and hand over | The engagement described above — we place a senior product lead inside your team and install the system directly. Monthly retainer. How a fractional CPO engagement works |
08Contact
Book a free 60-minute diagnosis
- linkedin.com/in/charleschamblas