The single biggest problem with communication.
George Bernard Shaw once said the single biggest problem with communication is the illusion that it had happened at all.
Arti and I have worked as scientists (biology), have a combined experience of 12 years in product management, and across all of these, we have to agree with Mr. Shaw.
Working in both science and product management (software) has afforded us some unique perspectives on leading talented teams; with remote and in-house teams, mobile and web tech, for and non-profit companies, and consumer and network technology products. Through it all, we’ve built a POV on the art [and science] of communications.
Since we see communication as the most critical element in leading successful product teams, we paired up to write this post and offer a few distinct lessons. Our post draws from our experiences as biologists and product managers, along with some favorite discussions in books like Algorithms to Live By, The Art of Scientific Investigation, and thought & practice leaders in the field (Ex: here, here, and here)
First, a story
It’s your first day on the job. You know at least 4 people in the company because they were the ones that interviewed you. Beyond that, you know a little about the product, the business model, and if there is one, a little about the company’s marketing and distribution strategy.
At this point you are hungry for knowledge and a deeper understanding of it all.
What do you do first?
- Demo the product, review product specs, read user feedback (if there is any) and have lunch with your new manager and team on Day 3.
- Learn the tech stack, read documentation (if there is any), dive into the backlog and start creating a product roadmap and JIRA tickets based on feedback of what features users have said they want.
Yes, A & B are important tasks. When and how they happen, though, depends on you creating a critical and predictable process around communications that ultimately will drive clarity and action around expectations (for you and others), goals, deadlines, and work flows.
So, your first weeks are the beginning of one of the most important processes you will ever own: Establishing communication protocols with all stakeholders involved in the product’s development.
Let’s start your first week a new way…
Untangle the web.
When you step into any new environment, approach it with a constant drive to understand the context of how each new person, idea, product, or process fits into the bigger picture. What are the inputs to the system, how does that input get processed, and what are the outputs that are directly related to that primary input?
This demands you use a skill you will use often regardless of where you are: active listening. This means the intense curiosity, with a seek-to-understand-before-being-understood practice that got you hired, now gets unleashed.
Active listening helps you to uncover the unseen, the unmentioned, the hidden bits that are below the superficial flotsam at the top and obvious.
Here are four ways to hone your approach and start setting up your organization’s communication in your first weeks:
- Listen first. Restrain your ego from taking over in these investigative conversations, and avoid jumping into your pre-programmed “Get shit done”, solution mode. That is detrimental to establishing effective and purposeful communications, and importantly, weakens your ability to build products people want. More importantly, by applying a “listening-first” approach, you’re telling your team that you value their ideas, thereby building the trust amongst your team members that is essential to building great products.
“We are prone to see what lies behind our eyes rather than what appears before them.” — Thomas Huxley
- Validate that communications were received. This is the first question for any protocol, human or machine. Whether it’s RNA transcription, cell-to-cell communications, or a central nervous system, you’ll find clear evidence demonstrating that these biological processes rely on validating whether or not chemical messages were correctly delivered. Build in validation into your communication protocols from the onset of establishing these lines of communication.
- Understand your endpoints, and determine if they are effective* and where there are lags, drops or inefficiencies. You might have to establish new ones for clearer and more effective communications. Note of caution: Remember, as your team size increases, the number of links to manage get downright hairy.
Note: *What is “effective”? This should be defined by you, and always in service of the business’s goals, milestones and the specific problems your products are trying solve.
“A small business of 50 people has an incredible 1225 links to manage.” — Janet Choi
- Prepare yourself, and everyone else, for over-communication. Additive Increase, Multiplicative Decrease (AIMD) is a feedback control algorithm designed to manage flow and congestion in TCP traffic. Similar to the mechanism used to manage TCP communications, you must ready your teams for this schema; you giving more (increasing the volume of communication), and a little more, then more… then pulling back (decreasing the volume — an overflow response), then a little more, then more. Be ready to talk about why and when you’ll do this with them, inviting ideas around the how.
Why biology is an excellent teacher
In biological systems, we felt the monumental challenge of unraveling individual components from the whole. At the macro level like animal ecology and behavior, for example, understanding a monk seal’s population size depends on everything from its physiology (at various moments in time) to ocean chemistry and temperatures. In order to understand how the tiniest of measures fit into the animal’s overall operation, we had to have a deeper understanding for the big picture. Understanding your “why” as a product manager, for the business, matters in everything you do.
Similarly, in our role as product managers, we now see a level and complexity of interconnections in the communications on a team that are very similar to our previous research work. As researchers, we saw the constant evolution of biological processes as evidence of the ultimate agile development machine, a system hell bent on making communications (feedback loops full of information) as clear, efficient, and effective as possible in order to realize many different goals.
Questions to get started
There are an incredible number of examples, both in the biological and artificial world of communication protocols, that are designed to understand and transmit information through a web of complex organizational processes. As a product manager it is to your entire team’s benefit that you understand where you, your role, and the output of your work, fit in the organization’s bigger picture.
Hold one on one meetings with as many people in the organization, and ask them four primary questions:
- What are you currently working on? Why?
- What are the 3 biggest pain points you experience in your day to day work? Why?
- How do you see your role in creating the product’s value?
- How do you see your role in the company’s mission?
When you’re approaching these interviews, pay close attention to your style. Are you leading (or “priming”) the other person with your questions? This refers to whether, or by how much, you make it easier for the person to answer the question by giving them an idea of the answer you want.
Guard against this by asking open, probing questions. Asking “why” as a follow up to your questions gets you closer to root causes or challenges that help you uncover where your work on communications can start. You want to know, from their perspective, how they view their work in the larger mission of the organization.
The four methods we gave you above will help you understand how each node fits into the larger picture of the organization. Every organization is a tangled web, and every new employee can either add to the unstructured nature of that web, or work to tease the knots out of it. Far from a one-time exercise, practicing these on a regular basis will allow your teams to work more on building products people want and less time pointing fingers.
. . . . . . . . . . . . . .
Please give us some love below by recommending this article, and we’ll take this as a sign we should keep writing.
If you’ve learned something from this, or have comments to add, we’d love to hear them!
