This post is for product managers, aspiring product managers and founders looking to get the most out of their engineering teams. I managed engineering teams for several years while at Unified and had the good fortune to collaborate with multiple outstanding PMs. Here are some of the lessons that I learned collaborating with product managers on dozens of engineering projects.

Contents

• Engineers are Your Partners, They Work With You, Not For You
• Respect Technical Scoping and Plan for Uncertainty
• Communicate Your Goals Clearly, Articulate the Why
• Protect Your Engineers from the Whims of the Business
• Communicate Back the Impact of Your Work

Engineers are Your Partners, They Work With You, Not For You

As a product manager, the relationship you build with your engineers will be the single most important factor in your ability to get things done. Your engineering partners must trust and respect you. They must trust that you're trying to do what's in the best interest of the business and not what's in your best interest or in the best interest of your boss. They must trust that you're effectively communicating back to the business constraints imposed by the technology. They must trust that you will protect them from the whims of management and customers.

Engineering Wants to Prioritize Application Stability

Because engineering is responsible for maintaining the product, preventing downtime, and fixing bugs, they must take a fundamentally defensive stance when asked for new features. Most of the time, there will be a long list of tasks that engineering does not have time to complete which would improve the existing system's stability and scalability while easing troubleshooting and monitoring. Your new feature request not only introduces an entirely new set of problems but prevents them from being able to fix and improve the existing system.

Therefore when you go to engineering and ask for a new feature, often this is what the engineer is thinking:

• Is this feature necessary?
• What impact is this feature going to have on the existing system?
• If it's a large feature, who will maintain it?
  

The engineering teams will not have as much insight into the marketplace or the customer as you do. They will not care as much about the customer experience or the business objectives as you do. Instead their primary concern is ensuring that the system works and does not break. Therefore when you ask them to build something new or add a new feature it is not obvious to them why it matters.

Feature Development vs. Maintenance

However, if they know that you understand that their responsibility does not end with the completion of a new feature and that you appreciate the inherent risks and effort associated with each new project they will have an easier time trusting you.  Where you will get into trouble is assuming that anything, no matter how small it seems, is going to be an easy quick fix or a small simple feature. Throwing feature requests over the wall to engineering teams will lead to resentment and mistrust.

They are your partners and without them you are powerless to effect change in your business. Treat them as partners and they will work hard to deliver the features that matter to you and the business.

Respect Technical Scoping and Plan for Uncertainty

Estimating how long it will take to build new features and products is not easy. Often something that looks simple ends up being far more complicated than anticipated or has unintended consequences. You, as the product manager, are often put in a position where you have to make commitments to leadership or to customers about when new features will be ready. This is unavoidable. 

Generally there are three reasons why engineers underestimate development timelines:

1. They fail to plan for unexpected and unknown delays
2. They feel pressure from product
3. They want to be helpful
   

Properly managed engineering teams will do their best to accurately scope a project and build in buffer for unexpected delays. Regardless of the experience level of your engineering team, you are ultimately accountable to your stakeholders and therefore your communication strategy must reflect this.

If you have a strong relationship with your engineering teams they will be open with you about the progress of a project and communicate early and openly about problems and delays. If they don't trust you then they're far more likely to hide and obfuscate problems until right before a feature is due. This can result in delayed released or buggy features.

Even if your engineering team has the proper processes in place to scope work, if they feel pressure from product, they will tend to underestimate timelines because

• Psychologically it's easier to push conflict into the future by telling the product manager what they want to hear
• The engineering team never felt the deadline was reasonable in the first place and will not hold themselves accountable
  

Trust by Default

What if engineers intentionally try to mislead you by claiming things will take far longer than they actually take and use the extra time to slack off? The presumption of laziness and deception generally leads to a fracturing of the relationship between the product manager and the engineering teams. It is likely that in some cases engineering will overestimate the time required to complete a task or feature. If you have a strong engineering culture then they will let you know and work ahead. Even if they do not, the overestimate scenario happens far less often and reclaiming this time at the cost of your relationship is never worth it in the long run.

Planning and communicating with your stakeholders becomes far easier if your engineering teams consistently deliver within the time frame they promise. Even if it means that engineering overestimates slightly, you'll win in the end. If the team agrees that the timeline is fair at the outset then it will be far easier to hold them accountable. It is critical that they feel like they can dictate timelines according the technical requirements.

Communicate Your Goals Clearly, Articulate the Why

Part of ensuring that your engineering teams deliver features on time and to spec is making sure they know exactly what it is that you want. This means three things:

1. Clearly communicate what is expected of the engineering teams (feature requirements) as well as what success looks like (completion requirements) according to their standards. This means that feature adoption is not a relevant metric to the engineering teams assuming the feature was built to spec.
2. Clearly communicate where you are leaving decisions up to engineering i.e. what requirements are unknown or subject to change. This is critical because it gives engineering the flexibility to design solutions that retain core functionality while compromising on less important features.
3. Clearly articulate why the feature is being built. This is important because it empowers your engineers to offer solutions to the core problem that you may not have considered.
   

Anything Not in the Spec is Open to Interpretation

Engineering teams do not understand the customer like you do and often lack broader business context. Do not assume they'll just know what needs to be built. A good product manager will be able to clearly communicate (and document) what exactly needs to be built.

Of course, you are busy as well and do not always have time to spell out every single little detail. This is fine, but you must be aware that anything not described in the spec is open to interpretation and often engineers must make decisions when translating abstract requirements into concrete product. Time invested up front is time saved at the end of features need to be rebuilt or rewritten. Not only does this waste time but it damages the relationship.

Feature Development is a Negotiation

Generally product has a grand vision for what they want however engineering teams are constrained by time and resources. Therefore good product managers create an open forum for negotiation with their technical leads to discuss the best ways to get the most for the least amount of effort. If the engineers understand both what needs to be done as well as why they will be in a better position to

• Propose alternative solutions given technical constraints
• Make good decisions when there are gaps in requirements
  

Protect Your Engineers from the Whims of the Business

As the product manager your are the engineering team's connection to the business and the customer. You are therefore responsible for filtering and repackaging communication to protect the team's time and maintain their focus. This matters to you because

• You want the engineering team to stay focused on only the most critical features for the business objectives you own
• The relationship will suffer if they feel like they are receiving mixed or conflicting messaging
  

You will have your own set of features that you believe are most important based on your knowledge of the business, the market, and the customer. The leadership, other teams within the business, and customers will all have their own perspective on the best use of engineering's time. It is your responsibility to protect the engineering team from these competing interests.

Help the Team Focus on Your Priorities

Engineers want clear requirements and time to focus. If you are able to remove distraction and filter out all the other voices competing for engineering time they will be better able to accomplish your objectives. If an engineer receives a request from an outside stakeholder do not assume he/she will know to push back. You must ensure the correct processes are put in place to help the engineers deflect on their own. Alternatively, if you can intervene directly and eliminate distracting work they will thank you.

Communicate Back the Impact of Their Work

Engineers want to work on features and products that make an impact. You must show them why their work matters even if it appears distant from the customer. While seemingly a small thing, I cannot understate how important it is to ensure that your teams have some view into the impact of all their hard work.

As the product manager you are constantly interacting with users and customers to gauge whether or not features are working, how they can be changed or improved, and what else needs to be added. To do this effectively you must be able to measure whether or not a feature justified the time invested to create it. Did it have an effect on the business objective you care about? If so, by how much?

It is too easy to take the results of this analysis, craft requirement for the next feature or improvement and then pass that on to engineering without taking time to show them how the last feature they built impacted the metrics you care about.  When you bring the team in on this analysis you make your success theirs. There is nothing more exciting than to see how a feature you built caused a change in the world. This improves your relationship and helps to focus the team.

Closing Thoughts

Working effectively with engineering teams is as much a part of a product manager's job as talking to customers and designing great product. You can only be as successful as your team allows you to be and therefore it is so important to cultivate those relationships and understand the world from  their perspective. Use these lessons to build trust with your teams and build alignment of mission and purpose. Good luck!