A managerial culture emphasizes rationality and control. Managers are problem solvers, whether their energies are directed toward goals, resources, organization structures, or people. While some of those problems can be technical and have a cause-effect resolution, others can be wicked. By wicked, I mean difficult or impossible to solve—generally because of its complex and interconnected nature. You have to be ready to work more on the mission and less on playing Tetris with teams and initiatives. And what is a mission? It's a story you tell to yourself and others.
Great stories build relationships and make people care
When you see a boring PowerPoint, a chart on a screen, two pieces of your brain light up when they put you under a brain scan, but when you see those same facts as conveyed through a story, five times as much of our brain activates. Our emotional centers, our motor cortex, which controls our physical reactions, so this is why you jump when you hear a surprising thing in a story, all of these parts in your brain light up when you hear a story.
A roadmap is a technical problem
A roadmap is a frame of mind. Your average PM will spend countless hours in meetings talking to non-front-line stakeholders about what their organizations will (or should) do in the future. They'll make fancy Gantt swim-lane roadmaps so that everyone feels heard. And then talk about pet solutions, show mock-ups, make a lot of guesses, play Tetris with initiatives, and pester engineers for estimates. Towards what end? Why?
Roadmaps encourage people to:
- Horse trade initiatives, placate stakeholders vs. focusing on value creation
- Stick to the plan when the plan is no longer optimal
- Chase harmfully high utilization rates (the jigsaw illusion)
- Future sell, instead of relying on the current merits of the product
- Prioritize new feature development (items that can be easily understood and sold) over equally promising enhancements to the existing product
- Coverage prematurely on solutions
- Rely on estimates, despite the fallibility of those estimates
Without a focus on outcomes and results, you're stuck on a feature factory treadmill.
Roadmaps:
- Encourage the illusion that efforts are linked to a timeline (when most aren't.)
- Obscure underlying assumptions, rationale, and vision. Even when described (e.g. a theme), it is still difficult to parse why the theme matters.
- Institutionalize "big batch" yearly planning, which in turn decreases agility.
- Fail to address the needs of all "users" (e.g. your roadmap is fine for communicating with executives, but fails to meet the needs of your front-line teams.)
- Discourage experimentation and acting on new insights/data.
- Create dependencies across the organization (decreases agility.)
A product is a wicked problem
Here is when the manager needs to advocate for thinking in terms of initiatives, problems to solve, and missions. Humans enjoy the ebb and flow! They like ambitious visions and a challenge. We enjoy stories with a beginning, middle, and end. We like making a difference.
To get to a higher level you'll eventually need empathy, inspiration, creativity, humanity, and novelty.
What counts is the mission: the engaging outcome you hope to generate for your customers and business.
Do you want to be right or happy?
Leverage the creativity within the communities of the world to solve their own problems: This is community-driven design, taking full advantage of the fact that it is the people in communities who best understand their problems and the impediments and affordances that impede and support change. Experts become facilitators, by mentoring and providing tools, toolkits, workshops, and support.
Management matters, but leadership matters more
While ensuring the competence, control, and the balance of power among groups with the potential for rivalry, managerial leadership, unfortunately, does not necessarily ensure imagination, creativity, or ethical behavior in guiding the destinies of corporate enterprises.
Some people blame their managers for a lack of career progression, and sometimes they're right. But often the progression of a manager's direct reports is out of their control. Factors such as how the company is structured, what type of work the business is prioritizing, and how the organization thinks about applying people to that work all come into play.
Maybe it's not that the PM is the one who generates the roadmaps. But someone is requiring them because that's the way the company operates.
As product people, we need to work more on the mission and less on playing Tetris with teams and initiatives. Too much planning ahead and chasing full utilization will undo your product.
Welcome to the feature factory mindset
How do you know if you're working in a feature factory? This is a question that John Cutler did in a post. Here are some points:
- No measurement. Teams do not measure the impact of their work. Or, if measurement happens, it is done in isolation by the product management team and selectively shared. You have no idea if your work succeeded.
- Rapid shuffling of teams and projects (aka Team Tetris). Instead of compelling missions or initiatives, teams deal in feature and project assignments. Chronic multitasking and over-utilization.
- Success theater around "shipping" with little discussion about impact. You can tell a great deal about an organization by what it celebrates.
- Infrequent (acknowledged) failures and scrapped work. No removed features. The primary measure of success is delivered features, not delivered outcomes. Work is rarely discarded in light of data and learning. Often the team lacks the prerequisite safety to admit misfires.
- No connection to core metrics. Infrequent discussions about the desired customer and business outcomes. The team cannot connect work to key business and customer satisfaction metrics. Impossible to connect iterations to "what matters most."
- No PM retrospectives. Product managers do not conduct regular retrospectives on the quality of their product decisions and compare expected benefits to actual benefits. Developers have "passing tests", but product managers do not. Product managers view velocity and output as their key performance indicators.
- Obsessing about prioritization. There is a mismatch between prioritization rigor (deciding what gets worked on) and validation rigor (deciding if it was, in fact, the right thing to work on). Prioritization rigor is designed exclusively to temper internal agendas so that people "feel confident". Lots of work goes into determining which ideas to work on, leaving little leeway for adjustments and improvisation based on data. Roadmaps show a list of features, not areas of focus and/or outcomes.
- No tweaking. Once work is "done", the team moves immediately on to the next "project", leaving no time to iterate based on qualitative and quantitative data.
- Culture of hand-offs. Front-loaded process in place to "get ahead of the work" so that items are "ready for engineering". The team is not directly involved in research, problem exploration, or experimentation and validation. Once work is shipped, the team has little contact with the support, customer success, and sales groups.
- Large batches. Without the mandate to experiment, features are delivered in single large batches instead of delivering incrementally. You might still work in sprints (yay, we're "Agile"), but nothing new is reaching customers at the conclusion of each sprint.
- Chasing upfront revenue. Features are implemented to close new deals. While not inherently wrong, the economic justifications are often flimsy (at best), and fail to account for the non-linear increase in product complexity (you make the quarter, but you pay for it many times over later). Again, this reinforces the idea that features are the unit of value measurement. Product decisions lack a sound economic grounding.
- Shiny objects. Low visibility for refactoring work and debt work-down. Low visibility for overall value delivery capabilities. As mentioned, the primary measure of success is new feature output. Little appreciation for the health of the whole product as opposed to shiny new objects. Little awareness around the impact of new features on usability (and maintainability and extensibility) of the existing product.
Tearing the factory down
A fresher approach could be to think about why we are doing what we are doing. After all, we spend 40 hours or more a week trying to make things work. And sometimes we don't even remember anymore because we either learned about it years ago or because no one ever told us about it.
It never hurts to go back to square one and, with a beginner's mind, re-evaluate the reasons that keep us doing what we are doing.
Whose behavior will change because of this work?
Our product development efforts target people who share some common traits and characteristics. What are those traits and characteristics, and who are the people that meet those traits and characteristics?
What is their current behavior?
What pattern of behavior are we hoping to change? This behavior can be extremely specific — like a particular navigation flow or interaction — or it can be very broad like purchasing habits, lifestyle choices, or major life decisions. How often does it happen? How ingrained is the behavior? How does the target benefit from the existing behavior, or at a minimum put up with it?
How will their behavior change?
Something will change as a result of our intervention. Will the user start or stop doing a particular activity? Will they do something more or less often? Will their outlook change? Will they give you more money and your competitors less money? Will they use your impressive new search feature instead of spending time navigating the tab structure?
How will the new behavior pattern benefit the user?
In the example above, the behavior change actually includes the proposed Intervention (in-app chat). The intervention might be a change in design, a change in tactics, or a change in packaging, messaging, or technology. We’re mixing the pot in some way and hopefully, something will happen.
How will the new behavior pattern benefit the business?
The behavior change must result in some benefit for it to “stick”. Without a significant payoff, you’ll be hard-pressed to persuade someone to change their mindset and habits. Big payoffs can reinforce significant behavior changes (like paying your company a lot more money). The benefit is the return on investment, where the investment is some shift from the status quo.
So now what
Bring your customers and the team closer together. Make the team obsesses over customers. To engage directly with them and get product ideas from observing customer struggles, and analyzing customer data.
Share some challenging news. Talk about missteps. Ask your team what success looks like to them. Get them involved. Ask your team to come up with actionable (and meaningful) metrics. Explain why targets/goals are what they are, and why it matters.
Teach all team members about your company's business model and operating assumptions. Regularly revisit those assumptions. Make it safe for someone to say things like "I'm not seeing why that's a win …." or "I really feel like we're cutting the wrong corners."
