A newer software team inside a larger energy company. No process yet.
Watt Footprint operates across three departments. Technical Studies handles energy audits and SEAI grant schemes. Project Implementation manages on-site hardware upgrades. The Software team, the newest of the three, builds the SaaS platform. When I joined in July 2025, the software backlog lived in a shared Notion workspace alongside tasks from the other departments, there was no sprint structure, and the external engineering team was managing their work through Slack.
The HOO was focused on business development. The Software Lead joined one month after me and came in on product strategy. Delivery was mine to own from day one.
Two teams, one codebase, both managed by me.
One external engineer was not delivering. I identified it during sprint reviews, raised it, and we offboarded them. Not easy mid-sprint on a small team. Still the right call.
Two client tiers. Two completely different product experiences.
The platform served two types of enterprise client. Redesigning for both simultaneously in the same sprints was one of the harder product challenges of the engagement.
- Clients without live meters
- Analytics and reporting on bill usage
- CO2 tracking from bill data
- BER-style energy rating, exclusive to this tier
- Guidance on improving the rating
- Real-time electricity, gas, water, solar
- CO2 tracking from live consumption
- Electricity bill management
- Trend analysis across sites
- IoT sensor and gateway management
The BER-style rating for Snapshot clients was a deliberate UX decision. Building Energy Rating is something Irish businesses already understand from property. Borrowing that mental model for the dashboard made energy performance immediately legible to clients without technical energy teams.
Two months before formal sprints. All over the place by design.
Formal sprints started September 4th. July and August were a different kind of work: building the structure that made the sprints possible, while simultaneously keeping everything else moving. There was no clean handover or runway period. It was all happening at once.
The cadence that held both teams together once sprints started: standups Tuesday and Thursday, a one-hour review every Friday. Both internal and external teams in the same Notion backlog from sprint 1 onwards.
7 sprints at 100%. Left during Sprint 8 with 14 tasks in flight.
The budget feature let clients set a monthly energy spend target with live tracking and threshold alerts. All 13 clients used it. The alerts system was configurable at a detailed level: frequency, condition, kWh threshold, which users to notify, date range, and filters by location and gateway. The Super Admin view in sprints 6 and 7 gave account administrators a unified dashboard across all their sites, with role-based access controls for site managers built on top of Clerk IAM.
Three new accounts in August. Nine IoT sites to coordinate.
Three new clients went live in August, before formal sprints even started. That is what drove the spike in the platform data: 681 create energy charge events and 1,195 update events in a single month, compared to negligible activity across all of H1. Two of those clients were large hospitality accounts, one with three sites and one with six.
Onboarding at that scale meant coordinating physical IoT sensor and gateway installation across nine locations, validating that data was coming through correctly from each site, and making sure live usage was accurate before the client's energy team relied on it. UK and UAE expansion required product changes across sprints 2 and 3: multi-currency support, adjusted energy charge structures for different billing formats, and bill reader validation for non-Irish bills.
Same user base. Significantly deeper engagement.
I reviewed Amplitude weekly and used it to prioritise each sprint. The H1 to H2 comparison tells a clear story: user growth was modest at 4%, but platform depth grew substantially. Clients who had access were now actively using the workflows the platform was built for.
| Metric | H1 2025 | H2 2025 | Change |
|---|---|---|---|
| Total Sessions | 1,689 | 3,108 | +84% |
| Returning Users | 197 | 264 | +34% |
| Avg Daily Active Users | ~8.5 | ~11.2 | +32% |
| Create Energy Charge | 48 | 1,352 | +2,717% |
| Update Energy Charge | 508 | 2,128 | +319% |
| Update Report | 13 | 315 | +2,323% |
| Create Sensor (IoT) | 292 | 424 | +45% |
| Create Gateway (IoT) | 46 | 96 | +109% |
Individual user login frequency softened slightly in H2 cohorts. In a B2B energy management tool that is expected: the person who manages energy data is typically one or two people per account. When the platform is working well, those users spend less time in it per session. The account-level number is the meaningful metric, and it was 100%.
Two-minute load times on some clients. I owned fixing it.
Several clients were hitting infographic load times over two minutes. Large data volumes on older accounts combined with undersized compute. It had not been formally reported but was affecting the clients using the platform most heavily. Fix: EC2 scaled to medium, continuous aggregates added to pre-compute heavy queries rather than running them on every request.
Ending the year with something clients would actually remember.
The Wrapped feature was the final Sprint 7 delivery. Modelled on Spotify Wrapped, it generated a personalised annual PDF for each enterprise client: total energy usage, CO2 emission savings, consumption trends, and site performance across the year. Auto-generated and emailed to all clients at the end of December 2025.
Retention
The timing was deliberate. Sending clients a concrete summary of the value the platform delivered in December, ahead of any renewal conversations, was both a product decision and a retention play. I left before seeing the full response but the LinkedIn reactions told a clear enough story.