Intro

When I joined Emitwise the first version of the product was in production. Their mission was to accelerate the transition of businesses to net-zero carbon emissions. Their software allows companies to reduce emissions from their operations and supply chain, enabling them to meet carbon targets faster and support the transition to a low-carbon economy.

The first version was designed to achieve some tasks that could satisfy the customers we had in the first years of the company. A classic MVP, with the minimum requirements to have a good user experience and also provide value.

The main problem with this version was first that the Engineering team was part of the process to provide that value. And second, because the product was designed to achieve a few tasks it was not scalable. What does it mean? It means that improving the product may cost us more time and resources that designing a completely new version of the product.

I’m going to explain the process we followed to solve these issues and the challenges we faced during that journey:

1. Part of the ship, part of the crew

The first step was quite obvious: we needed to remove the Engineers from the process of calculating carbon emissions in order to invest their resources in developing the best possible product experience.

We started analysing the journey of the data to understand better what was the moment when the engineering team was involved and what were the main actions they were performing each time they need to analyse a customer file.

We interviewed 5 Engineers and 5 Carbon Accountants to create a journey map of the data that showed us all the feedback loops that this issue was creating.

2. Divide and conquer

To make our product scalable we decided to start from scratch and set the right foundations that could allow our product to evolve in any direction we may need.

From the building side, we needed to define how all systems were going to interact in this new version. Furthermore, we challenged if the tools and frameworks used before were the right ones for this redesign. Performance was questioned.

The research started for both sides:

Engineers needed to find the right tools and frameworks to set solid foundations that enable us to scale and build on top.
Designers needed to understand the roots of the user’s problems and what is more important, the questions the users needed to answer.

Because Emitwise is a software as a service (SaaS), we provide relevant information to the user. The way we present that information is crucial to help them to understand it at a glance.

After we did some interviews with existing and new customers we elaborate a list of common questions they need to answer. That list allowed us to enter into a more detailed level defining Jobs To Be Done, dividing and grouping all the requirements into relevant epics and stories.

3. Battle plan

After we divided the stories into smaller chunks we defined a roadmap including the milestones we considered key in order to achieve the redesign. That roadmap was our guide to keep us focused and not fall into distractions of little shiny things:

Set solid foundations: It was very important that our product will be scalable and built on very solid grounds with the right tech that could allow us to iterate quickly and provide the best possible experience.
Ship a v2 MVP to test quickly: We didn’t want to be one year working on a single release. That’s not the way. We defined milestones to release frequently, test and keep iterating.
Migrate existing customers to v2: We need to prepare a migration plan that involves the transition from v1 to v2 for all our existing customers.
Find parity with v1 improving the experience: We didn’t want to just update the UI and sync it with the branding guidelines. We wanted to also solve many of the existing problems that the user was facing with the product.

Finally, we set up some OKRs and KRs related to these milestones and we started tracking their progress through different tools like product analytics, questionnaires, front-end monitoring or interviews with relevant stakeholders.

Thanks Mateo (one of our squad Engineers) for the sketches.

4. Ideation

The plan was defined and prioritised, now it was time to start ideating solutions that could spark a conversation with the team, remove the mist and put everything into the ground to define a clear vision of where we want to go.

A nice way to achieve this was designing a long-term vision where we all could see a kind of prediction of what the product may look like in 12 month time. We designed quickly a prototype to share across the different teams of the company and that allows us to ask for feedback and ideate with all of them.

That was a nice exercise that brought many great ideas to the table. Also, it helped us to visualise the path we have in front of us making everyone feel involved in the decision-making of the next version of the product.

After that, we start sketching many of the ideas, sharing wireframes concepts with the Carbon Accountants. They work directly with our customers and know better than anyone what they need. Because of that and the easy access to them as we are part of the same team, we developed a very strong relationship involving them very frequently in our squad rituals. This first filter helped us to understand what was working or not and to put our efforts into the features that will add more value to the user.

5. Shipping

We knew what we needed to build and how we were going to build it. Now it was time to get some rhythm and speed building it. The main challenge here was to deal with foundational work, migration work and develop new features for v2 at the same time.

It was a bit frustrating not being able to see something tangible because of the nature of foundational work or migration work they are not visible. For this reason, we tried an experiment, the Dual Track.

This way of working allows working on multiple projects at the same time if the team is completely synchronised. By doing this we could avoid common blockers a squad could find during the development process like Engineers waiting for designs, Designers waiting for the Product Manager to prioritise the problems... You could find more info in this article if you are interested.

We tried, and the main outcomes were visible, but also we found that we needed to be very coordinated to make it work.

6. Learnings

These are some of the lessons we learned during this journey that I hope someone will find reflected or useful for them:

Focus on performance: It doesn’t matter if you have to change the whole framework of your product, write in a different code language or use a different UI library. If any of those decisions are going to improve the performance of the product, the user experience will improve too.
There is no good time for feedback: be open and iterate the ways you ask for feedback. It could be scheduling a feedback session, giving context in a short meeting and then allowing them time to give you feedback during the day or even sharing a loom with what you are working on. Find the best way that works for each audience.
Deadlines are good: They bring ownership to the squad. Estimate your work and pick a date you will feel confident to release. Then, make it happen.
Challenge what others take as given: as Pablo Picasso used to say “Learn the rules like a pro, so you can break them like an artist.” Knowledge is the most powerful tool to challenge others’ thoughts.
Data visualisation is complex: working with dashboards for a year made me question myself about what I knew of data visualisation. Data overload, charts behaviours or complex charts are only surfaced by many of the main guidelines available today. I can’t recommend more this book and the popular Human and Material guidelines.
Life is an experiment: probably the most important one. Be brave enough to try new ways of working if you feel your squad is capable. If it’s working you can just change your rituals. If not you just need to iterate to what it was working before.

Emitwise: Designing Scalable Products