As I prepare for the fall semester, John has kindly agreed to a guest post, sharing some of his fascinating thinking on connecting tasks to goal. I hope you enjoy this as much as I do! – CW

A Map from Goals, Around Assumptions, Through Tasks, Towards Results

John Cutler is a product management and UX consultant. His passions are UX research, evidence-driven product development, and empowering the front line to solve business and customer problems.

Twitter: @johncutlefish
Medium: https://medium.com/@johnpcutler

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.

It’s tempting to be highly prescriptive: build this, build it this way, and build it in this order. You might even try a fancy kickoff template and collaborative visioning workshop to inspire the team with a powerful why. But the reality is that most initiatives are a messy bundle of evolving and emerging assumptions, data points, opportunities, and constraints. It’s what makes product development both fun and frustrating.

The best teams find a way to unpack this complexity and speak the same language. And then row relentlessly in the right direction, even when that point on the horizon shifts.

Below I describe a method for mind-mapping your product development goals, assumptions, and proposed solutions. It can be approached as a team activity (my personal favorite), or as an individual exercise. It takes work and some brain gymnastics — there’s no magic bullet — but your team will benefit from a deeper level of shared understanding.

The Lingo

Mind-mapping (especially team mind-mapping) can get out of control very quickly. To add structure, I use a handful of words to link the various ideas, assumptions, motivators, and data points. It’s Mad Lib-ish, but highly effective.

Because we assume (or we know) ___________________

This is the workhorse. We use these phrases to describe our rationale, evidence, and motivation.

By ___________________

How will we intervene? What action will we take?

While and Without ________________

Where are the guardrails? In our quest to solve the problem or produce the desired impact, how are we constrained?

In the diagram below (download a PDF here), I summarize how these words are used in this approach. The sections that follow discuss each step in more detail.

Brief Example

Before jumping into a product development example, let’s look at an oversimplified dog purchase example:

The Newfoundland seems like a good option due to their love of kids and water. But that nagging assumption remains … will the kids continue to love the dog once the new dog smell wears off?

Let’s look at the these words and concepts in more depth.

By: Nesting Problems and Solutions

Product development teams speak frequently about the distinction between problems and solutions. Developing a feature directly from a rigid specification is itself a “problem” to solve. You have to correctly interpret the design, architect it, and interpret the gaps in the specification. Similarly, hitting an annual revenue goal is a “solution” on the road to a long-term corporate goal. Every goal can be put into context between goals that are broader and less prescriptive and goals that are narrower and more prescriptive.

Given this fluidity, teams frequently struggle with the problem–solution dichotomy. By making the relationships between problems and solutions more explicit we challenge ourselves to maintain a logical thread that extends from front-line work to a powerful, all-encompassing goal. We also empower great ideas. What if the front line knows of a better way to move toward that big goal?

The word by implies both a hierarchical and cause-and-effect relationship. In the example below, decreasing churn by 20% is almost certainly a tactic that moves the organization toward some higher-level goal. However, it also allows the team conducting the “shorter, more focused sessions” to understand where their work fits in.

We Know, We Assume: Making Our Assumptions Explicit

There are things we know to be true and things we assume to be true. Teasing out these assumptions is essential for dynamic problem-solving. In the example below I address causation versus correlation, an example of a time that it’s important to separate knowledge and assumptions. It’s possible that the coaching sessions are not what affects these customers’ churn rate! That relationship is something the team should explore further.

Because: Understanding the Why

What is the reason or motivation to achieve this goal or solution? “Just because” is not very motivating (and, to some, is downright cringe-worthy). Your most motivated team members crave a high level of logical coherence, regardless of whether you are talking about something lofty (“Save the world!”) or mundane (“Because that’s what the pattern guide says”).

This approach uses the word because instead of why so that the mind map reads more fluidly. The “because” statement is almost always followed by “we know or “we assume” to show how the rationale is validated.

The example in this diagram mixes validated information and assumptions. We know our team hates losing customers. We also acknowledge that we’re only guessing that these quick-to-churn customers would have gone on to have high lifetime value. That assumption can be questioned. Maybe by moving on from these customers who were a poor fit, we can refocus elsewhere.

While, Without: Making Constraints Explicit

Once a goal is identified, what can be done to achieve it? Often nothing can be done, and at a minimum the team is constrained by available resources. These constraints should be defined. Where are the guardrails? What lines should not be crossed? How are we constrained?

Use without when you assume or know you don’t want to (or can’t) do something. Use while when you assume or know that you will do something alongside the solution.

This example acknowledges the cold reality that the team has exhausted their annual budget. They can’t hire more coaching specialists. They also guess that if they were to break their 24-hour case resolution deadline to conduct coaching they’d negate any session benefits.

Facilitation Tips

Limit the time to 30 minutes or less. This is a “full-contact” thinking activity. 30 minutes appears to be the maximum time a team can effectively “play” without taking a break.
Display the keywords up on the wall. They’ll quickly become second-nature.
Have one person volunteer to do drive the mind mapping software
As a warm-up, consider applying the process to something completely unrelated to work (like picking a lunch spot, or selecting a pet).
Don’t start at a level too high up. You can boil almost any problem up to an existential question, but it is best to practice with more discrete questions.
Aggressively use the collapse function in your tool of choice. This allows you to focus on the area of interest. You’ll be amazed by how much content you can produce. Don’t let it overwhelm your activity.
Challenge “we know” whenever possible. We take many assumptions for granted.
Depending on the team dynamics, consider a turn-based approach. Having the minority viewpoints represented is vital.