Data-driven product development

Data-driven product development

A better way to define success metrics, enabling better product iterations across the department

A better way to define success metrics, enabling better product iterations across the department

TLDR

Despite the diverse product teams within Partnerships, a common challenge was the limited data-driven approach to product development. To bridge this gap, I initiated a cross-functional initiative to optimise product development through data-driven insights and probes

TEAM

Solo designer, with guidance from my manager

ROLE

Leading the project, planning and executing, facilitating workshops, and managing collaborators and stakeholders


TIMELINE

6 months

APPROACH

Define

Problem mapping

Project briefing

Plan

Project plan

Feedback collection

Approach definition

Execute

Framework creation

Collaboration management

Workshop facilitation

Outcome collection

Analyse

Metric extraction and cleanup

Cross-functional collaboration

Outcome sharing and measuring impact

CONTEXT

The org structure and process

The org structure and process

The Partnerships department has over 9 product teams, constituted of developers, product managers, and designers. While each team has its own way of working and building different products, I noticed a gap between what we offer our end-users and the data we get in return.


I took it upon myself to start an initiative that brings together these cross-functional teams and help them optimize their product development through a data-driven approach.

The Partnerships department has over 9 product teams, constituted of developers, product managers, and designers. While each team has its own way of working and building different products, I noticed a gap between what we offer our end-users and the data we get in return.


I took it upon myself to start an initiative that brings together these cross-functional teams and help them optimize their product development through a data-driven approach.

Partnerships department

Booker experience track

Focusing on consumer facing products

Platforms track

Focusing on the Partner Center and business facing products

Ops track

Focused on internal tooling for commercial and product development

Product teams

Rewards and gating

Branded platforms

Apps

Partner Centre

API

Reporting

Fee admin

Internal tooling

Portal

PROBLEMS

PROBLEMS

Flaws in the process

Flaws in the process

A year into my year at Booking and within the Partnerships department, I realised there is a big discrepancy in the way the different teams other designers and I support track these products' efficiency and success/failure. 

A year into my year at Booking and within the Partnerships department, I realised there is a big discrepancy in the way the different teams other designers and I support track these products' efficiency and success/failure. 

The diversification of end-users (b2b vs b2c vs internal tooling) and the nature of the products we build in the department make it hard to have a useful success tracking system in place.

No common metrics used across teams and products, even though we feed into one departmental goal and priorities.

Tracked metrics were not necessarily helpful towards understanding how to continue iterating, or simply assess how the product is doing at a behavioral level.

Example

The primary metric tracked for a new launch sheet added to the core app is: number of total bookings. 

While it serves the much bigger purpose, what can we learn from this metric? How can our product development and reiteration based itself off of that metric?

INITIATIVE

INITIATIVE

Time to act and plan

Time to act and plan

My manager and I decided to take it on as a community project and laid out a plan. 

We first had to understand how to explain the impact and value of this data-driven mindset for the department's scope.

My manager and I decided to take it on as a community project and laid out a plan. 

We first had to understand how to explain the impact and value of this data-driven mindset for the department's scope.

KICKSTART

KICKSTART

Approaching stakeholders

Approaching stakeholders

Based on the feedback and engagement, we decided to approach each product team separately with a workshop that will summarise the document through a slide deck, and then with a workshop made to simplify and nurture the use of its framework whenever metrics need to be set for a product or feature iteration.

Based on the feedback and engagement, we decided to approach each product team separately with a workshop that will summarise the document through a slide deck, and then with a workshop made to simplify and nurture the use of its framework whenever metrics need to be set for a product or feature iteration.

1

Share the project plan

It was shared with all stakeholders from each product team in the department, as well as relevant principle developers. Feedback was collected then.

2

Assess engagement and knowledge

Based on the feedback and comments collected, we saw high interest, but low knowledge, even for product managers.

3

Define next steps

We decided to translate the document shared into a digestible workshop aimed at better defining success and failure metrics when launching products and features

Crafting the workshop framework

Crafting the workshop framework

After booking slots with all teams, I started designing the framework for the workshop. 

I researched any existing frameworks with the same purpose and topic. 

Struggling to do so, I took a step back and broke the main objective into key probes that would help me reach said objective.​

After booking slots with all teams, I started designing the framework for the workshop. 

I researched any existing frameworks with the same purpose and topic. 

Struggling to do so, I took a step back and broke the main objective into key probes that would help me reach said objective.​

DIRECTION

This set the direction the workshop would take. Based on this, I wished to make the workshop practical by asking the different teams to choose one product or feature to be used as a reference/example in the workshop.

EXPECTED IMPACT

This would help tailor each team's outcome to their product and process needs, and it showed the practicality and value of such a mindset using real-life examples.

POST-WORKSHOP

POST-WORKSHOP

Normalising the outcome

Normalising the outcome

We had 13 workshops with all product teams over the span of 2 months.

We had 13 workshops with all product teams over the span of 2 months.

We combined the outcome into one source of truth: a sheet that recognises metrics of common value across teams as well as individual metrics.

My manager and I then had a few sessions with people representing business and tech, where we normalised the metrics. We looked for overlaps, suggestions and categories for easier usage.

Jackpot

Product, tech, and UX now had the right tools and methods to find the optimal metrics for their products, making product development more efficient

We normalised data points that impact the products within the department and created a base to be used for primary metrics

Post-initiative

Post-initiative

Observations

A few months have passed since this initiative. I have noticed a shift in the way different product teams within the department handle metrics and data. Designers are more involved, discussions are made around measuring data instead of relying on the assigned developer to list down minimal metrics.


We are now able to make better decisions when building and improving products thanks to an data-informed process.

Next steps

As for next steps, I regularly follow up the developers in charge of implementing the common metrics and check with the designers in my department if their collaboration and processes are better.

In retrospective

In retrospective

A project that taught me better leadership and cross-functional collaboration with functions I hadn't worked with before (principles developers) among other things

A project that taught me better leadership and cross-functional collaboration with functions I hadn't worked with before (principles developers) among other things

The influence of designers on product success

Designers' role and involvement in defining metrics is essential.

Behavioral metrics are key to setting the expectations for a product or funnel's success/failure

No size-fits all approach

I spent a good amount of time researching workshops and frameworks I can use to approach my stakeholders. Sometimes breaking down my goal into smaller probes will guide the exercises and optimal approach

Assigning efficiently as a leader

Not everything needs a meeting, and I can't be the one managing all 9 product teams and their engagement. Knowing when to involve myself or others taught me to take more of a leader role in this project

Back to the top

Back to the top