carwow: A behind-the-scenes look at how we design and build products

A high-level overview of the discovery and delivery process at carwow

Hey! 👋

In my previous blog, I shared carwow’s Product Principles. For us, product principles are a set of fundamental guidelines defining how we act, think and produce work across all areas of the Product Organisation (Product Design, Engineering, Product Management, and Product Analytics). They establish a guiding path for communication, consistency and alignment between peers and empower us in the process.

As a next step, to codify and formalise carwow’s way of doing Product, we thought it was important to define our approach to discovery and delivery. The objective was to align the product organisation in how we can best deliver outcomes, from the initial discovery to the delivery of a service, feature or product, to analyse learnings informing our next steps in the product life cycle.

Many of the concepts featured here may seem familiar to you, as we have borrowed heavily from our favourite product giants such as Marty Cagan and Teresa Torres. It was not our goal to reinvent the wheel but to clarify to our current and future product designers, product managers and engineers what we believe in and how we think product building should be done at carwow!

Product Process Overview

The starting point of our process is having an objective with a metric that we want to move, normally the Key Result (KR) part of the product squad’s Objectives and Key Results (OKRs). Oh, I forgot about this. We use OKRs at carwow, but I will leave that (dry) topic for another time!

Our high level discovery and delivery process has two different phases with strong feedback loops. Unsurprisingly, these are: discovery and delivery.

A big part of our approach is based on a well-known design framework of the Double Diamond (I did mention earlier that we weren’t inventing anything new here.😋)

This process allows us to build confidence and validate problems and solutions mitigating the four major risks for any digital product defined by one of my Product Heroes, Marty Cagan. Here is the link (worth reading, IMO).

• Value risk: making sure customers will buy or choose to use it
• Usability risk: ensuring users can figure out how to use it
• Feasibility risk: whether our engineers can build and maintain the solution in a sustainable way
• Business viability risk: if it works for the various aspects of our business

Through the mitigation of these risks, the objective is to define a problem, ideate potential solutions and come up with a vision of the solution and the first experiments to validate the biggest risks. Then we can launch the defined experiments in the best possible way to maximise the speed of learnings, before finally summarising the learnings and insight of the work and figuring out what the next steps should be.

This can be followed through a five-step process. Here is carwow’s high-level overview of the discovery and delivery process…

1/5 Problem Exploration

💪 The goal

At this stage of the process, we need to create confidence in the Value Risk. We asked ourselves what are the biggest problems for car buyers and dealers that could move the metric.

We want to:

• 👀 1. Understand what are the customers or dealers’ problems that — once solved — would allow us to move our key result. We need to ensure that we have a deep understanding of the problems we’re looking to solve.
• 💬 2. Articulate: Breaking down the root cause into hypotheses we want to solve, validating them using either qualitative or quantitative data.
• 🚧 3. Scope: Understanding the size and complexity of the problem, making sure that there is significant value to take the problem through to ideation.

What happens at this stage

The process basically covers identifying problem hypotheses, prioritising and validating them through quantitative and qualitative techniques and then refining the problems and sizing them. At the last stage we define a “How might we… (HMW)” statement, which would help us in the ideation stage. See more about HMW statement here.

Summary of the tools we use to do this

2/5 Ideation

💪 The goal

In the ideation stage, our goal is to figure out how we might solve the user problem we’ve identified. This can only be effective if we’ve identified and understood the situation for car buyers, dealers or carwow.

✏ 1. Ideate: The product squad (with ambassadors from teams across carwow) will assimilate the insights gathered from the Problem investigation stage and get their creative juices flowing by exploring solutions through various ideation exercises and techniques. The purpose is to generate a broad set of ideas, with no attempt to judge or evaluate them until the creative stage is over.

📋 2. Ideation prioritisation: The team led by the product manager carries out a prioritisation exercise to pursue those ideas that have the most expected impact.

🏦 3. Value & usability validation: The team will use different tools and techniques to validate some of the ideas to be able to prioritise them.

What happens at this stage

The outcome

By the end of the process, the team will have a number of proposed ideas that can be assessed for impact and feasibility, then prioritised for further discovery, prototyping and experiment design.

Summary of the tools we use to do this

3/5 The solution

💪 The goal

The solution stage is where the refinement of a high-level vision is broken down into sizeable experiments to build towards a vision of developing a feature, user flow or service. We develop confidence as we gather and share insights to learn from, guiding our critical thinking.

🙇 1. Learn: Gather insights about our product risks, at a much lower cost in terms of time and effort than building out a product.

👭 2. Expose: Highlight issues that would otherwise be left unturned. Force the team to think through a problem at a substantially more in-depth level than if we were to talk about it or document it down. These may test use cases, business rules, and acceptance criteria.

👏 3. Share: Communicate our understanding of the solution across the product org and wider ambassador group. Communicate to engineers and the broader organisation what needs to be built.

What happens at this stage

We create a long-term view of what the solution could look like in the future. Informed by the product vision, this allows us to challenge and evolve the vision prototype.

Using different techniques to validate usability, feasibility and viability risks, we experiment by following our product vision, defining the initial experiments that we can launch, validating bigger risks and learning along the way as we step towards our vision.

The team will define: (i) the problem (ii) the job story (iii) the success metrics (iv) whether the AB test is needed (v) what are the main risk and why the test might fail (pre-mortem is a good approach for this. Added link to a great article) and how to mitigate it and (vi) variants design of the AB test, if needed.

The outcome

By the end of the solution phase, we should have assessed the four core solution risks to form a shared high fidelity understanding of the solution area we want to implement.

Summary of the tools we use to do this

4/5 Production

💪 The goal

At this stage of the process, our aim is to turn a concept into a reality. Here, we’ll develop and launch experiments, features and services while ensuring we maintain consistency and thoughtfully scale our technical and design systems.

👌 1. Finalised approach: Define an experiment or feature that we want to release with finalised UX and UI design,

💪 2. Go-to-market: The development criteria are broken down into sizeable tasks, leading to the launch of an experiment, feature or service.

💓 3. Quality assurance: Ensure we ship work free of mistakes and defects, creating as little technical and design debt as possible. Checking before we go live that the correct tracking has been applied, UX is functional and cross-browser compatibility.

The outcome

The outcome will see that three things are completed: the A/B test document writeup for AB tests, the internal and external communications, and the ADR (Architectural Design Record) document.

Summary of the tools we use to do this

5/5 Analysis & learnings

💪 The goal

Our objective here is to use our learnings to inform our next steps, measure current success and track how we are moving towards our company goals and product vision.

🙇 1. Analyse: Carry out quantitative and qualitative analysis to understand results and customer or dealer behaviour and impact on key success metrics, so we are confident that meets the desire behaviour.

💥 2. Decide: Make a decision about the next steps on the experiments (e.g. iterate, stop) and consider implications and overall prioritisation of problem hypothesis and solutions.

👏 3. Share: Outward communications to the wider teams and business of learnings and why certain decisions were made.

What happens at this stage

Quantitative and qualitative analysis

Distilling insights from the quantitative and qualitative analysis, against the original hypothesis and success metrics (primary and secondary) that were identified. This is to understand if we have proved or disapproved the initial hypothesis. Informing our learnings (with positive and negative feedback) informs us why we have been successful or not, allowing us to create a new hypothesis and redefine our prioritisation.

Learning & next steps

• At the end of an experiment we decide if there is still value in continuing. We will either iterate or stop work if there is little value.
• We need to be rigorous with the data analysis but pragmatic in terms of time and expected impact.
• Product development is part science, part art, so there might be a need to use experience and intuition at the top of the analysis.

Communicate

• Effective communications to the carwow organisation across countries, including; Product, Commercial Teams, Growth & Marketing and Legal. Sharing actions that were taken and what effect it will have for end-users and the business.

The outcome

The result of this stage involves documenting our next steps with clear conclusions tied to the original hypothesis, which will be communicated to stakeholders or the company, if required.

Summary of the tools we use to do this

Disclaimer

Our product process overview is ‘work in progress’ and should be used as guidance not as a detailed process. As we use it, it will become clear what we need to tweak and change. In the meantime, we’ll be following our principles (scientifically but pragmatically) and adapting them depending on the circumstances.

In the future, we want to adapt this guidance to reflect the different types of product work, for example feature, scaling, growth, product/market fit expansion.

Thank you to the whole group of product managers, product designers and principals engineers who worked to codify this process. Special thanks to Will Morgan (Product Manager) and Gareth (Head of Product Design) who help me lead this and to the rest of product managers who provided feedback on this blog. 💙

Do you want to work with carwow? We’re hiring! Head over to carwow.co.uk/jobs to find out what positions we currently have available.

In the meantime, keep reading our blogs. We’ll be sharing more about how we work and what our PMs, Designers and Engineers are learning along the way, so stay tuned!