What role do engineers have in planning which features you build in the sprint? How do I get buy-in without giving them control?

• At a high-level, I usually like to think about the somewhat simplistic delineation that PMs decide ‘what’ to build, while engineers deliver the ‘how’.
• Ultimately, prioritization comes back to thinking about the ‘return on an engineering investment’. PMs provide the ‘return’ (i.e., user value), engineers help size the necessary investment. No feature can ever be properly prioritized without both sides of this equation.
• Getting buy-in from engineering usually comes from a deeper involvement and collaboration of engineering and PM as part of roadmap and prioritization discussions. A few things to keep in mind that have always helped me in the past:
• Ensure alignment on the problem you are solving: PMs should be able to clearly articulate the customer problem that is being addressed and ensure their engineering counterparts have the same understanding of this problem. Additionally, it’s crucial to ensure that both PM and engineering agree on the success criteria and definition of done. This upfront alignment can help resolve a lot of friction that might otherwise occur further downstream in the planning or product development process.
• Collaborate with engineers during planning/scoping: once you have alignment on the problem you are solving, it will become much easier to collaborate and jointly problem solve the right solutions for a given feature or product decision. Your engineering team will develop a more intuitive understanding of your customers and in turn might think of additional (creative) solutions that can significantly enhance functionality or improvement development time - engineers are experts in figuring out what options exist to get things done within given system/tech limitations.
• Once you have jointly worked through a project or full roadmap, the issue of ‘engineering buy-in’ usually disappears given the amount of agency PM and engineering had in shaping their plans together.

Generally, the engineering manager (EM) is more involved than the individual contributor (IC) engineers. First, before planning of individual features happen, I make sure the EM is involved and aligned when we are creating the product strategy of our team. Doing this makes getting alignment on individual features much easier because the engineering team knows what the higher level goals are and why we are going after those goals. I've found that in order to get buy in with engineering, I have to make sure the team understands why the work they are doing is important - how it ladders up to a bigger strategy or goal.

I’m a huge believer in transparency. Make your roadmap and decision process transparent. We use a weighted scoring algorithm where roadmap items (and ultimately supporting tickets) roll up into a prioritization rubrik. That prioritization methodology should be available to anyone in your company, including engineers. Make grooming a collaborative activity - let them weigh in on the scores you are giving to specific tickets. Argue with fact, not opinion. If you’re doing your job you will have the best market insight and can fall back and cite your customer research. Generally that’s going to win out over internally generated engineering ideas, but not always! Sometimes engineers will have great contributions you can take away and validate with the market, and ultimately prioritize if the market agrees.

Engineers are part of your squad. They should be in the room for Problem Shaping, Live Prototyping, and Fresh Eyes. You should review your problem backlog regularly with your engineers and get their input and feedback.

—Influence is the curiosity to get to the best solution— and engineers will undoubtedly think about things differently than you - leverage this to find the biggest problems and get to the best solutions.

More about influence here: https://medium.com/@lizzymasotta/product-management-is-not-about-influence-e3004c12f44f

Hm. There appears to be an undercurrent of "us vs them" in your question, maybe this is intentional, but look at your inner beliefs on that to see if there's a negative bias towards engineers. What control are you unwilling to give up? And why?

First ask: What do you control and what do the engineers control?

I think about it in terms of what questions do the players solve.

• Product managers answer the why and the what: Why should we build this, and why now? What do we need to build?

• Engineers answer the questions of how and when: How can we build this in a way that truly solves the problem and when can we realistically deliver it?

• Don't forget those designers (my favorite players – Yes, I'm biased!) also play a role in answering the what and the how.