Chalk Talk: Mapping the Why, Assumptions, and Solutions

Video and Transcript

One of the central roles of a product manager is to drive shared understanding. With shared understanding, a team is more effective, resilient, and creative. Alignment without shared understanding is temporary and short-lived. The best teams find a way to break down complexity and speak the same language. They row relentlessly in the right direction, even when that point on the horizon shifts.

In my chalk talk, I share a framework for building shared understanding with your team and other stakeholders. You can either watch my chalk talk or read the transcript below. Enjoy!

Transcript …

The Problem: Context is Always Changing

We all know that one of the big challenges of product management is sharing context. You don’t only have to share it with your team, or across your team, but you also have to share it across the entire organization. You’re basically sharing context all the time. And the challenge is that the context is always changing. The context of yesterday is not the context of today.

In my chalk talk, I’m going to frame that problem, and give you some strategies to make sure that the context you share is the most current context, and is deep enough for your teams to be able to take action.

Direction vs. Destination

Think about some of the words that we use, and think about how we communicate strategy as product managers. Let’s say you’ve got a horizon, and you’re in a boat. Now for a lot of knowledge work, you’re just generally sailing west, like Columbus. You’re sailing to a point on the horizon. You’re going somewhere. That’s a direction.

Now think about how people frequently state goals. They state a series of unique points along a line, that you need to be able to hit in order to get to a specific endpoint. And that’s what we call a destination. Think about those two words: One is direction, and that’s a lot more applicable to knowledge work, and the other is a very linear, deterministic goal that you’re trying to hit. Direction versus destination.

Let’s take a real-life situation: You have a friend and they say, “I want to lose five pounds.” You have another friend that says, “I want to eat healthy.” Those are two different perspectives. One is a destination-based perspective (“I want to lose five pounds”). And the other one is a more systems-based perspective (“I want to eat healthy”).

Now, we all know there are many unhealthy ways that you could lose five pounds. The idea is by eating healthy, one of the things we might notice is losing weight. But we might also live longer, we might be happier, and we might be less stressed. So that’s more of a systems approach.

Now, the third example is this idea of cascading goals. Dividing one goal into a sub-goal, into many sub-sub-goals, into many sub-sub-sub-goals, into sub-sub-sub-sub-sub-goals. We see this in practices like OKRs, or management by objectives.

The idea is that everything cascades up and connects with a higher level goal. Teams are told to focus on their individual goal. Now, that might be good in some situations. But in a lot of the environments that we’re working in, the teams that are on the front lines actually need to be able to see the big picture. They need to do this so that they can take course corrections as they’re moving along. Think about a person who’s working right there [points at lower level goal]. If they know that’s the goal and they see the context changing, what if they could circumvent all these steps and just achieve that goal in another way? What if the context changes for this goal, or if they could take a shortcut?

I tried to lay these out here as we’re understanding the problem. You have destinations versus directions. You have goals versus systems. And then you have the need for teams to be able to see the big picture in knowledge work to make sure that they can take the course corrections necessary to move in the right direction.

The Reality: Context is a Moving Target

But the reality in product management is, we’ll do a kickoff, and at that point, shared understanding is at an all-time high. Or we think it’s at a high. But over time, we’re always fighting the downward pressure on shared understanding.

The context is changing. And at the same time, we’re learning, and we’re improving our shared understanding. We might be iterating and getting more shared understanding. It’s always this push and pull on what we’re learning and the degree to which our learning is depreciating that really dictates the situation.

That’s one problem. We’re always losing shared understanding and gaining shared understanding. And even when we have a new, better, shared understanding, we still have trouble communicating that.

A second reality is that different people on your team have different needs. You might have someone who is more junior, who’s new at this, who may just not care all that much about the big picture, and they’re looking down here [draws line downward]. They’re looking for things right in front of them: “Can you tell me what needs to be done next, please, so that I can do my job?”

Meanwhile, you have the people who are asking why all the time and the people who need to understand the big picture. And these sometimes are your most valuable employees. They want to understand the big picture, how things are fitting together, and how things relate to each other. You’ve got both of these personalities on your teams.

And the third part of the reality is, the problem-solution dichotomy that everyone talks about, where we’ll specify the problem and you specify the solution, is a lot more intricate than that. Because every problem has a solution to some higher-level problem. Even something like hitting quarterly goals, or a new round of funding, that’s a solution towards maybe reaching a higher-level goal for your company. When people are talking about problems and solutions, it’s a lot more complicated than that.

Talk to an engineer for example, even the slightest interface change is a problem to solve. You have nested problems and solutions and people with different needs. And you have the fact that shared understanding is always in a dynamic state, and you’re always having to communicate it.

The Solution: Mapping Context

I’ve found the following technique to be an extremely helpful tool to help you get your own head straight about things, and for communicating context to your team. I also recommend doing this exercise with your team. It’s a great way to develop a shared vocabulary.

And this is an issue with roadmaps as well; it’s really about having a conversation. It’s really about sharing the same vocabulary and having the conversation that yields the best results. Let me show you this method for mind mapping.

1. A Fuzzy Goal

You start with some fuzzy goal. And fuzzy goals like we’re talking about aren’t the most prescriptive goals, and they’re not the big pie-in-the-sky goals. They’re something that is actionable and directional.

2. Because, We Know, And We Assume

Now, everyone wants to know the why. Why are we trying this? Why are we doing this? To answer this question, we use the word because. Everyone can relate to the word because. And we throw on two other phrases: ‘we know’, and ‘we assume’. And this is absolutely essential. How many times have you gotten two months into a project, and someone says, ‘why are we doing this’? And someone said, ‘well, I guess we assumed that this was true’. And the person says, I know that’s not true. So by saying this, we know and we assume, you really make it clear why you’re doing it, and what’s the underlying rationale.

3. While And Without

And the next two words are ‘while’ and ‘without’. This can be a little tricky to wrap your head around. In your quest to achieve this fuzzy goal, what are the boundaries? What resources are you playing with? A great example that I can think about is that you’re doing something that might potentially damage the user experience. You might want to create a boundary there. You know what? No matter what we do in our effort to try to improve this fuzzy goal, we don’t want to mess up the user experience. So we use these words, ‘while’ and ‘without’. And I’ll give you an example of all of this together in a bit.

4. By Trying

And then finally, we have what people commonly call solutions, but I just call it ‘by trying’. We’re going to try something to attempt to move this fuzzy goal. But the most important point here is that you can nest these. And by nesting, you can start having another ‘because’ for this, and another ‘while’ or ‘without’, and another ‘by trying’.

5. Example

Let me give you an example that everyone can relate to, something like eating healthy.

Because we know that eating healthy might help you live longer. Maybe that’s an assumption, but I think commonly, people know that. And we assume that our relationship might be better if we eat healthy and we’re less stressed out. Because we assume that eating healthy reduces stress.

We’ll do this without breaking the bank. We’ll try to eat healthy, but you know, we’ve got a budget. And we’ll do this while making sure that, we have fun sometimes. We’re going to go out and eat with our friends.

And we’re going to do this by trying what? We’re going to do this by trying to cook in six nights a week. Because we think that by cooking in six nights a week, just by the nature of cooking in, we’re going to eat healthier. We’re going to do that without annoying our kids, because they watch TV at a certain time. And then we’re going to do that by trying to have a set menu ahead of time that we shop for at Whole Foods, for example.

What you see here is that if you can start to state your goals this way, instead of just having a big cascade of goals that just say things like ‘meet this revenue goal’, ‘or ‘this is this metric’, or this is this other aspect of your goal’ you’re explaining your rationale.

What I would like to encourage you to do is to try this mind mapping method as a way to just get your heads straight before jumping into a roadmap or another strategic document.

In Summary: Resist Prescriptive Goals

First we talked about the difference between a destination and a direction, or systems and goals. And next we talked about the challenges of shared understanding. That we’re always trying to grow shared understanding, but it’s always degrading, too. There’s always that dynamic happening.

And then, I talked about a mind mapping method to help you develop a common vocabulary. And that conversation is critical because if you have that conversation, you can constantly get context.

When you think about it from a product manager’s point of view, it is always tempting to have prescriptive goals. That is a temptation that always exists. And If you take a step back, that is too fragile for most knowledge work. If you just create those destinations that people must hit, then the context changes, they’re not going to be able to change course. You’re going to lose that shared understanding very quickly.

What I’d like you to do is to think about direction instead of destination as you’re putting together your roadmaps. Make sure that you’re communicating the why, the data that you have behind that, the boundaries that you’ve created around your particular goal, and also encourage people to try new things.

Maybe one thing won’t work, but if they can understand what your rationale is in your thought process, then they might creatively come up with other solutions that might achieve that goal even faster.