Three ways we run our Data team like a Product team at Feefo
This is an article on how we run our Data team like a Product team at Feefo. However, you don’t necessarily need to stop reading if you’re not an Analyst or a Product Manager. This article could have easily been called ‘How to build great skilled technical teams’ or ‘How to build things in a data-driven way’.
At Feefo our Data team aims to help drive Product and Engineering work effectively, you could class this as internal Business Intelligence or Product analytics. But we also create customer-facing solutions for insights and reporting that need to work effectively and at scale within our technical architecture. These insights into our customers’ ratings and reviews are a highly technical facet of our product, but the analysts and team delivering this work also have to think like Product Managers, we speak to our customer’s, understand their needs, and prioritise our work like PMs. So with this in mind, here’s how we think about our Data team at Feefo.
Great product teams are:
Proactive, thinking like owners or Mini CEOs
Thinking about discovery in parallel to delivery
Anti-fragile, making sharing and finding previous work simple
What do we mean by these points? Here are some actionable suggestions for how we’ve encouraged our Data team to act more like a Product team:
- Think like a Product Manager, and take ownership of your product
Good Product Managers are often likened to a mini CEO. with the freedom to decide the roadmap for a particular area, comes the demand for oversight of how that area works. Talking to everyone, communicating with both technical and non-technical stakeholders, and translating requirements into clear, actionable plans are skills that Analysts should also try to cultivate.
A good Analyst should do these things because knowing the business context behind data, how it’s collected, and the nuances and limitations from an engineering side can help Data teams make better impactful insights. For internally facing product analysts, having frequent conversations with Engineering and Product teams can also maximise your ‘surface area for opportunity’. How can you offer great data-driven recommendations to Product teams without knowing how the product is working , what new features or areas are being introduced, or how your end users actually interact with your product?
The Data team like any other team is hired to provide business value. If Data teams, or Product teams, don’t end up solving the business’s actual objectives then no matter how technically impressive or clever our work is, we’re failing.
A mindset shift to how Product Managers think can be beneficial to Analysts. Curiosity, customer centricity, and thinking like a mini CEO of your own area can encourage the kind of true ownership, domain knowledge, and innovation rather than turning your team into a reactive data treadmill.
2. Plan for discovery alongside delivery, and learn to ask the right questions
The hot trend in Product Management right now is the concept of continuous discovery, with Product Managers focussed simultaneously on delivering one piece of work while researching and lining up the next piece of work in a data-driven way. Can Data teams work in a similar way? Having team members with both the technical understanding of the product as well as the communication skills to talk to end users directly helps us to build in discovery for our work. This could take the form of conducting user interviews, knowing how to construct a useful A/B test, or using quantitative data to validate hypotheses.
Data teams could learn a lot from this process, for a long time Data teams were relegated to siloed IT departments, separate from conversations happening with Product or Engineering teams, they can also be at risk of turning into ad-hoc request factories, working reactively to answer questions from decision-makers in the rest of the business without looking ahead to the bigger picture.
The equivalent would be working reactively like a ‘feature factory’ for Product teams. We should try to understand the customers underlying needs and prioritise longer-term, more impactful fixes for them. The customer here could be internal stakeholders and business units, or the business’s actual end-user customers. This doesn’t mean ignoring and denying any ad hoc request that comes through to the Data team, but it does mean you should stay focused on the business needs and prioritise long-term work to that end.
So what does discovery in a Data team look like? Not too different from Product discovery it turns out. Talking to customers, striving to deeply understand their underlying needs, and looking at trends to form hypotheses before diving deeper into the data to validate or disprove them. There’s a lot that Data teams can steal from the Product handbook here to ensure they’re asking the right questions when speaking to customers and getting past easy answers and generalisations.
Teresa Torres has a great lesson (Page. 74) in her book about conducting insightful user interviews where she asked how someone typically purchases jeans, and received an answer “Fit is my number-one factor”, but when she then asked the interviewee to recall the last time they actually bought jeans they said ‘I bought them on Amazon…I didn’t know they would fit but they were a brand I liked and they were on sale”. The same skills can be employed by the Data team when talking to users about their needs, i.e rather than wanting to see ‘all my negative reviews’ the user really wants to understand recurring trends cropping up in negative reviews so they can address issues with their supplier, delivery company, or a particular branch.
3. Create frictionless ways to share knowledge, and cultivate a T-shaped team.
So how do you have enough bandwidth as a team to help the business with ad-hoc requests, discover the most impactful thing to work on next, and navigate the ever-growing and complex modern data tech stack?
Data teams headcount should be big enough that you can tackle these challenges, but also so that you can have multidisciplinary teams of ‘T shaped’ individuals. Data is such a multifaceted field, and new tools and technologies are constantly being released. It’s unreasonable to expect one team member to be an expert in data engineering, SQL databases, cloud warehousing, BI tools, expertly managing upwards/ across departments and presenting to senior leadership. But you could have team members who are great at one of those areas, with enough knowledge about the others to know where to call upon support from the rest of the team.
Knowledge consolidation. Analysts don’t have a ‘default’ place to store queries, do you save them within your data warehouse tagged up with keywords? Do you save commonly used queries into a view? Do you save down queries into a spreadsheet or personal notes tool? Or do you even fully integrate your analysts’ work with Git and push everything to a repo? These were all things suggested on Reddit where there has been a lot of discussion on the topic, suggesting there’s still not really a consensus about best practice here for analysts’ work:
At Feefo we’re maturing along this journey to better Data Analyst practices, we think the answer is cloud-based with Bigquery, DBT or Dataform, and documented well on Confluence. We think that the semantic layer for business intelligence and reporting should be as centralised as possible, with definitions done upstream in the data warehouse where possible, or defined as broadly in our BI tools in modules which can be reused across reports.
Whatever the answer is in your organisation, make sure it works for your team. A rigorous peer-reviewed process, where every change is run through Git, might be necessary for large teams working in highly regulated spaces working on client-facing reports, but would slow down a small team at a scale-up too much. Knowledge sharing and documentation are important, if you can make it as frictionless as possible, and have good habits in place to share with your team and find out what they’ve done, then you can save everyone time and headaches in repeating work.
Go beyond the stars with Feefo Reviews
Collecting reviews is just the beginning. We’re here to help you translate your customer feedback into actionable insights that will increase sales, boost traffic and improve your brand’s reputation. All Feefo Reviews are provided by verified buyers, helping you provide better experiences to your customers.
We’re hiring!
