There are many skills that Product Leaders find indispensable for success, some of them would be Research, Problem Solving, Prioritization, Strategic thinking, Delegation, Marketing & Communication. Ask a Product Leader how they handle any of these and you will hear about a plethora of Frameworks & Tools. Ask a bit more, and you will hear that a Product leader needs to be both a thinker & Doer who wears different hats all the time.
Mankind is racing to replicate the human brain in a computer to handle almost everything on planet earth – without human intervention. But one seldom realizes that the computer, or more specifically Computational Thinking, can be adopted by humans in almost all aspects of life. I’m not talking about using the computer… but using the way a computer is designed to think to aid human thinking!
Firstly, for those who are new to Computational Thinking: It is a systematic approach to solving problems in a way that can be handled by a computer or a human or both.
Well think of it… a computer can’t find a solution by guess work! One expects it to use the available inputs, solve the intended problem and provide the intended outputs or solutions. Take Google maps for example: When you enter From (Source) and To (Destination), it needs to take those inputs, solve many problems (evaluate available paths, traffic congestion, road blocks, etc.), and finally provide a few shortest paths between the two that meet a predefined set of assumptions. This enables the users to choose the path they prefer and start navigation.
In order to solve problems in the simplest and most predictable way, the process is split into 4 parts:
- Decomposition: Break down large data and problems into smaller problems.
- Pattern Recognition: Observe similarities or patterns in the data & the problems.
- Abstraction: Select or focus on the relevant details while ignoring the irrelevant ones.
- Algorithm: Develop step by step solutions to each of the smaller problems.
One may not need all parts of Computational thinking all the time… but having a mindset like that helps tremendously!
Here are 3 examples in a product journey where one can use Computational thinking.
1. Finding the Unmet needs (Problem Identification):
It all starts with the needs! When exploring a problem area, the Product Leader is usually looking for Unmet Needs of the customer. This stage often involves researching the market, talking to customers/stakeholders, and analyzing the competition. This phase tremendously benefits from Pattern Recognition and Abstraction. When we gather the unmet needs, they usually exhibit patterns or similarities. Recognizing patterns in the data we collect helps us to correlate the unmet needs. Also, once correlated, we can abstract them into one or more high level problem statements. Doing so helps us relate them to similar existing solutions or even come up with new ones.
Here is an example (and you don’t need to understand the technology I describe): About 15 years ago, I was working on an Ethernet Switching protocol called “Rapid Spanning Tree Protocol” that needed extensive configuration to find an alternate path for the network data traffic if an existing data path fails. My Japanese customer complained about the complexity, the delays introduced in finding new data paths (well it was not rapid enough for his network 🙂 ), and wanted a much simpler and predictable way to find an alternate data path in the network. After some elaborate discussions, I recognized the patterns in his unmet needs and abstracted it to mean that “I want a simple toggle/switch from a predetermined first path to a predetermined second path if the first path fails”. As simple as it seems, that led me to a patent that did exactly that with minimal configuration that brought down the network outage from around 2 seconds to 50 milliseconds.
The reason I was able to get to the solution and the patent idea was that the abstraction (leaving out the protocol details and focusing on the core need) made me look at it differently without bias!
2. Assumptions -> Hypotheses -> Validation:
One of the primary roles of a Product Leader is to gather assumptions about a product and get them validated. This not only prevents making wrong product decisions, but also helps to prioritize the right set of features. This is where Decomposition helps. Many of the solutions are complex to validate as a whole in one shot. It is easier to validate solutions to problems by Decomposing them into many smaller assumptions. This would be a team effort where all stakeholders engage in unfettered thinking and list down all assumptions. It helps the team gather all the assumptions: {Value – Growth}, {High Risk – Low Risk}, {Urgent – Not-Urgent}, {Quantitative – Qualitative}, {Subjective – Objective}, {Internal – External}, {Relevant – Irrelevant}, etc. The assumptions would then be converted to hypotheses that can be validated. At the end of this Decomposition exercise, the team will be able to find Patterns in the Hypotheses. This will help the team abstract them into different buckets, create Personas for validation, and delegate each set of abstracted hypotheses to the right stakeholders for validation.
In his book “The Lean Startup”, Eric Ries talks about the “Build, Measure, Learn” loop and how it can foster continuous innovation. Instead of testing a lot of assumptions, Eric Ries talks about Validated Learning to systematically figure out the right thing to build by selecting a few assumptions to validate. The Decomposition exercise would be critical to get the right assumptions to be validated.
3. Delegation
A Product Leader needs to correctly identify, delineate and delegate tasks… most often without authority. When one needs to influence without authority, where the roles and responsibilities of subgroups overlap and needs tight coordination, one needs to be accurate. The delegation should not seem like the Product Leader is influencing the solution. At the same time, it should not be vague allowing for scope creep or misinterpretation. This is where Abstraction helps tremendously. If the Product Leader gets the abstraction right, the delegation will be successful.
Accurate abstraction is an art. One gets better with practice. I have found that the most effective way to find out if your abstraction is accurate is to ask the delegated person to explain it back to you in their own words. You will save a lot of time and effort by doing this.
OK.. Algorithms? Why is that helpful?
The Algorithm part of Computational thinking would be the final part of our thinking process This will be the step by step execution of the tasks. But one cannot get into execution unless the sequence of each of the steps are clear. The Algorithm part will be right only if the other parts of Computational Thinking have been carried out correctly. Successful Product Leaders do this systematically.
IN CONCLUSION
Well, if I can give you one takeaway about Computational thinking, it would be this: Human beings are curious by nature. That curiosity is what gets us to identify and solve problems. If we embed Computational thinking into that curiosity to solve problems, it will be more systematic, efficient and effective. But remember one thing: Never get into the Algorithm phase without first covering the other parts of the Computational Thinking process. This may seem like a cliche – Don’t put the proverbial cart before the horse. Good Product Leaders will always keep the sequencing of the steps to the last!
“The secret of change is to focus all of your energy, not on fighting the old, but on building the new.” – Socrates.
There are two ways to look at a problem. It’s a problem and it’s a problem. However, it is much simpler to look for a solution!
Amazing article on relating computational thinking to product leadership. I don’t see many articles on the web on this subject. You have done a great job in elucidating the process with examples.
The abstraction of the Japanese customer’s needs is done well.
Thank you. There may be some articles sitting somewhere yet to be found :-). But I’m glad you liked it.
I would like more of your thoughts on this article. I’ll really appreciate it.
The delegation example for using abstraction is great. You are correct in saying many get it wrong. Often times it goes through multiple hands before a requirement is implemented. When it changes hands, the delegated work may have to be split between two or more team members. That would require decomposition and further delegation. The product leader can’t be doing that for all the teams.
Unless the entire team is trained to do this, many things can go wrong. Clear and frequent communication can help significantly. That is one of the reasons the Product Leader would have to attend the Review or Stand up meetings periodically… instead of being surprised at the implementation after completion!
Spot on. Delegation without authority has many challenges. Product Leader needs to coordinate many teams and having a clear structure and set of tools for communication goes a long way.
Great job Gokul.
Thank you.
Nice extrapolation for “The Lean Startup” by Eric Ries.
The Lean Startup is a bible :-). There is a lot of implicit references to Computational Thinking in the book. Its amazing how the “Build Measure Learn” can be applied to so many other areas – Like building personal relationship, Finding one’s true purpose.
I haven’t mentioned the other parts of Computational thinking like Logical reasoning, etc. Some day I might write more on this subject.
Interesting. Build Measure Learn applied to subjective uses cases in ones own life situations. That would mean try to validate your assumptions (or perceptions) about your relationship with your girlfriend/boyfriend in a systematic way so as to not loose time in finding the right partner. You should write about it.
Ahem!! I don’t want to stir a hornet’s nest :-).
Great explanation. In my experience, I see people trying to use all parts of computational thinking in sequence in a rigid manner and eventually stop using the computational thinking framework as they find unfettered and unstructured thinking easier. Many times they want to use heuristics or make giant leaps while reasoning and find computational thinking constraining their thought process.
Identifying when structured thinking is needed would help. Nobody has failed with innovation by adding structure. Just don’t make it rigid.