The Iimportance of Rrunning your Data team like a Product team
Data teams survive on being reactive. Data team members are the first to hear about issues with systems, dashboards, reports etc., which is why they can sometimes get a bad reputation of being blockers or impeding progress. Data teams are also often the most technical of all roles in companies, which usually results in a mismatch between explaining the Data in a friendly user focused way and understanding the complexity behind the analysis.
At Inchcape we've been on a growth journey in our Data and for just over 5 years. We've expanded from a small team of three people to a global team of 100+ individuals (we're still hiring), covering Data, BI, and automation. Our ability to scale so rapidly and get business buy in is due to our focus on delivering great Data products, focusing our attention on what’s coming up instead of what’s just passed.
The strategy of treating our Data team like a Product team was an important step in helping us to deliver Data products that were useful for the business and allowed us to spend less time explaining our reasoning behind new product building and more on just getting it done. Essentially front loading the why.
Data teams should always be trying to find ways that they can exploit their current tools and resources to save money for other things or even putting it back into new products
I would suggest any Data or BI teams out there looking to scale consider how they might approach their output as a product team, rather than as a traditional Data team. One of the first mistakes we made and one I see many teams make is viewing the Data team as a cost centre, available to answer questions from the business that take a long time and going in circles, always chasing what has just occurred. Although this is an essential component of the Data team, a more important aspect we discovered was returning value to the business by delivering insights, where the business should be focusing.
We began viewing our output like a product team to accomplish this. What was the return on investment and how would we be able to pique the company's interest on it? Essentially, we're front-loading the effort of explaining why we're building this product and what it will deliver us year after year.
This product team approach saved us a lot of time and resources, as opposed to building each product from the ground up. Data teams should always be trying to find ways that they can exploit their current tools and resources to save money for other things or even putting it back into new products.
By following this strategy, we were able to provide Data Product's that were helping to inform business decisions, rather than just chasing Data quality issues, and providing analysis for what had happened. We turned our focus on creating valuable insights for the business.
We took the process very seriously, recruiting product managers for each group of products we intended to provide, following AGILE procedures, and making UX a key component in all our projects. For each product we developed, we issued an internal press release that described all the features and how customers might use them to help the company.
This change in perspective and approach has resulted in the team expanding into 32+ markets, servicing more than 200+ companies within Inchcape. This is an excellent result for a team that includes most team members who have been at the company for less than 18 months. I think you should do the same if you have a Data department and desire to get the most out of it.