For quite some time, I’ve preferred the term “product engineering” over plainly “engineering” or “R&D.” That’s mainly because, as I’ve written before, the most important partnership of any tech executive is with their product peer. However, it seems that even while many leaders understand this at face value, they don’t know how to translate this thinking into changes on the ground. Let’s improve your team’s collaboration with product.
The Handoff Jar
One of my favorite tricks for improving collaboration in a startup is introducing the “handoff jar.” That is, people are not allowed to claim a better “handoff” between Product and R&D or QA is the silver bullet. If you put your mind to it, you’d be surprised how many times we discuss how work should be passed between product and engineering and vice versa. On the surface, it might register as merely introducing good processes. However, experience taught me that, more often than not, this is rooted in attempting to create silos efficiently.
We might be doing it unconsciously, but wanting to make things strict and clear is essentially like codifying an API between R&D and Product. When do we want strict APIs? When we’re looking to get decoupling. However, the product engineering mindset is all about collaboration, and therefore, we should accept that the communication channels should always be open, flexible, and welcoming. That doesn’t mean that any form of process is bad, but that you should be mindful of it becoming too much of a focus.
Buggy Specs
Similarly, I do not allow the now customary bemoaning of engineers about how poor the specs product gives them are. It’s always mind-boggling how coders expect perfect specifications that go into all the details where they themselves would say anyone’s insane for expecting coders never to have bugs. We need to apply the same forgiveness we have for our teammates to our product peers.
Moreover, when well-intentioned product managers hear this feedback and try to implement it, things often get worse. First, they have to spend even more time creating the specs, causing delays. Second, they’re also trying to become engineers in coming up with all different edge cases. Unless they are actually past engineers, this is usually bound to fail. And lastly, in the cases where PMs pull this off, things get worse. That’s because the engineers then turn into code monkeys that have to execute on very detailed specs, which fits the kind of collaboration one would expect from an outsourced “feature factory” and not between peers.
Team Up
The trend of engineers and PMs working side by side in the same team is a great one (note that I’m using the word “trend” to mean something that’s picking up popularity, not as a “fad”). Whether you call it cross-functional teams, squads, pods, or fellowships, it is often a change for the better. When we increase visibility between these two professions, we tend to quickly get improvements in communication and also in compassion.
The latter is about making the work more real. I’m sure that there are people in your company that you look at and wonder, “What are they even doing all day?” I promise you that there are many engineers in your organization with the same sort of thinking towards PMs. However, when they all work together, sometimes in the same room and other times in many collaborative meetings, these people become “3D,” and we understand them better.
Product Mastery
The last trick is one you’ve heard about if you’ve been following my writing for any amount of time. Product mastery is about engineers not just understanding the tech stack but also having a basic understanding of the company, its business, its users, the market, etc. This fundamental knowledge turns one from a general and abstract engineer to a collaborator in a particular company. When engineers understand the product—and know what they don’t know about it—they can more easily collaborate. That’s how you get those magical questions that show a misunderstanding and save weeks of work or how we get some amazing ways to save some work or try something innovative.
Furthermore, gaining product mastery is something that engineers cannot do without collaboration with product. Often, when product people go through the effort of routinely sharing anecdotes and summaries of learnings and insights, they become better at communicating with engineers as well. This in turn improves communication throughout the company and again will pay off in dividends shortly. Set up a product mastery routine, and you won’t regret it (check out the chapter about Product Mastery in my book for more details).