Case study

From tracking sustainability targets to making better decisions

Company
Built for
  • The world’s largest independent beverage bottler and a global FMCG leader.
  • The world’s largest brewer and a leading global beverage corporation.
  • A Fortune 500 consumer goods leader with omnipresent global brands.
Scope
Target tracking, scenarios, AI-suggested projects
Worked with
Product, Engineering, Data

Interfaces are reconstructed to respect client confidentiality.

Status to targetOn trackTarget value0.246 hl/hlExpected impact5.1M hlScenario cost$2.8MTarget: Water Use EfficiencyFY22FY24FY26FY28FY30BaselineLast reportedTargetHistoric dataTargetScenario 1Scenario 2Scenario 3Scenario 1Low investmentShort by 2.6M m³Off trackHow to reach the target?Scenario 2Full programmeReaches the target in FY2029On trackView scenarioScenario 3Phased rolloutShort by 1.1M m³Off trackHow to reach the target? Combinations that reach the target Projects and investment, ranked by costWastewater recycling + Condensate return$620KFY2029Rotary spray balls + CIP rinse recovery$480KFY2030Wastewater recycling + Cleaning skid$710KFY2028

The context

Waterplan is a platform that helps big companies understand and manage their water use. Its customers, such as beverage makers and brewers, commit to water targets, for example to use less water to make every litre of product by 2030.

Each target has a baseline (the starting point), the last reported results from the company’s plants, and the target itself (the goal).

The problem

A target is a promise made years in advance. Sustainability teams set it, mostly based on what each site produces: how much water it uses, how much electricity it consumes, how much carbon it emits.

That data lives in facilities all over the world, and collecting it is painful. Spreadsheets, disconnected systems and paper documents all feed into it, and there is too much of it to even begin analyzing. By the time a team has centralized and cleaned the data, it is already old. When they finally saw a gap, it was too late to close it.

The client asked us for a product where they could see their targets and monitor progress in real time, so they could answer the questions that matter: will we make it? And if not, what should we do?

Why it was hard

Every client measures progress in its own way. Each one has its own formulas for calculating certain metrics, its own approach to collecting data, and its own language for reporting.

The same screen had to work for three different clients, all of them leaders in their field. And for each client, the solution had to serve two kinds of readers: analysts who want every detail, and executives who want a simple answer.

A single progress bar, or a dashboard that looks like a spreadsheet, would have been easy to build and easy to read. It would also have been the wrong solution.

My role

From the very beginning, I supported the research team in asking the questions that would help us fully understand the pain. I went beyond what the client was telling us. My job was to tell apart what the client asked for from what they actually needed.

It is easy to fall into the trap of doing what we are told, and how we are told to do it, instead of asking more questions, strategic ones, and proposing new paths and solutions.

The decisions that shaped the product

  1. Build a shared framework, not a custom tool for every customer

    Decision
    A common target-tracking model, flexible enough to support different customers.
    Over
    Replicating each customer’s existing methodology exactly.

    Every company tracked targets differently. The challenge was deciding which needs belonged in the core product and which were too customer-specific to scale.

  2. Grow from tracking into decision-making

    Decision
    Let users explore and compare combinations of real projects.
    Over
    Stopping at showing whether a target was on or off track.

    Once teams could see they were off track, the natural next question became: what can we actually do about it? That pushed the product from monitoring into scenarios, simulation and prioritization.

  3. Expand the model, not build separate products

    Decision
    Extend the same product logic across water, carbon and energy.
    Over
    Creating disconnected experiences for each environmental metric.

    As customer needs expanded beyond water, the challenge was to grow the system without fragmenting the experience. Reusing the same core model across carbon and energy made the product easier to scale, learn and maintain.

The evolution

Water use efficiencyBaseline 2019 · 12 facilities · updated todayTargetBaselineCurrentProgressWater use efficiency0.310.2748%Total withdrawals4.2 Mm³3.6 Mm³42%Total discharges3.1 Mm³2.8 Mm³39%Reuse rate8%12%40%Leak reduction19%16%40%Basin protection3 sites5 sites50%FY22FY24FY26FY28FY30BaselineLast reportedTargetHistoric dataTargetScenario 1Scenario 2Scenario 3Scenario 1Low investmentShort by 2.6M m³Off trackHow to reach the target?Scenario 2Full programmeReaches the target in FY2029On trackView scenarioScenario 3Phased rolloutShort by 1.1M m³Off trackHow to reach the target?
  1. A simple table that centralizes all the information

    The first version was the trickiest, because first we needed to centralize the data. Once we had it, we could list the targets in a single picture of the data. It was accurate, but it was not tracking anything yet. We were just curating information.

  2. Progress towards the target

    Turning the data into a timeline showed the current situation against the targets, and the gaps became visible for the first time. That let us start asking the next question: now what do we do with this information?

  3. From a gap to a plan

    The idea of simulating scenarios emerged as a strategic tool to support decisions on project investment. Teams could compare scenarios, draft business cases to escalate to their managers, ask for more budget, and forecast data into the future.

Outcome

Customers moved workflows previously managed through spreadsheets and Power BI into Waterplan, bringing data, calculations, targets, and project decisions into one place.

What started as a way to answer “Are we on track?” became a way to ask “What should we do next?”

Lessons learned

  1. Flexibility has a cost.

    Supporting different customer methodologies only works when the underlying product model stays clear.

  2. The first request is rarely the real problem.

    Looking beyond what customers asked for often revealed a more scalable problem worth solving.

  3. Designing for change matters.

    After years of iterations, I learned to think beyond the feature in front of me and consider how each decision would hold up as the product evolved.