Communicating technical stuff with broader audiences

I've been working as a Product Manager for products with a huge technical load for a while, and I love it. First for the backend and Public APIs at GoTo (ex LogMeIn), and now taking care of Build and Deploy pipes at Vercel.

One big challenge that you usually face when working with this kind of product is how you communicate your work, vision, and even projects with people who are not fully embedded in the team or the technology behind those products.

I've always liked the idea, that when communicating about your product, you should think about what are you enabling with this message. Always communicate with the end goal of enabling your receptor to do something they couldn't do before they got this new information.

Enable other people to help

Translating the enablement philosophy to communicating with colleagues, the main goal is usually enabling them to help with the development of the product. Finding new angles, new use cases, or invalidating assumptions.

But something you can't neglect is that not all stakeholders are technical enough to feel comfortable engaging in those discussions unless you put your part in including them. Sometimes you can be losing great resources just because your communication is excluding certain folks and working against your product's success.

Focus on value to the customer

This one might sound trivial, but always focus on what's the value for the customer when communicating recent changes, or current projects. Try to not fall into deep technical details, you can add it for whoever is interested, but to the broader audience try to keep it focused on their day-to-day vocabulary and metrics.

It's easier to understand that you'll be working on reducing the time to connect to a call, rather than on making the service API-call-pairing 2x faster. Tying your communication to the value perceived by the customer is generally the best way to communicate with a broader audience.

This can help a lot to open communication about for example, how relevant is that work for your user base, if there is some dealignment between organizations on what are we focusing on, or even enable a customer success folk to update a customer having issues with the time to connect to a call that an update is coming.

Make it tangible

Whenever you can, you should advocate for making your efforts tangible. Try to communicate specific examples, and avoid being vague. It's really nice having a concrete specific example instead of an abstract explanation.

What do I mean? For example, if you are improving the building time, besides communicating that it has been improved and the order of magnitude. It's always a good touch to go with specific numbers on how much it affected particular customers.

It's easier to empathize with a specific user you've been following their pain, and seeing how much easier their life will be. It also opens the door to better and more compelling communication with your customers.

Do the inverse work too

Something I'd like to close with is that this is a bi-directional relationship, you should also do the same the other way around. You must always be clear with your more technical folks, on what is the value for the customers when they work on something.

Mapping your current work into customers' value is a key factor to keep the team focused, you should do it frequently. Ideally, your development culture should be heavily focused on the customers. With empowered engineers who can make decisions based on improving customers' life.