Embedding Product Analytics Ways of Working at Kingfisher
A feature post by guest writer Stuart Milne, Lead Digital Analyst at Kingfisher
In this post, I will talk through how we’ve spent the last year embedding our Product Analytics ways of working at Kingfisher.
Who is Kingfisher?
Kingfisher is a FTSE 100 group comprising of of several retail companies (‘banners’ at they are referred to internally) including B&Q, Screwfix, Castorama and Brico Depot. While the banners, to an extent, operate independently some functions operate at a group level to serve a collection of banners, importantly this includes our Digital Product teams and our Data & Digital Analytics teams.
What was the landscape?
The Group Analytics function was new to Kingfisher, it had only recently been set up and the Product Analytics team would be a brand new team dedicated to serving our Digital Product & Digital Ops teams. This meant there were no pre-existing ways of working with the stakeholders, and no strategy set up to allow us to optimise the value analytics can bring to our product teams.
When I started in Kingfisher I had my intro meeting with our Director of Digital Product and she talked through her team, going through each area and how analytics could support each domain. The first element on this that was quick to realise was the scale of the team, various product domains with each responsible for large elements of multiple websites, highlighting the importance of getting the ways of working and strategy for product analytics correct. That led me to spending time with the leaders of each product domain, as well as the current analysts in the business who were around pre the set of the dedicated product analytics team. And the biggest takeaway from this was that because the analytics resource was sparse, and was covering multiple domains, the involvement in the product lifecycle was very sporadic and ad-hoc. This meant analytics was involved at some points of the lifecycle, but rarely all, so for example if a feature was being released, we might have been asked for analysis into the impact of it going live, but we hadn’t been involved in the ideation to really understand what we were trying to solve by releasing this feature.
But throughout the conversations with the stakeholders it was clear that they saw the value in data, they thought “Analytics is the missing link in turning us into a best-in-class product team” and “Analytics is key if we want to get things right“ but I also heard things like “All test ideas come from banners and POs, analytics isn’t much involved”. How could this be the case if we had a product team crying out for data and analytical resource eager to be involved and help our product teams? This led me to setting out some basic principles to enable us to succeed as a Product Analytics function.
What were the fundamentals?
Although these are very simple, these two fundamentals have enabled us to start on our journey to make data a key part of our product lifecycle and it very quickly allowed us to start bringing value from analytics. These two fundamentals are below, which are then expanded on in more detail:
- Resource allocation
- Reporting/Performance hubs
Resource allocation
Our product domains are large, too big for more than one analyst to dedicate enough time to individually, this meant that we had to be smart about how we allocated our resource. We had to ensure that we firstly didn’t stretch ourselves too thinly, leading to a workload that meant we increased our likelihood for errors but also to ensure we had enough time as analysts to understand the product domain deeply enough as well as leaving us enough time to ask ourselves the “so what?” and to spend time looking for opportunities in the data to feed back to our product teams. When deciding how to allocate our resource there were two options:
- Option A — allocate a dedicated resource into some of the domains, leaving some without dedicated resource.
- Option B — agree to serve all product domains, pooling resource out and prioritising our requests.
In simple terms option 1 would mean we only serve 2 of the domains (with one analyst aligned into each), leaving 3 without dedicated resource, while option 2 would mean our two analysts would spread their resource across all 5 domains. After spending time looking into these two options, I decided to pitch option 1 to our Product Director due to the understanding of the current landscape. If we tried to spread ourselves too thinly and serve every domain, we wouldn’t get deep enough to really understand each area, and it would become to easy for us to agree to take on priorities from other teams and lose focus on ensuring we are part of the whole lifecycle for the area that needed the most focus. The obvious drawback would that we would have to have an agreement that we wouldn’t spend time focusing on certain domains, with the overall aim being we would highlight the value of having dedicated resource in each domain and then use that to justify more resource in the future. After pitching this to the Product Director this approach was signed off!
Reporting/Performance hubs
The second fundamental, and again a very simple one, was the creation of what we call our Product Performance Hub to ensure we had a one stop shop for all reporting & insights relevant for our Digital Product team. So often I have seen business operate with a multitude of dashboards and reports sitting in people’s bookmarks, or referenced in emails, but with no way to easily access them all in one place or to easily share all the relevant reports with new starters joining the business. This led to the setup of the hub where we house everything in one place, allowing for one link to be shared & bookmarked, and giving easy access to anyone in the business who wanted to access our reports and insights. And to keep the hub as relevant and useful as possible we tag all our tabs into one of the following 3 areas, to make it easy to find what you’re looking for — but also to allow you to delve deeper into areas that might be of interest:
- Reporting — tabs showing performance against fundamental KPIs.
- Ideation — tabs showing insights for existing features and suggesting opportunities for improvements.
- Release — tabs showing performance of new features when released.
By classifying our work into these three steams we can help to put data at the centre of the product lifecycle, providing insights and answer to hypothesis our product team has, while then helping them to understand the impact of releasing new features. All this underpinned by an understanding of how we are tracking against our product KPIs.
What have we achieved?
We set out on this journey around 12 months ago and have achieved a lot in that time, our ways of working have meant we have become knowledgeable about the domains we focus on allowing us to be confident in our recommendations for opportunities, and we’re in the detail enough to prioritise effectively for our stakeholders. Through Design Thinking methodology we have filled the Performance Hub with insights and ideas for improvements to features and have tangible examples of where data has led to product improvements. The hub has also been used thousands of times by our stakeholders to help them understand the performance of their products, which has helped us to put data far closer to the centre of the lifecycle of our products, but we still have a journey ahead of us!
What’s next?
While we’ve embedded these ways of working over the past year, we still have a way to go to achieve our ultimate aim of making data a crucial part of the product lifecycle. We want to continue to highlight the value we’re bringing to justify increasing our resource to bring value to the domains we don’t currently focus on, and to continue to enhance our Performance Hub with insights & opportunities and tell stories with our data to continue to support product development.
💼 If you need anything, you can reach me on LinkedIn and if you want to join me at Kingfisher visit our careers page.
