In past roles, I have spent a lot of time structuring relationships between product and engineering teams. This primarily focuses on establishing practices for planning, scheduling and communicating development work. As teams interact, individual relationships between product and engineering team members can sometimes break down. In these cases, I find myself listening to each side’s perspective, digging into problem areas and coaching people to more productive interactions. Given this experience, I thought it would be useful to share some tips for maintaining a healthy relationship between product and engineering leaders. To be most practical, I’ll focus on product managers and engineering leads at the small team level, where the business context is delivering software products over the Internet at a rapidly growing company.

For the Product Manager

  • Address why – not just what. When you are asking your engineering team to build a new product feature, take the time to explain why it is important. What are your goals for the feature and how do these fit into the overall objectives for the product? Explain how the feature will improve the user experience. If you haven’t reviewed key product tracking metrics with your engineering team, step back and schedule some time to do this. Understanding the business objectives for a product enhancement provides two benefits for engineers. First, they can use their judgment to answer small design questions for themselves, obviating the need to ping you incessantly about the product spec. Second, engineers like to solve problems. If a user engagement opportunity is presented as a problem (we would like to increase the user registration rate by 20% by adding Facebook auth integration), then engineers will be more aligned with how their work contributes to the product’s success. After launch, they can track the impact of the new feature and help optimize performance based on data.
  • Design the minimum viable product. This means investing the smallest amount of engineering effort necessary to get sufficient feedback from users to make a decision about a product feature. MVP may be a well-known product design concept, but I sometimes see it failing in practice. Product managers and UX designers naturally get excited about the potential for a new feature that is bound to delight users.  This can lead to a tendency to over-design. Once the feature is launched, however, users may not engage with it and it is promptly turned off. This reaction is often spun positively as “failing fast”. Failing fast is fine, but if the failed feature required multiple sprints to build, then there may have been wasted engineering cycles. Engineers get frustrated by waste and dislike writing a lot of “throw away” code. Building and testing a MVP can minimize the discarded effort. As an example, if the new feature idea is to provide users with free use of the product in exchange for friend referrals, think about the easiest way to determine if users would be willing to make this exchange. I have been involved in elaborate implementations of a friend referral feature, only to find out after launch that users aren’t interested in referring their friends to some product types. Instead of building out the full referral feature, perhaps sufficient feedback could be collected by just displaying a button describing the offer. While the button would need to link to some sort of “coming soon” landing page, it would quickly indicate interest in that kind of offer.
  • Share design changes as early as possible.  After you deliver a spec for a new product feature, engineering will begin the process of conducting their technical design and implementation. From that point forward, engineers subconsciously expect the spec to be fixed. However, in a rapidly evolving product space, new information about the feasibility of a product direction manifests every day. This is understandable. If new information will alter the design for the product feature, you should bring this information to your engineering lead as soon as possible. Even if you haven’t determined the extent of the changes, it’s best to still share the possibility of a change. Take the time to explain the new information and your rationale for the re-design. This allows the engineering lead to assume ownership for it with his team. With the anticipated change, the lead can adjust the feature implementation steps appropriately. Best case, the design change won’t impact the delivery schedule because the lead is able re-order implementation tasks around the changing part.
  • Understand implementation schedule trade-offs and don’t always pick the option with the shortest delivery time. Your engineering lead should prepare a couple of implementation trade-offs as they scope out your product feature request. Usually, these trade-offs involve technology choices and software design decisions, where there is a “fast way” and a “right way”. In most cases, the right way invests effort now to make future development of the product feature easier. Examples are moving some supporting code into a shared library, or building the feature on a different technology. If not addressed now, these items will be addressed in the future and collect as “tech debt”. As a product manager, your tendency may be to always pick the implementation option that results in the shortest delivery time. However, if the schedule will allow for some cycles to address the tech debt items now, they will generally be completed faster. This is because the team is already in context and won’t need to incur refresh cycles on past code. Regardless of your decision, ensure that you fully understand and evaluate the implementation trade-offs. You and your engineering lead should collectively agree on the best option based on your product objectives. If tech debt is generated by your decision, ensure that you backlog it and offer to schedule it during a future sprint planning exercise.
  • Share your product roadmap and solicit feedback from engineering. If you maintain a product roadmap, share this with your engineering team. Granted, your roadmap’s planning window may short, like a couple of months. That’s okay – even seeing a backlog of feature ideas is helpful. Sharing the product roadmap allows engineers to make technology design decisions with your future direction in mind. When done well, this can reduce implementation effort for new features, because an engineer is armed with the foresight to build extensions into a related code module or service. Also, as you share the feature backlog, it is productive to solicit feedback from your engineering team. As builders, and often users of the product, they may have additional insights into usability. Engineers can be a great source of product ideas, or suggest tweaks to an existing design that may result in a better outcome.

For the Engineering Lead

  • Think of your product manager as a customer. While your product manager technically is a peer, it is productive consider your product manager as a customer of your engineering team’s services. In essence, they are generating a product design request and hiring your team to build it. An analogy would be if they outsourced development to a consulting company. If you were the lead consultant, how would that change your interactions with the product manager? Would you be more collaborative, responsive or proactive? While not perfect, I have found that this kind of relationship modeling helps align the engineering team with the product manager’s expectations.
  • Understand the business and your product’s key measures. Given that your company is inherently a business, it is crucial that you understand how the company generates revenue from its products. This is usually translated by the product team into a set of key metrics that indicate the success of the product. As the engineering lead, it is important that you understand these metrics and how your team can impact them. Fortunately, your product manager is well versed in these metrics and makes all decisions based upon them. Make an effort to learn about these metrics and get your hands on whatever reporting system the product manager uses to track them. This way, you can understand what the product manager is trying to accomplish with feature requests. Additionally, you can quickly identify when key metrics are negatively affected by a change. Aligning with your product manager on this shared scoreboard will streamline decision making for you both.
  • Do not obfuscate implementation schedules. When presenting a proposed delivery schedule for a project to your product manager, be specific. Explain the details of your plan. Review your assumptions and highlight risks to project milestones. If you have added time to allow for unknowns, delineate these items and share your methodology.
  • Provide implementation trade-offs. An implementation plan will invariably have some trade-offs. Usually, these take the form of work items that could be deferred in order to reduce the timeline for launch of the feature. Granted, these deferred items will need to be addressed eventually, but it’s also possible that the feature may not resonate with users and be discarded. Therefore, it is important to include these trade-offs in your implementation proposal. Trade-offs should address both the anticipated schedule reduction and the “cost” of deferring the work. For example, if conducting a load test of the new product feature is part of your plan, you can describe the risks of launching without it. Alternately, if you wanted to bundle some of the business logic into a new micro-service, explain the benefits (future maintenance cost reduction) of that work. Then, review your implementation plan and trade-offs with your product manager. If work items are deferred, make sure these are added to your tech debt backlog.
  • Explain the technology. Educate your product manager on the technology that your solution utilizes. Don’t assume they won’t understand. Many product managers (like at Google) have an engineering background. This education can be done in one-on-ones, at lunch-and-learn sessions, or during monthly group all-hands meetings. The more your product manager knows about the technology, the better equipped they will be to appreciate the benefits of non-feature development work.  
  • Share bad news early and in person. If there is a new circumstance that would be considered “bad” by your product manager, share that as soon as possible. Bad news could represent a setback in the implementation plan, an undiscovered bug, a team member change, or anything else that might effect your product manager’s goals. This news should be discussed in person. Don’t postpone it for a team planning meeting, or include it in an email. A big part of relationship building is interpersonal communication. In your discussion, share the update and options to address it. If you and the product manager are not in the same office, communicate via a phone call or better yet, a video conference.

Danger Areas

  • Lack of trust. Loss of trust between a product manager and an engineering lead can be devastating. Like with any relationship, trust is foundational. Think of your product manager or engineering lead as a significant other. Do not speak in a way or do something that would undermine this relationship. Examples include prevaricating, withholding information, disparaging or double-dealing. Evidence of lack of trust might be if a product manager has little confidence in  delivery schedules or an engineering lead openly criticizes feature choices.
  • Poor communication. The product manager and engineering lead should be joined at the hip. They should be communicating frequently and informally. Ideally, they sit together. They should both be comfortable in talking to each other, without the need to be guarded. Strained or sporadic communication should be flagged.
  • Timidity – inability to push back. Like a marriage, it is not healthy if one partner dominates all interactions and always gets their way. Both the product manager and engineering lead should have the confidence and fortitude to push back if they have issue with the other’s actions. Conflict is healthy and usually leads to better outcomes.

I’m sure there is much more advice on this topic, but I will try to keep this article reasonably short. If you have additional suggestions, please post them in the comments.