Data as a Product Roundtable Series #1

On Tuesday 4th May we held the first roundtable as part of a series of events which will focus on Data as a Product, and how they work together within organisations. We’ve both seen a trend towards hiring requirements for Data Product Managers in the last year or so and have been working with clients who are structing their Data teams to incorporate a product element, as well as aiding their Data Ops capability. So, we thought it would be a great opportunity to run an event on topics around this space as we’re often speaking to leaders running these functions who have the same problems in the hope of finding some solutions as a collective! 

The topic was: 

“What is the optimal Product organisation structure and where does the Data product fit best, and how does this differ between internal Data ‘products’ and external Data-led products (separate subfunction vs embedded in every product squad with a "platform" approach)?” 

The event ran for a little over an hour and was brilliantly facilitated by Lorenzo Espinosa (Director, Data Ops & Data Product at Chattermill), who posed some excellent questions to draw out the problems of each leader to determine optimal structures and find solutions. We ran the event under the Chatham House Rule to keep it an open forum to share ideas and speak openly, hence this write-up will only summarise some key takeaways and ideas that were discussed, rather than highlighting the specific running's, problems, solutions of everyone.  

Along with Lorenzo, we were joined by: 

• Bronwen Bazzard – Global Product Manager @ Telmar 
• Gilberto Blanco – Director of Product Management @ Imagination Technologies 
• Isabel Thompson – Head of Data Platform @ Dimensions 
• Natalie Seatter – Chief Product Officer @ OAG 
• Pete Williams – Director of Data @ Penguin Random House 
• Babis Marmanis – Chief Technology Officer @ Center 

Ownership: 

One theme of the discussion was over ownership. If you are treating data as a product to either internal or external customers, then who directs the work of a data team. Should it be a technical head of data, a product manager embedded in the Data team or a combination of the two. Customer needs.  It seems to be a common trend in organisations to have separate siloes, both for product and data. To align the two, the biggest obstacle seems to be over who gets ownership of the platform. There didn’t seem to be a clear answer to this, other than to have product professionals embedded and leading the data function.  

There was also the problem, that with data is it often easy to point blame away from yourself. The data team can blame the quality of incoming data, and a lack of communication from the business. The business can blame the data team. The Product team often sit in the middle between stakeholders trying to please everyone. One solution was to have an embedded product manager, another was to build clear use case request framework for the business to work with. 

Ad hoc vs Automation: 

Another friction between data and the business seems to be over long-term vs short-term solutions. For internal data, ad Hoc reports are the quick fix and keep the business happy in the short term.  However, if a data team only does ad Hoc work, they can never start to automate processes as well as build a self-service platform. The problem is that a data platform must be everything to everyone, this is where a Product Manager come in and start to prioritise long term projects.  The Product Manager can also cover the data teams back when pressed by stakeholders for short term returns, because they have a clear long-term roadmap for the data platform.  

Culture: 

Something else that was raised was the importance of culture. When trying to treat data as a product it is integral to the success of a data function to have buy in. You need buy in from the data teams, the upper echelons of an organisation, the internal stakeholders and the rest of business. This is because, whether there are data product professionals or not, you still need the stakeholders and business to take the time to request new use cases for the data. Also, in some circumstances you need the business to understand the importance of quality data when supplying data to the data team. You also need the ‘heads of’ and c-suite to supply the budget to support the data team, rather than treat the data platform as purely a cost centre. Finally, you need the data team to understand how they provide value and what is required by the business, not what they think is most useful independent of ‘customer’ needs. 

Data team: 

Another topic of discussion was on how best to structure a data team. There was broad agreement that there was no perfect way to do this. However, some trends emerged. Cross functionality was key. Data engineers, scientists, analysts working alongside each other, creating products that the business needs, rather than being siloed and unable to work cohesively. There was discussion over how you would split the teams, there was some interesting discussion on this point, but it was generally agreed that it depends completely on the specifics of an organisation. There was a trend of agreement that the leaders in the data teams need to be product minded or at least work closely with product professionals. 

Data Product alignment: 

All in all, the group did come to a decision around the optimal way to structure things in most organisations (although it was agreed there is no perfect way and we could’ve spoken about it for hours longer!).  There was consensus that the flow of requirements into the data function is best put through one entry point, and that should be a Data Product Manager. The role of this person would be to prioritise the use cases coming in as well as being the sole link between business stakeholder and Data, creating a slicker, more streamlined approach. It was also generally thought that for multiple products, it would be most optimal to keep one Data team still with multiple Data Product Managers working across a few products each, but all still feeding directly into the wider Data function (this is opposed to having a separate Data team and Data Product Manager for each product). 

These are some questions we think would be interesting for next time:  

• How to prioritise different use cases from the business? 
• How can you bridge the gap between Data and the business? 
• Data investment can improve the speed, quality and ease of decision making for a business, but how do you show this to a board of an organisation that only see data as a cost. 
• What are the potential downsides to embedding data product owners/managers into data teams? 
• How do you separate and define ownership of a data platform, if product, business and data are very closely aligned rather than siloed? 

What next?

Again, a massive thank you to those who attended and to Lorenzo for facilitating. We both feel this is a hot space at the moment and hope this series of roundtables can help create a community for Data Product leaders to share ideas so they can best tackle this new way of thinking. What became clear during the roundtable was that the person making these decisions in the business or thinking in this way is often a stand-alone figure, and so there isn’t much internal collaboration around the best ways to go about these re-structures. Hence, it’s more important than ever to share ideas externally and hopefully the Data Product community will be a forum in which this can be done. 

We’re looking forward to catching-up with the attendees again soon as we plan our next event, and if you’re reading this and thinking how much you’d like to get involved then don’t hesitate to drop one of us a message and we’ll jump on a call to discuss further! 

Callum Cleaver & Ben Moulton