Shaping Product Direction at TWAICE

TL;DR

TWAICE was a company built by battery engineers, for battery engineers. The initial instinct was "give us the data and we'll figure it out" — design was new to the organization, and the product development culture had not yet adapted to what a successful SaaS business really requires.

Over three years I earned trust by consistently delivering when it wasn't straightforward. I shaped product strategy and experience architecture that became the foundation of TWAICE's current flagship product, built genuine cross-functional alignment across engineering, CS, and product teams, and delivered the design system and unified interaction model that the product runs on today.

The result is a platform that operators, asset managers, and maintenance engineers rely on daily — to make fast calls under time pressure, run deep root-cause investigations, and protect the uptime of large-scale energy storage systems.

---

My Role

I joined as a Senior UX Designer and over time became the primary design voice shaping product direction — without a formal leadership title. I operated with significant autonomy from early on, with the trust of two successive design managers and growing influence across product, engineering, and customer success teams. For a period of several months I was the most senior designer in the company without a manager above me.

My work spanned hands-on product design, experience strategy, design system ownership, cross-functional alignment, and mentoring. I was embedded in the energy team as the sole designer for the majority of my time there — owning design from discovery through to shipped product.

"Leonardo has consistently demonstrated resilience and a highly collaborative spirit. He has an exceptional ability to clearly articulate his design decisions, facilitating smooth cross-functional collaboration and empowering less experienced designers."

---

What I Found When I Arrived

TWAICE had one product when I joined: a basic State of Health chart embedded in its platform. The company was making its first serious attempt to build a SaaS product, but the culture around how products get built hadn't fully formed yet. PMs held the vision, engineers built toward it, and designers were new additions whose value wasn't yet clear to everyone.

I was allocated to the e-mobility team, which served mobility companies managing electric vehicle fleets. My starting point was that single SoH chart. Within my first year I turned it into a battery health widget ecosystem — designed to be embedded directly into third-party operational software. We closed deals with a software provider and two clients.

That work taught me how to move inside this organization: how to earn credibility with engineers, how to run product discovery in an environment that wasn't used to it, and how to deliver something real in a domain I was learning in parallel.

It also showed me where the friction was. Parts of the company were skeptical of design's role. The Customer Success team, in particular, had developed a wariness toward designers in client contexts after an earlier experience that had felt irrelevant to customers. That history created a quiet wall I'd need to dismantle later — carefully.

---

Building Trust and Earning Autonomy

My design manager Oliver gave me room quickly. After early projects he stepped back and let me run — not out of disengagement, but because the trust was there. He encouraged me to write OKRs for design, to plan quarterly design work across the teams I was involved in.

His words later: "His ability to deliver high quality results at lightning speed without ever compromising on accuracy is a rare and invaluable asset, especially in high pressure situations."

That autonomy became the platform for everything that followed.

---

The Energy Team: Building a Product Trio That Actually Worked

When the lead designer on the energy team went on paternity leave, I stepped in to support. I never fully stepped back out.

The energy team had a multi-product setup built around a central KPI — State of Health — with separate modules for warranty tracking, safety monitoring, a data explorer, and an emerging performance topic. The products were technically capable. But they were siloed in a way that didn't reflect how operators actually worked.

More immediately: the relationship between design and the energy team hadn't been productive before I arrived. I came in without that history and focused on one thing first — being genuinely useful to the people making product decisions, not just the people using them.

Within months, the energy team became the first at TWAICE to achieve what the company was working toward organizationally: a balanced product trio where design, PM, and engineering shared real ownership of product direction. Other teams were still working through that transition. We had already landed.

"Especially from a Product Manager perspective he can do the heavy lifting from customer interview to tested and deployed solution."

When the original PM left and was replaced by Matthias — a solution engineer with deep battery domain expertise but less product development experience — my role expanded naturally. I supported discovery strategy, validation approaches, how to structure experiments given our team composition. We co-defined roadmap priorities and product milestones together.

"He is incredibly adaptable, quickly pivoting to meet changing priorities without compromising quality. At the same time, he ensures that everyone in the team keeps the user and their needs in mind."

---

Energy Health: Making Battery Data Actionable

The first major product initiative was Energy Health — giving O&M engineers and asset owners a clear, actionable view of battery degradation and what to do about it.

The challenge wasn't technical. TWAICE had the data and the models. The challenge was that the existing output — raw metrics and time-series charts — required users to already know what they were looking for. That excluded asset owners without deep technical backgrounds, and slowed down engineers who did.

My approach centered on a different question: what is the user actually trying to answer? Not "what is the State of Health value?" but "is this battery performing the way it should, and what does that mean for my operation today?"

That reframe drove every design decision — surfacing interpreted insights rather than raw readings, providing trend context rather than just current values, and making recommended actions visible without burying them behind layers of charts.

"By optimizing our operating strategy with the TWAICE Battery Analytics Platform, we expect a 2-year longer lifetime of our energy storage."

"We improve our understanding of our BESS in operation even without having an armada of operational and data analytics experts."

Result: 48% increase in annual contract value for energy products. €1.6M in additional revenue per 10MWh for clients like VERBUND.

---

Redesigning the Investigation Flow: Unified Architecture

As the product suite grew — Energy Health, Warranty, Safety Monitoring, Data Explorer — a deeper structural problem became impossible to ignore.

The product architecture reflected how engineers had built the system internally. It did not reflect how operators moved through a real investigation.

In practice, a root cause investigation never stays in one module. An operator might start at a system-level health overview, drill down to a specific string, check how it's affecting performance, look at imbalance patterns, then cross-reference warranty coverage to decide what action to take. In the old architecture, every one of those steps happened in a separate browser tab — with a full asset hierarchy re-navigation each time.

I proposed a unified architecture built around the user's investigation flow, not the product's internal logic. The core principle: wherever you are in the product, you can continue — drill deeper, move sideways to a related insight, shift context without losing your place in the hierarchy. The asset context travels with you.

This was a different mental model of what the product was for. Less a collection of analytical tools, more an investigation environment.

Convincing the team wasn't the hard part — the connection between the user problem and the proposed solution was clear. The work was in the orchestration: how to slice the development across roadmaps, what to build first, how to migrate without breaking existing workflows.

Result: 80% reduction in time-to-value for critical workflows. 35–40% reduction in front-end development time through the reusable component system the new architecture enabled.

"TWAICE enables us to gain critical insights into the performance and aging of battery systems. This allows us not only to increase operational safety, but also to maximize the profitability of our projects."

---

Performance Manager: From Data Access to Decision Support

The most strategically significant shift of my time at TWAICE came from a question that wasn't initially a design question: what do our customers actually need to care about on a daily basis?

Battery systems are designed to last around seven years. A product organized primarily around degradation and end-of-life wasn't creating the kind of ongoing engagement a SaaS needs. But battery performance — specifically, how operational decisions affect trading revenue and system uptime day to day — that was a conversation with different stakes entirely.

The imbalance topic had been surfacing as a signal. Performance gaps between battery strings were directly affecting trading margins. The business had it on the radar. What was missing was clarity on how to build a product experience around it.

The engineering team's natural instinct was a dashboard of analytical views: imbalance charts by inverter, by string, temperature heatmaps, SoC correlation views. All technically correct. All useful for deep investigation.

I pushed for a different starting point — because I'd learned something about who actually uses this product.

Operators are not primarily analysts. They're decision-makers under time pressure. When a shutdown event happens, they need to act fast. When a trader needs input on operating boundaries, they need a clear answer. A wall of charts to interpret is the wrong tool for that first moment.

My proposal: lead with actionable insights. Surface what requires attention, with enough context to understand why and enough confidence to act. Let the deep investigation — the charts, correlations, root cause evidence — live one step behind: accessible when needed, not in the way when it isn't.

This became the structural logic of the Performance Manager: an insight-driven experience with investigation depth on demand, not a data exploration tool with insights bolted on afterward.

We validated the approach through prototype testing with customers and targeted sessions with the Battery Think Tank — an expert panel of industry practitioners we ran to pressure-test concepts against real operational mental models before committing to development.

The concept landed. Development was prioritized. When I left TWAICE, 80% of the planned concept was live, and the Performance Manager had become the company's primary product.

"I log into TWAICE every morning — it gives me a clear, reliable snapshot of how our systems are performing. If something looks off, I can quickly drill down, export the data, and send it straight to the integrator or service provider. It just works."

"With TWAICE, it's like being able to see into the battery data. TWAICE has helped us uncover many underperforming components that we wouldn't have found otherwise."

---

Cross-Team Influence: Design System and the CS Relationship

Two parallel threads defined the broader shape of my time at TWAICE.

The Lithium Design System

As the product suite grew, inconsistency was accumulating quietly. Different component styles across product generations, duplicated front-end work, designers solving the same visual problems independently. I started pushing for a shared foundation — and I also drove the new design language for the product, replacing a fragmented and dated visual system with something coherent across all modules.

The challenge wasn't convincing people it was needed. It was finding space in roadmaps that were already full. I learned to nest design system work inside product priorities: when a team needed a new component anyway, that became the moment to build it reusably and bring it into the system.

I partnered with Tom (FE engineer on mobility, later promoted to Engineering Manager) and Ahmed (full-stack engineer on energy) to share ownership across design and engineering. On the design side, Monique and I defined how experimental components graduated into reusable system components.

Full adoption across teams within 2 months of formal rollout.

"Leonardo self-initiated the design systems project. He built, maintained and scaled the system to bring efficiency and speed in UI design and development. This contribution helped the organisation test many business ideas quickly."

"Leonardo's ability to synchronize efforts between design and engineering was key to streamlining collaboration. The design system saved us time and allowed designers to focus on strategic initiatives."

Result: 50% reduction in UI concept execution time. 35–40% faster front-end implementation.

The CS Relationship

The Customer Success team had a quiet but real skepticism toward design involvement in client contexts. I didn't try to overcome it directly — I found a different entry point.

I started having working conversations with CS engineers about investigation flows: what data matters at which point in a root cause analysis, what sequence of questions operators typically move through, what context they need to act with confidence. CS engineers knew this territory intimately. They had the mental models I needed, and those conversations gave them something valuable in return — a designer who was asking the right questions.

By the time we were deep in Performance Manager development, CS was actively involved in concept testing. Not as a favor, but because they saw their input shaping what got built.

The breakthrough was quiet: a CS engineer who had been professionally distant started volunteering information before I asked for it. That's when I knew the relationship had actually shifted.

---

What I Left Behind

Three years in, the energy team had a product architecture built around how operators actually investigate problems. The company's primary product — the Performance Manager — was structured around an experience logic that started with design. The design system had reduced duplicated effort and given the team space to focus on harder problems. And CS, engineering, and design were collaborating in ways they hadn't before I arrived.

"Other designers in our team, including me, would often take his designs as inspiration. Leonardo brings valuable expertise in product strategy and user research."

I never held a management title at TWAICE. What I held was trust — from my managers, from the product trio, from engineers, from CS, from designers navigating their own challenges who knew where to go for a useful conversation.

That trust was built one honest, useful interaction at a time. And it's what made the product work possible.