better communication means better product

Many product development problems are complex or [shudder] wicked. They’re more intricate than they may seem, they change over time, and they involve humans. It may seem paradoxical, then, to say that a significant contributing factor to product dev problems is simple to express:

communication is the problem

someone somewhere

A lot of the problems that I encounter in my current product role stem from poor communication between users and designers, between designers and developers, between developers and QA testers, between product managers, and senior leaders, and between product teams and other teams in an organization.

  • Poor communication undermines research insights and design decisions.
  • Poor communication produces poor sprint plans.
  • Poor communication undermines backlog refinement.
  • Poor communication produces poor relationships and weak alliances.

… and the list goes on.

The neat thing about this insight is that you can do something about it right away. You can make small changes in your daily routine; ones that by definition won’t require you to overhaul the way you interact with your team.

You can ask more clarifying questions, you can check your understanding more frequently, and you can capture more details that result from both of these activities.

Here are some understanding checks that I cycle through on the regular:

Let me make sure I’m tracking what you’re saying; ___________. Am I on the trolley?”

“I just want to confirm that I get it, so let me say it back to you in a different way. _______________. Does that sound right to you?”

“I don’t understand. Can you explain it to me like I’m in middle school?”

“It sounds like you’re saying __________. Is that right?”

and the classic, effective “Wait. What?”

When I ask these (and others) I usually have Notes open on my desktop (I’m a Macbook user…) and I jot down a few details to capture the exchange and its key outcomes. This way I have both a record of the exchange in case I need to trot it out to remind the team and, more importantly, I make its details more concrete in my own mind so that when someone else asks me about a schedule, a feature, etc., I can likely communicate my current understanding more efficiently and effectively.

Published by

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: