Simple Product Management Tricks

I’m a fairly poor product manager. It’s not a discipline I’ve practiced much, so I haven’t developed any of the skills I’d need to be good at it. Constitutionally, I’m too easily distracted by the “ooh shiny” to keep a solid focus on the most important parts of a product. I’ve often been lucky enough to partner with a great PM – but sometimes that’s not an option.

Here are a few of the simple moves I’ve learned to use when I need to wear a product hat. This is far from expert advice, just a few tricks I’ve picked up that help me be not completely useless as a product manager.

Perform an effort/impact analysis

This is a technique for long-term planning; I use this when I need to help a team decide what to focus on from a backlog or set of ideas.

I learned this from Craig Kerstiens when I worked with him at Heroku. It’s a technique he originally started using with the Heroku Postgres team. You lay out potential work on a grid that maps difficulty against impact:

When I do this, it’s very fast and loose: we don’t worry too much about precise definitions of “difficulty” or “impact”; we just quickly throw things up on the matrix.

What’s remarkable is that often that’s all it takes for a plan to emerge. Items in that upper-left area – high impact, low effort – are obvious wins; items in the bottom right – low impact, high effort – are obvious “no’s”. Then you pick a few items from the middle, as you have appetite for more work, and there’s a plan.

It’s amazing how effective this technique is in getting a team to agree on a set of work in a short amount of time. See Craig’s post about the technique for details, and give it a try some time. You won’t regret it.

Timebox hard-to-estimate work

A common question that came up after I wrote my series on estimation was how to handle work that has huge unknowns. For example, think about migrating a legacy codebase: anyone who’s worked on a project like this knows that unknowns dominate the timeline. It can be nearly impossible to know upfront exactly what tasks will be required.

In cases like this, my go-to technique is timeboxing: picking an arbitrary length of time – a week or two, usually – and just seeing how far we get. At the end of a timebox, we’ll have more knowledge about the work. We can review our progress, and make better-informed decisions about how to proceed.

Timeboxing is powerful because it approaches estimation from a different direction. Instead of “how long will X take?”, timeboxing asks questions like, “what can we do in two weeks?”

Timeboxing is also very useful for projects that clearly can’t be completed in a reasonable about of time. For example, think about a team with a massive backlog of bug reports. It might be untenable to spend the time required to drive the queue to zero, but spending one day a week driving the queue down might be fine.

Timeboxes are a great way of making progress despite mountains of work or significant unknowns.

Write playbooks before automation

Finally, my approach to process automation. Most software developers know the temptation to automate: when we see some time-consuming manual process, it’s extremely tempting to try to convert it into code.

Unfortunately, the reality is that automation isn’t always the slam-dunk we think it will be:

Here’s where a lot of folks get stuck: we know that writing some code to automate a process isn’t necessarily as easy as we’d like it to be; but we also know that the process is complex, error-prone, messy, or otherwise not great to leave as a manual process.

Playbooks are the middle ground I reach for in these circumstances. When I see a process like this, instead of either doing nothing or just diving in and writing some code, I’ll first write a playbook. A playbook is nothing more than a set of instructions for performing the task – a “recipe” if you will. The key is to be as specific as possible. If this is some sort of task that involves code, you can even include bits of code or shell commands that someone following the playbook could copy and paste.

This gets a few steps closer to the goals of automation – consistency, repeatability, reliability – at a fraction of the effort. And, if you later decide that automation is worth the effort, the playbook serves as a detailed specification for your code.

Hope this helps. If you give them a try, or if you have other simple tricks you use, send me an email - I’d love to hear about it.