The big question for your end game

As a Product Manager sooner or later you find yourself dealing with one of those precarious situations where there seems to be no sane resolution to the challenge in front of you. The release date cannot be moved, you have no additional resources to work with, and there seems to be endless number of release blockers - features or defects that absolutely must be addressed prior to release.

To help successfully navigate through this last mile of your release journey, ask yourself and your team the following question:

At this stage of the project, can we afford to expend any effort on anything other than feature or capability that if missing will prevent 100% of our target customer base from adopting our product?

• Any effort includes testing and documentation of workarounds;

• Anything other includes useful capabilities requested by loyal, real customers - people with families and kids who we absolutely want to delight;

• Target customer base does not necessarily include each and every one of our existing customers, and does not have to be centered on Big Bank ABC in particular (or Super Big Telecom, or Government Contractor XYZ, nor many other prominent check writers).

One way to upset your developers

While there is no shortage of different ways to upset someone working hard and under stress, I'd like to share a real life story to illustrate how even seemingly innocent discussion can have unintended effect.

As a product owner I began noticing more and more technical stories added to my backlog by the scrum team members. These stories often focus on improvements that are not immediately clear to the end user of the product. In many cases with a little extra effort it is possible to rephrase the description to turn them into user stories. In other cases, these are indeed technical stories benefiting developers more than the end users.

Here is how I tried to explain to my scrum team why I am not the right person to rank these stories for them.

I told them as a representative of our customers, I want to understand the value of every story on the backlog in as far as it relates to a tangible product feature or a capability. If I see enough value to potentially pay at least $1 for the feature, this means a story is a valid user story and I should be able to rank it. For example, if I buy a car, I may care about maximum speed, rear view mirror and even the type of stitches used for my seat covers. As long as I care for these things, I could potentially arrange them in a ranked list. On the other hand, features that I don't understand... I simply don't care about. For example, I don't care if my car is powered by a V-type, in-line, horizontally-opposed or rotary style engine, what type of alloy is used in my brake pads, or that my SUV came from the same assembly line that also makes minivans.

I told my team they are welcome to use technical debt for these stories, which can take as much as half of our typical sprint velocity. The team knows better which of these stories are more important and should make prioritization decisions based on technical merits, not the product owner.

Can you see a problem with my reasoning? If so how would you go differently about it?