I just gave a copy of a children’s book called Stone Soup to a seasoned product manager/mentee. She and I had been talking about leadership in the absence of formal authority, and this folk tale seemed very relevant.
Synopsis: A hungry old soldier arrives at a village, and the villagers hide their food rather than offer to feed him. Thinking creatively, he picks up a stone and announces that he will be making stone soup, which villagers can share if they are willing to contribute. The woman who lends her large kettle will get soup, as will the old man adding a few onions. Donated carrots, cabbages, a bit of meat… Simmered up together, the soup is nourishing and everyone gets to eat.
The soldier, of course, provides (only) a common goal and a keen understanding of motivations. The stone is purely ceremonial. This transfers directly to product managers – and others with heavily matrixed roles.
Remember that no one works for us: developers and designers and tech writers are in their own functional groups or scrum teams. Marketing and Sales report up through the revenue side of the house. Finance and Support have their own issues. We’re not the boss of anyone. Plenty of responsibility, but no actual authority.
So getting products built takes a big ladleful of leadership. It’s not enough to have a development team assigned: we’ve got to provide a shared understanding of customer problems and a desire to address those problems. We need to engage our teams’ hearts and minds. Otherwise, we serve up flavorless features and pro forma story points.
A few specific applications of stone soup theory:
[1] Deliver some tangible/tasty results in your first 30 days
If you’re newly assigned to a development team, especially if they’ve been without good product management, you only have three or four weeks to demonstrate that you really add value. That their days are better because you are involved. You need to rapidly assess the product/team/situation, build a backlog of potential quick wins, and make some visible improvements. You have to get busy making soup.
Possibilities:
- Organize some customer feedback calls and share your notes — or have devs listen in on the calls.
- Intercept a low value/high visibility sales escalation. Remind everyone that you’re now the blocker for development interrupts.
- Pull developers, testers and UX designers into the same room to sort out some amorphous feature.
- Brief your folks on pending deals and sales pipelines, emphasizing that lots of real customers are using (loving) their work.
- Create (or find) your product’s market success metrics and talk the team through the numbers.
This is proof-by-example: doing something useful that your team will notice and appreciate. Getting one dev to say to another: “I’m not really sure what’s changed, but we seem more engaged and productive than last week. This product management thing is pretty tasty.”
[2] Don’t wait for permission or organizational clarity
Every company is confused about the boundaries of product management, and who should do what. You could spend your first month parsing job descriptions and arguing about the perfect development workflow, or you can make some unilateral decisions about how you’re going to spend your time. Grab the ladle and stir. GSD.
In particular, there’s a temptation for you to wait for someone more senior (with ‘strategy’ in his title) to show up with a thoughtfully prioritized product strategy. Rarely happens. Or the strategy includes contradictory initiatives. Or it’s mostly buzzwords and science fiction. Real product strategy happens when top-down market goals meet reality-based bottom-up prioritization. You need to get your team focused on the two most important items while everyone else is updating PPTs. Start feeding improved products to hungry customers but don’t tell anyone that you’re being strategic.
[3] Leadership is about outcomes, not titles
It doesn’t matter if you call yourself product manager, product owner or pastry chef. Leadership is about setting clear direction and having people follow voluntarily. Because you’re collectively doing the right things and collectively celebrating progress. Because better product is shipping and more customers are posting rave reviews. Because everyone is helping in the kitchen. You earn the right to lead by delivering better results for those who participate, not by flashing your business card.
BTW, bloviating about how “product managers are the CEOs of their products” is a silly waste of air. It’s obviously not true unless we have hire/fire/promote authority over our development teams. And makes us sound self-important. Instead, consider calling yourself a “product wilderness guide” or “market segment success enabler” or “champion of meaningful customer outcomes.”
SOUND BYTE
You’re a product leader if you draw up the menu and everyone willingly does their part in the kitchen. If you don’t wait for permission, or titles, or the perfect organization. Because the proof of the pudding is in the collective eating.