I am trying to brainstorm some good screening questions as a candidate to ask companies during my interviews that would suggest the following:
- Product team is seen as a feature factory / custom dev shop
- Focus is on how much they output rather than the outcomes they achieve
- PMs are littered with busy work, multi-tasking and meetings rather than focused, deep work
Excellent question. If you think like that ahead of time I think you’ll be fine anyway
It’s all guessing after all when we’re trying to figure it out from the outside but here are a couple of things right off the top of my mind based on my experience leading a large product team:
1- Ask about what the PM’s day is like. One of the most important distinctions is what kind of PM team it is. In my opinion there are broadly 3 types;
- The strategy/business PM (what does the customer need? How does this fit/shape our company strategy? What does this translate into in terms of features? Etc),
- The architecture, CS strategy and tech strategy PM (often called the TPM. I like to call TPMs the kings/queens of aha moments when they’re working with the first type of PMs. Aha, we can do that if we tap into the payment platform and run a greedy algorithm because their data is structured in X way and what we need is Y)
- The roadmap PM (ok let me break this into sprints and make sure the factory is working without critical failures).
If I understand your concern correctly, you don’t wanna be on a team that is predominantly the third type.
2- Ask about product P&Ls. Yes I know it sounds heretical in tech-land but it is extremely telling. Who owns budgets (very different from who spends them) and owns top line responsibility pretty much determines 80% of the “actual product ownership” no matter what any company tells you (some exceptions exist at certain places in google, AWS, etc but they’re rare and they eventually converge as well)
3- Ask about reporting lines. This is a double edged sword. If the PM team reports to engineering then it very well could become a sprint managing group of Jira/spreadsheet masters. If they report to some marketing functions (I’ve seen it happen before not at Amazon though) they could become more fluff than product. This one you got to use to complement the rest of the data points to form a picture.
Hope this helps
Some questions you can ask -
What’s the last experience your team shipped, can you walk me through how that came to be?
Red flags: it was on our roadmap, our VP of X suggested it, and no mention of vision.
Alternate: Ask what the product value prop is and the last feature that meaningfully strengthened or advanced that value prop.
Red flags: A value prop that does not map to company strengths. Platitudes in the value prop like “easy to discover” “customer experience”—clarify, ask what those mean to the person if you hear them. Descriptions that suggest the person is back fitting a recently launched feature into the value prop.
Awesome topic and great answers.
My two cents: ask about the planning artifacts the team(s) utilize from the highest level product strategy to a single epic or PRD. If they mostly revolve around deliverables rather than capabilities, or even better - outcomes, then you my friend have a problem
- A company that is product-centric has a very strong emphasis on being able to articulate their core strategy and competitive advantage to teams, has planning artifacts derived from that strategy that identify areas within their market that if tackled can result in high business impact, and transparently measures the impact they actually created.
- Sales-driven companies, that essentially use “tech teams” to deliver features they want to sell/market usually have planning artifacts and processes that don’t bother passing down the strategy and areas of investment (as the decisions on “what” and even “how” have already been made), and logically focus on deliverables and outputs. You’ll notice how “high level” artifacts are usually thin or non-existing, heavy focus is on backlog/roadmap, and then measurements/rinse&repeat are again non-existing.
Also, the PM-to-engineer ratio speaks volumes on how PMs are utilized. A PM that spends their time trying to understand how to deliver the most value can’t service 7-10-12 engineers, at least not without a junior PM help. I had PMs without teams operating for a full quarter or even more, just to grow confidence and validate hypotheses how are we are going to deliver value in a specific area before an engineering team dives into making amazing things happen.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.