Emitwise Redesign

The first step was removing engineers from the carbon calculation loop entirely. Every time a customer needed to analyse their data, an engineer had to get involved — a bottleneck that made the product impossible to scale. We interviewed 5 engineers and 5 carbon accountants to map the full data journey. The journey map made the problem impossible to ignore: engineering time was being consumed by manual data processing that the product itself should handle.

Rather than patching v1, we committed to starting from scratch and setting foundations that could evolve in any direction. Engineers researched new frameworks. Designers dug into the root of the user's problems — specifically, the questions users needed to answer, not the features they asked for. As a SaaS product, Emitwise provides information. The way that information is presented is as important as the information itself. We ran interviews with existing and new customers, compiled a list of common questions they needed to answer, and used that to define Jobs To Be Done and group requirements into epics.

With stories defined, we built a roadmap around four milestones: set solid foundations, ship a v2 MVP quickly, migrate existing customers, then find parity with v1 while improving the experience. We set OKRs and KRs for each milestone and tracked them through product analytics, questionnaires, front-end monitoring, and stakeholder interviews.

With a plan in place, we designed a long-term product vision — a prototype of what the product could look like in 12 months — and shared it across the company. This created alignment, generated ideas from unexpected places, and helped everyone visualise the path ahead. We then worked closely with Carbon Accountants, the team members who knew customers best. Regular wireframe reviews became a first filter: if something didn't work for them, it wouldn't work for customers.

The biggest challenge was running foundational work, migration, and new feature development simultaneously. We tried the Dual Track approach — working on multiple streams in parallel with fully synchronised teams. This avoided common blockers: engineers waiting for designs, designers waiting for prioritisation. The approach worked when coordination was tight. When it slipped, blockers compounded. The lesson: Dual Track requires deliberate synchronisation rituals, not just good intentions.

Performance over aesthetics: if a framework change improves performance, the user experience improves too. Never compromise on it. There is no good time for feedback: evolve your methods constantly — sessions, async Looms, quick reviews. Find what works per audience. Deadlines bring ownership: estimate, commit to a date, and deliver. Vague timelines create stress and drift. Data visualisation is deep: working with dashboards for a year revealed how much conventional guidelines leave unsaid — data overload, chart behaviour, complex hierarchies. Read widely and question defaults.