How to Deliver Business Impact with Data
Tips for Developing Data Products
Post was originally published in January 2020 and has been updated in May, June, and October 2020, April, November and December 2021, January + November 2022 for relevance.
After developing data products for 10 years, I learned to ask all of these questions during the kick-off(s) the hard way. Data Analytics/Business Intelligence/Data Science/Analytics/Machine Learning should not be done in a vacuum or for the sake of doing BI/ML/AI. Instead, it should aim to be part of a data product deliverable that helps bring value back to the customers and the business.
What is a data product?
A product is something that's "offered to a market to solve a problem, or to satisfy a want or need" [Koombea].
A data product solves your customer(s) pain-point by leveraging data.
Put another way, data products are those the provide actionable recommendations to our stakeholders that save/make the company money. (Here's my talk on how to uncover this.)
What does a data product deliverable look like?
Ahead of any development, it helps to align with your stakeholder by understanding about the business and the stakeholder/customer ask, to help you understand the impact of the work, to scope out and discuss what it will take to (iteratively) deliver a data product.
Here are the questions I ask in an intake meeting (and follow-up) meetings to help me and my potential collaborators get there.
Context, e.g. "Why?"
How does the company make money? What is its core mission?
What is your customer really after? e.g. What is the underlying goal (vs. an ask to do X approach)? What is their pain point? What's at the core of this ask?
Why is this initiative important now -- above all other priorities?
What is the business question?
e.g. Suppose your client/company spent $200K on data + salary. How can the data product you create have a business impact, e.g. generate (or save) $300K for the business? $400K+?
e.g. Alternatively, if you don't do this, what will be happen to the business then? What will happen if this report (for example) no longer runs?
One way to evaluate if you know the business question is to see if you can fill-in the blanks:
We want to see <behavior change> so that <impact> [1], to help you answer why the company is interested in the analyses now.
Has this question been answered before? If so, what was done? what didn't work? what are some lessons learned? What would they like to do differently? What is the business logic we should include?
End Goal
Who is the stakeholder that will use the deliverable?
To help us deliver actionable next steps: How will the results/deliverable be used immediately (or in the short term) by the stakeholder, to answer the business question?
How will the results/deliverable help the company in the long term to improve its product market fit -- and have happier customers?
By answering these questions, you'll be able to form a "user story":
My (stakeholder) wants to do (task) so that they get (desired result)
Collaboration
Does the stakeholder have any ideas/directions they'd like you to explore? (e.g. If the deliverable is a visual, did they have a sample visual/infographic in mind?)
Are we on the same page about what the scoped-down, POC deliverable will look like?
Technical Requirements
What will it take to get the deliverable into production?
What's the rollout strategy to customers?
What does the input and output format look like?
Next Steps
Does the deliverable have an associated KPI or acceptance criteria? Any intermediate deliverables?
What's the deadline, budget (if applicable), and best time for recurring check-ins?
Are we on the same page about next steps?
Parting Advice
Start with descriptive analyses; only when you understand what happened in the past, should you move onto predictive analyses to forecast what may happen in the future.
It's usually hard to estimate how long something may take when it comes data (esp. sight unseen). I recommend time-boxing the work instead, which also fits better into the Agile process. Katie Bauer calls the time-boxed analysis the Minimum Viable Insight/Analysis [14 min], which is then presented to the stakeholder(s), to discuss next steps.
Esther Schindler shares this advice: "Never work on stuff you don’t understand enough to explain to others and explain its value" as advice for women around self-promotion; it holds true for collaborating and developing data products.
Do you need an expert to guide you on your next data product, to improve your product market fit and have happier customers? Please reach out.
Keywords: Data products, business impact and value
You may also like:
Talk: Tell me what you want, what you really really want: How to identify the real business question
Blog post version for the "Locally Optimistic" blog
Dear Advisor: I’d like to make data-driven decisions. Where do I start?
Talk: Top 5 Reasons Why your Data Science Project Didn't Make it and How to Get It Right the First Time
Column: Your Business Has Lots of Ideas on What To Work On. Here’s How To Decide on What’s Next
Dear Advisor: How do I do Product-Led-Growth (PLG) as my Go-to-Market (GTM) strategy for Product market fit (PMF)?
More about Stakeholder Communication
ASCCR Frame for Learning Essential Collaboration Skills, by Eric Vance and Heather Smith
Asking Great Questions, by Eric A. Vance and Heather S. Smith
Ask HN: How to effectively communicate results of my work to non-engineers?
More about Developing Data Products
Scaling Data: Data Informed to Data Driven to Data Led, by Crystal Widjaja -- on who should be the first hire, how to align the team and how to scale it
Run Your Data Team Like A Product Team, by Emilie Schario and Taylor A. Murphy, PhD
Making Data relevant to Businesses, by Ravin Kumar (PyData 2019)
What's Data Science Reporting, by Amy Tzu-Yu Chen (PyData 2019)
Why You're Not Getting Value from your Data Science (Harvard Business Review)
Why organizations fail to make data-driven decisions, by George Xing
Project Charter, by Azure
What is "data as a product" really?, by Parker Rogers
The Eternal Suffering of Data Practitioners: Part 1 and how to wear the Product hat as a Data Team of size 1, by Pedram Navid
Don't Confuse Motion with Progress, by Sean Byrnes via The Analytics Engineering Roundup
More about Data Project Management
Linear and Circular Projects in Data, Parts 1 and 2, by Alexis Johnson-Gresham and Caitlin Moorman
Why your organization may need a Data Product Manager, by Seth Rosen
Your Data PM is not a panacea, by The Analytics Engineering Roundup
How to develop product sense, by Lenny Rachitsky and Jules Walter
The Comprehensive Guide to Customer Discovery Interviews, by Dianna Lesage
On owning a software problem, by Vicky Boykis
Bring Back Scenario Analysis!: Why leaving behind spreadsheets made us forget how to ask "what if" questions, by Tristan Handy
The Why Conversation, by Jonathan Stark
Graphic for quantifying business impact for Marketing, from article "How to Get Your Marketing Team to Drive More Impact" by Emily Kramer, for Lenny's Newsletter
References
Image with fill-in-the-blanks from DataKind's advice for identifying Data-Serviceable Problem