We’ve lived most of our lives under pressure to make deadlines: a senior year thesis, a wedding or party to plan, a half marathon you signed up for next spring. Product managers are under the same duress, if not more. If you’ve ever managed a product, then you’ve probably managed a roadmap (or at least contributed to one). A product roadmap is the source of truth behind your organization’s product strategy and – in most cases – lists future capabilities with release dates. On the surface, it puts a team on the hook to release something by a certain date.
Getting the product to a point of release readiness requires major preparation, better known as a “go to market” plan. The spectrum of PM responsibilities – at least as far as this author is concerned – covers four major areas regarding a product’s lifecycle: Build, Market, Sell, Support (feedback gathering, ideation and design are included in the Build component). Product folks are responsible for preparing the various teams who are going to build, market, sell and support the product. That work should happen weeks – if not months – before the planned release date.
For these reasons – a published deadline and field readiness – the Product Manager is on the hook for providing and making a release date. But what happens when we miss the date? Well, it usually means the product isn’t ready for its intended use. It sucks.
Our team missed a product release date recently. Test results came back negative and we had to regroup and rebuild a component of our product we hadn’t planned to. A member of our engineering team summarized the situation: “This sucks.” I replied, “Yes, but this is ultimately a good thing. It will be better for our customers.” It was my honest assessment of the situation, not a cheerleading effort. We’ll learn from this experience, too.
Consider the alternative: Had the team been measured by shipping products (fortunately we’re not), we’d be tempted to remove the functionality in error, or possibly build a cheap workaround. In the same vein, what if your senior thesis had required ten more hours of research? What happens when the hired entertainment for your kid’s birthday party cancels? Perhaps you needed a few extra weeks to heal that nagging running injury before the big race? The product suffers.
So, how can teams avoid falling into the “release date trap”?
Organizations that measure product teams by their ability to hit release dates are incentivizing the wrong behavior. Instead of promoting product efficacy and customer happiness, we’re rewarding project management and totally disregarding customer happiness. On top of that, serious investments across sales and marketing were put toward a lackluster version of what they’re promoting to prospective customers.
So how can teams fix this potential pitfall? First and foremost, product manager performance should be measured by customer success instead of ability to release code by a certain date. This requires some additional thinking. After all, “customer success” needs to be defined. Is it usage? Is it revenue? Is it positive qualitative feedback?
Next, stop publishing or circulating a product roadmap. This isn’t to say to stop authoring the document as a team, but the document should be a living, breathing entity that is used in small groups as a reflection of how the product vision gets realized. In short, quit emailing a formal roadmap to Sales. Target dates are fine to communicate as long as their labeled as target dates. In addition, define target dates on a quarterly basis (at most). This builds in padding for any final touches. After all, “close is easy, done is hard.”
Third, only communicate actual upcoming release dates when the product has been built, fully-tested and – ideally – beta tested by a few customers. Yes, this may push the date out, but again, will pay dividends in the long term.
One dissenting opinion to this approach may be that a roadmap “motivates” the team to make deadlines that are critical to the business; it promotes accountability and commitment. If motivation, commitment and accountability are legitimate concerns where you work, you probably have greater organizational challenges than this article will solve. If inspired, teams will want to build great stuff.
As for our predicament, our team will fix the code and deliver the product we had promised to build. It may take a little bit longer but ultimately our customers will be happier. We’re patient, committed and focused on building the right product.
Close is easy. Done is hard. Done right is required.