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?
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.
- 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])
- 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.”
- 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.
- 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.
- 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?
Some projects, unfortunately, are inherently long. Any tips or thoughts on dividing them up or figuring out a way to deliver value in smaller increments. An example of this from my experience is building something like a client-facing API from the ground up. It's very difficult to limit the calls, architecture, or other features in order to narrow the scope and cut down development time without winding up with something that is incomplete.
Beau – this is definitely a challenge. I've found that almost any project/release/feature can be staged to some degree. Any staging reduces risks, so it's always worth doing, even if it potentially makes the overall project longer. (Better a small delay than a total failure, in my opinion as a professional. Customers forget a small delay, but they never forget a failure.)
[…] to do if your release is running late, and how to mitigate that in the […]
[…] might not actually be important in the long run. I illustrated the use of this rule in my article 5 tips for when your release is running late? You can push to get it out on time, even if there might be quality problems. That’s going to […]