Ingo Wiegand

* 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.

* 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 and c) things that are nice-to-have or could benefit from additional trade-off discussions (these are usually where you will gain most flexibility in terms of resourcing). * Initially, all work (incl. potential ‘must do’ items) will benefit from going through a first order trade-off discussion to ensure criticality. * I’ve found the following key questions to be a useful starter set to kickstart these types of conversations: * Where can features be de-scoped to allow for growth/product delivery in increments within budget? * Where can features be sequenced in a way that hypotheses can be tested at a smaller scale, without needing much larger engineering investments? * What alternative solutions have been considered and is the proposed feature/work the most efficient from an engineering perspective? * What are the biggest risks that need to be mitigated (the associated work might turn into ‘must do’ items)? * Where can you ensure progress without too many ‘one-way doors’ that might limit opportunity/flexibility later? * What are the key skillsets needed and does your team have those readily available today? * Once you have a better understanding of answers to these question, it becomes easier to stac

* 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 time component will be determined based on bottoms-up planning against the required work (i.e., it will be shipped ‘when done’ for the most part) * It’s worth recognizing that ‘shipping on time’ isn’t a standalone issue, but very quickly moves into a trade-off discussion with the other dimensions. * That being said, when discussing scope, it is easy to get into ‘analysis paralysis’ of trying to find ‘perfect’ data/insights to support your product direction. There is no simple answer for ‘how much research is good’, but I like to use the following constructs to think through trade-offs and ensure I’m comfortable with the amount of unknown unknowns and associated risks before moving ahead: * Definition of success: being clear on the desired outcomes/target state and how to measure success are critical. Not being clear on this item usually indicates that more research is necessary, otherwise the risk of shipping something ‘on time’ that’s not useful (or needs to be reworked) is high. * One-way doors vs. two-way doors: without further research, will you need to make decisions that will lock you and your team into an irreversible path for future product/engineering work? If so, it usually makes sense to assess insights further to make sure that this won’t cause issues down the road. Two-way doors on the other hand (i.e., decisions that are easily adjusted/reversed in the future) keep optionality to iterate and might indicate that it’s worth shipping now and use this as an opportunity to gain more direct customer feedback/insights. * “Crawl, walk, run”: sometimes it’s more important to ship small increments quickly to gain traction and learn more about your customers’ needs. It’s worth thinking about whether additional insights/analysis with the currently available information will be faster/give you more confidence in your product decisions than shipping something quickly that will allow you to iterate with customers and get direct feedback that way.

* 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 considerations of how I would think about adjusting this ratio for individual teams based on scale and product considerations: Scale * Larger scale for an R&D organization usually implies an increased need for coordination and likely more ‘interfaces’ (e.g., there are more product and engineering teams, more platform-wide services, APIs etc.) and in many cases this maturity also brings technical complexity. All of these factors might indicate that a single PM can cover a wider range of engineers, so even a ratio of 1:15 might work in those cases. This doesn’t necessarily mean that a single engineering team needs to hit that size, but PMs might start work that naturally spans multiple (potentially cross-functional) engineering teams * Smaller companies can usually start out with an 8-10 engineer per PM ratio and then adjust based on growth trajectory. In hyper-growth scenarios, PM capacity can become a bottleneck, especially when it comes to B2B/Enterprise-oriented products, where in-depth knowledge and a clear articulation of specific customer processes and varying user personas might increase the need for more dedicated PM bandwidth (and critical product trade-offs), adjusting the ratio to 1:6 could temporarily make sense Nature of the Product * A product or feature with high user complexity (e.g., enterprise operations workflows with varying business needs, complex business logic) or high initial business uncertainty (e.g., first foray into a new market) might warrant more PM bandwidth and an adjusted PM to Eng ratio of 5-6 engineers per PM * On the opposite end of the spectrum, lower user complexity (or generally higher Eng complexity) would lead me to move towards a ratio that skews towards more engineers per PM (typical examples here could be AI/ML-driven features that might require a wider range of technical expertise and teams to succeed)

* 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 development cycle (and test before they release, incl. all relevant edge cases), while PMs should not close out any of their user stories until they had a chance to validate that the desired end-user functionality has been delivered. Most of my teams actually leverage joint PM and Eng ‘dog fooding’ sessions before signing off on new feature releases. * This setup will also help eng to develop more user empathy over time, while ensuring incentives are aligned to not write ‘untestable’ code that will be hard to maintain in the long-run.

* 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 address them: * Disagreement on overall roadmap prioritization: take a step back and ensure clear alignment on the problem to solve (and how you landed on the current prioritization of your roadmap) * Atmosphere of distrust between PM and engineering: run a structured retrospective discussion to ensure both PM and engineers can give feedback/understand where the disconnect is coming from * Not all work that needs to be done in engineering has been captured in the current plans: review engineering plans and evaluate whether estimates have properly accounted for tech debt/uncertainties along the way; alternatively, consider providing the engineering team with a small ‘discretionary’ budget of 10-20% of engineering time every sprint/planning cycle to work on their own p0 items * More tenured engineers are looking for more challenging work: think about facilitating rotations or discussing opportunities to flex into more technically challenging work where it aligns with roadmap opportunities * Most failure modes can be addressed with proper cross-functional communication and a focus on more stringent product development practices.