The InterContinental Hotel lobby in downtown San Francisco isn’t a bad place to look for tomorrow’s unicorns. Go there on a weekday and you’ll see entrepreneurs editing pitch decks at practically every table. The atmosphere of optimism and urgency is pure startup.
The lobby shop sells the usual necessities, plus an unusually broad selection of computer adapters and USB connectors. Even more unusual is the fact that you can buy a nesting doll of Josef Stalin there. Why? God knows. Take your pick of his human right atrocities; they’re all pretty darn awful.
I found Stalin’s five-year plans to industrialize the country particularly callous. The plans worked like this: (1) Set insane production targets; (2) Liquidate dissenters, (3) Embellish results. (Then repeat Step 2 ad inifinitum.) Trying to meet those targets brought out the worst in the regime.
In fairness, pressure to meet ambitious goals can bring out the worst in many people. Unfortunately, leaders are prone to setting unrealistic, even impossible goals at least every now and then. When the thing you want and when you want that thing by are detached from what it takes to achieve it, all it takes is commitment to an investor, the board, a partner, or a customer to lock the organization into a death march.
I’ve been on both sides of this: I’ve been given unrealistic and inflexible timelines, and I’ll admit I’ve given them too. Here’s what I can say about navigating both experiences.
When You’ve Been Dealt Impossible Timelines
First, if you’re staring down the barrel of a delivery timeline that looks highly unrealistic, it’s probably not because your bosses are mean or dumb. The management team has to answer to investors and shareholders on a quarterly basis, while the agile planning process is generally agnostic to calendar dates. Some amount of tension is inevitable as a result.
Your role as a product manager is to be sensitive to the business and technical concerns. You’re the person with one foot in each world, after all. Here are some ways to do that:
Set Priorities – Every product has its need-to-have and nice-to-have features. Put on your business hat and be stingy with that “need” designation. If a feature doesn’t substantially improve the odds of selling the product or how much you can charge for it, it’s a nice-to-have. This is when you really need to focus on the buyer first for B2B products, by the way.
Spell Out the Drawbacks – One of the common mistakes that product managers make is assuming their bosses know everything they’re doing. Remember, you spend far more time thinking about the product at a low-level than your managers probably do. It’s your responsibility to remind them of technical debt, dependencies, and other issues fling under their collective radar. They may have missed something that could change their whole calculus.
Force Trade-offs – Sometimes, you need to be the one who asks the boss, “What are we not going to do?” Look across all of the other initiatives going or planned to begin and ask what’s no longer as critical. Be prepared for them to say “Nothing,” and if they do, that’s when you get into the weeds with them about resource availability.
Forward-Sell – You may be able to relieve some of the pressure from your executive team by de-coupling the release date from sales and marketing kick-off. This makes sense especially for products with long sales cycles. If you can be in-market and forward-selling fast, you can usually buy yourself a little breathing room.
If You’re the One in Charge…
The management team is responsible for assembling a capable team, providing a compelling vision, and allowing the team to do great work. Do all that, and you can cross “motivate the team” off your to-do list, because motivation will take care of itself.
Objectives which are aggressive to the point where the team has little chance of actually achieving them takes a major toll on their motivation. It’s obvoius why: busting your ass when failure (as the boss defines it) is all but certain is depressing. It’s depressing when the goal is communicated to you, depressing while you’re working towards it, and depressing when you miss it.
A development team only has so much rocket fuel you can call upon to hit major milestones. If you use too much too quickly, the team burns out and nobody wins. Sometimes you really do need to take that risk, but at least do so wisely by thinking about the following:
Acknowledge Your Screw-ups – If the project timeline requires serious overtime, that’s your fault. You didn’t anticipate something, missed an opportunity earlier, spent resources on the wrong things…whatever. Getting the team to haul ass might be the best decision for the business, but you still screwed up somewhere. Own it, and your team will at least respect that.
Be Sure It’s Worth It – You have an opportunity to launch at TechCrunch Disrupt? Okay, let’s talk. You made an uninformed commitment to the board or a customer? Your team won’t be so thrilled to work weekends for that.
Don’t Ignore the Costs – It’s easy to visualize the benefits of getting to market faster, but don’t forget about the costs when you burn up that rocket fuel. Aside from the risk of people burnout, speeding up the timeline frequently introduces quality risks. You may spend as much or more time addressing bugs and tech debt later and slow you down at even worse time.
Consider the Impact on Culture – When you impose a top-down deadline on a team used to planning things in a bottom-up, agile process, you undermine the integrity of that process. You’re signaling that their expertise and input isn’t relevant. Managers often bemoan their teams padding development estimates; but they often do it to protect themselves against arbitrary top-down decision making.
Make It a Dialogue – Talk to the team leads about the timelines and listen to what they say about how they can make it happen. In 99% of cases, being unyielding isn’t a sign of strength – it makes it seem like you’re sticking your head in the sand and are trying to avoid the details.
Ultimately, if you can’t trust your team to make good faith estimates and do high quality work, the problem is either the team or you. Either way, it’s your fault.