How to Avoid Over-engineering the Product Role
3 on-the-job lessons from an engineer-turned-product manager
An engineering background is generally considered a great foundation for product management in the tech industry. Having a technical background goes a long way in communicating product requirements with engineers and also communicating complexities of the product to non-engineers. However, newly-minted product managers coming into the role from an engineering background should be cautious to not “over-engineer” the PM position by being conscious of some unintentional biases that might linger from the engineering -> PM transition.
1. An engineering background serves as a sanity check…
…not a license to be prescriptive. Great PMs that come from an engineering background are constantly empowering the engineers they work with to fully own the “how” behind product development. It’s easy to shift into an over-prescriptive mindset rather than a creative partnership when entering your first few product-engineering conversations. But I’ve found that an engineering background is most effective as a sanity check to discern whether an engineering team might be under-engineering (or over-engineering) a solution in the context of the original product goals. For example, you can help engineers come to a particular architectural or design decision by highlighting or emphasizing specific use cases and user journeys that might have a larger anticipated lift.
2. Remove your engineering bias on timeline estimation
As a former engineer, it’s really tempting to jump to assessing engineering lift and scoping timelines in your first few product-engineering conversations around a product feature. Even if your engineering training is subconsciously estimating how long you might take to build a feature you’re proposing, give your engineering colleagues the appropriate amount of space to come to their own conclusions. Intentionally make an effort to bring engineers earlier in the product ideation process to open up space for other engineering perspectives to uncover unforeseen complexities or reframe the problem that offers an accelerated timeline for implementation.
One actionable suggestion I would give my former self would be to focus on the goals of a proposed feature in starting conversations with engineers and leave scoping/timeline estimation for a later conversation. This helps set expectations around the scope of the product feature by aligning what it is and what it explicitly is not (I actually make it a point to write an “out of scope” section to highlight this specifically). It also becomes an effective channel to explain how a product feature might evolve over time and what qualitative and quantitative benchmarks might trigger next steps for the feature. Be cautious to jump to the estimation of timelines, edge cases, acceptance criteria until there is mutual alignment of the goals and expectations of the product feature.
3. Understand (or suggest) when engineering and product responsibilities are shared or separate
If you’re transitioning from engineering to product, chances are high that you were a pretty product-oriented engineer that proactively participated in product design or even product brainstorming processes with product folks in your former role. You should be conscious to not make the implicit assumption that your engineering teammates on your current team will have the same sort of mindset. Instead, help your product and engineering teams come to a consensus on where shared responsibilities begin and end in the product lifecycle. I think it’s especially important to know when and where engineering and product should have equal weight and where one team should be taking point (with the other team acting as support).
Of course, there’s a lot of different points of view on what product-engineering relationships should look like, and I believe that it’s entirely subject to the context your respective organizations are working in. However, making sure that there’s a shared framework puts a helpful structure and groundwork upon which collaborative creativity can thrive. Here are some resources I found helpful in priming these conversations.
How do you think about working with engineers on your team whether or not you come from an engineering background? We’d love to help share your experiences with other early-career and aspiring PMs — send us your ideas at pathtoproduct@gmail.com!
