Case study
From tracking sustainability targets to making better decisions
Interfaces are reconstructed to respect client confidentiality.
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
-
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.
-
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.
-
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
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.
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?
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
Flexibility has a cost.
Supporting different customer methodologies only works when the underlying product model stays clear.
The first request is rarely the real problem.
Looking beyond what customers asked for often revealed a more scalable problem worth solving.
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.
