I talk with CPOs/VPs of Product almost every day. And with CTOs/VPs of Engineering every week. A frequent topic is how to collaborate and support each other — even as we sometimes need to raise uncomfortable issues. My starting point is always that VPs of Product and Engineering need to be fully aligned in public, aka “shoulder to shoulder.”
At most (tech) companies, product managers are more than transmitters of requirements or sales demands. More than checklist completers. If we’re living up to our potential, we have a unique birds-eye view of where customer value meets great technology. And we often represent the technical side of the company to Sales, Marketing, Support, customers and analysts: explaining why our awesome software solves important problems that people will pay for. Which makes product managers the visible champions of our (under-appreciated) development and design teams… the blockers of hourly interrupts from sales prospects for just one more tiny deal-driven fix… the often-mocked believers in EXCLUSIVE OR prioritization.
And we remember (with some prompting) that we don’t build what our customers buy: our “maker” teams of developers and designers and test engineers and tech writers and CloudOps actually create the products that we bring to market… that our whole team collaborates on solving hard problems rather than having product managers single-handedly write every user story. Said another way, product managers form tight emotional bonds with our maker teams: shared goals, shared roadmaps, shared customer insights, shared jokes, shared processes, shared success. A product manager without a team is lonely and unhappy.
For this to work, the Head of Product and Head of Engineering need to be just as bonded as our teams. We don’t always agree, but we assume good intent and come together to speak with one voice. We voice appreciation for each other’s expertise. We model good behavior for our respective groups.
For Example
- In public, Product and Engineering are fully aligned. Among the Executive Leadership Team, we never throw each other under the tram. (Occasionally, we discuss in advance how we’ll disagree in public.)
- Product and Engineering have an agreed 1-4 quarter roadmap and description of ideal customers/users. (If there’s a separate technology roadmap, it parallels the product roadmap and is built collaboratively.) We work together to allocate effort against architecture, bugs, refactoring and test automation.
- Product shares broad justifications, customer problems, goals, the why’s attached to our big asks. Engineering/Design actively engage in problem definition and solutions, rather than just doing what they are told. Product may get the final call on priorities, but everyone feels included.
- We work together to reduce team-level multi-tasking. Engineering managers and product managers partner to reduce interrupts, route requests to Product instead of individual developers, hold back the chaos. Since that’s never 100% successful, we decide together how to deal with specials, deal-driven commitments, and executive overrides. Product managers typically play “bad cop” since we have thicker skin.
- Sometimes we hide some engineering capacity from internal stakeholders if we’re unable to get buy-in for retiring tech debt or investing in quality.
- Now that everything is in the cloud, the cost of AWS or Azure or Google Cloud, the cost of computing is big and visible. Engineering managers have to project capacity and costs, but product managers often have more P&L experience – so help their engineering counterparts sort this out.
- We avoid narrow legalistic role definitions. Sometimes designers lead user interviews, sometimes architects write epics, sometimes product managers fix SQL, sometimes test engineers identify problematic workflows. Who’s the best person to help/fix/do that? Ron Lichty reminds us that “software development is a team sport.”
As CPO/VPs of Product and CTO/VPs of Engineering, we set the tone for our groups. We undercut politics. We applaud each other’s work – especially when the rest of the company is listening. We have each other’s backs. We hang together (so that we don’t hang separately.)
Anti-Patterns
When this isn’t going well, what does it look like?
- OKRs are mis-aligned. Product has immovable delivery dates while Engineering is measured on quality. Design’s top priority is a new identity system, so no one sweats usability on upcoming features. Customers can’t use our API without accurate technical docs, but our writers have been lent to Marketing. Teams are very unhappy.
- They build separate roadmaps. “I just saw my engineering manager’s Q2 roadmap, which he is presenting to executives today. I had no input, we had no collaboration, and it doesn’t align with my own Q2 product priorities.”
- Product doesn’t value production infrastructure or clean code as much as Engineering does, so Product keeps postponing scalability and security and refactoring to “next quarter” in favor of shiny new features. Engineering ignores Product’s force-ranked backlog and works on what they think is most important.
- Engineering builds some super-fancy machine learning models that don’t have any obvious customer use. Product describes that work in glowing (but inaccurate) words that get customers excited until they try to use it.
Sound Byte
By ourselves, we product manager can’t deliver great solutions for customers. By themselves, engineering/maker teams can’t build well-positioned and profitable whole products that bring market success and end user joy. Together, there’s a chance for magic.