Product Development Process

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

1:10 is what has been used as a rule of thumb in my experience. A PM wears many hats. If you don't have a program manager (pgm/tpm) 30% - 40% of the PM's time may be going into project management activities and you may need an extra PM (or your first TPM) You may be supplementing other functions in the org: marketing, sales, solution consulting, BD. The point here is to assess what are the org needs and what role PM is playing or ought to be playing. It might not be a matter of how many PMs to Eng ratio. How would an extra PM accelerate the busines? If you were the CEO how would you best in...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 collaboration of engineering and PM as part of roadmap and prioritizatio...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 development cycle (and test before they release, incl. all relevant edge case...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 address them: * Disagreement on overall roadmap prioritization: take a s...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 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...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 time component will be determined based on bottoms-up p...more