What to Ask Before You Build Another Supply Chain Product

Each problem may suggest a different capability, from better forecasting to integrated planning across functions. The harder question is whether that capability improves a decision that matters.

By Entrepreneur UK | May 29, 2026
Julia Sanzharova

You're reading Entrepreneur United Kingdom, an international franchise of Entrepreneur Media.

Demand, capacity, cost, time, and risk pull against each other in a supply chain plan. Demand shifts unpredictably. Suppliers carry risk. Teams optimise their own piece of the chain instead of the whole thing. A lot of the planning that should connect all of this still happens in spreadsheets and email.

Each of those problems points to a different kind of fix: better forecasting for volatile demand, an end-to-end platform to break down silos. Each problem may suggest a different capability, from better forecasting to integrated planning across functions. The harder question is whether that capability improves a decision that matters. Product leader Julia Sanzharova, who has spent more than 18 years working across supply chain, enterprise planning and technology, uses four questions to test that connection before committing to build.

Which Decision Needs to Improve? 

Sanzharova starts every product conversation by asking which decision is broken. “A product is only as strong as the question it answers,” she says. For her, that means identifying where value is actually leaking, in lost sales, excess inventory, higher costs, before agreeing what the technology should do about it.

The moment a team commits to optimising forecasting, or automating exceptions, or building a dashboard, a boundary has already been drawn around what counts as the problem. Drawn too early, that boundary lets a product perform exactly as designed while the real issue stays untouched.

Who Lives With the Exceptions? 

Naming the right decision is only half the problem. Sanzharova’s answer to what comes next is direct: “Cooking with the chef, not for the chef,” is how she describes it. The distinction can be more meaningful than it initially appears. In her approach, a user isn’t a source of feedback collected after the fact. They’re part of the design itself, involved from the moment a problem is scoped through the sprints and pilots that follow.

A forecasting tool built without input from the planner who regularly adjusts it may not fully reflect how the forecast is used in practice. Getting that planner involved early usually surfaces the real question: why the override happens, and whether that’s a modelling problem or something upstream nobody’s looked at yet. 

What emerges from that process also shapes the roadmap. Capabilities are prioritised according to the value of the decision they improve, their potential for reuse and the readiness of the underlying data.

Can It Scale Beyond the Pilot? 

Even a well-diagnosed, well-designed capability can fail at the next stage: making it work somewhere else. A successful pilot may not translate directly from one market to another. It can be helpful to distinguish between the elements that benefit from consistency and those that may need to adapt to local conditions. Consistent elements can support trust in the product, while flexible elements may help encourage adoption.

Approached this way, scale may look less like a single major rollout and more like a gradual process that builds over time. “That’s how global transformation really happens, not through one big leap, but through shared takeoffs,” Sanzharova says. A capability proven in one category or market becomes the reference point for the next, and the shared core gets stronger with every rollout instead of splitting into another version somebody has to maintain.

How Will Value and Adoption Be Measured? 

The final question is often overlooked: how will the team know whether the product has worked? 

Login counts and training completion rates show who showed up, not whether anything changed. Business measures such as forecast accuracy, inventory levels, and cash flow can help indicate whether the product supported better decision-making in the intended area. Sanzharova watches one signal in particular: whether planners keep rebuilding the plan in a parallel spreadsheet, a sign of low trust even when the platform itself is technically stable.

That signal is also what convinces large organisations to invest. “Clients with more than $10 billion in annual revenue didn’t buy into AI buzzwords,” Sanzharova says. “They invested in solutions that freed up cash, optimised cost and inventory, and accelerated planning cycles.” According to the client, her experience spans more than $60 million in digital transformation programmes.

“When great ideas meet great execution, they scale,” Sanzharova says. 

These four questions create the discipline between an initial idea and a supply chain product capable of delivering measurable value at scale.

Demand, capacity, cost, time, and risk pull against each other in a supply chain plan. Demand shifts unpredictably. Suppliers carry risk. Teams optimise their own piece of the chain instead of the whole thing. A lot of the planning that should connect all of this still happens in spreadsheets and email.

Each of those problems points to a different kind of fix: better forecasting for volatile demand, an end-to-end platform to break down silos. Each problem may suggest a different capability, from better forecasting to integrated planning across functions. The harder question is whether that capability improves a decision that matters. Product leader Julia Sanzharova, who has spent more than 18 years working across supply chain, enterprise planning and technology, uses four questions to test that connection before committing to build.

Entrepreneur UK

Entrepreneur Staff

Related Content