Ingo Wiegand

The right PM to Eng ratio depends on a couple of different factors, many of which can from my perspective be boiled down to 1) the overall stage and scale of the company and 2) the nature of the product you are working on. Given those dependencies, it also makes sense to revisit this decision at key turning points of your product (or company). Practically speaking, the traditional ‘2 pizza box team’ of 8-10 engineers per PM is a decent baseline to start with. Here are a few example consideration ...Read More

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 co ...Read More

I generally like to break product problems into smaller, independent pieces to help me more effectively prioritize and isolate critical ‘must do’ work One potential way to approach a problem decomposition like this is to think of three distinct categories of feature work:a) items that are crucial to achieve your overall product goals (clear ‘must do’)b) ‘critical path’ dependencies that can block success/completion andc) things that are nice-to-have or could benefit from additional trade-off dis ...Read More

I’m a strong believer in product/feature teams owning their deliverables end to end, which includes not only product definition and development, but also testing and validation. This is even more important in an early-stage environment, where moving quickly means engineers will need to make game-time design decisions day-in and day-out. Eng and PM should collaborate closely to ensure the quality of the feature being worked on. I recommend engineers incorporate testing as part of their developmen ...Read More

Generally, I think about three fundamental dimensions in product development: time, scope, and resourcing. You will never be able to force all three to your liking, in most cases you will pick two, which in turn determine the third: If you have a team with a given size and you pick a ‘ship date’, you are implicitly making the decision that scope needs to be flexible (i.e., you will have to be OK cutting / adjusting what is getting shipped) If you have a team setup and a clear scope in mind, the ...Read More

The first question I would ask is whether PM and engineering have aligned upfront on a mutually agreed-upon definition of the problem to be solved and the definition of success. In my experience, engineers don’t just slip in features for no reason, but there might be other failure modes upstream of that decision. It’s important to understand the ‘why’ and adjust processes and behaviors accordingly. Here are some typical examples of friction points I’ve seen in the past and how to potentially add ...Read More