Pair PM-ing, An Exploration of an Idea

Pair PM-ing

Silicon Valley Product Camp 2013

Exploring Deep Questions

or Not to Pairto Pair

Spending Our Time

• Intro’s• Perspective• Premise• Primer• Stories• Suggestions

Introductions

5 Seconds Each

Hi My Name is Scott Gilbert

• I’m a product guy who likes Agile/Lean• Been building new SaaS products lately• Helped create P-Camp, 2013 Camp Organizer• Pan, praise or poke me @AgileProductMgr

Your Turn

5 Seconds Each

My Perspective On PM

• It’s a big tough job– Too much work, not enough time– Can’t cover the whole grid

• Covering the planning onion is hard to do– Can’t be in 2 places at once (Team & Market)

• We feel like we could/should be doing better• We generally don’t collaborate together– But we kind of like to…look around

• We have hard problems to solve

Premise

• Engineers pair to solve tough problems and achieve better outcomes.

• PM’s have tough problems to solve so why can’t we pair too?

Pairing Primer

• 2 people 1 workstation• Driver / Navigator roles• Rotate “often”

Pairing Benefits• Produce shorter programs, with better designs and fewer bugs, • Typically consider more design alternatives • Arrive at simpler, more-maintainable designs; they also catch design defects

early.• Usually complete work faster • “Impossible" problems become easy or even quick, or at least possible to

solve when they work together• Knowledge passes between pair programmers as they work. They share

knowledge of the specifics of the system, and they pick up techniques from each other

• New hires quickly pick up the team practices and learn the the system• Improved discipline and time management. The partner "keeps them

honest”• People are more reluctant to interrupt a pair than someone working alone• Increased morale and greater confidence in the correctness of the code

Let’s Share Some Stories

First Story

PM’s pairing on 1 products

Second Story

PM’s pairing across products

Pairing on 1 Product

• The Situation– Flipin the whole flipin’ Model and Brand– 3 PM’s, 1 Product, 2 Teams*– C-level tiger team met daily and made decisions– Teams are executing and iterating weekly

Paring on 1 Product

• What we did– Iterative solution definition using Jeff Patton’s

story mapping technique to find our MVP.• I drove initial map set up• My pairs helped navigated to find right solutions• I updated stories and AC’s during/after each session

– Once we agreed, I handed off story map and they drove implementation rolling stories into backlogs

– I was then free to handle rest of of the go to market and other tasks

Pairing Across Products

• The Situation– Implementing a portfolio-wide capability (Q1 ship)– 4 PM’s, 5 Products, 5 Teams– Each team at a different stage of development• 1 already shipped a partial solution…the Pioneer*• 1 already shipped a complete solution…the Standard• 3 were in development…the Followers

– Historically not well “aligned”• PM’s go it alone • releases would come out and…“you did what?”

Pairing Across Products

• What we did– Show and tell• Document differences, issues, opportunities

– Prioritize the list agreeing upon acceptance criteria and exceptions for each product• Established a portfolio wide MVP

– Rolled stories based on above into each backlog with coordinated release schedules

Suggestions

• Pairing Benefits– More critical thinking– Better understanding of the problem– Find cross-product issues sooner– More funner workin’ together

• Pairing Situations– Roadmaps/Release Plans– Backlog Grooming & Priority– Market / User Research– Epic Breakdowns / Story Mapping– Lo-fi prototypes– Stories, esp. the AC’s, esp. across the portfolio

Suggestions

• Pairing Practices– No Cold Starts – have something minimal to start– Do it in Chunks – Don’t be together all day– Do it Consistently – Maybe through 1 release cycle– Switch your Pair – Rotate and pair with others– Switch your Role – Start as Driver, be Navigator

Go Get a Pair

Thanks & Happy Camping !!

Some Content• A funny video (pairing bit @45 sec)http://vooza.com/videos/code-pigs • A critique of pairinghttp://techcrunch.com/2012/03/03/pair-programming-considered-harmful• A story about a PM & Developer pairinghttp://www.philmetcalfe.com/developer-and-product-manager-pair-programming • A story about Pair Designinghttp://www.slideshare.net/k4rl/the-psychology-behind-pair-designing• An article on Product Managers and Ownershttp://www.rallydev.com/community/agile-blog/how-staff-appropriately-successful-transition-agile-product-management