E-Mobility Online-Shop

Case Snapshot

Role: Technical Product Owner
Organisation: E.ON, Essen
Period: 02/2022 – 04/2023
Starting point: Separate purchasing processes for electricity tariffs and wallboxes; an initial target date had already been communicated
Decision: Reactivate an existing PHP shop rather than build a new AEM integration
Outcome: A combined purchasing process, expanded over several releases to include more wallboxes, tariffs, accessories, installation and vouchers

Starting point

E.ON wanted to sell wallboxes and electricity tariffs together online. The existing shop, however, was designed for electricity contracts; physical products and their fulfilment were not part of that model. Customers had to go through two separate purchasing processes for a wallbox and an electricity tariff, and enter some of their details again.

When I took over the project as Technical Product Owner, the long-serving Product Owner was leaving. There were two days for the handover. Management had already communicated the target date for the first combined sales journey, while what existed at that point was essentially a UI/UX concept. The technical feasibility within the existing system landscape had yet to be established.

So the main question was: How could we actually get it into production under the technical constraints and deadline we had?

My role

I worked between business stakeholders, management, architecture and development. Together with architects and developers, I assessed the solution options and their implications for the deadline, existing systems and team capacity. Once we understood the technical constraints, I turned them into epics and stories and started prioritising the backlog.

This also meant clarifying dependencies involving the backend, CRM, payment and fulfilment with the people responsible, and regularly communicating risks to management and stakeholders. The staffing situation mattered, the established development and testing team mainly knew Adobe and JavaScript, and initially only one backend developer was available for the existing backend. The Scrum Master also supported other teams.

Approach

1. Assess two options under time pressure

In the first two weeks, I worked with architects, backend developers and management to develop and compare two options:

• Adobe Experience Manager (AEM): Add functionality within the existing Adobe environment. This option was a better fit for the team's existing skills and a cleaner integration from the perspective of the intended architecture. However, procurement and approval for the additional module were considered a risk to the target date already set.
• Reactivate the existing PHP shop: Adapt an application previously used to sell IoT devices, with its own CRM and parts of the necessary infrastructure and permissions already in place. This appeared to make the first release capable of taking orders achievable sooner. The PHP application, however, was a poorer fit for the original team and brought operational and maintenance work with it.

We chose to reactivate the existing shop. That was not a claim that a legacy system was inherently better than AEM; it was a decision to prioritise time-to-market against a specific deadline. It also meant we had to change the team and the technical foundation before we could pick up speed on product features.

2. Carry the groundwork the decision required

After the decision, we investigated how a wallbox and electricity tariff could be represented together and how orders could be handed over to CRM, payment and fulfilment. Only with that understanding could we define realistic development and testing requirements.

Reactivation involved more work than the initial conversations had suggested. Alongside the existing CMS, parts of the Adobe functionality already available on E.ON's side had to be recreated for the PHP shop. A PHP update and updates to several libraries also took additional effort. The application required more PHP expertise than the original team had.

I raised the need for those skills while the two options were still being assessed. After the decision, the team was adjusted accordingly; in parallel, we had to agree on additional budget and the changed approach. With the deadline fixed, this created friction within the team. The first few weeks were therefore not just about developing features, but about making the chosen solution viable for the work ahead.

3. Document decisions

On this project, I introduced Architecture Decision Records (ADRs) as a way of working for the first time and asked those involved to document significant technical decisions, including their context, alternatives and consequences. Among other things, the architects recorded the trade-off between AEM and the existing shop.

That proved useful later. When the decision to reactivate the legacy shop was challenged, we could point to the constraints at the time and the documented decision. When developers joined the team, the records also helped them get up to speed on decisions already made. The documentation did not remove every objection, but it made the discussion more concrete than claiming in hindsight that we had had “no other choice”.

4. Split the scope into releases

The first production release was meant to cover just one use case: buying one wallbox together with a specific electricity tariff. We put this first sales journey into production by the communicated target date.

The initial expectation for the expansion was to deliver the entire remaining scope at once. Together with the lead architect, I proposed five successive phases instead. This allowed us to put the technical prerequisites in place step by step while delivering an expanded purchasing process with each release:

1. One wallbox with a specific electricity tariff in a combined purchasing process.
2. Multiple wallboxes with one electricity tariff.
3. Multiple wallboxes with one electricity tariff and accessories.
4. Multiple wallboxes with multiple electricity tariffs, accessories and wallbox installation.
5. Discount vouchers added to the expanded purchasing process.

Management accepted the staged approach. The order was not determined solely by what could be developed first: offering more wallboxes initially had greater business importance than offering more tariffs, while vouchers were less urgent than the other expansion stages. We also had to consider which changes to the shop and downstream systems would enable each next step.

The visualised sales and customer journey helped me break the overall process into epics and user stories for these stages. The fact that few major ad-hoc changes came in from the business during development kept planning relatively stable.

5. Don't stop at checkout

A combined basket alone would not have solved the problem. The process had to work beyond the interface:

Select product → put together an offer → pay → hand over the order → process the physical product and electricity contract correctly in downstream systems.

I coordinated dependencies involving the backend, CRM, payment and fulfilment when defining requirements, prioritising work and planning releases. What looked like a seamless purchasing process in the UI/UX concept had to be supported by the systems involved.

Management and collaboration

I prioritised the product backlog, prepared refinements and sprint planning, and supported reviews and releases. On the team side, we looked at sprint velocity and delivered features, among other things. Operations monitored the technical infrastructure.

Marketing analysed clicks, purchases, conversion rates and abandonment rates, and sent us weekly updates on sales figures. This feedback made use of the sales channel visible during the project. I do not infer specific commercial improvements from it here, because I am not publishing reliable comparative figures.

My weekly status reports to management and stakeholders covered progress, the schedule, open issues, risks and the planned scope of upcoming releases. To the best of my knowledge, no production incidents classified as Blocker, Major or Critical were reported during my time on the project. That is a statement about reported incidents in those categories, not a claim that the system was entirely free of defects.

After several releases, the tone of the discussions changed too. We were no longer talking only about what we intended to do. Stakeholders could see what was already live and what we were working on next. The meetings became noticeably calmer. To me, that trust came both from delivering regularly and from communicating openly about obstacles and proposed solutions.

Outcome

Over the course of the project, two separate purchasing processes became one digital sales channel. The first release combined one wallbox with a specific electricity tariff. Across the five releases, more wallboxes, accessories, further tariffs, wallbox installation and discount vouchers were added.

The success was not just a new shop interface: we adapted an existing system landscape to support the combined purchase of a physical product and an electricity tariff, as well as the processing that followed. The cost of getting the first release live sooner was additional work on the PHP application, CRM, libraries and team composition. To me, both sides are part of the outcome of the same decision.

What I learned

Options

When choosing between AEM and the existing shop, we gave considerable weight to the target date. That was understandable under the circumstances, but I initially underestimated the work involved in updates, recreating functionality and bringing in the PHP expertise we needed. Today, I would make those downstream costs more explicit when assessing the options — not only as a technical risk, but also as a need for time, budget and people with the right skills.

Product Ownership

The UI/UX concept gave the team a clear picture of the goal. It could not tell us whether the backend, CRM, payment and fulfilment systems could support a combined purchase. This project shaped how I understand the role: a Technical Product Owner does not need to develop every component personally, but does need to understand the technical consequences of a product decision well enough to assess viable options with architects and developers.

The position was explicitly advertised as “Technical Product Owner” a title I had not come across before. After this project, it felt right to me, it describes the combination of product responsibility and technical understanding that the work actually required.

Incremental releases

The first release was on purpose a small one. Only one wallbox and one electricity tariff as a fixed bundle. Apart from the hard deadline what mattered most was making shure that the shop could support further offers afterwards. I still catch myself wanting to put too much into a first release (especially when I planed my portfolio as a product). The E.ON project reminded me that reducing scope is only useful if you have a realistic path for what comes next.

Team

Choosing the PHP application changed more than the code and infrastructure. It changed what was needed from an established Adobe and JavaScript team. Under time pressure, that led to tensions that a new roadmap alone could not resolve. In this phase, I saw how important it is to have a Scrum Master who, despite also supporting other teams, makes space to raise problems early and stabilise how the team works together. For me, staffing and supporting the team therefore belong in the same decision-making process as the technology.