Some #prodmgmt Qs for interviewer... (1/4)
- technical debt
- recent prod issues / reactive work
- direct access to customers
- attrition rate for PMs
- typical calendar / mix of activities
- last 5-10 prod decisions and outcomes
- details of decision making process
- metric you must drive to be successful
- psych safety on teams
- dedicated #ux ?
- how team missions are crafted
- autonomy over roadmap ?
- deployment pipeline, ease of collaboration
- access to product usage data (tools?)
- current “big bet” and key unknowns
- career development (conferences, training)
- incentive structure for team members
- amount of pre-committed work
- examples of PMs being reward for specific behavior
- details of approvals, sign-offs, roadmap reviews
- overall product “culture” (role of product)
- What you say, and how often you say it
- What, when, and how you celebrate
- The losses and missteps you acknowledge, and how you respond
- How you behave when the chips are down
- What you fight for at all costs
- The corners you cut
- Who you hire, promote, and compensate, and who you fire
- Who you “smoke out” until they leave the organization
- The worst behavior you accept and the best behavior you reject
- The voices you amplify, and the voices you suppress
- When you encourage conformity, and when you promote diversity
- How you handle disagreements and differences in opinion
- How and where you spend your time and money
- What gets discussed out in the open, and behind closed doors
Here’s something you see often w/ teams and #kanban
Team: “Can we move cards backwards?” (1/11)
When this happens, we’re in a pickle. In true pull-system fashion, the developer has pulled another card. Test finds an issue that demands developer’s attention. What to do? (2/11)
One solution is to say “hey dev, you can only be on two things at once...one of which is developing”. Seems reasonable...and keeps their bandwidth open to fix issues. (3/11)
Model the work, not the “workers”. With team member magnets, checklists, and markers...the bottom design can more than adequately model the work
If work ever “moves left” (e.g. QA/demo passes an item “back to dev”), then the top dsgn breaks. It is all doing.
Another classic anti-pattern is team/individual lanes and “splitting” the work. The bottom option will probably catalyze the right conversations....though the top option with string can also do the trick. (2/4) #kanban
A compromise if teams want their own card for some reason... is a hybrid board with “epics” (larger chunks of work), and all of their related cards.(3/4) #Kanban
...and you know what? Those exact same things are muttered by engineers/QA all the time.
They have nothing to do with #agile, but everything to do with paint-by-numbers approaches to “delivery”, org silos, and overly simplistic “#design then build” models. 3/n