Category: Engineering

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.

Keeping engineers in their place

This is one of a series of essays about how to relate to some of the most common types of stakeholders and teammates. Here, I’ll provide some tips for working successfully with engineers.

  • Know some shit about technology and programming. For real. Not a weekend bootcamp or a few YouTube videos. If you didn’t take programming in school, take a class online, and build something real. Simple html/css/js web sites are really easy to build, for example. One of the best ways to connect with almost any engineer is to have opinions about programming languages or tech fads. DON’T fake it, but also knowing what is hard for you, what you like or find cool in tech is great small talk and icebreaker fodder.
  • The most important thing the PM can do to influence an engineer’s motivation is to give them context and provide reasons why. Explain the politics, if you have to make an “exec mandate” decision. Give them the data behind your decisions. Always be willing to share reports and product docs with them.
  • Even in the most “top down, corporate controlled” culture, you must remember that software engineers are skilled, and often highly in demand. They are not your minions to build your beautiful visions; they are your skilled partners.
  • Don’t let them refactor without reason. If engineers are asking to refactor or rewrite software a lot, get an understanding of why, how long or often this is likely to go on, and if there are other factors in play. One CTO co-founder of mine literally banned engineers from saying in stand-up that they were “re-factoring” something as their task that day. They had to explain what functionality was being changed and why. That seemed to result in a lot less refactoring, some how 😉
  • If you have talented and valued engineers and they reject process and administrative tasks, don’t fight hard. If you can, simplify and do it for them. if they still reject participation and process, become a broken, polite, but insistent record. If that fails, escalate.
  • Always treat standup as not optional for the team (including the PM). Showing up and participating in standup is the definition of being on the team. If you don’t take it seriously, you don’t take the team seriously. Especially for remote people or teams. Don’t ever let engineers skip stand-ups regularly.
  • Never think of your engineers as interchangeable. Engineers have unique problem solving styles, skills and strengths. Managing a development team is like  managing a baseball team. You can’t make a pitcher a 1st base slugger. Or in an orchestra, if you prefer a non-sport analogy, you maybe can get a viola to play violin, but if you need a French horn, there is not much they can do for you. Its not like the roles are 100% rigid, but players have some roles they can do, some they excel at, and some they can’t do.  Know what your engineers are good at, what they like doing, and try to incorporate that into your planning and management.
  • Every engineer has a multiplier. The multiplier is the difference between how long an engineers estimates are and how long their work really takes. Rather than point/velocity systems, I prefer to use these multipliers for planning. Basically when an engineer “takes up” a task or needs to size it up for planning, I ask how long it will take. When I first work with an engineer I keep track of how that estimate relates to the outcome. After a few weeks you should be able to pretty accurately plan delivery (modulo tech risk, scope change, etc) from the engineers estimates times their multiplier. I’ve worked with engineers who’s multipliers have been from 0.75 to 3 or more. Don’t try to get them to be more accurate estimators, and don’t flaunt you’re multiplication in their face. It could seem like you don’t trust them. Let this be one of those subtle arts of PM’ing.
  • Some engineers, especially young, ambitious, ones, might be keenly interested in,  or vocal about, product or design decisions or plans. If you can safely involve them, you should try to do so. If their ideas are bad, or their “product orientation” is detrimental to the team (rather than helpful, which it can also be), be direct about it with them. On the other hand if an engineer is not interested in business context, product theories, or the why of their work,  and just want to work on task, respect that and leave them alone. The outcome is what matters, not the method.