Product Managers Are Outsiders in the Product Development Process
There are two underlying problems for Product Managers when considering any product development process, whether it is Agile, Waterfall, or a hybrid process.
- The product development process is a subset of a larger product process (from product conception, to detailed business planning, all the way through end-of-life). However, while the product development process is usually well defined and defended, the overall product process is often ad-hoc, if it exists at all. Consequently, the more well-defined development process becomes the common understanding of the “product process,” even though it lacks a complete view of how product value is created and measured.
- Because the product development process is owned by engineering, the product manager has limited influence over the outcomes. As most product managers are well aware, there are hundreds, if not thousands of micro-decisions affecting the product that take place daily in the product development process. How can a product manager step in and lead when the process itself is owned by another part of the organization?
Agile methodologies attempt to address the second issue, and we can see this in scrum through the role of the product owner and the use of retrospectives.
But is there more that product managers can be doing to address these process issues? Yes, there is.
But as Einstein reminds us, the answers can’t be found at the same level of thinking that created the problem. We need to take a step back and look more holistically at the system.
What is Systems Thinking?
In Peter Senge’s highly influential book The Fifth Discipline, he describes systems thinking as “a way of thinking about, and a language for describing and understanding, the forces and interrelationships that shape the behavior of systems.” Which sounds very conceptual and is hard to wrap our heads around. He goes on to explain,
“Have you ever seen in a family, people producing consequences in the family, how people act, how people feel, that aren’t what anybody intends?’ Yes. ‘How does that happen?’ Well… then people tell their stories and think about it. But that then grounds people in not the jargon of ‘system’ or ‘systems thinking’ but the reality – that we live in webs of interdependence.”
Have you ever seen the product process, with its subset the product development process, produce unintended consequences? Produce defects, clash of egos/prioritizations, tradeoffs, compromises, or even end resulting products that were unintended?
Taking a high-level, interconnected system view of the product process can lead to new ways of understanding how products get defined, built, communicated, and maintained. And as a product manager, our role sits directly at the hub of the entire system, there is no one better placed or more directly responsible for understanding and guiding the system, than us.
The Iceberg Model
The Iceberg Model, formulated by M. Goodman in 2002, is a direct and practical way to utilize systems thinking. It states that the tip of the system iceberg looks at events, what is happening right now, and usually leads to knee-jerk reactions that are short-term and symptom-focused.
- For example, let’s say that engineering resources are moved from your project onto another project. You react vehemently defending your resources, going to your management and engineering management attempting to get resources back on your product. How successful are you?
Just below the surface of the water on the iceberg is a deeper level of thinking, and that is seeking out trends. Does this event happen often? What are the usual ways we solve this issue and does it have any long-term benefits or does it simply create more problems?
- In our example, you could look at how often resources are moved between projects. Is there some way for you to predict or influence this event that you haven’t seen or tried before? If it has happened before, what was the outcome to both your product, but also to the whole organization? Can you expect the same outcome this time? If you were to approach the problem with more trending data, would you be more successful in changing it?
Digging deeper into the iceberg, we find another level that explores the structures that create the trends. What is it about how our business or decision-making processes are set up that continue to create the same situation?
- For our example, how is the overall value creation of products measured and is it even part of the decision making? What sort of risks is the company comfortable undertaking by shifting resources? What triggers the resource shift? Who is making the decisions and what data are they using?
Finally, we get to the deepest level of the iceberg, down in the murky waters that are the mental models of the organization. Here is where you evaluate what kinds of beliefs and assumptions are supporting the structures.
- For our example, is there a fundamental expectation that PMs should be competing for resources? What beliefs exist around authority (both by the organization, and yourself) that would have the PM not be part of this decision-making? Do you feel powerless, or are you inserting yourself into the process?
Using Systems Thinking to Influence Your Product Development Process
As product managers there are some key ways to use systems thinking to influence all the processes surrounding our products, including the product development process.
Applying the ideas in the Iceberg model will help us move away from fire-fighting and start addressing root issues that impact long-term benefits. It will help align others through shared thinking, and will reveal leverage points where we can make small process changes to get maximum benefits.
Iceberg Level 1 (Events): Get Past Your Own Reactivity
If we want to influence at a deeper level we have to stop being reactive, stop thinking at the most shallow levels, and bring ourselves into deeper understanding of the problems and what we’re capable of.
Essentially, stop blaming others for our situations and see ourselves as powerful enough to make a difference in the system.
Iceberg Level 2 (Trends): Triangulate
Get new views of the trends that are taking place. One way of doing this is through feedback loops coupled with a mind to continuous improvement.
First, of course, take advantage of all engineering retrospectives that you can. But also implement feedback loops with other parts of the organization such as customer support, training, finance and legal, as well as with other product managers.
Find out what has been happening? Where are the changes? What can we predict? What are best practices and do they still work? Are there even better processes? Where are the breakdowns? This will give you insights into other people’s processes, how to improve coordination with them, and move away from competition and into collaboration.
Iceberg Level 3 (Structure): Establish a Well-Defined Product Process and Set Product Goals
Two of the strongest ways to establish a structure to support your product are through a coherent product process and through the creation of clear product goals.
If you do not already have a well-defined product process, then get one. I am a big fan of The 280 Group’s Optimal Product Process which I find to be thorough and flexible, but there are others. You need to learn then practice your product process; walk the talk, support it, get it sponsored, teach it to the organization and evangelize it. (The 280 Group has tools to help with all of this.)
Secondly, it is said that systems will self-organize around whatever goals are established, so you want to be driving the goals as much as possible. This means that you need to:
- Establish clear product goals that people can feel motivated to achieve. ROI, roadmaps, MVP, personas, problem statements, user stories and acceptance criteria are all part of the product goals that impact the product development process. Make sure that you’re including the opinions of all the relevant stakeholders when you establish those goals so that all parties will feel an ownership to achieve them.
- Understand the competing goals. For example, all of your engineers all have personal goals set with their own managers that will determine if they are successful or not (if they will get a raise or not.) Do you know those goals? How can your product goals be framed to support those goals? Other products also have goals—how can you work with other product managers to determine which set of goals across a portfolio will result in the highest value for the organization?
Iceberg Level 4 (Mental Models): Product Vision, Passion, Commitment
While it can be difficult to overcome some detrimental mental models, such as pitting product managers against each other to compete for resources, or sacrificing product value creation for a single individual’s personal political gain, there are some tools in a product manager’s toolkit here.
The most powerful tools are your product vision, coupled with your passion and commitment to that vision. We talked about how to create a product vision in a previous blog, so I won’t repeat that information here. But hopefully now you can see why it is so important to have one, because it establishes the mental model for the product team.
And remember, there is not a single person in the organization that will ever have more passion or commitment to your vision than you, so it is important that you set the bar high, very high.
Give It Time
Finally, understand that it may take time to discern, develop, and apply alternative behaviors in your organization. People have been doing things a particular way, possibly for a long time, and find comfort in repeating old patterns. Keep learning, keep walking your talk, keep moving forward.
To learn more about how to create positive change in you organization, take the 280 Group’s Leadership for Product Managers Training Course, or People Skills for Product Managers and Product Marketers, which teaches you the people skills that elevate Product Managers to the next level.