John Cutler was coaching a product team when an executive tapped him on the shoulder.
“When are we going to stop experimenting and when are we going to actually work?” the executive asked him. “This isn’t science class, this is a business. When is the work going to start?”
That’s when Cutler, who has coached hundreds of product teams as part of his work with Amplitude, noticed something: As soon as he started talking about experiments, he’d often lose the people in the room who were anxious to get the work done. Language is powerful in business and Cutler realized if he changed it subtly, he could have better conversations with executives who bristled at the word “experiment”.
In all his years coaching product teams, Cutler started seeing thinking models and the same patterns emerge. He recently presented those six thinking models during a ProductTank Waterloo talk. (Cutler has since translated some of this talk into a book draft, 50 Short Product Lessons.)
The messy middle
The messy middle comes up in call after call, said Cutler. Typically work is broken up into a series of timeframes, from one-to-three hours to one-to-three decades. The messy middle is where the shape of work happens and it’s where product teams can help the organization focus on its little picture and big picture goals.
“One of the most actionable things for junior product managers or other folks is to see if they can string together the work across the messy middle,” said Cutler.
One way to do that is with a small exercise that, at first, may seem mundane: Approach an engineer and ask them to explain in more than three steps how a one-to-three hour task they’re doing translates into one-to-three year work. You want them to explain it in more than three steps so that the language is specific.
“This [question] cuts to the role of product in a lot of organizations,” said Cutler. “If someone has trouble answering this question, this is really on product. We’re not filling in the context.”
The messy middle is about creating shared understanding and intention behind the work to help agile teams unlock their potential, rather than turning them into feature factories.
Framing things as bets
In the opening story about the executive who bristled at the word “experiment” Cutler realized that using flexible words such as “bets” meant he could have better conversations with people.
“It’s a flexible way to guide the language in conversation,” he said. Bets can be big, bold, small, safe, or risky. So when an executive says the company has to build something, he encourages product teams not to talk about all the experiments they would need to run first, which can lead to frustration. Instead, he suggested product managers respond by telling the executive their suggestion is a “really interesting bet.” It gets the executive to recognize that what they’re asking for isn’t a sure thing, said Cutler.
He asks the product teams he coaches to do what he called “bet libs”, a fill-in-the-blank exercise that frames bets in a way that lets you have deeper conversation from a product angle.
Explore ownership boundaries
There’s a constant debate in organizations over who owns the problem and who owns the solution. But it’s not an effective way to talk about decision boundaries, said Cutler. He developed a tool that doesn’t oversimplify work into “problem-solution.” Rather the tool has a range of levels, from A — asking someone to build something based on a specification — to I — generating long term business outcomes.
“At any given time in your company there’s work happening at all these levels, and there’s not one that’s inherently good or inherently bad, it’s just where your work is,” he said.
All are important, but make sure you have a visual of where people are operating in your organization. Often someone’s work on the model won’t be a straight line, but rather a curve, he said. And recognize that not everyone is ready or interested in operating at these levels all the time.
But the model helps teams think about where they’re operating in a way that goes beyond the simplistic problem-solution. Using the approach helps organizations define their decision boundaries, he said.
Hack the language
Just as words can reframe a discussion, so too can they be deterministic, said Cutler.
But subtle hacks with language can be very effective, he added.
A problem is something to be solved, but an opportunity is something you explore.
And if you’re using the word “done” right now with your product team, Cutler said to stop.
“We’re never done in product,” he said. “We’re never, never done. So what if you reframe it as a decision point?” How many people need to adopt a product before you decide you’re going to stop working on it?
Want to hack the language with your team? Ask them: What words do we use that confuse everyone? Then go back to them with new replacement words that mean something a little different and see if you can move the conversation forward, said Cutler.
Designing work
Sometimes when Cutler is coaching teams, they want to use another organization’s template for getting work done, or ask Cutler for one. But when that happens he pushes back and works with them to co-design templates that set out how they work.
“If you make something your own in your company and you make it relevant to what you’re doing, it’s much more likely to stand the test of time and get adopted,” he said.
One way he starts the conversation is by asking: What must you eventually know about this work to make good decisions at the right cadence?
The question is a powerful one, he said, because it’s not about a checklist or about what you need to know immediately. It’s about focusing on the knowledge the company needs to make the right decisions.
The goal is to get companies to start talking about their work — rather than the theory of work — then think about how the work is grouped, its complexity, and the patterns that emerge.
Once that’s done, he returns to the question: What must the company know about this work to make good decisions at the right cadence? Very quickly the teams he coaches come up with a list of questions they can use the next time they're framing their work.
Finding your North Star
As part of his work with Amplitude, Cutler wrote a book about the North Star framework. The idea of the North Star, he said, is that you think about the leading indicator to sustainable product-led growth for your company, and then connect that with a series of inputs. A North Star is a single, specific metric that represents your product strategy. As long as your strategy is consistent, you can use the framework to create a model of value for the company.
North Stars are not objectives and key results — commonly known as OKRs in many organizations. But when you have a North Star, OKRs become easier because they relate to a company forecast.
Where things get really interesting, said Cutler, is when you start to think about the work you’re doing and can layer it onto the North Star model. Then, he suggested taking those layers and turning them into a visual product of what your organization’s work looks like.
Cutler’s talk was the fifth ProductTank Waterloo talk this year. ProductTank Waterloo is a monthly meetup group for product people to come together to learn and share. Learn more about ProductTank Waterloo’s next meetup.
