Chatting With: Elaine McVey

Elaine’s Twitter profile picture

I wasn’t aware of Elaine’s work before the conference, but she gave an amazing talk titled “Agile Data Science” (link to her slides here) which resonated a lot with me and my colleagues. I chatted with her after her presentation, and I think it’s worth sharing both what we talked about and what her presentation covered — I know I got a ton out of it.

Some quick context setting: at RV, we tend to think that there is a lot of overlap between the skills of effective data scientists and effective product managers. For an “oldie, but a goodie” take on this, see Ben Horowitz’s “Good Product Manager, Bad Product Manager” — something that rung so true to me the first time I read it that I printed it out, highlighted it, and posted it in my room at home 😅.

Elaine gave an updated take on this overlap: she identified three ways that the data science process could benefit from stealing from some ideas from our friendly neighborhood PMs:

1. Write user stories

As data scientists, we have to be good at the cognitive dissonance that is viewing a project from an implementer’s perspective as well as from an end-user’s perspective (what’s the impact or the “why”). For me, user stories are a really effective way of forcing myself to describe the end result in terms of the impact it will have — “as an X, I want to do Y, so that I can Z”, where Z is the “impact” or “why” part of the equation. This keeps me focused on the end result and keeps me from getting bogged down in the “how”.

An example of rephrasing a project in terms of a user story from Elaine’s slides

2. Vertical Slicing

Vertical slicing, as Elaine describes it, is the idea that when starting a new project you should try to complete a quick and basic pass through all stages of that project to validate your approach and ensure that you’re pointed at the right outcome. The visual analogy is that you should slice a layer cake thinly at first to get a taste of all the layers before deciding whether or not you actually like the cake.

The way that my team hears me describe this practice is “get to the end to see what it looks like”. The “Minimum Viable Product” concept has this same goal in mind: taking a “quick and dirty” approach to a project the first time around is often a better and more efficient approach than “let me get this 100% right the first time through”.

3. Stakeholder Reviews

At Red Ventures, our business teams are separated by vertical (Home Services, Financial Services) and within each vertical they are further split by business partnership. As data scientists, our projects are joint efforts with the business teams where we are contributing to their key strategic objectives (onsite experience personalization, increasing digital transactions, etc) by helping them leverage more data to make better decisions.

Since we’re a centralized data science team, we take it upon ourselves to make sure that our main stakeholders (the business teams) are kept up to date with what we’re working on and how it aligns with their business strategy. For this purpose, Elaine suggested having regular (monthly) Stakeholder Reviews like some Product Managers do to keep the business teams updated and aligned with what the technology teams are up to.

She suggested answering questions like these ones at these reviews:

What did we do last month?

What do we plan to do next month? And why?

What are risks that may mean we don’t accomplish our goal?

What is the primary impact of the work we will or have done?

I love this idea, and we’re working on what our first dedicated Stakeholder Review should look like from an audience and content perspective.