Managing a Backlog

Product management fundamentals #1

As we grow the product team at RelayRides, I’ve been assembling some tips about the rudimentary responsibilities for the product organization.

I’m sharing these more broadly to increase the useful feedback from the broader product management community. Hopefully, they can also be useful for PM noobies just beginning their rewarding career of massive responsibility with virtually no authority. Welcome!

First up: Wrestling the angel known as the backlog.

Product owners revel in discussing products, but are strangely reticent to discuss the procedural mechanics of managing a backlog. It’s mostly like that scene in Rushmore: Max ‘Were you in the shit?’ Blume ‘Yeah, I was in the shit.’

The backlog is an ordered list of user stories to answer the question ‘What should we work on next?’ The atomic unit of a backlog is the user story, the brief write-up of a discrete end user benefit with guidelines.

Once your market, strategy and key metrics are identified, your cup runneth over with seemingly worthwhile user stories.

In a way, it’s simple.

Two simple and effective mantras for organizing a product backlog are:

Will this make the product great? (aka the Jobs way)

Will this make your product grow? (aka the Graham way)

Both are right-minded and hygienic lenses to detect an indefensibly weak backlog. These approaches, however, have significant limitations.

The Jobs way presumes a leader (you?) with miraculously divine instincts about market fit. If you’re that, don’t bother reading further. You’re the next tech messiah!

The ‘provable growth impact or BS’ mindset can lead to short sighted optimizations. Growth hacking can crumble as distribution platforms shift. It discounts dark social word-of-mouth that great products generate. Growth is fragile if customers don’t truly value your product.

In a more accurate way, it’s not so simple.

Acknowledging the oversimplification of ‘growth’ and ‘greatness,’ here are (at least) two more granular categories of factors

Utopian factors: Those that strictly analyze signals for a product/market fit.

Pragmatic factors: Those that take into account human nature and constraints.

Utopian

The backlog should primarily be ordered this way: by looking at the marketplace and getting signal about what’s working and what’s not.

Implicit Consumer Data

We’re blessed to live in an era and industry with fantastic tools to access and manipulate implicit user analytics. It’s the primary input for many backlog decisions. As soon as you’re in alpha, it’s reliably the justification that resonates most clearly with an engineering team. And for good reason. Customers vote with their feet. And we see their footprints. Invest in the experiences that are being used by the customer you care most about; reimagine or avoid the ones that aren’t. Beware the Streetlight Effect (looking where the data is clearest versus where it’s most relevant).

Direct consumer asks or complaints

To paraphrase Kramer as Mr. Moviefone: ‘Why don’t you just tell me the user story you want to see?” This, of course, happens all the time! Ask your customers. Talk to them, interview them, send them surveys. Their insights are gold. Pay special attention to your support tickets and staff.

Direct Competitive Parity

Your product’s deficiency could be their differentiation. You want to match or, ideally, exceed your competition note for note. Sometimes it’s hard to rally the troops on this one, especially if you’re matching versus leapfrogging. Only the paranoid survive. Contempt for this is hubris.

Industry Parity

We’re ambitious for our products. We want them to be world-class. When an industry-wide approach becomes de rigueur, everyone notices when you’re a laggard. A perfect recent example is sites moving to ‘https.’ Justification based on direct ROI for these types of changes is often challenging. Even harder if the parity is design-based versus something that’s seems less subjective, like security. Appetite for these is usually baked into what the company culture values.

Want more? Hell, yes.

The Pragmatic.

Exclusively focusing on utopian, versus pragmatic, factors can make your backlog academic or, worse, irrelevant. You need to include human factors, team dynamics and external dependencies. Some of these can be politically complex to address or ignore.

Deal or Legal

Those deal or legal compliance dates can creep up, can’t they? Other than being tardy, the main thing to keep an eye on is the specter of a deal or legal requirement versus its actual existence. To avoid this, build trust and keep open lines of communication with someone who can tell you what’s what. Note that, for legitimate hard dates, there’s rarely a penalty for getting something done early. And a late-breaking curveball in implementation can take longer than expected.

Variety

Variety is important to ensure each dimension of your customer experience is constantly improving. Something might be important, but not time-sensitive or sexy. SEO, notifications, admin features are good examples of product areas that need constant grooming to be great. But rarely are they the top priority. Variety can also help keep a team stay motivated. Variety should not be incompatible with focus.

How baked (and how long baking)

How long a user story has been in the oven (discussed and refined) affects how it tastes. Sometimes, an obvious idea comes to light and it feels like it must be done now, now, now. If a story goes in to sprint planning too hot, though, it often gets spit out. It hasn’t been socialized sufficiently. The implications haven’t been thought through. It conflicts with other approaches. Conversely, sometimes a user story’s been baking too long and gets a stench. That stench is lack of support to build it.

Team Domain Expertise

This is an important factor that is rarely explicitly mentioned out of sensitivity. When discussed, it’s often quickly dismissed. It can be the elephant in the room. If you feel a strategic area is crippling the product offering, you’ve got to influence recruiting or outsource accordingly. It’s not always a negative, of course. Domain expertise can also be opportunistic way to differentiate (Our Android wizard can do this).

The Window of Opportunity

You’re a smallish consumer ‘quantified-self’ app startup. Someone within Apple likes you. They approach you about being one of the first applications available on the new wearable computing iWatch. Drop everything. Stop the presses. The world just changed. Often someone is trying to make you feel that this magnitude of opportunity is happening. It’s rare. But be aware that they do occur.

Executive Mandate

Learning to push back comes naturally to most PMs, who are by and large, an opinionated and bull-headed breed. Learning how to push back is hard. Learning when not to is harder. In larger enterprises, executive influence seems to play a larger role. Even in small organizations, though, unless you’re CEO, it’d be misleading to not include this factor. Pro-tip: it’s bad form to use this justification to the team unless absolutely necessary. There’s a reason you’ve been told to do something; make that case. Related: choose your bosses and your battles carefully.

Momentum

The major user stories of an epic have shipped and, in a vacuum, some of the smaller follow-up stories would not be next on the list from a priority standpoint. But those smaller stories are unfinished business. And, from experience, it’s now or never. Because team tolerance for incremental improvements diminishes dramatically from the moment the heart of the change is complete.

Bonus: The Hat Tricks

Oftentimes (hopefully, most of the time), a user story or epic aligns to capture multiple factors simultaneously and unexpectedly. This can make it more valuable than any of the single justifications. For example, it could lead to quantifiable decreased cost, competitive parity, and also address a direct customer complaint. It’s born at the right time.

There are, of course, many other human, situational, hell… seasonal factors that influence what makes a backlog well managed. The key to making this process instinctual versus overwhelming is to feed on a steady diet of the data that inform these factors. Constantly graze on user metrics and customer care tickets. Chitchat with customer care and engineers every day.

After you’ve considered them all, take another close look at your ordered list of user stories. Ask yourself again: will this make our product great? Will this make our product grow? Rinse and repeat. You’re now managing the backlog. Salud!

Next time:

Product Management Fundamentals #2

A Product organization’s role in Sprints