The Gap between the R&D and the product managementPosted: August 26, 2009
While looking around in any organization, you most probably recognize the Gap between the product management/PO and the R&D/Teams/designers. It is significant in surprisingly small organizations.
This becomes obvious when starting Scrum. The Gap has always been there. Why? What have been the workarounds earlier? Why is it important to understand the root cause? Actually there are more gaps on the value stream…
Have you ever heard the following, when taking Scrum into use:
Team: Scrum says Give us the prioritized backlog.
Product manager: Yes, but we don’t know about tech, you do. Here You have the 5-liner. Just start working.
Team: Yes, but we need to know where to start.
PM: Yes, but we can’t prioritize technical items, you have always done it.
Team: But we can not work if we don’t know the priorities for the next sprint.
PM: What’s wrong with you?
And so on…
The Gap means simply that there is too little knowledge power, too few people who would understand both technology and business. I have many many times experienced how drawing this picture on a flipboard will stop the blame war in the room, when people realize that it is the system, not us.
When looking back in the history of the organization, you most probably find at least some symptoms of the Gap:
- Totally unrealistic early effort estimations (seen 10-fold errors)
- Confusion about priorities, progress, responsibilities, commitments, ownership or resources
- No common vocabulary — even more confusion
- Excuses, ping-pong of responsibilities and blaming
- Waiting — no skills, ownership or resources
- add Your own favorite
So the Gap has always been there. Likewise there have always been talented individuals who have filled the Gap.
- Projects have bridged the Gap one at a time. It has been effective, but not necessarily optimal. Using projects, the device for one time solution, easily leads to short term local optimization, and leaves long term development undone. It also tends to undervalue the voice of the designers. If the situation has grown bad, there are messianic expectations towards the project manager.
- Establish a system engineering or architect role/group. This solution is serving the knowledge creation and organizational memory better. It certainly makes one handover more. The architects easily become the bottlenecks, and the capacity of the designers is not fully utilized.
- Superficial Scrum is a good candidate for the next fill, with the product owner as the new hero.
This has been patching, it is better to solve the root cause.
The cause of the Gap
There are natural conflicting interests and thus Tension. The customer would like to have better products cheaper and faster. The designers work in the production reality with limited capability and need for fairness. And the product management is in the middle, transmitting the customer needs to the R&D and back, trying to make business.
Of course everyone needs the organization to stay alive, the parties have a shared interest too.
The pattern, now called the Gap, emerges in the complex organization, based on local interaction. The intelligent agents, managers and designers, human beings, try to minimize their exposure to the painful Tension. The “natural” solution is to avoid interaction, to keep within one’s own role and subculture, to seek safety from the own kin. This leads to alienation from the other party, avoiding empathy, avoid emotions by rationalization, bluntly deny issues, postpone everything to big batches, dilute issues by abstracting. There are innumerable defenses in action.
So it seems that the Gap is natural. Instead, creating flow, learning and decision making capability requires enlightened leadership. The benefits of Scrum and Lean are obvious.
The Medicine for one Gap
The first medicine is the continuous flow of small batches done. Since the emotional reasons are so strong in forming the Gap, I emphasize the emotional side of small batches.
- Small batches are less complicated, understandable and manageable to the limited human cognition. (the more people the more limited)
- The emotional load transferred and born at the interaction can be handled, is not too much.
- The flow of batches enables the flow of feedback and learning. Learning is proportional to the number of cycles, not size.
The second key medicine is the conscious knowledge creation and sharing. Knowledge is relevant, when it helps you to make good decisions. The designers need to know about the customers and end-users. The Customer interface needs to know about the technology and R&D capabilities. The practical cross-pollination happens by making the practical decisions together.
In military organizations it has long been realized, that the mass of critical decisions are made at the frontier. The empowerment and decision making capability of the periphery is heavily developed by training, simulations and so on.
The greatness of Scrum is that it a) brings the Tension between the Team and PO to the center of attention b) provides robust guidelines to deal with it. This is truly unique ingenuity.
Help for the Product Owner?
However, Scrum does not provide much for the Product Owner to deal with a wider world. Traditionally it may have looked like this.
The Gaps are opening to the discontinuities of the value stream; organizational, geographical, cultural and power related. In big organizations the stakes and the Tension are high. It may happen that there is one point, one Gap, in the chain where all the pain concentrates.
In addition to the previously mentioned medicines for one Gap, this organization needs to minimize the number of gaps by teamwork and different topology, getting R&D to interact with end-users and so on. Lean has good advice for this.
I will come back with some thoughts about the product owner, the Tension, big product and multiple customers.