Imagine a colleague asks you to describe the software product manager role. Where would you begin? So few of us actually studied this stuff in college. How can we hope to explain it when we’re not even sure we’re doing it right ourselves? We deliver MVPs for MVAs. We set goals using OKRs and KPIs. And we apply a host of methodologies to build all this incredible software. But in the midst of all the jargon, it’s easy to lose sight of our greater purpose.
In this episode of the Product Momentum Podcast, Sean and Paul chat with Johanna Rothman. Also known as the “Pragmatic Manager,” Johanna helps product leaders identify problems, recognize opportunities, and remove obstacles in their development process. Though she has authored more than a dozen books on digital product management, Johanna sees software not as the end goal – but as the means by which we achieve that greater purpose – inspiring our teams to improve the world around us.
The Path to That Greater Purpose – 3 Steps
Johanna’s no-nonsense, pragmatic approach to software product management helps us understand how product professionals create software. Put simply, we generate the best results when teams are aligned, confident, and committed to the goals they set out to achieve together.
These things don’t happen by themselves. Alignment speaks to a shared agreement on desired outcomes. Confidence builds when visionary product leaders develop the skills of their talented teams. And commitment reflects the team’s obligation to not only the mission and each other, but to the product’s end users whose lives will improve as a result.
Start with Why[1]
When product leaders start by explaining why, we increase the likelihood of motivating our teams to do the right thing, or at least more of the right thing than they might have done otherwise.
Like tipping that first domino, the magic really unfolds when we begin by describing the desired outcome, Johanna offers.
By starting with why, we’re able to meet people where they are. What I have said to people is this: “Here is our goal, our purpose, our task; we will solve our customers’ problems and we will use software to do it.” – Johanna Rothman
“By starting with why, we’re able to meet people where they are. What I have said to people is this: “here is our goal, our purpose, our task; we will solve our customers’ problems and we will use software to do it.” Again, Johanna points out software’s role as enabler and facilitator – not as the ultimate objective.
Framed in this way, she adds, the motivated team creates its own product vision and its own release criteria. When leaders communicate the desired outcome, and leave the team to come up with the path for achieving it, the team becomes responsible for defining “done.”
As Johanna explains in detail, teams arrive at “done” from sometimes vastly different points of origin.
Balance Team Incentives and Individual Rewards
Much of Johanna’s recent writing has focused on the notion of modern management and self-management, helping product leaders create an environment where we’re fostering growth and development for everyone on our teams and in our community.
It’s important to remember, though, that teams are comprised of individuals. Individuals bring their own dreams and aspirations to the table, regardless of how team-focused they may also be. Johanna’s insights, based on real-world experiences, help team leaders incentivize individual behaviors that support team goals without creating a “lone wolf” culture that distorts the ecosystem.
“The way we’ve organized our workplaces reflects too much the way we used to organize our schools,” Johanna says. “Students were graded on what they accomplished as individuals. But if we think in terms of how teams learn together today, how we produce together as teams…how can we possibly reward people for their individual work?”[2]
During the podcast conversation, Johanna underscores the point, sharing an enlightening story about a team she once worked on and how she and her colleagues modeled this balance of team incentive and individual reward.
Explore Together: Symmathesy and Communities of Practice
Johanna introduces us to the idea of symmathesy – pronounced si-MATH-uh-see. Coined by Nora Bateson and popularized by Jessica Kerr, symmathesy means “learning together” and applies with equal validity in the workplace and the classroom.
The more we can learn together and the more we think together about software, this whole idea of an agile community starts to come together. – Johanna Rothman
Symmathesy is a fundamental building block within the context of agile product teams in which “we learn from and with the people we work with.
“The more we can learn together and the more we think together about software, this whole idea of an agile community starts to come together,” she says.
“The act of working together in small, cross-functional teams and figuring out how to do simple, safe-to-fail experiments as we proceed, this stuff is all about learning.”
When we have multiple teams performing similar functions across an organization – testers and developers, architects and designers – it’s really helpful when they can get together, Johanna suggests.
“They get to geek out about their particular functional skills, ask the questions they have, and share all the tricks they’ve learned,” she adds.
Learning from other people who do similar things to what we do, but maybe not on the same product or in the same project, can really help the entire organization share knowledge. That’s the point of a community of practice.
“This whole business of, ‘how can we explore together? How can we grow together?’ That’s a really big deal,” Johanna says.
Check out the Product Momentum Podcast and catch Johanna’s straightforward approach to not only understanding the software product manager role – but actually doing software product management.
[1] See Start With Why, by Simon Sinek. See also the ITX blog Momentum, in which ITX EVP of Innovation Sean Flaherty describes The Momentum Framework, referencing Sinek’s research around The Golden Circle.
[2] Refer to our podcast conversation with Professor Miguel Cardona, as he describes the notion of Contributive Design – leveraging tools to evaluate the performance of project teams while isolating the contributions of each individuals.
