There are some key learnings for product managers from Peter Senge’s ‘The Art and Practice of the Learning Organization’ and lean principles. I have extracted three of them and their applications to product management here:
- Keep away from “I am my position” syndrome
This is has been identified as one of the learning disabilities in organizations.“When people are asked what they do for a living, they often describe the tasks they perform everyday, not the purpose of the enterprise of which they are part of. Most see themselves within a system over which they have little or no influence.”
A product manager must not take this standpoint especially because one has to work across organizational boundaries to achieve success. Focusing only on your position and protecting it does not result in a great product. A product manager has to feel a sense of overall responsibility for the results produced when all positions within an organization interact and be a catalyst in enabling these interactions.
- Be very slow to judge
Each one of us has a tendency to blame someone else when something goes wrong, this begins in our early years in this world. Its most common form in organizations is when one department blames another. A product manager who exhibits ‘I am my position’ syndrome often fails to see how his/her actions extend beyond the boundary of the role. Each person’s actions has consequences, and these actions often do come back to hurt us, and very often these problems are perceived as externally caused. People’s behavior is based on the the system they work within, this means we must be slow to judge. There are some complex dynamics in workplaces.
- Understand overburden produces waste
It is common for customers to apply high pressure when it comes to release dates, and the easiest thing to do is to pass this pressure straight down to development. Who does development pass on the pressure to? Code of course, developers perform some quality-destroying shortcuts and introduce technical debt into the system. A short-term goal maybe achieved e.g. deadlines for current release is met, however future releases slow down and the pressure is on again and this visious cycle continues. Overburdening developers results in quick gains that may seem fine at the outset, but introduces waste in the future.