F$*# your feature roadmap.

This comic strikes a chord with me for two reasons:

  1. Remote controls are too complex and I still can’t figure mine out to this day.
  2. Sadly, this meeting has happened far too many times in our newsroom.

So, let’s start by discussing my failure to manage these meetings, shall we?

Recently, I kicked-off a sprint discussion with our design/UX team. The agenda: review a list of MVP requirements for our responsive web article template. In a nutshell, this meeting was for me to give design a set of instructions to begin building wireframes.

And boy, did I provide them with a feature list. A doozy, if you will. It included all sorts of fun widgets and goodies requested from editorial, business development, ad ops, marketing and sales. After this “backlog grooming” review session — in which I carefully wasted nearly sixty minutes of everyone’s mental energy talking about every single feature necessary in the upcoming sprint— I asked if there were any questions. No? Wonderful. Then let’s regroup next week to review the first round of wires.

(I could feel the design team’s desire to gouge their eyes out with my Fage Greek Yogurt spoon.)

Sure enough, next week’s initial wireframe review was messy. The initial wires accomplished none of the goals we set out to achieve: to let our editors tell a news story more efficiently, to improve ad viewability, and eventually lighten the page (a.k.a. dump the junk slowing down our page load speed).

It would’ve been easy to point the finger at our design team; to tell them these wires did not achieve what we aimed for. After all, design seemingly went on a tangent focusing on a problem they thought they were solving for (hey, let’s make this template prettier!). But here’s the real issue from the start: I never effectively communicated what we were trying to achieve.

Seriously, F$*# your feature roadmap.

Instead of presenting the team a prioritized list of features, I should’ve presented a prioritize list of problems to solve.

Why does this matter? 
It makes room for the team.

For one, product managers don’t always have the right answers (as much as we’d like to think we do). In fact, when I look at who attends our sprint kickoff meetings, there are some incredibly talented folks in the room all eager to put their various skills to use. So, why not make room for them to do their actual jobs?

Great PMs should determine the right questions to ask, then route them to the right people who will be excited to answer them.

Also, this shift in perspective helps us avoid the old knowledge curse. Once the team is able to step back and reframe the problem, sometimes that widget no longer is the right solution. Perhaps it’s a new widget we never even considered to begin with that’s the smarter alternative.

Most importantly, this forces me (and the rest of the team) to take a user/customer oriented mindset. If we don’t think about the user journey and what his/her pain-points are, then the products we build won’t solve for anything of actual importance. And if it’s not important or doesn’t solve a problem for the user, then why build in the first place?

Of course, this doesn’t get me off scot-free. I’ll still need need to provide some framework for the sprint ahead. I’m not suggesting PMs should completely do away with their feature list. Keep it, but don’t allow more than a month or two of work to get into the feature backlog list. Don’t spend hours upon hours grooming it, speccing it, or talking about backlog items to designers and engineers in hour-long meetings. Instead, it should be seen as a final check-list we’re not allowed to talk about or constantly work on.

Now, enough writing for one night and onto Netflix.

If only I can figure out my remote…