08
May 15

5 Tips For When Your Release Is Running Late

The other day I got a question on a PM chat system:

“Wanted to tap into the experts here, although might sound like a stupid question. What are some of the PM strategies to apply when you know your product release is running behind schedule?”

As software product creators, most of what we do is surrounded by uncertainty. How do we keep our releases running on time despite all that uncertainty? How do you get to a point where you’re never behind schedule even though you are inventing the future?

Vintage Train

Vintage Train (photo by Tim Abbott, CC 2.0 license)

After ensuring the questioner that this never happens to me (LOL), I came up with a short list of ideas that I hope will be helpful. There are, realistically, a few things you can do.

  1. Make sure you’re always working on the most important things (aka agile). That means that at least the stuff you are getting done is more important than the stuff you aren’t getting done. ([tweetthis hidden_hashtags=”#prodmgmt” remove_twitter_handles=”true”]Agile means “the features you aren’t delivering are less important than the features you are delivering”[/tweetthis])
  2. Recognize that software dev/product dev is inherently highly uncertain – it’s invention, and at best your estimates are predicting an uncertain future. As Yogi Berra famously said, “Prediction is hard, especially about the future.”
  3. Use a “release train” method – the release always leaves the station, and anything that’s done, or “done done”, goes on the train. Things that aren’t done wait for the next train. This means that releases always go out, and features go out as they are finished. That’s hard if you have big monolithic features that take a huge amount of time and effort to complete. Try to avoid having those, or at least try to avoid delivering those as monolithic features.
  4. Sometimes working 24 hours a day for a short period can work to recover a schedule. But it has to be a short period, with a very focused – and important – goal. You can’t do it often, and you definitely need to show a lot of appreciation for the efforts and sacrifices that people are making. And they have to see that their efforts also resulted in a good outcome. Otherwise it definitely won’t work a second time.
  5. Obviously, you have to be really good at cutting scope. An especially important PM skill is to be able to work with the dev team to surface and eliminate assumptions that cause development costs to go up. ([tweetthis]Key #prodmgmt skill: be able to surface and kill assumptions that cause dev costs to go up[/tweetthis]) For example, it’s often much cheaper to stub off unlikely corner cases than to do costly additional coding to support them.

Those were the thoughts I had – what do you do when your release is running late?


10
Mar 15

The Most Important Problem

What is the most important problem that our customers, or the people we want to sell to, are having – that we can solve?

This is the fundamental question we PMs have to keep asking ourselves (and our customers/market).

Ideally what we’d do is prioritize solving that problem. And then, if we have capacity left over, we ask, “what’s the second most important problem that our customers, or the people we want to sell to, are having – that we can solve?”

And then we prioritize solving that second problem. We keep doing this until we run out of resources.

Then we do it all again.

There are of course lots more details – how much of that #1 problem do we solve? Do we get it to MVP state? To V1.0 state? To highly polished state? The answer to this question depends on a few things:

  • How we will use this solution to sell
  • How we will use this solution to differentiate
  • How hard it is to get from MVP to the next level, or the one after that
  • Whether the MVP is actually “marketable”
  • If a competitor has set a bar on how much functionality is needed

It’s hard to live with this approach on a day-to-day basis, but it’s really what we should be doing.

And the roadmap is then just a list of the problems we’ll be solving over time – [tweetthis hidden_hashtags=”#prodmgmt”]”The roadmap is then just a list of the problems we’ll be solving over time”[/tweetthis] – (subject to change, of course, as the problems customers face change.)


18
Jun 14

Prioritizing Features – The Simplest Possible Example

Acme – Wile E. Coyote’s favorite supplier. (Photo by Elliott Brown, CC 2.0 licensed)

Say I have one feature in the backlog that would delight Acme Inc, and another feature that would delight Barclay Instruments. My strategy (i.e., my prioritization criteria) says that Barclay is the more important customer. If I can only deliver one feature, which one will it be? Obviously the one that Barclay wants!

Because I have a big backlog of features I could deliver, I want my prioritization scheme to help me pick the features that match my strategy the best. Tell me which features will further the strategy, and hide the ones that will not contribute.

If my boss comes to me tomorrow and says, “Oh, we lost Barclay, let’s focus on Acme,” then it’s also obvious which feature becomes more important.

But notice that the features themselves didn’t change in response to the strategy. What changed was their strategic value. The fact that Feature 1 is appealing to Acme is intrinsic to the feature. The fact that it didn’t align with the first strategy, and does align with the second strategy, is purely a function of the strategies.

Real-life strategies are more complicated than simply “Barclay Instruments is the most important customer,” so the calculation of strategic value gets harder. But the point remains – the strategy doesn’t change the feature, it just changes the value of the feature for that strategy. Another way to think of this is that the strategic value of a feature is a “point in time” value, that changes when the strategy changes.

The problem I see with many of the requirements (feature) management tools that include prioritization functions is that they munge the prioritization criteria (point-in-time data) into the feature. Essentially what they’re doing is to denormalize the data. And just as with a database, denormalizing means there is a big maintenance cost when the prioritization criteria change. When the strategy changes, the features also have to change. And this can happen a lot as in the example.

In other words, with most tools I’d have had to put in a score for how well the feature matched strategy 1 (Barclay) into both features. And then when the strategy changed, I’d have to go back into both features and change the score again.That’s a lot of work if my big backlog is more than two features!

For a better approach, check my post on prioritization schemes. Or stay tuned to this blog – I’m sure I’ll be following up. Because to enable my idea, you have to support relationships in your requirements data model, and none of the tools do that very well.


02
Oct 13

Two Good Articles on Decision-Making For Product Managers

The first is by the terrific Theresa Torres (@ttorres) on her Product Talk blog, on how to commit but not overcommit to a new idea, feature, or strategy – Don’t Overcommit to a Bad Idea:

Whether you are considering a new feature, experimenting with a new user acquisition strategy, or considering a shift in your overall strategy, tripwires can ensure that you don’t commit too soon.

The second article is by the equally terrific Jim Anderson (@drjimanderson) on his Accidental Product Manager blog on why product managers should not listen to their gut on many decisions:

One of the biggest problems that product managers run into when it comes time for them to make a decision is that they then tend to “narrow frame” the decision by considering only one option. The question that they are now trying to answer is “should I choose this one” instead of “from these options, which one should I choose?”

Both of these suggestions echo the excellent decision-making guidelines laid out by the Chip and Dan Heath in one of my favorite books of 2013, Decisive. Bottom line – you can make much better decisions if you follow the guidelines that Theresa, Jim, and the brothers Heath suggest.


07
Jun 12

How to Prioritize: Top 6 Techniques

Too much to do

As a product manager, one of the fundamental issues you will have in your life is that you will have a lot of things to do, and you won’t be able to do them all. Whether it’s the list of features and capabilities you want to implement in your product, or the customers you want to visit and get insights from, or the anthropological studies you should be doing with prospects in your market or the market you want to get into, you will not be able to do everything you want. This means you have to prioritize your activities, and what you ask from your developers (i.e., in terms of features), but you also have to be able to defend and justify your priorities to your supervisors, to the business, and to the people who are executing the work you have specified.

Priority!

Prioritization is a critical capability for product managers

In this post I outline some of the basic concepts of prioritization, which we will explore in more detail in future posts. I’m not going to cover everything there is to know about prioritization, but give a number of techniques that (typically in combination) you can use to help you make better decisions about what to do. Better, at any rate, than simply flipping a coin. Of course, nothing is guaranteed – as many a product manager has discovered before me, you can make the best decisions in the world and your product may still fail for reasons beyond your control. But if you want to have the best shot, here are some of the things you should think about.

Techniques of prioritization

I’m going to write this as though the priorities were new features for your product, but the same ideas work for other things you might need to prioritize:

  1. Trust your instinct – more on this in a future post, but remember that one of the reasons you are a product manager is that you have specific expertise about the product, or the space, or about decision-making per se. So your gut feelings are likely to be decent. On the other hand, if you’re like me, you want something more concrete to backup your decisions.
  2. Analytics – either qualitative or quantitative. The types of analytics you can use to support your decisions varies widely. For example, if you have talked to several customers about a new feature, and they’ve all said it would be highly valuable to them, and your gut says most customers would get value from it, that might be enough “analytics” to move forward. Analytics can get a lot more sophisticated, of course – people use spreadsheets comparing the revenue outcomes for different combinations of features, and tools that graphically illustrate how well a set of requirements satisfies a set of prioritization criteria based on a market model, to tools that use “option pricing” and other advanced financial techniques to give you a numeric priority value. Analytics are the best tool in your toolbox for defending and justifying your decisions.
  3. Stack ranking, and ignoring things at the bottom of the stack. Part of being a good prioritizer is not getting weighed down by the stuff you’re not going to be able to do, no matter how desirable it is. One way to help you achieve this clarity of mind is to stack rank your new features, with the most important ones – determined, perhaps using your gut instincts backed up with some analytics – and then ignore everything in that list after the first ten items. This is a fundamental technique from agile software development – once you have decided what is the most important feature to deliver, concentrate on delivering that feature and ignore anything else that’s lower in priority. Once the most important feature is delivered (or complete and ready for delivery), then you can revisit the stack-ranked list, review the ranking, make any changes necessary, and then focus again just on the top items.
  4. Doing tests with a “minimum viable product” or MVP – sometimes you have an idea of whether a feature or a tactic will be valuable, but you need validation from the market that your instinct – which we can call a hypothesis in this case – is correct. As in real science, you test a hypothesis with an experiment, which in the world of lean software development has come to be called an MVP – a minimum viable product. The phrase “minimum viable” means “the minimum amount of development needed to test the hypothesis.” Sometimes an MVP is as simple as a webpage, while sometimes it can be a complete development project in itself – it completely depends on the hypothesis you’re testing. The point is that you are not doing any more work than you have to in order to find out if your hypothesis is correct or not.
  5. What’s the worst thing that could possibly happen? The process of prioritization always has winners and losers, and one way to test whether your prioritization is correct is to do a thought experiment. For each of the candidate features, ask yourself, what is the worst thing that can possibly happen if we don’t deliver the feature? You can use the answers to this question for each feature to minimize the worst possible outcome. Of course, it’s very possible that not delivering a new feature won’t have a bad outcome, but delivering it would have an very positive outcome, so you can’t use this as your sole decision-making criterion.
  6. Make sure that your boss’s pet feature is handled. This may sound a bit cynical, but remember that you’re not just optimizing your development team’s efforts to deliver value, but you’re also optimizing your own career – your success depends on you delivering good products and on staying employed and keeping your boss happy. If your boss has a feature that he or she really wants to see in the product, then that feature has extra weight in your prioritization – you might still cut it, but you need to have an especially strong story for why that had to happen.

What prioritization techniques do you use?

That’s a few quick ideas on how to do effective prioritization of features into a release, or in general how to prioritize anything in your career (or life). Let me know in the comments if you make use of these techniques or if you have other prioritization tools you like to use.