-
Product Owner Fail – Bogged Down on the Trail
Winter Is Coming
Suddenly, the Product Owner is facing disaster. A key deployment deadline for the product is looming ahead like the early snows of a hard winter, threatening to close the mountain passes and strand the project in the wilderness. And now, after a long journey, the outlook is increasingly bleak. The project is not going to make that deadline. How did it come to this? After some early fits and starts, it seemed like we were making such good progress! Actually, the problem didn’t arise all that suddenly—we’ve been dragging it along the whole way.
It seems that one of the most difficult lessons for new Product Owners to learn is to ruthlessly prioritize the product backlog, and to be equally brutal with every feature and story. Or to put it even more baldly, their worst case assumptions are never sufficiently dire. The consequent is that they are too generous with their features and/or lazy with their priorities, leading to unnecessary crisis as deadlines begin to loom.
What We Have Here Is a Failure to Communicate
Novice Product Owner often find it very difficult to comprehend just how merciless they need to be with their stakeholders and the product backlog. We give them what we think is unambiguous advice: Don’t gold-plate the features, you’ve got to identify and give highest priority to your Minimum Viable Product. First complete only what you absolutely need! But what does that mean to the novice PO? Here is a portrait of dear, departed Grandpa Jones—Grandma really needs it! And look at all these reports our legacy system had—the users will be outraged if they don’t have their heirloom glass cabinet to display the china! And don’t even try to start with me about the piano—Uncle Thad says if the piano isn’t in the wagon, he’s not coming either.
Yes, the project stakeholders are all very needy, and how can the project go forward without their support? So item by item, everything on the farm goes into the wagon … uh, backlog. All that very valuable, very-needed stuff gets dragged along in the wagon, and it is heavy. The PO decides it’s all got to come, so she doesn’t bother to prioritize it. It’s left to stakeholdersthe team to decide in what order to move it. Maybe they’ll do it by weight, or by risk. More likely, they’ll decide to move the easy stuff first; or the pretty stuff, the stuff that demos well and really pleases the stakeholders. Given the feedback from the demos, everything seems like it’s beginning to progress nicely, but all the really awkward stuff, that farm equipment, gets left until last while the team mulls over how to deal with it. (The plow! How will we move that?! It won’t fit in the wagon; we’ll have to take it apart, maybe reinforce the back axel of the wagon … let’s move the silverware first.)
Items that looked easy are revealed to be rather more challenging—and rather heavier—than originally thought. That antique chest didn’t look too heavy. Whoops, it’s filled with books! Does anyone suggest we might dump the books out? No, the books are just a refinement to this feature, the PO is not going to try to renegotiate the feature with the stakeholders now—everything associated with Needed Features must go in!
Draggin’ the Wagon
Even if this kind of stuff is just sitting there in the backlog, it drags the team down. They should ignore it, but they can’t help worrying about how those requirements will interact with current features. The whole MVP vision becomes oriented to the most complex of the “must have” features. The team adds extra complexity to the design because “we’re going to need it when we do those remaining high-priority features in Sprint 6.” It’s a heavy wagon. It’s so much harder to ford those rivers, drag it through those muddy patches where the corporate security group is complaining about potential vulnerabilities, and clear paths for it through administrative thickets.
Too late in a long journey we finally reach the foothills for the last hard push up the mountain when the snowflakes have already started falling. Now, at last, reality begins to set in, and so does panic. In their determination to “get the project back on track”, project management likely begins to “think out of the box”—that is, crazy talk—blurting threats of massive overtime or injections of additional resources. Hopefully, after contemplating the likely outcome of charging up narrow mountain trails in the dark with new (and somewhat dazed) team members, rationality will prevail.
Throw Out Your D[r]ead
Throw out the excess baggageThe truth is, short of just abandoning the whole project outright, there is only one viable option left: throw out the excess baggage. In fact, that was our first and best strategy all along, but now, with winter upon us, it’s difficult to throw enough out to make a difference. Suddenly, everything looks far more expendable than necessary, but even picking out the superfluous items takes time we don’t have. Not only Uncle Thad’s piano, but Uncle Thad as well may be dumped in a long sad trail of uncompleted and completed (but now deadly heavy) features. We “finished” that feature, but we don’t have time to finish the training, or work out the deployment procedures, or fix all those little issues we found in final acceptance testing (oh, we should have done user acceptance testing as part of the Definition of Done, but it seemed like such a chore to acceptance test incrementally when it’s so much easier to test all the necessary features together).
Perhaps, in the end, we avoid the very worst and make it through the pass with just the food and warm clothing. Sometimes, the best we can get at this point of maximum desperation is the MPVP—the Minimally Politically Viable Product. No user would be willing to call this product viable, but this release has just enough useful function to be declared an acceptable down payment on future deliveries.
Prioritize for the Perfect Storm, Then Enjoy the Sunny Day
Let us Retrospect together: how could we have avoided this near-death experience? The MVP is not a stretch goal! It is the very least thing providing value that the team is reasonably confident they can produce well before the deadline. The goal is to pare the first product release down as much as possible; to beat the deadline, not stuff it full of hopes and dreams. Even each sprint must come as close as possible to a MVP-If-Suddenly-We-Were-Right-Up-Against-It, a release we could live with if we were caught in an early blizzard next sprint. In that vein, the PO must continue to streamline every feature as the team develops them and she refines them with the users, sprint by sprint (don’t let the pigs get so fat they can’t carry their own weight!)
Indeed, the PO role is so very difficult because she must recognize and focus on global priorities across all the user factions. There are so many user factions, and each faction is convinced that their own needs are the most important. The PO must have both the authority and the confidence to prioritize demands without becoming a Feature Nazi (“No features for you!”). Instead, she is sympathetic and positive (“Yes, I’ve currently included your feature in a later release.”) while still paring that first release to only the most vital, absolutely essential and affordable, features.
What she doesn’t need to worry about is being “fair.” Corporate goals translated to project essential objectives dictate priorities. Some users may be left out and have to catch another wagon, but nobody gets stranded in the snow. Look, see that by the trail? It’s a glass cabinet! And there’s a whole dining room set! Who would try to bring a whole set? It’s a warning. Leave that stuff behind for the next load. Then enjoy the sunny day on your rapid traversal through the mountain pass.
Racing chuck wagon