Communicating with other product teams
Building internal products takes a village. Sometimes you have to work with that other village down the road. Make sure you’re intentional with that communication.
Some experiences over the past few months have helped me realize that many problems product teams face do not require an upset the apple cart agile transformation, or overbearing new processes.
You can often solve, or even prevent, many problems by being more intentional about how you communicate with people inside and outside your team.
Lessons learned working with outside teams
My product team is working a new integration with a third party service party that required a couple new APIs. The interaction has been a little rocky with several fits and starts. This experience reinforced some lessons about working with teams outside your product team.
It also so happens that a couple of these lessons cross over to one of the 7D’s - describe your solution. I guess that goes to show how these activities are all interconnected.
Use consistent language
Eric Evans coined the term ubiquitous language for the practice of establishing a common, rigorous language between a product team and users.
In practice this means you use business terms for the data objects in API requests and responses. That way, you can talk about the data you’re exchanging and it’s clear to your users what you’re talking about.
Creating your API definitions with business terms is the first step. Consistently using those terms when you’re talking about those concepts is the next step.
There are business terms such as price, cost, and dates that have very specific meanings and often require more specificity. There may be multiple dates that you care about, or you may have multiple prices that are relevant.
So if you have an attribute in your API request called dealerCost, don’t use other names to refer to it in communication.
You went to the trouble to give the attribute a business specific name. It’s ok, and actually quite helpful, to be pedantic about using that specific term when referring to it.
Clarify with examples
A truly helpful API spec provides a bit of metadata about attributes in requests and responses including:
Attribute names
Any limitations on formats
A brief description of the attributes
Examples of expected values.
The list of examples of expected values is helpful if the attribute contains some form of code.
If the attribute contains numeric values or is a date, the best kind of an example is a complete set of data for a request so you can see expected values in context.
For example if a cost field depends on a calculation involving other attributes in the request (you could argue whether this is a good idea) it’s helpful to provide a full example so that the team you’re working with can see what values you expect.
Follow the email golden rule
When you work with a team outside your organization, it’s likely your main form of communication with that team is email.
Given that fact, it’s important to remember some key aspects about communication via email. First, do not treat it as a synchronous communication mechanism. You should not expect people to respond to emails immediately after you send them.
Second, keep the email golden rule in mind. In case you’re not familiar, the general golden rule is “Do unto others as you would have them do unto you.”
When applied to the asynchronous nature of email, the golden rule means live up to response times that you expect from others.
To put it in practical terms, don’t let an email sit from a team you’re working with for a week, and then turn around and hound that team when you don’t receive a response from one of your emails within a couple of hours.
That’s not a way to build a strong working relationship between teams.
There’s a lot more to communication than sharing API specs, so here are some additional resources on communicating in and among product teams.
Effective Communications: A simple framework for Product Managers
Raise your hand if you’ve seen “excellent written and verbal communication skills” on every job description you’ve ever seen? It’s such a basic expectation of all roles, that the importance of communications in the context of product management is a little lost. There’s a lot here, and this is probably one of my longest posts, but it’s really critical and there is A LOT to cover.
The role of product manager is a central linking point between many teams, and has the ability to impact the business in a large way. If a PM is anything less than an awesome communicator they will struggle in the role and struggle to move up.
Chris Petersen put together this framework to help you improve your product management communication skills.
Understanding the 3 Product Manager Communication Streams
No two interactions are the same, and each interpersonal dynamic is slightly different. But the majority of your professional communications fall into three categories: horizontal, vertical, and external. The folks from ProductPlan explore each of the three product manager communication streams, examining why they’re different, and how to optimize your delivery for each.
Optimizing internal product communications
A lot of your time as a product person is spent communicating with other people in your organization. There’s high-level communication and discussion, and there’s low-level interaction with stakeholders about the day-to-day of the product’s development and operation.
It seems that you’re endlessly providing (or seeking) answers about anything related to the product. This happens naturally, because your role is at the center of the process that figures out what to build, builds it, and then gets it into the hands of users. The cross-functional nature of what you do means that you have to align and inform everyone around you.
Daniel Zacarias explains thatIf you stop to think a little bit about your internal communication strategy you can be both more effective in getting the message through, and reduce the amount of time you spend on it.
Five Essential Rules of Remote Communication
Paweł Huryn shared advice from his 3+ years of working as a remote Product Manager with distributed product teams across different time zones. Pavel suggests that communication is the most essential skill for a Product Manager. You must communicate the strategic context and turn chaos into clarity.
Here are five essential communication rules Paweł follows in his work as a PM:
Real-time messaging over email
Async over sync communication
Video > Sound > Text
Horizontal and vertical communication channels
Camera on?
Thanks for reading
Thanks again for reading InsideProduct.
If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, let me know.
Talk to you next time,
Kent