Category: Communication

Looking back: Five years on the Power BI CAT team

On By Matthew RocheIn Career, Communication, Community, Mental Health, Power BILeave a comment

Five year ago this week I joined the Power BI Customer Advisory Team, commonly known as the CAT team.[1]

I didn’t know it at the time, but in early 2018 I made the most positive change in my two-plus decades working in tech. The work since then has often been challenging and difficult, but I have never felt more satisfied or more appreciated[2] than I have on this team. As I’ve shared before, I’ve worked in tech for over 25 years, but my time on this team has been the best of the lot, by a wide margin.

Why has my time on the Power BI CAT team been so amazing? Looking back over the past five years I see five key factors to my success.

A team that needed the unique strengths I bring
In 2018 the Power BI CAT team already had some of the world’s leading experts on Power BI and the Microsoft business intelligence platform. Although I’d been a data professional in my pre-Microsoft career, I was feeling a little stale on the hands-on side of things, and was definitely feeling my share of impostor syndrome as I started my new role.

What I found was that my product management, data warehousing, ETL, and data governance experience filled gaps in the team’s existing strengths. From the beginning I was welcomed and empowered to make suggestions and implement solutions to problems that the team had not previously been able to solve. Given the prevalence of “not invented here syndrome” in some parts of Microsoft, this welcome wasn’t something I could take for granted.

A team with strengths that complement my weaknesses
When I joined the Power BI CAT team I was anything but a Power BI expert.[3] I honestly don’t know why they hired me, because even in retrospect I don’t believe I was a great fit for the team’s priorities when I joined. Although I did bring my own unique strengths, the fact that I didn’t know the difference between Live Connection and Direct Query[4] had the potential to introduce challenges.

The entire team had my back. When I reached out to request assistance or to ask “dumb” questions, everyone stepped up to help out. They valued me and my unique background and perspective. They knew that it was a smart investment to help me get over these “new to space” speed bumps, and to get up to speed on the ins and outs of Power BI. They were right, of course, but given the competitive nature of some past teams, this support also wasn’t something I could take for granted.

A manager who consistently provides opportunity, trust, and support
It’s taken a real effort to keep this post from becoming fawning Marc Reguera fan appreciation, but I cannot overstate the impact made by having a great manager.  I’ve worked for some wonderful and helpful managers over the years, but I have never before worked for anyone with Marc’s gift. He deeply understands people’s strengths – what people are good at and what gives them joy and energy. He then finds high-value problems for them to solve using their strengths, and which align with the evolving goals of the team.

Time and again Marc enabled me to try new things, and provided a safe space for me to work outside my comfort zone. Marc tirelessly promoted my work and the results I delivered, and he consistently pushed me to do more and to think bigger. Marc saw strengths in me that I didn’t recognize in myself, and he gave me the opportunities to exercise those strengths. I put in the hard work, but Marc provided the environment for my work to deliver the most impressive results.

A leader and sponsor who earns and maintains my trust
How has Power BI gone from a new offering in 2015 to being the clear leader in business intelligence for many years running? This is a bigger question than I can answer in a blog post, but a lot of the answer is understanding what customers need, and relentlessly delivering improvements based on this understanding.

When I joined the Power BI team in 2018 we already had well-established channels for listening to users, and a team culture that prioritized acting on user input. What we didn’t yet have was a similarly strong channel to understand what large enterprise customer organizations needed to drive broad adoption and manage a complex user base. Much of what I’ve done since then has been building this channel and expanding on its scope and impact… but what does this have to do with leadership I can trust?

When you’re building a new customer feedback channel, sometimes you’ll learn things that don’t align with the status quo. Sometimes the feedback you’re sharing contradicts current understanding and plans. In my experience this is one of the most telling tests of an organization’s culture. I’ve worked on teams where sharing truths that don’t fit leadership’s narrative was a career-limiting move, but this is not the case on the Power BI team.

Instead, I’ve found the strongest executive sponsorship I can imagine, with leaders who are eager to learn about customers’ lived realities, and who are willing to change plans and priorities based on what they learn. At every step of the way, Arun Ulag and his leadership team have championed my work, and empowered me to make a bigger difference than I could ever had made otherwise. Having an executive sponsor isn’t only important for building a data culture.

A global pandemic that normalized remote work
This factor doesn’t really fit in with the other four, but if I’m being honest with myself I need to include it. Over the past few years I’ve written and spoken publicly about some of my personal mental health challenges, and how I’ve worked to find and apply the unique strengths produced by these challenges.

One challenge I never truly appreciated until remote/virtual work became the norm was how much energy I spent every day on face-to-face social activities. Walking to a conference room, making social chit-chat as people filter into the room, maintaining appropriate eye contact and body language throughout the meeting, walking to the next conference room, and repeating this pattern all day long. I’m exhausted just typing it.[5]

In all seriousness, I probably expended 30-40% of my total daily budget of emotional and intellectual energy[6] on these non-value-add activities. When I was working in person I could get the job done, but when everyone was working remotely I could thrive. It was like someone had removed a great weight I had been carrying so long I didn’t know it was there, and once that weight was gone I had so much more of everything to give.

Patrick seems excited that I made it through my list of Power BI CAT success factors

This post has ended up very different than the post I intended to write when I sat down at the keyboard, but it’s apparently the post that needed to come out. Sometimes you need to share your gratitude for the people and circumstances that have made your life better in important ways, and an anniversary like this is one of those times.

Five years ago I felt like my career had stalled, and it wasn’t clear to me what I should do next. Since I can’t begin to claim that the past five years of growth and success were planned, the next best thing is sharing a personal retrospective. I hope you’ll be able to look at these factors for my successes and find their parallels in your own life. If you find yourself on a team like this, you may want to stay there. If you find yourself on a team that’s the opposite of the Power BI CAT team, you may want to start looking for your next opportunity.

Here’s to another glorious five years.

[1] Let’s get it out of the way early: Yes, the T in CAT stands for Team. No, I don’t care. Work with me here.

[2] Yes, this appreciation includes bigger numbers with dollar signs next to them, but that is definitely not the most important part of the story.

[3] Let’s be honest – compared to most of my CAT counterparts, I’m still not.

[4] Seriously.

[5] I suspect that readers who have autism spectrum behaviors will be nodding along at this point. I know that it’s not just me.

[6] Or spoons, as my teenager assures me the kids no longer say.

The Unplanned Career

On By Matthew RocheIn Career, Communication, Community, Diversity, Presentations, Video3 Comments

If you’ve worked in tech for 25 years, you’ve seen some stuff, and you’ve learned a lesson or two. On October 1st, I presented a new session at Data Saturday Atlanta, sharing the story of my unplanned career, and some of the lessons I’ve learned along the way. This was the first time I presented this very personal session; and I’m incredibly grateful for the full crowd that attended, and for their feedback after the session.

My primary goal for the session is to show that you don’t need a computer science degree to build a successful career in tech – and that our industry needs more people from more non-traditional backgrounds.

My secondary goal for the session is to share some of the sharp edges that are typically hidden when people talk about their careers. Everyone wants to share their highlights, but sharing your own pain and failures is harder. This is important, because too often we’re each comparing our own blooper reel against everyone else’s highlights… and nothing good comes from that.

The Data Saturday event was in-person only[1], but I’d had a bunch of people mention they wanted to attend, but couldn’t make it to Atlanta. So…I packed a camera and microphone and recorded the video on my own.

If you weren’t able to attend, please check out the recording, and please let me know what you think!

[1] Please understand that there is no criticism implied here. Organizing a hybrid event is significantly more difficult than organizing an in-person or online-only event, and focusing on in-person community produced wonderful results.

On building expertise

On By Matthew RocheIn Career, Communication1 Comment

How do you learn a new skill? How do you go from beginner to intermediate to expert… or at least from knowing very little to knowing enough that other people start to think of you as an expert?

This post describes the learning approach that has worked for me when gaining multiple skills, from cooking to sword fighting to communication. This approach may work for you or it may not… but I suspect that you’ll find something useful even if your learning style is different.

Purely decorative stock photo

When I’m building expertise[1] in a new area, there are typically five key activities that together help me make the learning progress I need. They don’t come in any particular order, and they all tend to be ongoing and overlapping activities, but in my experience they’re all present.

Practicing: Building expertise in an area or skill requires actively performing that skill. You can’t become great at something without doing that thing. Practice whenever you can, and look for opportunities to practice things that are outside your comfort zone. If your practice is always successful, this may be a sign that you’re not pushing your self enough, and your progress may be slower than it needs to be.

Studying: It’s rare to learn something completely new. Even if you’re trailblazing a brand new area of expertise, you probably get there by learning about related better-known areas, from existing experts. Read whatever you can, watch whatever you can, listen to whatever you can. Find content that matches the way you prefer to learn, and spend as much time as you can consuming that content. Make it part of your daily routine.

Observing: Find existing experts and watch them work. Where reading books or watching videos exposes you to the static aspect of expertise, being “expert adjacent” exposes you to the dynamic aspect. Mindfully observing how an expert approaches a problem, how they structure their work area, how they structure their day, will give you insights into how you can improve in these aspects.

Networking: Find ways to engage with a community of like-minded people who share your interest in your chosen area of expertise. Not only will these activities provide ongoing opportunities to learn from peers, the questions and problems that other community members share can serve as motivation to explore topics you may not have otherwise thought of independently.

Teaching: Teaching a skill to others forces you to think about that skill in ways that would probably not be needed if you were learning on your own. Teaching forces you to look at problems and concepts in ways that expose your biases and blind spots, and to ask (and answer) questions that would never have occurred to you on your own. Teaching a skill is in many ways the best way to deeply learn that skill.

Please note that these activities aren’t sequential, and no one activity is dependent on the others. In my experience, all five activities are ongoing and overlapping, and each one complements and enables the others.

What does this look like in practice?

I grew up in a family where cooking wasn’t really a thing[2], so I started learning to cook as an adult. Despite this, my cooking and baking have become something of a gold standard for friends and acquaintances. My learning experience looked something like this:

Studying: I bought and read dozens of cookbooks. If a topic or book looked interesting, I bought it and read it. I subscribed to many cooking magazines and read them when they arrived each month and watched pretty much every cooking show I could fit into my schedule.[3]

Practicing: I cooked and baked almost every day. I tried new ingredients and recipes and techniques that I discovered through my study, and figured out what worked, and what I needed to do to make it work for me. I organized fancy dinners for friends as a forcing function, and to keep myself from getting too lazy.

Observing: When I dined in restaurants[4], I would try to sit at the chef’s counter or somewhere I could get a good view of the kitchen, and would mindfully watch how the chef prepared and served each dish.

Networking: I made foodie friends. I talked about food and cooking with them, and occasionally cooked with them as well. Sometimes we’d go to cooking classes together. Sometimes we’d borrow equipment or cookbooks from each other. Eventually we’d invite each other over for dinner. Those were the days…

Teaching: I found opportunities to share what I’d learned with others. When someone would exclaim “Oh my goodness – how did you make this?!?”[5] I would do my best to tell them and show them. Sometimes this was a conversation, sometimes it was a 1:1 tutoring session, sometimes it was a small group class. Each time I learned something about the topic I was teaching because of the questions people asked.

Cooking is just one example, but I have similar experiences for every topic where people have asked me questions like “how do you know all this?” or “how did you get so good at this?” For every area where I have developed a reasonable degree of expertise, it’s because I have done some combination of these things, often over many years. I have every reason to believe that this approach will work for you as well.

Ok… that’s the blog post, but I’m not quite done. Back in January when I started writing this one, I started with the three “content seeds” you see below.

Data Chef

FFS

That’s right. Past Matthew left me the phrase “Data Chef,” the link to the PowerBI.tips video he’d just finished watching, and the phrase “FFS.” Three months later I have no idea how these relate to the topic of building expertise. If you can figure it out, please let me know.

[1] You may have noticed that I’m deliberately using the phrase “building expertise” instead of a different phrase like “learning” or “acquiring a new” skill. I’ve chosen this phrase because the approach described here isn’t what I do when I’m learning something casually – it’s what I’ve done when building a wide and deep level of knowledge and capability around a specific problem or solution domain.

[2] I love my mother dearly, but when I was a child she would cook broccoli by boiling it until it was grey, and you could eat it with a spoon. I never realized that food was more than fuel until I was in my 20s and met my future wife.

[3] Yes, I’m old, in case talking about magazines didn’t give it away. I assume the same pattern today would involve subscribing to blogs or other content sources. Also, can you remember back when you needed to watch TV shows when they were on, not when you wanted to watch them?

[4] Back in the day I used to travel for work a lot, so I ate in restaurants a lot. Sometimes I was on the road two or three weeks per month, which translated into a lot of restaurant dinners.

[5] If you’ve never met me in person and have never eaten the food I make and share, you might be surprised by how often this happens. If you know me personally, you probably won’t be surprised at all.

Thank you for sticking around – 200th post!

On By Matthew RocheIn Communication, Generic Blather, Mental HealthLeave a comment

I write this blog mainly for myself.

I write about topics that are of interest to me, mainly because they’re interesting to me but also because there doesn’t seem to be anyone in the Power BI community covering them. There are dozens of blogs and YouTube channels[1] covering topics like data visualization, data modeling, DAX, and Power Query – but I haven’t found any other source that covers the less-tangible side of being a data professional that is so compelling to me.

I write on my own chaotic schedule. Some months I might post every other day, or I might go weeks or months without posting anything[2]. These days I try to post once per week, but that’s definitely a stretch goal rather than something to which I will commit. Sometimes my creativity flows freely, but sometimes writing comes from the same budget of emotion and energy that I need for work and life… and blogging typically ends up near the bottom of my priority list.

And yet, here we are, 40 months and 200 blog posts later. In the past few weeks I’ve seen dozens of people reference Roche’s Maxim of Data Transformation, which started out as a tongue-in-cheek self-deprecating joke and then took on a life of its own. Earlier this week I spent time with another team at Microsoft that has organized been collectively reading and discussing my recent series on problems and solutions, and looking for ways to change how their team works to deliver greater impact. More and more often I talk with customers who mention how they’re using some information or advice from this blog… and it’s still weird every single time.

In these dark days it’s easy to feel isolated and alone. It’s easy to dismiss and downplay online interactions and social media as superficial or unimportant. It’s easy to feel like no one notices, like no one cares, and like nothing I’m doing really makes a difference[3].

So for this 200th post, I wanted to take the time to say thank you to everyone who has taken the time to let me know that I’m not alone, and that someone is listening. It makes a big difference to me, even if I don’t always know how to show it.

Let’s keep doing this. Together.

[1] I recently discovered that two of my co-workers have their own little YouTube channel. Who knew?

[2] Please don’t even get me started on how long it’s been since I posted a new video.

[3] This is a reminder that Talking About Mental Health is Important. I have good days and bad days. Although I make a real effort to downplay the bad and to amplify the good, there’s always a voice inside my head questioning and criticizing everything I do. It’s important to talk about mental health because this is a voice that many people have, and not everyone knows that it’s not just them. Not everyone knows that the voice is lying.

Risk Management Basics

On By Matthew RocheIn Career, Communication1 Comment

When I began my software career back in the 90s, one of the software-adjacent skills I discovered I needed was risk management. When you’re building anything non-trivial, it’s likely that something will go wrong. How do you find the right balance between analysis paralysis and blindly charging ahead? How do you know what deserves your attention today, and what can be safely put on the back burner and monitored as needed?

This is where risk management comes in.[1]

In this context, a risk is something that could possibly go wrong that would impact your work if it did go wrong. Risk management is the process of identifying risks, and deciding what do do about them.

One simple and lightweight approach for risk management[2] involves looking at two factors: risk likelihood, and risk impact.

Risk likelihood is just what it sounds like: how likely is the risk to occur. Once you’re aware that a risk exists, you can measure or estimate how likely that risk is to be realized. In many situations an educated guess is good enough. You don’t need to have a perfectly accurate number – you just need a number that no key stakeholders disagree with too much.[3] Rather than assigning a percentage value I prefer to use a simple 1-10 scale. This helps make it clear that it’s just an approximation, and can help prevent unproductive discussions about whether a given risk is 25% likely or 26% likely.

Risk impact is also what it sounds like: how bad would it be if the risk did occur? I also like to use a simple 1-10 scale for measuring risk impact, which is more obviously subjective than the risk likelihood. So long as everyone who needs to agree agrees that the impact a given risk is 3 or 4 or whatever, that’s what matters.

Once you have identified risks and assigned impact and likelihood values to each one, multiply them together to get a risk score from 1 to 100. Sort your list by this score and you have a prioritized starting point for risk mitigation.

Risk mitigation generally falls into one or more of these buckets:[4]

  1. Risk prevention – you take proactive steps to reduce the likelihood of the risk occurring.
  2. Risk preparation – you take proactive steps to plan for how you’ll respond to reduce the impact if the risk does occur.

For risks with high risk scores, you’ll probably want to do both – you’ll take steps to make the risk more likely to occur, and you’ll take steps to be ready in case it still does.

Here are a few examples of risks that might be identified when performing risk management for a BI project, along with examples of how each might be mitigated:

  • Risk: A database server might be unavailable due to hardware failure, thus interrupting business operations
    • Possible prevention: Purchase and configure server server hardware with redundant storage and other subsystems
    • Possible preparation: Define and test a business continuity and disaster recovery[5] plan for recovering the database server
  • Risk: You might not get permissions to access a data source in a timely manner
    • Possible prevention: Prioritize getting access to all required data sources before committing to the project
    • Possible preparation: Identify an executive sponsor and escalation path for situations where additional data source access is required
  • Risk: A key team member might leave the team or the company
    • Possible prevention: Work to keep the team member happy and engaged
    • Possible preparation: Cross-train other members of your team to minimize the impact if that key member moves on
  • Risk: Your data center might lose power for a week
    • Possible prevention: Locate the data center in a facility with redundant power and a reliable power grid
    • Possible preparation: Purchase and install generators and fuel reserves
  • Risk: Your data center location might be destroyed by a giant meteor
    • Possible prevention: Um… nothing leaps to mind for this one
    • Possible preparation: Again um, but maybe using a geo-distributed database like Azure Cosmos DB to ensure that the destruction of one data center doesn’t result in downtime or data loss?[6]

You get the idea. I’m not going to assign likelihood or impact values to these hypothetical risks, but you can see how some are more likely than others, and some have a higher potential impact.

Now let’s get back to a question posed at the top of the post: how do you find the right balance between analysis paralysis and blindly charging ahead?

Even in simple contexts, it’s not possible to eliminate risk. Insisting that a mitigation strategy needs to eliminate a risk and not only reduce it is ineffective and counterproductive. It’s not useful or rational to refuse to get in a car because of the statistical risk of getting injured or killed in a collision – instead we wear seat belts and drive safely to find a balance.

And this is kind of what inspired this post:

The “perfect or nothing” mindset isn’t effective or appropriate for the real world. Choosing to do nothing because there isn’t an available perfect solution that eliminates a risk is simply willful ignorance.

Most real-world problems don’t have perfect solutions because the real world is complex. Instead of looking for perfect solutions we look for solutions that provide the right tradeoff between cost[7] and benefit. We implement those pragmatic solutions and we keep our eyes open, both for changes to the risks we face and to the possibility of new mitigations we might consider.

Whether or not risk management is a formal part of your development processes, thinking about risks and how you will mitigate them will help you ensure you’re not taken by surprise as often when things go wrong… as they inevitably do…

[1] Yes, I’m linking to a Wikipedia article for a technical topic. It’s surprisingly useful for an introduction, and any search engine you choose can help you find lots of articles that are likely to be more targeted and useful if you have a specific scenario in mind.

[2] This is the only approach to risk management that will be shared in this article. If you want something more involved or specialized, you’ll need to look elsewhere… perhaps starting with the Wikipedia article shared earlier, and following the links that sound interesting.

[3] If you are in a situation where “good enough” isn’t good enough, you’ll probably want to read more than just this introductory blog post. Are you starting to see a trend in these footnotes?

[4] That Wikipedia article takes a slightly different approach (direct link to section) but there’s a lot of overlap as well. What I describe above as “risk prevention” aligns most with their “risk reduction” and my “risk preparation” aligns most with their “risk retention” even though they’re not exact matches.

[5] The other BCDR.

[6] I had originally included the “giant meteor strike” risk as an example of things you couldn’t effectively mitigate, but then I remembered how easy Cosmos DB makes it to implement global data distribution. This made me realize how the other technical risks are also largely mitigated by using a managed cloud service… and this in turn made me realize how long ago I learned about mitigating risks for data projects. Anyway, at that point I wasn’t going back to pick different examples…

[7] However you want to measure that cost – money, time, effort, or some other metric.

Communicating the voice of the customer

On By Matthew RocheIn Career, Communication, Patterns, Power BI1 Comment

My last post focused primarily on a problem that can arise when there’s a central team that sits between a team responsible for delivering solutions, and teams that have problems to be solved. The advice in that article is valuable[1], but it’s also very general. It also introduces a problem without providing any advice to solve the problem, beyond the not-very-helpful “keep an eye open for this problem behavior playing out.”

In this article I’m going to share some more specific advice to help overcome this challenge if you’re part of that central team. In this article I’m going to share my advice for communicating the voice of the customer.

In my experience, there are four key success factors for effectively communicating the voice of the customer when you’re not really the customer yourself.

Success Factor 1: Understand both the problem domain and the solution domain. Since this is what most of the last set of articles have covered already I don’t plan to re-cover this familiar ground, but it’s still important to mention. If you’re going to act as a bridge between two worlds, you need a meaningfully deep understanding of both.

Success Factor 2: Don’t have an agenda. More specifically, don’t have an agenda other than enabling the success of the the solution team and the customers you enable. In order to speak with the voice of the customer, the people you’re communicating with need to understand that you’re really speaking for the customer, and not for yourself. This doesn’t mean you can’t have an opinion – it means that you need to share the customer’s truth even when it might not support that opinion.

Success Factor 3: Tell a story. If you only share numbers and statistics, you’re leaving the interpretation of those numbers up to your audience, and that audience doesn’t have the context that you do. You’re from the team that understands the needs of the customer – and you’re the one that doesn’t have an agenda. These two facts make put you in an ideal position to tell a story that captures the customer’s scenarios, goals, priorities, and challenges and to ensure that it is received in a way that inspires your audience to action.

Success Factor 4: Include numbers and statistics. If you only tell a story, your audience will often assume that you’re telling your own story to forward your own agenda. Having data available to back up the story, including specific data to back up each key story point, helps overcome any skepticism and ensure that your story can be received, believed, and acted upon. The amount of data you need will depend on factors including how much trust you’ve already earned with your audience, and how well the actions you’re hoping to inspire align with their current goals.[2] 

Somewhere between telling a story and including data[3]  lies including the literal voice of the customer. When you’re meeting with customers, take thorough notes. When possible, record your customer conversations. Then, when preparing to tell your story, have verbatim customer quotes prepared to reinforce they key points of your story. This lets you say “here’s a customer problem I think you need to prioritize solving” and “here’s how these customers have independently described their experiences in their own words.” It’s easy for someone to say that you don’t really understand the customer’s problem, because you’re not really the customer. But it’s hard for someone say that the customer doesn’t understand their own problem.[4] Bringing the voice of the customer to a story is like having another five or six aces up your sleeve, but it’s not technically cheating.

These four behaviors have proven indispensable in my work on the Power BI CAT team, and I see them as success factors in many of the teams I’ve worked with that also operate between the problem domain and the solution domain. If you’re part of a center of excellence or another team that follows this pattern, look for opportunities to incorporate these behaviors into your work. They’ve served me very well, and I suspect they’ll do the same for you.

[1] In any event, I think it’s valuable, but my opinion here may not be coming from a position of neutral impartiality. You can reach your own conclusion.

[2] In my experience, earning and retaining the trust of your audience is a much more important factor than the story or the data. Right now the only advice I can think of here is “act consistently with integrity and transparency” but maybe I can find a blog post on this topic at some point.

[3]  I could call this “Success Factor 5” or even “Success Factor 3.5” but then I would need to go back up and edit the post introduction and I’m far too lazy for that sort of work.

[4] If you do find the solution team you work with saying that the customer’s problems aren’t real, this is a massive red flag that needs to be confronted. In my experience, if this attitude persists it’s time to start escalating or looking for a new team.

Measuring success and satisfaction

On By Matthew RocheIn Career, Communication, Patterns, Power BI1 Comment

Back in 2020 I wrote a post titled “Successfully measuring / measuring success” that talked about a problem without meaningfully describing it, because at the time I didn’t believe that the problem itself was particularly relevant. I was more interested in the pattern, which at the time I thought was “measuring the wrong thing.”

In recent weeks I’ve found myself sharing this post more frequently, and have come to believe that the underlying pattern is actually something else. Let’s look at my beautiful  2010-era chart one more time.

Before Power BI we had PowerPoint, but data is still Power

In this chart, both series represent NSAT[1] scores – basically they’re saying “this is how happy our customers are with a thing.” This sounds pretty simple, but the tricky part is in the details. Who are “our customers” and what is the “thing” they’re happy or unhappy with?

In the context of the chart above, the yellow series was “customer satisfaction with what they got.” The blue series was “customer satisfaction with what we shipped.” Implied in these descriptions and the difference in the two data series is that something happened between the time we shipped something and the time the customers got something, and that the thing that happened was key to the customers’ satisfaction.

Without going into too many details[3], we were shipping a product that was used by partners, and those partners used our product to deliver an experience to their customers. In the FY06 timeframe we started to change the product that we shipped, and the partners used the updated product to deliver an experience that met their customers’ needs. Now they just had to do a little more work to keep their customers happy. As the product changes continued, the partner load increased. They had to do more and more to fix what we gave them and to keep their customers happy. You can see the story play out in the blue series in the chart above.

We were looking at the yellow series, and falsely conflating “customer satisfaction” with “customer satisfaction in what we have shipped to partners.” We didn’t truly appreciate the importance of the party in the middle and their impact, and it ended up causing no end of problems. We were measuring customer satisfaction, but failing to appreciate what it was that customers were satisfied with – and how little that satisfaction related to what we had created.

And this is the pattern I’ve been seeing more often lately.

In my recent post on the role of the Power BI CAT team and how that role has parallels with Power BI centers of excellence, I described a success pattern where a central team serves as a value-add bridge between people with problems and people with solutions.

This pattern is one that I’ve seen provide significant value in multiple contexts… but it also introduces risk of measuring the wrong things, and overlooking real problems. This is a side-effect of the value that the central team provides. Customers are interacting with the work of the central team in addition to[4] the work of the solution team, and it may be difficult for them to understand what part of their experience is dependent on what factors.

In this situation there is a risk of the solution team overlooking or failing to appreciate and prioritize the problems their customers are experiencing. This is  a problem that the “curate” function in the diagram above is designed to mitigate, but the risk is real, and the mitigation takes ongoing effort.

When a member of a solution team works with customers directly, it’s hard to overlook their challenges and pain. When that solution team member hears about customer challenges from an interim party, the immediacy and impact can be lost. This effect is human nature, and the ongoing effort of the central team to curate customer feedback is vital to counteract it.[5]

As mentioned at the top of the article, I’ve seen this pattern more often recently, where a solution team is failing to recognize problems or opportunities because they’re looking at the wrong thing. They’re focused on what their end customer is saying, instead of looking at the bigger picture and the downstream value chain that includes them and their customers, but isn’t limited to these two parties. It’s easy to mistake “customer being happy” for “customer being happy with what we produce” if you’re not keeping an eye on the big picture.

It’s easy to mistake “customer being happy” for “customer being happy with what we produce” if you’re not keeping an eye on the big picture.

If you’re in a situation like this, whether you’re a member of a solution team, a member of a central team, or a member of a customer/consumer team, you’ll do well to keep an eye open for this problem behavior playing out.

[1] You can read this article if you’re curious about NSAT as a metric and what the numbers mean and were too lazy[2] to read the 2020 blog post I linked to above.

[2] I’m judging you, but not too harshly.

[3] I’m being deliberately vague here, trying to find a balance between establishing enough context to make a point and not sharing any decade-plus-old confidential information.

[4] Or in some circumstances, instead of.

[5] Please keep in mind that in most circumstances the central team is introduced when direct ongoing engagement between the solution team and customers can’t effectively scale. If you’re wondering why you’d want a central team in the first place, it may be because your current scenario doesn’t need it. If this is the case, please keep reading so you’ll be better prepared when your scenario gets larger or more complex and you need to start thinking about different solutions.

You are not the customer!

On By Matthew RocheIn Career, Communication, Cooking and Baking, Diversity1 Comment

Unless you’re building a solution for your exclusive personal use, you are not the customer. If you are not the customer, you need to invest in understanding the customer’s motivations, problems, and goals. The right solution for you may not be the right solution for someone else – even someone you may think of as being “like you” – for reasons that may not be apparent until you look more closely.[1]

This is another post looking at problem domains and solution domains, and it’s inspired by a recent non-technical conversation over brunch[2] with some foodie friends. My wife and I had gotten together with friends who love good food – people who we’ve had over for dinner many times over the years, and from whom we’re always delighted to receive dinner invitations. These are people who know how to cook, and who have invested in their kitchens over the years, so they’re well-equipped to cook what they want.

Imagine my surprise when a friend who has a fabulous combi oven[4] in her kitchen kept talking about how much she loved her new toaster oven that was also an air fryer. Or when another friend who is more than capable of making wonderful meals from scratch waxed poetic about how Thermomix now allows you to use community recipes from any region so she can now make that dumpling recipe she’s been looking at… and about how easy it is to make toast in her June smart oven because it recognizes that she’s put a slice of bread into it and knows how dark she likes her toast…

My initial reaction was to point out how all of these toys were unnecessary, because they already had the real tools they needed to do all these things and more[5], but as the conversation went on I realized I was in a tastier version of a very familiar conversation. This was a conversion about pro and self-service tools, and  about persona-appropriate experiences.

Have you ever been in a conversation when someone suggests that “all you need to do” to solve a problem is to use some code-first tool or service, when all you really want is something lightweight and simple? You probably don’t have an environment set up already, and even if you did the proposed tool don’t solve the problem in the way you want to solve it… even though the tool is capable of solving the problem.

Have you ever built a report that gives its users all the information they need to answer their questions, only to find that your target audience doesn’t like or use the report, and instead keep building their own workarounds?[6]

Have you ever found yourself on the other side of that scenario, where someone has given you a report with all of the numbers, but none of the answers?

These are all variations on the same theme: the importance of persona-appropriate experiences. Delivering capabilities is never enough – you need to deliver capabilities via an experience that works for the people who will use it.

Building an experience people want to use requires a meaningful understanding of those people. What are their backgrounds, their skills, their motivations, their priorities, their preferences… as well as the problems they need to solve. There are lots of ways to build this understanding, and they all start with your acknowledging that you are not the customer, and your willingness to spend time understanding the actual customer’s problems before you start trying to solve them.

I’m confident that a commercial restaurant kitchen would have all of the capabilities you would need to prepare breakfast – and more. I’m similarly confident that you would prefer something smaller, less complex, and more familiar – like your own home kitchen – and that if you were only given a commercial kitchen you would soon start looking for alternatives or workarounds that work better for you.

The next time you’re working to solve someone else’s problems – whether you’re building a BI solution or a software product or service – pause to ask yourself if you’re giving a commercial kitchen to a home cook. While you’re paused, also take a minute to remind yourself that you’re not the customer.

[1] The admonition “you are not the customer” was included in some of the first training materials I read when I became a program manager at Microsoft. It took me a few years to understand why this is so important, but now it’s something I think about almost every day.

[2] This was December 2021, our first restaurant meal with friends since December 2019, right before the omicron wave arrived in the Seattle area. Who knows when we’ll be able to dine out again…

[3] Kind of like me. I’ve been cooking and baking as a primary hobby for over 30 years, and have a wonderfully-equipped home kitchen. It doesn’t have every tool or toy I might want, but it has everything I need, and quite a few specialized tools I might not technically need but which make common-enough tasks easier and less time consuming.

[4] A combi oven is an oven that combines convection and steam, and which allows you to precisely control both the temperature and humidity while you’re baking.  This simplifies baking lots of things, from bread to cheesecake, but they tend to be very expensive. They’ve just recently moved from high-end professional kitchens into high-end home kitchens. I don’t own one, but I definitely want one.

[5] Thankfully I had my mask on as we were waiting for our food to arrive, which made it easier for me to keep my damned mouth shut for just one minute, which is not my forte.

[6] Yes, in Excel.

On joining the product team

On By Matthew RocheIn Career, Communication, Power BILeave a comment

Almost two years ago I published a blog post and video on Being a Program Manager at Microsoft, in which I shared some of my personal experience and advice based on my decade plus at Microsoft. I’ve received an incredible amount of feedback[1] on that 2020 post… and now it’s time for a follow-up.

My last few posts have focused on topics related to problem domains and solution domains, including how these concepts relate to Power BI and my work on the Power BI CAT team. What about for people who are currently Power BI or data professionals who might be thinking about changing careers to join the product team? These are pretty abstract concepts – what do they mean to you?

This conversation calls for an analogy, and since I don’t know anything about driving race cars or automotive mechanics, I’m going to use an analogy about race car driving and mechanics[2].

As a Power BI or data professional, you’re like a race car driver.

Your job is to win races. You need to respond to the rapidly-changing demands of the moment to deliver victory for your team[3]. You’re in the spotlight,

As a race car driver, there are two main factors that contribute to your wins and losses:

  1. Your skills as a driver
  2. The performance of the car you’re driving

To win a race, you need to know how to get the most from your car, and make it perform for the conditions on the track, and within the rules of the race.

As a program manager on the product team, you’re like a mechanical engineer responsible for designing, refining and tuning the race car engine.

Your job is to deliver an engine that performs the way your drivers need it to perform, as part of the larger system of the race car as a whole. The race car needs to have the capabilities and characteristics that enable drivers to win races, and the engine is a key part of that… as is the steering, suspension, and whatever other subsystems make up a race car.

Your job is not to drive the race car, and you can excel at your job without ever having won (or driven in) a race.

Re-read that last sentence and pause to let it sink in. If you’re thinking about joining the product team that makes your favorite software tool or platform, you’re also thinking about giving up the day to day job of using that software.

Even more than this, the skills that you’ve built as a race car driver – or as a data professional – are no longer directly relevant. Please don’t get me wrong – if you’ve spent years implementing data and BI solutions this will serve you very well as a program manager on a product team building data and BI tools. But that experience will be valuable in the way that having been a race car driver could be valuable in informing the design and optimization of race car engines.

Having an intimate understanding of – and deep personal experience with – the problem domain can help inform your work in building and improving the solution domain… but your job is no longer what it used to be. You need to learn and master new skills to be successful in the new role, and that means no longer being the expert on the problem domain like you used to be.[4]

This can be a difficult realization and wake-up call for people making a career change, because it means giving up – or at least moving away from – the work they know and love. It can also mean discovering new work and new challenges that they may love even more… but change is hard at the best of times, and it doesn’t always come at the best of times.

I hope this blog post and analogy[5] doesn’t scare anyone off. Working on a product team can be incredibly fun and rewarding – it’s just different from working with the product that the team builds and ships. It’s another situation where the problem domain and solution domain differ in ways that aren’t always obvious until you’ve had a chance to work in both worlds.

Joining the product team after working as a data professional changes your relationship with the product. What used to be your solution domain, where you were the expert responsible for understanding the product and delivering solutions based on its capabilities, now becomes your problem domain. You’re responsible for increasing its capabilities to make it more useful for others to build their solutions, but you’re no longer building those solutions yourself.

 

[1] I continue to believe that this video may have been the best thing I did in 2020. I’ve had dozens of conversations with people around the world who want to be program managers or product manager – at Microsoft or other tech companies, and some of them have already achieved their goal. This feels like I’m actually making a difference in the world when the world is doing its best to make me feel powerless, and that’s like a gift that keeps on giving. I may not be the only one who feels this way. While this post was in draft form waiting to be published, my friend Davide created a website to showcase this video – he even transcribed it! You can check it out here: http://aka.ms/being-a-ms-pm.

[2] Because of course I am. This is an analogy that presented itself to me in one of those conversations mentioned just one footnote earlier, and which works as well as any I’ve found so far.

[3] There are teams in racing, right?

[4] This is where it’s useful to have a person or team responsible for bridging these two worlds.

[5] Another possibly less scary analogy could have involved someone who loves eating becoming a chef in a professional kitchen. Since I know enough about these worlds to be dangerous, I didn’t trust myself to use this analogy without ratholing on lots of details no one but me would care about. Maybe I’ll try that one again when I have more time to think about it…

Simplifying the solution domain

On By Matthew RocheIn Communication, Community, Data Culture, Metaphors, Power BILeave a comment

My recent posts have focused on the importance of understanding both the problem domain and solution domain in which you’re working, the value of operating in both the problem domain and the solution domain, and some specific resources and techniques for solution-oriented practitioners to increase their fluency in understanding the problem domain. A lot of the message I’ve been trying to get across in these posts can be summarized as “the problem domain is really important, and we need to get better at appreciating and understanding the problems we work to solve.”

This message is predicated on two basic assumptions:

  1. You, the reader, are a technical professional of some sort[1], and you need to deliver technical solutions to people with problems
  2. The people who have problems can’t solve those problems on their own

Let’s look more closely at that second assumption, because it’s becoming increasingly less valid, and less true. And let’s look at it through the lens of… furniture.

Close your eyes and imagine for a moment that you need a table. Let’s say you need a bedside table. What do you do?

As you read through this list you were probably evaluating each option against your own requirements and preferences. Odds are you’ve chosen one or more options at some point in your life. Odds are the criteria you used to decide which options are viable or preferable have changed as your circumstances, skills, and budget have changed.

I couldn’t find Ikea instructions for a bedside table, but honestly I didn’t try very hard

Of course, the decision doesn’t need to be about a bedside table. It could be about a dining room table, or a bed, or a full set of kitchen cabinets. Each option will have different but similar choices, and you’ll likely use different criteria to evaluate and select the choice that’s right for you.

This is also true if the choice is about business intelligence solutions, which may not technically be considered furniture[2]. Close your eyes once more and imagine for a moment that you need a report, which may or may not include a table.  What do you do?

  • You could use an existing report
  • You could start with an existing report and customize it
  • You could start with an existing dataset use it to build a new report
  • You could start with an existing dataset, customize it using a composite model, and use it to build a new report
  • You could work with a center of excellence or BI team to create a dataset, customize a dataset, create a report, or customize a report to meet your needs
  • You could locate or create data sources and build a custom BI solution end-to-end, maybe getting some help along the way if you don’t already have the tools and expertise required for the project

The parallels are easy to see, and they hold up surprisingly well to closer inspection. Just as ready-to-build options make it possible for someone with no woodworking or cabinetry skills[3] to self-serve their own furniture, DIY BI tools[4] like Power BI make it increasingly easy for someone with no data preparation or data modeling skills to build their own BI solutions.

To step away from the furniture analogy, tools like Power BI simplify the solution domain and make it easy for problem domain experts to solve their own problems without needing to become true experts in the solution domain.

Any finance or supply chain professional can use Power BI Desktop to build reports that do what they need, without needing to ask for help. Their reports may not be the most beautiful or best optimized[5],  but maybe they don’t need to be. Maybe “good enough” is actually good enough. Just as it might make more sense to buy a $40 Ikea bedside table instead of spending hundreds or thousands of dollars on something fancier, it might make sense to stack a few milk cartons on top of each other and call it good, at least until you can save up for something better[6]. There is no one size that fits all.

If you are a Power BI professional, it may be difficult to think of the “boards and cinderblocks bookshelf” approach as acceptable, but in most circumstances it’s not up to you to decide. The tools for DIY BI are widely and freely available, and people will use them if they present the most attractive and accessible option to solve their problems. You can’t stop them from building DIY solutions, but you can help them build better ones.

This is where having an effective and engaged center of excellence comes in. Whether you think in terms of problem and solution domains, or in terms of enabling DIY through readily available tools and guidance[7], you can help make “good enough” better by meeting your problem domain experts where they are. They have the tools they need to get started building their own solutions, but they probably need your expertise and assistance to achieve their full potential.

You should help them.

[1] Probably a Power BI practitioner, but who knows?

[2] I have repeatedly seen Power BI referred to as a “platform” which is basically the same thing as a table, so I’m going to withhold judgment on this one.

[3] Someone like me! I married a carpenter and have never found the motivation to develop these skills myself.

[4] DIY BI has a ring to it that SSBI doesn’t have. Why don’t we start using DIY BI instead. DBIY? D(B)IY? D(BI)Y? Hmmm…

[5] They may indeed be the Power BI versions of my DIY home improvement projects.

[6] Please raise your hand if you too had bookshelves made of random boards and cinderblocks when you were in college, and were also happy with the results.

[7] This is the second place in this post where I’ve shared a link to this Marketplace story. If you run a Power BI COE for your organization, do yourself a favor and listen to the story – it will inspire you to think about your COE in different ways.