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