1/ What problem are you addressing? How are you solving it and to what extent? Who’s hero will you be and when? This all goes into a plan (but isn’t yet a plan — ask @stevesi). No matter how out-of-control a project is when you arrive, putting up a straw man plan up is important.
2/ Problems are more complex than 1:1 mappings to solutions. Popular product often address a portion of a larger long-term vision. Regardless of ship frequency, PMs need to limit that vision to determine who the team can be a hero to in the next ship timeframe.
3/ Data about the problem is important to determine how much pain you can reduce for users w/each unit of effort. Data about your team capacity and effectiveness is important to understand available units of effort in the milestone.
4/ Armed with that data, you can create a prioritized list of functionality, and you can draw a line through that list where your capacity stops (buffer for time off, unknowns, etc). That’s just the basics, but you now have an idea of what your next ship train has onboard.
5/ Get agreement/sign off. Stakeholders not signing off? Set a date for feedback on what’s needs to change and why. Address that feedback & gain agreement or, if one can’t be reached, commitment to the plan anyway (Amazon calls this “Disagree and commit”)
6/ Now comes process to stay on track. You’re PM team are basically Spartans — a small group that holds the line. Set up a daily intake triage, and a daily war room. Stakeholders “finds” work that they think needs done (bugs, features, etc)? Bring it to triage and prioritize it.
7/ if the work goes above the line, then the proposer brings it to war room where they and other stakeholders debate priority. If it does stay above the line, other work needs to fall off the bottom ... immediately. You now have a new straw man that needs full agreement. Repeat.
8/ Your new straw man should be evaluated to determine if it still solves the intended vision. If your straw man can’t gain agreement based on the work falling off of the bottom, then your options are adding capacity or increasin time.
9/ People rarely know how to execute on the PM triangle. I’ve just told you. Your GA plan is the product bible. Make people argue to get on it, or off. Constantly evaluate changes to the bible to determine if they relieve the pain you intended to.
10/ Use beta feedback to adjust your vision. You prioritized work based on your understanding of the data you had. Beta brings new customer insights and you should change your roadmaps accordingly.
11/ All of this is oversimplified and seems basic, but it clearly isn’t. We see evidence of the difficulty all the time: Products that miss the mark & get poor reviews. Overworked developers pushed past their capacity due to constant interruptions/context-switching mid-sprint.
12/ A solid plan requires a solid process to defend and morph it as necessary or it isn’t a plan at all. Executives, stakeholders, customers and team members need reason to believe that your process maintains the best agile path forward. Get yours together!
