Product Management Flaws
Developers have “passing tests,” but product managers do not. Product managers view velocity and output as their key performance indicators. A mismatch between prioritization rigor (deciding what gets worked on) and validation rigor (choosing if it was the right thing to work on). Prioritization rigor is designed only to temper internal agendas so people “feel confident”. Much work goes into determining which ideas to work on, leaving little leeway for adjustments and improvisation based on data. Front-loaded process in place to “get ahead of the work” so that items are “ready for engineering”. Once work is “done”, the team moves immediately to the next “project”, leaving no time to iterate based on qualitative and quantitative data. Roadmaps show features, not areas of focus and outcomes. The team is not involved in research, problem exploration, or experimentation and validation. Once work is shipped, the team needs more contact with the support, customer success, and sales. Without the mandate to experiment, features are delivered in single large batches instead. You might still work in sprints (yay, we’re “Agile”), but nothing new is reaching customers after each sprint. Low visibility for refactoring work and debt work-down. Low visibility for value delivery capabilities.
Fear is rampant on too many teams. People are afraid to make changes, afraid to voice their opinions, and fearful of making mistakes. The trouble is fear kills performance. If you have a culture of fear, you will need more fancy processes or practices to help you. Blaming increases negativity and helps no one. Making safety a prerequisite means establishing safety before engaging in hazardous work. If security isn’t improved after each accident or near-miss, excellence will be elusive. Instead of compelling missions or initiatives, teams deal in feature and project assignments. You can tell much about an organization by what it celebrates — no removed features. The primary measure of success is delivered features, not provided outcomes. Work is rarely discarded in light of data and learning. Product managers do not conduct regular retrospectives on the quality of their product decisions. They compare expected benefits to actual benefits.
Teams do not measure the impact of their work. Or, if measurement happens, it is done in isolation by the product management team and shared. You need to find out if your work is working. Teams need to connect work to crucial business and customer satisfaction metrics.
Part of reaching this point in a transformation or the evolution of a new organization is recognizing that change is a constant. Due to internal or external forces, conditions keep changing, and the operating system has to keep pace. That’s why a community of practice is emerging among self-managed and agile organizations. They tend to share more about what they are doing, how it’s going, and what they’re learning. And they tend to be curious about how others resolve the same tensions. Managing energy, not time, is the key to high performance.
[¹]: Brave New Work: Are You Ready to Reinvent Your Organization?
