In our workshops, we tend to start with an activity centered around two questions — 1) What problem are we trying to solve?; and 2) How do we measure success?

The first question is for context. We work in a variety of industries, from pharma to math education to leadership coaching to trucking logistics, and asking about problems is the best shortcut to understanding the true needs of the business.

The second question is for focus. A lot of the problem-solving talk revolves around pain points, issues with current workflows, market needs, etc., but that second question gets down to how the business itself will view the project — .

We’ve always encountered project meant to “change the world,” “make people’s lives better”, etc. when the metrics focus exclusively on traffic and revenue. In any system, what gets measured tends to get valued and what doesn’t, doesn’t. Metrics drive behavior.

So coming into a project, I always want to know what charts, graphs and numbers are going to show up in the report the project lead will be giving 6 months post-launch. That tells me what’s really valued.


I wasn’t totally happy with this activity. We do it quickly, having people brainstorm on Post-Its what numbers we could measure, then grouping them together in clusters. There are two challenges — either the people in the room don’t know anything about metrics, or they know way too much. In the first case, you get a bunch of responses that don’t really help — “customer happiness” is not a real metric, people — and in the second case, it feels like you are wasting people’s time.

Plus, you often have both types of people mixed in the same workshop. So the CEO’s note with a single huge dollar sign written on it is next to the marketing expert’s LTV formula:

Lifetime Value Calculation from

Now, it’s still a good activity, and the conversations it brings up when you have different levels of metric-savvy among the team are usually worthwhile, but I wasn’t satisfied with the amount of buy-in from some participants and felt that I wasn’t getting the context I really needed out of the activity. So lately I’ve been using a different activity for eliciting context and putting the focus on what people truly value. It’s a three-part activity called “Stories.”


The fun part ^

Put two minutes on the timer and have people respond to this prompt. Forecast a great success and explain what happened. Then share out the responses. (This takes a while, so for groups larger than 5 or so, split into breakouts to share).

This type of activity encourages people to take a long view, to think critically about competitors, about channels, about potential partnerships — having a window into those larger strategic considerations is a great asset once we start actually doing the design work. Plus, it’s a feel-good activity that creates good vibes in the room and gets everyone feeling awesome.

Then, as the facilitator, you pull the rug out from under them.


The interesting part ^

Same activity, different prompt. Expect groans when you put up this slide — people can get very uncomfortable here. I first encountered this activity when working in an agile dev team and the lead called it a “pre-postmortem”, but I prefer the less-euphemistic term.

Here is where you start to hear about people’s fears, about the big risks, about the major issues that could make or break the project. The room gets real quiet at the end — it’s not fun to think about, but better to consider failure when the timeline’s at its longest and the budget at its highest, then face it when both those things are badly depleted.

It’s a rookie mistake to stop here or take a break, so plan accordingly — you’ve made people sad, now lead them to meaning…

Part 3: Metrics

The first two parts lay the groundwork for a truly useful discussion of metrics. You’ve charted out two paths for the project — how will we tell if we’re on one path as opposed to the other? What are the early warning signs that we’re moving towards failure? What will tell us that we’re doing it right?


Now every participant has the right context to determine what measurements matter to the project. Now people will have the focus to really drill down on what their team should care about. Now our metrics brainstorm is powerfully motivated and a fertile ground for meaningful conversations.

So the next time you want to talk metrics with your team, try it out — even a numbers-based setting, storytelling remains the best way to communicate.

Thanks for reading! If you made it this far, please clap so others can see it as well. You also might be interested in learning about our design teardown activity, and you should follow us on twitter for more design insights, or check out our work at

Source link—-138adf9c44c—4


Please enter your comment!
Please enter your name here