May the Loops Be With You
Balancing work in product development
In the Star Wars universe everyone can be divided into two different groups based on how they perceive the Force: the ones who don’t perceive it and the ones who can feel it. So are all human on how they see the world around them: event oriented thinkers and system thinkers.
Most of the people can’t perceive the Force. These people define an event as a sequential chain of success: there is always a cause for a problem, if you want to solve it, find the cause and fix it. This state of mind can be applied, as to many environments, for instance to Product Managers’ workflows.
If there is a misbehavior, developers might find the cause and patch it as soon as possible. And that is not wrong nor correct. It is only a behavior.
They react actively to solve the issue and consume resources to fix the situation. That fix is probably going to fail in a short or longer period. If it is not introducing new misbehaviors, it creates a temporary patched solution.
And with the time, a patch falls down.
In the other hand are the Jedi. The ones who own a different mindset. They understand the whole world as a system of Feedback Loops. It is certainly a longer path to master. If there are positive Feedback Loops, the system thinkers can improve the whole system in its own benefits and goals.
The problems never come from customers’ misbehaviors. The origin of the problems resides on the structure of the System and to solve the issues, the system thinkers should understand the structure in order to modify it and cause people to act according as they expect.
The Product Manager has to play both roles.
There is not that much to say about the event oriented thinkers. But a lot about the system thinkers talk we should.
The Problem
The problem that we are trying to solve with this setup is divide the way we approach and solve the different types of tasks that a product team is facing on a daily basis.
Having different ways to solve problems depends of the nature of the problem. We can not try to solve an outage with the same structure we develop a new feature or refactor a data layer.
It is definitely wrong to use the same “tools”. The first that we need to know is to adopt different mindsets for different types of problems.
The Mindset
There are three concepts to learn to become a system thinker:
- All systems are composed of inter-connected parts. All parts are connected in the System and these connections cause behavior from one part to impact the other one. In order to improve the connections, it is necessary to create Feedback Loops.
- The structure of a system determines its behavior. The System is defined by a pattern of connections between the different parts. The success of a System is based on the connections, not on the parts. This determines how the different parts work assembled in harmony. To improve a System, first understand its connections. To modify the behavior of a System is necessary to deeply know how the parts work together.
- Feedback loops control a system’s major dynamic behavior.A feedback loop is a series of connections causing output from one part to eventually influence input to that same part. This circular flow results in large amplification, delay, and dampening effects, which is what causes the gross behavior of the system. Every part is involved in one or more feedback loops. Systems have more feedback loops than parts, which causes unimaginable complexity.
Obviously the main key of System Thinking are the creation of Feedback Loops. And this is anything else than improving the communication between the parts in the whole System.
When a Product Manager creates feedback, is able to control the dynamics on a complex system and so she will be able to modify the connections to improve the behavior of the whole System.
Once we are able to handle and control the dynamics in any loop, then we are able to identify easier wreck points in order to balance the whole system.
Finding the Balance
There are two categories of Feedback Loops: reinforcing and balancing loops. A Feedback Loop occurs when a change in a product comes to cause another change. If that new change goes in the same direction than the previous one, then it is a positive loop (reinforcing); if not it is a balancing loop.
Every change in a product is made according to a goal. Therefore all loops have the same goal. Positive loops are benefitial to make stronger the goal and to improve the product in one direction. Negative feedback loops improves the product based on the microsteps theory. Improving is also negate the negative.
Not having Feedback Loops properly implemented is the only way to keep having unplanned work jeopardizing the whole System. It is a secure path to fail.
Systems Thinking in Product Development
In The Phoenix Project, the masterpiece about DevOps, are pretty well defined the four types of work in IT. Most of the people knows these already.
They are:
- Business Projects
- Internal Projects
- Operational Changes and
- Unplanned Work
These four types of work can be divided on event oriented work and system work based on that the first three works have potentially an impact on business’ goals. Unplanned works are heavily event oriented and their focus is to solve immediate issues.
The only outcome of unplanned work is delay of development on the other three types of tasks. Nothing else. A patched system will eventually fail and make everyone stay awake at night while trying to figure out what failed.
The big truth is that nothing else failed but the control of the Force, the whole structure.
The Dark Side of IT is the unplanned work. It will affect the delivery of projects, deployment of changes, it will delay the planning of future projects and many other daily tasks that belong to the first three types of work.
But there is no light without dark. Minimizing the amount of darkness is also a daily task for a Product Manager and mastering the System Thinking will definitely make possible this desirable balance.
At this stage it is crucial to learn to balance the whole System.
How to achieve that?
I will describe briefly here how my colleagues and I tried to achieve this balance. Product Managers should divide type of mindsets as they divided type of works. Event oriented thinking to tackle unplanned work and system thinking to resolve the rest of work.
But it is definitely not only about implementing that switch.
It is important to have a solid division on what is Planning and what is Execution, which tasks can be planned and what needs immediately a response.
From the product perspective it is needed to split the works in two different categories:
1. Ideas
2. Unplanned work
If you want to have good ideas you must have many ideas. Most of them will be wrong, and what you have to learn is which ones to throw away“ — Linus Pauling
For the unplanned work we established a Service Desk where all the users could have access to report what was causing misbehaviors in any of our customer facing applications. So we could handle easily any unplanned activity.
For the development of new ideas we started using ProdPad (a brutally good tool for product managers) where all the stakeholders can send an idea, that a posteriori and together with product managers would be evaluated according to its business impact and the required effort to materialize it.
During the implementation of these framework we also integrate developers on certain steps of the preparation of an idea. It creates another loop inside, where more information is needed.
At this stage, the developers did not throw a single line of code. The good thing about this is that, when developers receive the tasks, all the needed information is placed on the tasks.
Business jobs and unplanned work are thought to use dedicated channels. That left to Product Managers and Engineers the other kind of jobs. Internal tech jobs and changes should remain inside of the product-technologies working environment.
Systems Thinking and Stakeholders
One of the most important points on Product Development as a System is the stakeholders.
Bringing all them to get into the system, align them, make them understand the necessity of this differentiation between issue types, etc. can be a hard job.
So you need a strategy. Prepare all the set up and let them get on board. There is no need to get deeper in explanations. They just need to help the product development with the creation of ideas and defining the idea’s business impact.
After that, is just a matter of iterate with different frequencies to groom, update and plan the ideas before pushing them to development.
The goal of all this framework is to understand product development as a well balanced system where stakeholders, designers, data analysts, and developers actively work together to boost the product.
If you are struggling with this kind of problems drop me a message. I’d be glad to share our findings with you.
Thanks for reading! If you enjoyed this story, let’s discuss about it and before you go click the clap button and share to help others find it! Also feel free to leave a comment below.
Here is my Twitter.
