Influenced by pointillism- Software engineer’s guide to product management
Early in my career as a software engineering intern, the tech lead shared this story with me.
“ There was a wise Zen master. People from far and near visited him to seek his counsel. One day an entrepreneur visited the Zen master to seek his advise. The entrepreneur introduced himself and went on to talk about his various accomplishments and travels. The Zen master listened quietly and suggested they discuss further over a cup of tea. When the tea was served, the Zen master poured the tea in the cup and continued to do so even as the cup was overflowing . The tea was spilling all over the carpet and the entrepreneur yelled , “Stop , cant you see that the cup is full?”. The master replied, “You are like the full tea cup. Come back with a empty mind if you seek to learn”.
Never has this story resonated more, than in my transition to product management. As a software engineer going over requirements , it seems like a voice is whispering through the brains, relating all the ways to deduce the right logic, the catalog of tools to solve the problem. We are the answers to all the business problems; how can we take that manually generated excel report and transform it into an online dashboard that emails you alerts every day or wait … how do we first get some of this dark data into cloud… or if given our druthers, we prefer to write a service… But as a product manager, the question is never “How can I solve this?”, but rather “What are we trying to solve” and more importantly “ Why do you need this?”.
The key to a requirement session with the business team is to start from tabula rasa and reason. While its virtually impossible to go in with a clean slate, it helps to be aware, present and curious. The business client possesses the wisdom of the past and present working of the process in question. In the Chris Voss’s , Never Split the Difference: Negotiating as if Your Life Depended on It, he mentions “The goal is to uncover as much information as possible. To quiet the voices in your head, make your sole and all-encompassing focus the other person and what they have to say.” Although Voss’s advice is for negotiations, it definitely applies here .The business team may not be aware of the benefits of swapping their excel macros with efficacious panda libraries for data analysis.But this is not a time to excogitate an answer, instead embrace this moment of learning; of opening the mind to see the world from the new optics lent to you.A world where request response is not as important as the layers of nuances that lie in between to help navigate the decision making process. Before trying to wrap this complex requirement into a logical code, look at the picture as you were observing a painting created using pointillism technique.
Even if you are not an aesthete, painting styles involving pointillism make you pause and observe the beauty. It sets of a tussle between your eyes and brain as you take in the “Snow on Alden Brook” by Neil Welliver. While your eyes curiously focuses in on those contrasting juxtaposition of dots, you also take in the overall painting. There is poetry , there is science and together they trick you into submitting to this external stimuli. But understanding the creation process of the pointillism styled painting and applying it to product management is what I want to discuss here.
Immerse in the experience. Artists who use pointillism techniques spend more time familiarizing themselves with the subject.
Instead of looking at the problem in insularity, seek to understand the underlying the impetus for the request. Discovery sessions and innovation days might help bring the spotlight on critical challenges, but gaining the intimacy through good old old fashioned interviews with business clients helps us understand why they do what they do. For instance as a product manager its common to get ad hoc requests from business teams on enhancing outdated tools to get through daily activities. Instead of trying to solution this by bringing the latest and most robust software ; don the role of the business client. Understanding the current process and strategy helps us to ascertain the criticality of the problem and if its something that is going to last a long time or if its a short term fix. Step further back out and understand the organizational goals, is there an enterprise solution being developed or already in place that can be leveraged to support this request. The hardest part for an engineer is to make those broad strokes without being bogged down in technical minutia.
Draw the ideas in its entirety . Artists start my sketching the painting on an canvas to create a guideline for the end product
Start by building an end to end process flow and then focus on the problem. Building a process map helps bubble up other steps in the process that can benefit from the solution and ensures that the final product seamlessly ties into the day to day activities. Sometimes business teams are so used to performing the quotidian tasks like second nature that they don’t look to enhance routine, the requests are mostly around the ones that are broken and need fixing. To put things in context, there might be a request to build a tool for risk analysis; a tool to understand external impacts on margin that helps business plan accordingly. A need for this tool arises because the data needed to do a “What if analysis” is unstructured and requires manual intervention. But there could be other core activities leading up to this process that involves using outdated BI solutions and the steps to upload the external risk factors could be delayed and often error prone. In this context, building an advanced risk analysis tool while helpful will in no way significantly improve the throughput or the accuracy, because the business team will still rely on their existing activity done by rote, however cumbersome. Additionally,if the upstream process of loading the risk factors is not fixed, the tool is going to be rendered useless. Before investing in the solution, clarify the efficiency of the process and the existing systems in place.
Build the work in pieces. The Artist leaves nothing to chance in creating the well orchestrated and precise final product.
In the requirements phase, product managers often prioritize tasks based on time constraints, urgency and level of effort needed. A software engineer’s strength in obsessing over the details shines through in this phase. Often business tends to overlook the data or system dependencies between the tasks, but thinking through solutions in a data flow diagram unveils formulations to problems that would have cropped later in the project only to create reworks. This is a time to reify the business process as technical constructs and build upon the perceptions consumed from an engineering background. Bringing a developer’s view in this process phase will bring to light technical challenges that have to ironed out in the requirement phase itself so as to not disrupt the development phase.
In conclusion , leave behind the promptings of technical wisdom and be there to learn the business processes and capture critical requirements and additional desiderata. Decisions must be made after looking at the process in its entirety, one broken streak of process will cause a ripple- down effect and can domino into downstream processes and prevent the project from coming to fruition. Lastly, use your problem- solving technical background to add those finishing touches to the requirements by narrowing in on the details and addressing complexities that might arise in the development and implementation phase.
Reference : https://crystalbridges.org/blog/neil-welliver-snow-on-alden-brook/
