Recover Alignment with Abstraction Laddering
Have you ever looked at your salt shaker and thought, man, I wish this thing had a mood light.
Probably not. But if you have, maybe Smalt is for you – It’s a salt shaker with a mood light. And a bluetooth speaker, and a dial, and a “mode” button.
An actual device that was funded on Kickstarter.
Smalt is a frankenproduct – an unfortunate mess that happens when we work on solutions (or features) that don’t connect to a meaningful customer problem.
A lot of product teams (maybe all product teams?) operate with these habits, and without consistent recalibration, those teams are at risk of shipping a frankenproduct.
Abstraction Laddering is a fantastic recalibration mechanism. It’s designed to get the team on the same page about what problem we are solving, then refocus on the solution itself. We like to use it to recover alignment on a team mid-way through a sprint or project. It’s a good compliment to problem framing and a trust-building activity like the ICBD, which we use to prevent misalignment.
How to Use Abstraction Laddering
Use the abstraction laddering exercise to define and align around a “why” before executing — or even planning — a feature or a solution.
Here are the steps:
Review the original problem statement (or feature, or directive, or solution) as a team.
Each person works individually and considers why solving this problem is important. Set a timer for 1 minute. Add "Why"s on individual stickies by completing the phrase, "In order to..."
When the timer goes off, take turns reading aloud yours "Why"s
Group similar stickies together.
Each person votes on their favorite "Why" – one vote per person. If you have a Decider in the room, like a VP, use a two-step voting system. The team votes first to advise the Decider, then the Decider decides. If you’re deciding as a team, then use the most popular why.
Each person works individually and considers how they might solve the top-voted "Why". Set a timer for 1 minute. Add "How"s on individual stickies by completing the phrase, "We could..."
As a team, decide whether to iterate on the original problem statement (or feature, or directive, or solution) based on what you learned together, or stick with the original.
An Example of Abstraction Laddering in Practice
We asked this product team to design a better recycling bin. You can probably see where this is going — “better” is not a fair ask. One stakeholder’s definition of “better” will not be the same an another’s, which is asking for a frustrating conversation down the road. Better is a wiggle word, which means it could mean anything.
If you are handed a similarly unclear directive from, say, a VP, try to have that VP in the room with you for the Abstraction Laddering exercise. If they’re unwilling to join, at least get them to clarify their definition of “better” by asking questions like, “what does better look like?”
Without that clarity, you’ll come up with solutions that are hard to compare (and hard to test!) because they don’t solve the same problem. Like these, all different takes on a “better” recycling bin:
To get this team back on the same page so they could ideate, prototype, and test concepts that solve the same customer problem, we introduced abstraction laddering.
This gave us a system to identify higher-order benefits that customers are seeking before debating which product features to prioritize. That sets up the “features” conversation to be productive and collaborative, not an hour listening to people fight with each other on Zoom.
When To Use Abstraction Laddering
When you’re given a solution-focused directive
When your product starts to feel fragmented
When a team can’t agree on priorities
When deciding whether to add something to the roadmap
When something on the roadmap feels like the nugget of a good idea but not quite the right approach
Get Started With Abstraction Laddering
Use our Miro template to run an abstraction laddering workshop as a team. And let us know how it goes! (also available as a MURAL template)
