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 at every stage of the product lifecycle.
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.
<a name=“part-1”></a>
1. Communicate long-term vision
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 meeting customer needs, 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, product managers and engineering managers 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:
-
What new capabilities will be available?
-
How will we be more scalable?
-
How will we enable additional integrations?
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 software engineers to sprint or quarterly goals. Create space for high-level questions like:
-
What will the world look like three years from now?
-
What new products are we competing with?
-
What obstacles prevent us from making our customers really happy?
-
What are the big opportunities that no one has seized yet?
As you invest in deep technical foundations, work with engineering to bake in the vision of your product design 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:
-
What we’re finding from customers
-
What different teams are doing in terms of architecture
-
The capabilities we’ll be able to unlock soon
-
The software development tools and methodologies we need to work together effectively
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.
2. Create space to be strategic
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 healthy backlog 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, the product team 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:
-
Shadowing users to understand different personas
-
Exploring competitors’ products
-
Attending conferences
To ensure that engineering can support product requirements 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 prioritizing research, 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.
Implement joint project planning
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.
Collaboration in practice: a success story
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 strategy.
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 product development metrics. There will also be intangible, equally valuable results: less attrition, more engagement, and a team that enjoys building successful products together.
Free Resources
