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