Today I’m answering a question that was submitted to the show by listener Will Angel, who asks how he can prioritize and scale effective discovery throughout the data product development process. Throughout this episode, I explain why discovery work is a process that should be taking place throughout the lifecycle of a project, rather than a defined period at the start of the project. I also emphasize the value of understanding the benefit users will see from the product as the main goal, and how to streamline the effectiveness of the discovery process.

Highlights/ Skip to:

Brian introduces today’s topic, Discovery with Data Products, with a listener question (00:28)
Why Brian sees discovery work as something that is ongoing throughout the lifecycle of a project (01:53)
Brian tackles the first question of how to avoid getting killed by the process overhead of discovery and prioritization (03:38)
Brian discusses his take on the question, “What are the ultimate business and user benefits that the beneficiaries hope to get from the product?”(06:02)
The value Brian sees in stating anti-goals and anti-personas (07:47)
How creative work is valuable despite the discomfort of not being execution-oriented (09:35)
Why customer and stakeholder research activities need to be ongoing efforts (11:20)
The two modes of design that Brian uses and their distinct purposes (15:09)
Brian explains why a clear strategy is critical to proper prioritization (19:36)
Why doing a few things really well usually beats out delivering a bunch of features and products that don’t get used (23:24)
Brian on why saying “no” can be a gift when used correctly (27:18)
How you can join the Data Product Leadership Community for more dialog like this and how to submit your own questions to the show (32:25)

Quotes from Today’s Episode

“Discovery work, to me is something that largely happens up front at the beginning of a project, but it doesn’t end at the beginning of the project or product initiative, or whatever it is that you’re working on. Instead, I think discovery is a continual thing that’s going on all the time.” — Brian T. O’Neill (01:57)
“As tooling gets easier and easier and we need to stand up less infrastructure and basic pipelining in order to get from nothing to something, I think more of the work simply does become the discovery part of the work. And that is always going to feel somewhat inefficient because by definition it is.” — Brian T. O’Neill (04:48)
“Measuring [project management metrics] does not tell us whether or not the product is going to be valuable. It just tells us how fast are we writing the code and doing execution against something that may or may not actually have any value to the business at all.” — Brian T. O’Neill (07:33)
“How would you measure an improvement in the beneficiaries' lives? Because if you can improve their life in some way—and this often means me at work— the business value is likely to follow there.” — Brian T. O’Neill (18:42)
“Without a clear strategy, you’re not going to be able to do prioritization work efficiently because you don’t know what success looks like.” — Brian T. O’Neill (19:49)
“Doing a few things really well probably beats delivering a lot of stuff that doesn’t get used. There’s little point in a portfolio of data products that is really wide, but it’s very shallow in terms of value.” — Brian T. O’Neill (23:27)
“Anytime you’re going to be changing behavior or major workflows, the non-technical costs and work increase. And we have to figure out, ‘How are we going to market this and evangelize it and make people see the value of it?’ These types of behavior changes are really hard to implement and they need to be figured out during the design of the solution — not afterwards.” — Brian T. O’Neill (26:25)

Links

designingforanalytics.com/podcast: https://designingforanalytics.com/podcast
designingforanalytics.com/community: https://designingforanalytics.com/community

122 - Listener Questions Answered: Conducting Effective Discovery for Data Products with Brian T. O’Neill

Experiencing Data w/ Brian T. O’Neill