How A Football Coach Taught Me To Product Manage Like a Boss
Making critical calls under pressure requires a framework for removing emotion
Every product organization starts with the intention of building the most important features desired by the most customers and to differentiate its offerings from the competition. Yet as organizations, we often fall short of this goal for predictable reasons: the executives shouting loudest often get their way, the CEO asks for pet projects based on that thing he heard at that one conference, and developers build the stuff that’s most fun.
We’re all guilty of this.
I’ve run product teams for the last seven years and been in tech for 15+ years. And I’ve developed a matrix to help prioritize the right things to build and to communicate the priorities to tame our poorly behaved instincts.
An Internet product manager has two jobs: (1) Figure out the right things to build (priority) and (2) figure out how those things should be built. Let’s talk about prioritization. The matrix below is a tool that’s come in quite handy for prioritization, and I have Andy Reid to thank. Read on.
The challenge, as I mentioned, is that requests come from all corners. Most of the time, these don’t have any correlation to actual strategic importance. Any one of these projects could be the right one, but without a framework, it can be exceedingly frustrating for everyone involved. Decisions seem arbitrary or biased, and engineers start rolling their eyes at you or looking for new jobs because they keep getting sent on fool’s errands.
Enter Andy Reid.
As a die-hard Eagles fan, there were a lot of things I hated about our former coach. But the one thing I did admire — and is surprisingly applicable to the product world — is that Reid always carried with him a decision matrix to help decide when to go for it on 4th down, when to go for two-point conversions, etc. You see, in football, lots of coaches (and people playing Madden) make emotional decisions such as going for it on fourth down when the wisest decision might be to punt the ball and simply manage field position. If you can figure out your decisions ahead of time without game-time pressure, you can create a framework that everyone can agree on ahead of time, which takes emotion and stress out of the equation.
In the product world, this means setting out clear strategic goals and a framework to support that. Agreement on these strategic goals independent of specific projects means decisions can be justified based on how well they support those goals rather than some arbitrary reason. When someone comes to you with their hair on fire asking for some random feature that doesn’t align with the strategic goals, you can point to the priorities that everyone agreed upon to explain why it won’t get done.
This starts at the highest levels, where leaders must set clear, simple, unambiguous corporate goals. At Upworthy, our founders limit them to three. It’s tempting to go beyond, but we are big believers in focusing on a few things in big ways. We revisit them every 6 months or so. But having three big goals immediately helps provide filters for projects — they either support the goals or they don’t.
The next level down, we start using a spreadsheet to rank our projects. We use two scores: Impact and Scope, and assign them on a scale of 1-5. Impact measures how much a project will affect our stated goals. Be sure to indicate which goal it supports. If it doesn’t support the stated goals, it doesn’t make the cut. Different goals may have different scales, so a key is important so everyone’s talking apples to apples. Scope should be pretty much standard and indicates the level of effort required to build said project.
This is an example in a hypothetical NSA project prioritization:
If we plot them out, they’d go into quadrants like the one I showed at the top of the post. The high-impact, low effort projects are the “No Brainer” projects we should do immediately. The high-impact, high-scope projects we call “High Risk Swings,” and we take a couple of those a quarter. The low-effort, low-impact projects we do as “Filler” projects when a developer has free cycles. And obviously the low-impact, high-effort stuff we avoid like Andy Reid avoids running the ball.
Occasionally, something we really really want to do falls outside of our desired quadrant. This actually is a useful tool to help challenge our conviction around that. Exceptions can be made, but they are explicit exceptions, rather than done simply because so-and-so asked us to. We better make sure we understand why we’re deviating from our agreed-upon strategy. Is it new data? Is it competition? Do we need to revisit our goals? We won’t do it just cause so-and-so really really wants it.
Finally, the one flaw with this type of prioritization is that many internal projects quickly fall by the wayside. Things like code refactoring for future scalability, or security, or automated backups, or disaster recovery. The best way to address that is to say that we’ll spend X% of our time/resources on business priorities and Y% of time on infrastructure/R&D projects. You should agree as a company that infrastructure investment should remain an ongoing investment at Y% and tie those projects to that goal.
Mike Su is Head of Product at Upworthy. I know everyone asks it, but I’m asking nicely-er. Will you follow me @biggiesu on Twitter or on Facebook?
Also, big shout-out to fellow Eagles fanatic Mark Suster, the hipster-Andy-Reid-hater (he hated him before it was cool to hate him), who provided lots of feedback on drafts, as well as folks from the Spark Capital PM group for reading early drafts.
