Effective partnerships between product and engineering don't focus on shipping tickets. They focus on solving user pain.
Clement Kao is the founder of Product Teacher, a product management education company with the mission of creating accessible and effective resources for a global community of product managers, founders, innovators, and entrepreneurs. Product Teacher offers self-paced courses, career coaching, corporate training, and other professional development services. As an ex-Principal Product Manager, Clement has shipped 10 multimillion dollar B2B software products (and dozens of smaller ones) over the last five years at multiple startups. Clement has also written 150+ product management best practice articles and has been a featured speaker and writer for 100+ different organizations.
Early in my career as a Junior Product Manager, I made a crucial mistake that ultimately changed how I interact with engineers. My mistake? I failed to invest in the human side of building products together.
On this particular project, I was a consummate task manager. I gave engineers demands and deadlines but didn’t explain the business strategy behind them. Without the context or agency to push back on my specs, engineers built to the letter instead of the spirit of the ticket. My assumptions ruined parts of the architecture, and engineers quickly lost motivation.
I’m lucky I encountered this challenge early in my career. It pushed me to mature quickly and learn a vital lesson: great products require PMs and EMs to collaborate as thought partners. When you treat engineering as a vendor, you miss out on strategic insights that can accelerate product goals and drive maximum ROI. Both PMs and EMs need to understand the value that each partner brings and invest in effective communication practices.
As I progressed in my career, I realized that my early mistakes are common pitfalls for PMs and EMs looking to create a great product. Today we’ll discuss 3 strategies that helped me to reset my relationship with EMs and build a strong foundation for collaboration.
When product and engineering work together, it’s often very tactical and execution-driven: how will we meet deadlines this sprint or solve a particular bug? Instead of taking a high-level approach to solving user pain points, PMs and EMs function as a “feature factory”: product generates tickets, engineers deliver on tickets, and users ingest another feature that may not meet their needs.
To move away from this “feature factory” dynamic, PMs and EMs should communicate long-term vision. Engaging in open dialogue about technical and business trajectories can help everyone to align on product goals and collaborate more effectively.
Engineering
As an EM, you can set your team up for success by sharing the engineering roadmap with product. This information helps PMs to see where engineering is headed and how those goals can support what users and the business need. Discuss how your platform might continue to evolve over the next 3-6 months:
For instance, if engineering plans to take a monolith of code and break it down into individual microservices, that is highly valuable for PMs to know. Once we do, we can provide an ROI business case statement to ensure that engineering has the time and resources to invest in that deep technical foundation.
The more PMs know about engineering plans, the more effectively we can advocate for you – not as vendors, but as internal stakeholders.
Product
On the flip side, PMs need to provide longer-term visibility about the thesis of your product and the pain you want to solve in the world. Don’t limit the scope of your work with engineers to sprint or quarterly goals. Create space for high-level questions like:
As you invest in deep technical foundations, work with engineering to bake in the vision of your product and its mission within the company. For example, let’s say your product is only available to internal customers. To gain additional traction, visibility, and sales, you plan to open up your product so that others can integrate into it as a platform. If engineering doesn’t know about your vision, your product may not have the technical robustness to handle increased traffic. To make the short and medium-term work happen to achieve this goal, you need to have joint discussions about the engineering roadmap and product vision.
For PMs and EMs who aren’t accustomed to having future-oriented conversations, start by committing to a one-hour meeting per month. This should be a fun and exploratory conversation where managers riff on what they think the future will look like from product and engineering perspectives. Ask yourselves: how might we start to incorporate these hypotheses into our engineering and product roadmaps?
As a PM, I’ve evolved from a monthly conversation with my EM counterparts to a standing one-hour block per week to discuss where product and engineering are headed. Topics include:
This isn’t a formal one-pager. It’s a casual conversation that builds a shared context between product and engineering. In my experience, carving out even just one hour per month for PMs and EMs to discuss the future helps to build more effective and strategic partnerships.
In earlier-stage startups and more traditional industries, it’s common for engineering to be staffed to the gills. The focus is on execution: we have this many story points allocated per sprint, and we’re going to use all of them.
The problem is that in this environment, product and engineering are so consumed by creating and fulfilling tickets that they have no time to be strategic. As a result, your company misses out on deeper investments that could take your product to the next level. Both engineering and product have high-level insights that can benefit your company. To unlock this value, PMs and EMs should carve out time for each team to engage in strategic exploration.
Engineering
Pumping out tickets for each sprint makes your team seem highly productive. However, using all of your engineering bandwidth to write code comes at a cost. It means that folks don’t have time to go through the technical stack and identify potential investments. This slows progress in the medium to long term.
Instead of devoting 100% of engineering resources to coding, reallocate 20% for strategic technical exploration. By technical exploration, I don’t mean hackathons or disruptive technologies. I mean taking time each sprint to create a “burn list” of potential investments that can improve your architecture and increase team velocity.
For example, let’s say there is an opportunity to replace ineffective automated tests that were built years ago. As an EM, identify the cost and ROI: it will take 3 months to invest in this core part of the code, and the result will be increased engineering velocity sprint by sprint. From there, the PM can advocate for you by bringing business case statements to leadership and shielding your time.
EMs can also utilize strategic exploration to form partnerships with different engineering teams. There may be opportunities to synergize with your technical teammates. Or, you may be able to draw on what other teams are doing to refactor and build things more robustly in the future.
Product
PMs often feel like we’re on a treadmill: to keep engineers writing code at 100% capacity, we need to feed them a constant stream of tickets. This means PMs don’t have the space to engage in deep research.
EMs can provide strategic value by devoting 20% of their time to investing in technical foundations. Similarly, PMs can accelerate product goals by spending 20% of their time researching what the future might look like. These activities can include:
To ensure that engineering can remain productive while you are in the field, plan ahead and communicate your needs. Let EMs know that at the quarterly or annual level, certain weeks or months will be light in terms of future tickets.
Frame these needs as part of a coordinated strategic effort. While you are on your fact-finding mission, engineering can take the time to review their burn list of deep technical investments. This will enable EMs to build their own projects without relying on product.
When EMs and PMs give each other the space to be strategic, you will use resources more efficiently and develop more innovative solutions. Instead of making incremental improvements, you can collectively identify and work towards the next big investment that will change users’ lives.
Sudden departures, bugs, and escalations are an inevitable part of any project. To be resilient to disruptions, EMs and PMs need effective methods for anticipating downstream impacts. This can be especially challenging when you are working on larger initiatives that stretch over multiple quarters.
Back when I worked at Blend, my EM and I developed a kind of joint project planning between product and engineering. It improved our ability to restructure work at the individual, sprint, and quarterly levels, and I’ve used it ever since.
Our approach enables a rough macroview of big rocks, or main goals, six sprints out. From there, we pencil in the kind of work that each person on the team will be doing. The key is that we don’t actually expect folks to adhere to the plan. In fact, we create the plan knowing we will deviate from it. Here’s what that can look like and why it’s valuable.
Let’s say we have three devs on the team. Between them, we have 18 sprints to plan for over the quarter. We don’t want to allocate work at the ticket level. Instead, roughly identify the bigger blocks folks will be responsible for in each sprint. This means that we have a high-level plan for each person in each sprint of the upcoming quarter.
During this planning process, we may realize that we can’t hit the desired goals under our current circumstances. That’s a valuable discovery – it gives us the opportunity to brainstorm high-level tradeoffs before the problem arises. For example, can we preemptively move some initiatives out of scope or advocate for additional folks to join the team?
Of course, not all challenges can be anticipated ahead of time. Luckily, the “big rocks” view of the quarter enables us to respond to unexpected challenges more effectively. Let’s say one of our three devs falls ill. We can use our high-level plan to reorganize work between our two remaining devs and model the downstream impacts of these changes. We still need to make hard tradeoffs. However, the plan enables us to swap out work more fluidly – and before it’s too late to save the project.
I hope that the strategies I’ve shared today empower you to build deep partnerships with your EM or PM. While I had to learn these strategies the hard way, I’ve also experienced the incredible results they can yield.
I once worked with a team of two engineers and one EM. This was a new experience for me, as I was used to working with 20 devs at one time. I was convinced we would never get anything done – however, my expectations were quickly upended.
Because the team was so small, we spent a lot of time building deep one-on-one relationships. I talked with engineering about what users and the business wanted to accomplish; engineers laid out the technical culture they wanted to build. These conversations helped us to understand each other better and plan for the future more effectively.
Knowing that we had limited resources to work with, our team had no choice but to be strategic. Instead of focusing on churning out features, we built work around a shared purpose. We’re not here to ship tickets. We’re here to change lives for the better. We discussed the highest-return investments we could make in order to achieve that purpose. That’s when our partnership truly blossomed.
Product and engineering each took the lead on certain initiatives, but we created space for one another at the table. The EM looped me in as an advocate to enable technical investments and engineer growth. I gave engineering the space to drive product decisions.
What’s shocking is this 2-person dev team churned out more work than the 20-person teams I’d worked with previously. We regularly crushed sprint and quarterly metrics – not because we had greater technical skill, but because we were so deeply in tune with each other.
This experience solidified my belief that investing in deep partnerships should be a top priority for product and engineering. There will be tangible results, such as crushing your quarterly metrics. There will also be intangible, equally valuable results: less attrition, more engagement, and a team that enjoys tackling problems together.
As a software engineer turned founder, I am passionate about ensuring that developers are technically equipped. Here are the critical areas of focus...
A focus on standard developer collaboration practices and how they should be modified to better enable developer productivity.
People are not resources, whether the job involves putting something on the factory floor or coding things out on the computer.