Most of what I do in my day job involves listening.

Specifically, I spend a lot of time listening to people who use Power BI^[1] talk about why they use it, how they use it, and where they struggle along the way. I ask a few questions to get them started, and then I ask a few follow-up questions to help them along as they tell their story – but mainly I listen.

I listen, and then I use what I hear to help make Power BI a better tool for these people and their organizations’ needs.

I listen for patterns and trends, and for a signal to emerge from the noise of hundreds of conversations. When it does, I make sure that the right decision-makers and leaders hear it and understand it, so they can take it into account as they decide where to invest and how to prioritize those investments.^[2]

I listen with an informed ear. I spent almost 15 years building software and data solutions, so I understand a lot of the technical and organizational challenges these people face. I spent the next decade or so building data products and services as a program manager at Microsoft, so I understand a lot of the challenges involved in prioritizing and building product features. And perhaps most importantly, I am genuinely interested in listening to and learning from the people with whom I talk. I truly want to hear their stories.

Of course there’s only one of me, and I can’t spend my whole workday listening to people tell their stories… so I’ve helped build a team to listen^[3], and it’s making a difference. The next time you see an announcement about new capabilities in Power BI that will improve the lives of large enterprise customers, odds are this team had a hand in making those capabilities a reality.

Why am I telling you all this? This is my personal blog, and I’m not looking for a job, so who cares, right?

You care.

You care because this type of listening is a thing that you can do to make better software. You can do this whether you’re building commercial software or if you’re part of a BI team that needs to build solutions for larger user populations.^[4]

You care because letting the people who use your software – or the people you want to use your software – talk about what what’s important to them… will let you know what’s important to them. And if you’re really listening, you can use what you learn to make better decisions and deliver better products and features.

If you’re genuinely interested in the people who use the software you build, you should consider giving this approach a try.

^[1] These people tend to be the business and IT owners of Power BI in large enterprise organizations, but they can be just about anyone involved in implementing, adopting, using, or supporting Power BI.

^[2] If you’re interested in learning more about the Power BI product team’s planning process, I cannot recommend highly enough this 2019 presentation from Will Thompson.

^[3] As part of building that team we all read and/or re-read Lean Customer Development by Cindy Alvarez. If you have not yet read this awesome book, there’s no time like the present.

^[4] I honestly don’t know if this type of rigor is appropriate at a smaller scale, because I haven’t done it and haven’t personally seen it done. I suspect that it would be very valuable, but also suspect that there may be lighter-weight options that would provide a better return on investment.