Monkeynoodle.Org

We can’t do all the things at once. In fact, good product management requires painful prioritization: working on this now, working on that later if at all. Some of the rocks get dealt with now. Others have to be deferred.

Product ideas are a relatively easy problem to prioritize, mostly. Customers want them, and if you defer something important, demand will be loud and it will be back. No customer demand? Maybe it wasn’t really a good idea. But what about normal tasks? Move this project from temporary ownership to stable ownership. Update that project from an older toolkit to a newer one. Fix all the paper-cuts and performance bugs over here. These are maintenance tasks, and they can seem quite different from the enhancement requests coming from customers and the field. However, product problems and maintenance tasks are really two sides of the same coin; they all involve getting things changed, coordinating different parts of the organization, and improving outcomes. While an external customer might see and know to ask for changes in the product features, they can also benefit from what seems to be a wholly internal process improvement. For instance, a SaaS changing its billing infrastructure can result in better accessibility to billing data. Maybe that means more timely or accurate account statements, or maybe it means a new license model becomes possible. They can fall into the trap of medium sized problems.

If you haven’t heard of it, the medium sized problems trap looks like this:

• Small things get done easily and quickly. If they’re annoying, someone just does it, if they’re dumb someone explains and solves.
• Big things either get done or get purposely deferred. They demand attention and decisions. Like the product feature ideas discussed earlier, a big problem like failing a compliance audit or a big opportunity like winning a major customer is going to get priority now.
• Medium sized things are too hard to fix quickly, but not urgent enough to fix now, so they don’t get done. Ever. They’re too interesting to ignore, but not critical enough to prioritize. We wish we were the organization that could do these things today so we hold them on our backlog and hope something changes.

Hope is not a strategy. Solve medium sized problems like this: Evaluate the problem, do what’s feasible now, and defer what isn’t until a set time.

Evaluate

Take a minute to review the medium sized problem with fresh eyes.

1. Honestly evaluate what happens if you do nothing right now. After all, a medium sized problem tends to not get solved, so you’ve probably got some history to point to. So what happens if you don’t act this sprint? Maybe things are changing in such a way that it’s less of a problem. On the other hand, is this the month where it’s finally a real problem?
2. Is there something that can be done with incremental resources? In other words, using the current team and deferring something else, could you solve a part of the medium sized problem? Has the landscape altered in a way that makes part of this problem more tractable? The key here is to break off a tractable bit of the medium sized problem. For instance, often a medium sized problem is larger than it strictly needs to be. Maybe customers are asking for better use of Key Management Systems (KMS), and you’ve got a medium sized design to use the three major players in all six of the places your product needs keys, plus migration from current state. What if you only enable use of a single KMS vendor in the most frequently touched key management task and ignored migration for now?
3. What if you went radical? Hire an outside team, refocus an internal team onto this right now, treat it like a big rock and just get it done? What’s the cost-benefit pencil out to?

Do

After that evaluation, you may have some tasks that are immediately feasible: allocating parts of the problem for development now, finding a contractor, assigning an intern to try out that new technology. Alternatively, you might just have a single task: document that you’re deciding not to act on this problem right now because your evaluated nothing/increment/radical options make doing nothing look optimal.

Defer

Whether you selected Nothing or Incremental, the final step is to defer (assuming a Radical approach ends with the medium sized problem going away now). The key to a good deferral is to schedule returning to it: otherwise, it’s a forgotten surprise to trip over later. I like to set up calendar time, at least for myself and possibly for other interested parties. I don’t like to assume that it’ll be remembered and reviewed in the usual sprint-planning ceremonies, unless there’s an active ticket bankruptcy scheme in place to remind people of the ideas hitting their use-by dates. So I might invite relevant engineering managers and product managers for instance, to a short call in three months after this thing was supposed to have been resolved. When that time rolls around and I see the meeting in my preparation for the week… if the problem was really resolved I can delete the meeting and everyone is happy to get time recovered.