Participatory Product Management

The reasons to make your product management and planning processes more participatory is a subject for another essay. Suffice to say, it’s something I think has powerful payoffs and, for me, is a strong cultural preference. By participatory, I mean involving other people in research, planning and even decision making in a real, genuine way. Anyone can ask for feedback, are you confident that you sold your strategy well internally? Let people vote anonymously, it may surprise you.

I’ve been lucky to work as a cofounder, in small orgs and now in a collaboration focused medium sized org, so I’ve had some practice at it. Here’s some tips for making your product management more broadly participatory.

A Few Ideas
  • I strongly recommend you adopt a kanban[LINK] or similar queue based work process. Don’t be dogmatic about it, but kanban is based on a pull queue and allows skilled team members to manage their own pace and have a sense of ownership of the tasks they take on. At the same time it allows you to maintain prioritiy and context. I believe scrum systems, in particular any system which requires negotiated sprint commitments is detrimental to the PM’s relationship with the team. It sets you outside the team and is focused on a tension (the scope the product owner wants vs. what the team thinks it can do).
  • I like to have teams perform a product self-evaluation. We pick a set of aspirations for our product or ourselves, (“sticky”, meaning hitting a certain user retention,”stable” which we’ll define to mean a certain crash rate). Prior to long term planning processes, we anonymously rate the product from 1-10 on these aspirations. This allows everyone to see how their peers feel about what they’re building together. It also can help to focus planning discussions if there is obvious consensus on the areas needing most improvement.
  • No spectators. All team members should participate in as many process meetings as possible. Design, QA, data analysts, ops, research… anyone who builds, rather than sells, the product should be at stand-ups, planning and retros at minimum. Then, run inclusive meetings. Open up the floor to everyone. Call people out in positive ways, especially if they are marginal (ie. not a lead or core member). Don’t let interrupters and loud mouths dominate. Don’t let men talk over women.  Encourage introverts and non-native English speakers to follow up over email or in 1:1s where they might feel more comfortable participating genuinely. It takes work to participate, and it can be a great gauge of engagement and commitment. But in enabling and evaluating participation, be very aware of bias and culture.
  • In very healthy situations you can actually allow teams to vote on their priorities and it doesn’t turn out horribly for everyone! Here’s how it works: you’ll need a team that has a strategy and is bought into it, has some rough consensus (or a couple is okay), and a reasonable ratio of different functions (ie. this doesn’t work if their are 8 backend engineers, 1 frontend and 1 designer). I have used a weighted voting process to mixed effect, depending on the team, but sometimes resulting in a better plan and very high level of team commitment and deliver.It can be done in person or on a hangout, but in person is more effective at the emotional bonding and buy-in. This is a good activity to do at a retreat or off-site.
  1. I do this after status and strategy presentations and discussions. This puts people in the right frame of mind, and reminds them there are shared goals and constraints they are operating under.
  2. I write up potential epics on large post-its and put them on a wall.
  3. The team write their own proposed epics and post them on the wall. People can ask questions about the scope and meaning of the proposals, and posposals might be edited, split or grouped at this stage.
  4. I move any “must deliver” epics into the “approved” area of the wall. Try to limit these to existing/carry-over commitments and executive mandates.
  5. Assign a budget of dots/stickers/votes to each team member. People can then vote by placing the dot/sticker/vote on a post-it. They can use their votes in any distribution they want, so they could put all their votes on their biggest priority or distribute their votes. Seeing how team members assign their votes and how they allocate their budget can be very revealing of people’s priorities and interests. Don’t forget to vote yourself 🙂
  6. Remove any epics that received no votes. Allow each team member to assign one additional vote.
  7. Guesstimate the capacity for the planning period (weeks of work is a good level of estimation). Order the winners by vote. For each do a very rough on the spot scope and estimate (again a week is a good level of granularity). Do not record these estimates and DO NOT USE THEM as commitments. DO use them to determine how far down the list to go. Move a reasonable number of epics to the approved area.
  8. Review dependencies of the approved epics and identify tasks to be filed and next steps for each. Follow through. When you set up a road map, board or whatever manifestation “planning” has for you, be sure to point out the effect of the voting on the resulting roadmap.
Warnings
  • Don’t waste time being participatory if you don’t need or want to; only be genuine. It’s worse to tell people they have a say but actually dictate than it is to just dictate and be done with it.
  • These kinds of approaches and cultures are not great for making deadlines. But that doesn’t mean they are slow. In fact, I would posit that the velocity and agility of participatorily planned teams is greater than command and control or scrum-negotiation teams. Particularly for startups or where pay is lower and thus you need alignment via shared intrinsic motivation, rather than carrot/stick compensation and corporate laddering.
  • Introduce and practice these things cautiously and iteratively. Always retro. I cannot say that enough. But as you practice and iterate, also learn the nuances and tools available to you to subtly manipulate the outcomes, based on your particular skill, personality and context. Be genuine. Respect the outcomes of votes and take input seriously. Don’t try to damn the river. Learn how to channel it.