Release dates are driven by two factors: Internal and External. External examples would be a tradeshow – you need to release by August 25th because the tradeshow starts on the 30th. Internal factors also apply – Development will usually come back to you and say “There’s no way we can meet August 25th with the current feature set. You can either reduce it or push out the date. Or cut QA, beta, and documentation [side note: not smart].” As a Product Manager, you are the CEO of your product, meaning you have to bring balance to these competing forces.
As you get closer to your release date, your accuracy in predicting that date should improve. Should. This first graph depicts what we’d like to see in our schedules:
When you first start your project, call it 12 months out, you will have a target date for release. As you get Development feedback and weigh features versus resources, your project will change. You have three choices: change your date to meet your feature/resource goal (cost in time to market), change your features or resources to meet your date (cost in product quality), or add resources to meet your date (cost in dollars). You should have checkpoints built into your schedule (listed 1-8 above) to make these decisions. These tradeoffs can lead to a graph that looks more like this…
Look familiar? Here’s a typical rollercoaster scenario:
- “Hmmm, let’s set a date based on our Spring tradeshow and see how much Development pushes back. It’s almost a year out, we should be able to hit that.”
- “Yeah! Development feels good, Marketing and Sales are good, we’re rocking!”
- “Holy ****, our lead developer just quit. We’re screwed, no way are we hitting our date.”
- “Hey looks like the other developers are picking up the slack, they say they ‘feel good’ about making it, what a relief!”
- “F***. They just told me that the major feature has a huge bug that the old developer left and they don’t think they can fix in time. What are we going to launch at the show?”
- “Yes! They fixed it! Features are locked, on to QA and Beta!”
- “Ughhhhhhh, we found a show stopper bug.”
- “Finally ready for release. I’m going to go drown in a beer.”
In that scenario, by the time you get to #8, where do you think you are in regards to the date you set at #1? The real killer to your date is The Unknown. Known risks you can manage for, plan around, and adjust against.
There are four categories of things you know. Donald Rumsfeld got a lot of crap from the media for this a few years ago but he is actually right. Starting at the top left, there are Unknown Knows (UK’s). These are things you don’t know that you know. For me an Unknown Known is geometry – I think I know it but I don’t know how much I actually retain from high school, and I won’t until I put it into practice.
Known Knowns (KK’s) are things you know that you know. I know that it takes me an average of X days to write a good MRD, and I can communicate that to my Executive team when they ask how long it takes. You want as many known knowns as you can get.
Known Unknowns (KU’s) are things you know that you don’t know. I know I don’t know how long it will take Development to build a certain feature (hopefully that’s a KK to them), so I depend on them to tell me.
Last are Unknown Unknowns (UU’s). Things you don’t know that you don’t know. These are killers, like a developer who doesn’t think through a feature and realizes halfway that they have no idea how to build the thing (with good development leadership that should never happen, but…), or it could be any other monkey wrench that gets thrown into your project. How do you account for that bucket (I’m going to outline how I do it, but I’d like to hear from you as well)?
The way that I try to conquer this problem is by proxy. I recognize and accept that I can’t manage all the KU’s, let alone the UU’s, plus the delays that can sink your date don’t just come from Development, you can have hiccups in Operations/Manufacturing, Marketing, Sales, or anywhere in your chain. So I outsource that job to my peers in each group.
We have a product tracker, which lists all the current products in development. I show the overall progress of the product along three tracks: Development, Operations, and Marketing. I’ve given the VP’s of each of these departments individual tracking sheets and asked them to create all the milestones that they need to cross for any given project. For example, Operations has to receive Gerber files before they can work with Manufacturing to product a BOM. As milestones are crossed, I have them fill in the date that the milestone was created. If there are 10 milestones in their track, and 3 are completed, they are 30% of the way there. We know roughly how long it takes to get through each milestone, so we compare that to our external date to see if we’re on a realistic path.
It works more than it doesn’t for now, although we are constantly evolving. The downside is that this method only shows milestones crossed, not work effort. Each group has complained to me several times that they feel that their work isn’t accurately represented because they’re working really hard but haven’t checked off the milestone yet. I resist that compliant because we could all work really hard from now until whenever, but if don’t cross any milestones, we’re just spinning our tires.
If you’re in an organization that has dedicated project management, then you probably have someone thinking about this problem all the time and applying much more sophisticated analysis. If you don’t have it, you are probably being asked to perform some level of forecasting for your product. Beware of outsourcing this to Development because they won’t consider the time it takes for all the other things you need to launch a product, like sales training, marketing collateral creation, etc. The date that becomes embedded in everyone’s mind will be the date that they think they’ll be done coding.
I’m curious to hear your thoughts on how you deal with this problem, please comment below.