If you’re reading a Power BI-focused blog[1] you’re probably someone who builds solutions. As a BI and data practitioner, you may build reports, datasets, dataflows, databases, or any number of technical artifacts that together represent a solution domain. You have a toolset at your disposal, and you invest your valuable time and energy into refining the skills needed to use those tools.
But what if you’re holding the right tools, while using them to implement the wrong solution? This could happen if you’re holding a hammer and building a chair when what’s really needed is a table, but it could also happen if you’re using Power BI to build a solution that deliver what its users need to make their jobs easier.
Action doesn’t equate with value, and time spent solving a problem you don’t meaningfully understand is often time wasted. So how do you, as a Power BI author, meaningfully understand problems in domains like finance, supply chain, HR, or patient care if you lack personal experience in those domains?
Asking good questions is a great start.
If you want to deliver a fix for a problem someone has reported, asking targeted closed-ended questions to narrow down the scope of the problem can be valuable. What is the error message, when did it start happening, what are the steps to reproduce the problem, does it happen all the time, does it happen on other computers, does it happen for other users… that sort of thing.
This type of question is often great if you need to deliver a fix, but what about when you need to deliver a product? What if you need to deliver a Power BI app that will help a group of people be more productive completing a complex set busines processes?[2]
Asking good questions is still a great start, but you need to ask different questions.
While focused, detailed, targeted questions can be very effective for scoping down a tactical problem to deliver a fix, they tend to not be great for understanding a broader problem domain. Ask closed-ended questions when you want to deliver a fix; ask open-ended questions when you want to understand the problem.
What does your current process look like, where are the places where you struggle, what are the triggers that would cause you to begin the process, why do you do it that way, who works with the output you produce, and what do they do with it… that sort of thing.
If you’re used to asking the first sort of question, the second sort may not be obviously useful. What would you do with these answers? How can you act on them?
The short answer is “it’s complicated” and the longer answer is “read The Customer-Driven Playbook by Travis Lowdermilk and Jessica Rich.”
This amazing book presents a “hypothesis progression framework” that includes tools for learning about customers and their problems before building a solution to those problems. This framework is broken down into four phases:
At the risk of oversimplifying 250 pages of expert guidance, the framework looks something like this:
- Who is my customer, what does she do, what motivates her, and what problems does she have?
- What is the scope of my customer’s problem, how does it affect her, and what is its impact?
- How well the concept you’ve come up with to solve to solve the problem actually fit with your customer’s needs, does its value proposition motivate her to learn more, and how will the limitations of the concept reduce its value?
- How well does the product or feature you’ve built to implement the validated concept actually solve the customer’s problem it was built to solve?
Each of these phases is presented with best practices for asking the right types of questions of the right people in the right way, with guidance for formulating the right questions, asking them in structured experiments so you can better trust the answers you get, and then making sense of what you’ve heard. That sensemaking process is where your deep expertise in the solution domain will help you the most, as you look closely and mindfully at what you you’ve heard and decide how to act… but most of the process is about learning the details and nuances of the problem, not about solving it.
Albert Einstein once said “If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” Think about that.
In my experience most technical professionals don’t value and appreciate the importance of the problem domain, and instead focus their energies on solutions to problems they don’t fully understand. We can do better, as individuals and as teams and as an industry, and The Customer-Driven Playbook is an excellent place to start. I hope you’ll read it, and I hope you’ll let me know how it changes the way you approach problems and solutions.
[1] Does BI Polar count as a Power BI-focused blog? These days it feels like I’m posting more about ancillary topics and less about Power BI itself.
[2] For that matter, what if you need to deliver a complex commercial software product like Power BI?
BI Polar 
Pingback: Simplifying the solution domain – BI Polar
As always great article & totally agree. Its easy to create a forest of Power BI in which people get lost and have nothing to eat. Carefully planning & plant a few trees with fruit people want and will eat is more difficult. At the end everything comes done to close cross functional collaboration.
In all honesty i see more challenges in improving the data governance and getting clean data out of processes which neatly integrates across processes. Blood, sweat, ownership & discipline is what is needed for that. But people often do not or are willing to spend time on it while not appreciating that E2E time would be saved & enabling more focus on value and risk. Everyone knows it – still a hard nut to crack. Any tips how to effectively communicate this back to customers?
LikeLike
“Any tips how to effectively communicate this back to customers?”
Consistently, repeatedly, and patiently. š
Since we’re dealing with people here the real answer is complicated, but the main tip is that you need to meet people where they are. You can’t say “stop doing your job and let me tell you about how you can spend a lot more time to deliver a lot of stuff you don’t really care about.” Instead, you need to help them see – REALLY see and believe – how doing things “the right way” will be valuable to them.
This is a key responsibility of a center of excellence. The COE team should make available a wide range of resources that make it as easy as possible for each user to learn and grow on their own terms, when they’re ready. This is typically a mix of on-demand resources like links, videos, and documentation, plus higher-touch synchronous activities like office hours or 1:1 mentoring and co-development.
By having these resources available and well-communicated to the community of practice, the COE can put in place the foundation for a data culture where learning and growth is the norm. It takes time, but in my mind this is the key to success.
As you think about this, please keep in mind that your customers won’t “bite” until changing their way of working is easier than not changing is. Good luck!
LikeLike
Pingback: You are not the customer! – BI Polar