The tension between product and engineering is real. It makes perfect sense. After all, it’s product’s job to stay ahead of the ball, coming up with new initiatives days, weeks, or sometimes months before engineering can get to implementation. From engineering’s view, tasks like writing proper tests, or ensuring flexibility to prevent future need of rewriting code, are high priority. Yet these types of things slow down engineering.
My view on the balance between product and engineering is pretty simple and can be broken down into three important points:
1 – A product manager needs to understand what engineers are talking about. Conversely, the product manager must also understand what he or she is asking of the engineer. For example, let’s say you’d like to communicate directly with users on the site, so you want to implement a chat service. There’s lots of ways to go about doing this, from building something yourself to using a 3rd-party service. Exploring the options and understanding the pros and cons of each requires great technical understanding on the part of the product manager, almost as great as the engineer who will be implementing the functionality. This type of understanding also allows a product manager to make smart decisions by being able to sense how complex something is before bringing it before the engineering team.
2 – Tracking the engineering team’s progress in a quantifiable fashion is of utmost importance. It might take a couple months, but having points that accurately reflect the time a ticket will take to develop should remove any false expectations on the part of the product manager as to when something might get done. Here, sprint retrospectives are essential, because they will ensure that everyone is held to the same standard.
3 – There is a time to rush, and there is a time to go slowly. When a business needs a feature for a critical reason (maybe it needs to show off a new feature to a prospective client, or perhaps a revenue-generating feature must be completed to ensure the business’ viability), then speed takes precedence above “doing it right.” This is up to the product or project manager to determine, and the engineering team must understand that their ability to do things “properly” may be hampered sometimes. Fostering this understanding early on is crucial.
Another tough issue that creates tension can be shifting priorities. At startups, priorities can shift so quickly it’ll give you whiplash. One day, implementing a customer chat window is the most important thing ever. Then the next day, reformatting ad layouts on the site might become priority one. This is tougher to overcome for engineers or product managers that expect stability in their lives. I’ve come to believe that some people enjoy this type of environment, and some don’t. When hiring, I always emphasize that we may change direction mid-sprint if required (though it’s not desirable to do so, of course), and I want to absolutely ensure every member of my team can handle this sort of organized chaos.
Finally, open communication can be the single tool that most effectively eases tension between engineering and product. People often want to know the “why” behind a decision. If product can properly communicate the need for an initiative, there’s a great chance any upset from engineering will fade away. If engineering is proactive in communicating why certain tasks are taking longer than anticipated, then product can either work the modified timeline into the roadmap, or make new decisions based on the fresh information.
I’ve heard so, so, so many product people express frustration with the engineering teams at their respective organizations, but I always refer back to the advice from this post. Identifying which of these areas in which you’re weak can help you dramatically grow as a product manager.
