Given the importance of technology offerings for many organizations, the idea of a product roadmap is seen as an absolutely essential component of their growth strategy. It’s seen as the most effective and logical way to understand where their technology is right now, and where it will be at various stages in the future. For companies like these, a clear delineation of milestones and deadlines provides them with a view into the future and, ideally, some control over where that road is headed.
For many of these companies, growth hinges on bringing in additional product revenue every month. Their sellers want to know how they’ll be able to generate pipeline and attract new clients, and sexy new product features are a great way to achieve that. Meanwhile, the marketing team wants to put together effective advertising and PR campaigns that sync with the release of those new features. And operations managers want to be ready with the resources needed to support the launch and efficiency of those features when they’re ready. Even external clients often ask for a product roadmap, as they want to ensure that the vendor is continuing to innovate to stay ahead of market trends.
Given all this, product leadership is often inundated from both internal and external stakeholders with requests for product roadmaps. However, when it comes to providing them with an understanding of your product strategy and direction, a roadmap is rarely the best solution.
Learn how DoiT’s intelligent software and unrivalled cloud expertise can save you time and money. Sign up for a free trial of the product.
Potential pitfalls
There’s an inherent problem with roadmaps. Business needs and circumstances are constantly changing, so no roadmap will ever be 100% accurate. The hallmark of a successful SaaS strategy is adaptability and a nimble, agile approach that allows you to pivot quickly in reaction to changes in the market landscape.
When you design a time-driven schedule that commits to delivering Feature X by Date Y, you inadvertently create a no-win situation. When things change, if you change your original plan, you risk losing credibility and the confidence of your customers and sellers.
On the other hand, if you firmly adhere to a rigid schedule of deliverables, you sacrifice the flexibility that’s necessary to adjust to new market conditions or customer needs. Pivoting from a plan takes time and money, slowing production and angering customers and partners. Delays stifle innovation and derail the creative process, frustrating developers. Under the pressure of fixed, unrealistic timelines, many businesses end up making poor decisions that dissatisfy all concerned.
A better way
Rather than spelling out specific milestones and deadlines, consider a more fluid approach. If someone asks where you’re taking a product, consider a Now-Next-Later approach that specifically avoids a calendar-based timeline. Instead, tell them what areas you’re currently investing in, what you’ll be doing next. Great discussions will inevitably follow.
As an R&D organization at DoiT, we focus on the speed and frequency of delivery, breaking big projects down into bite-sized elements we can release more frequently. Continuous delivery makes much more sense than a predetermined schedule. We don’t assure stakeholders that we’ll deliver something by a certain date; we promise to provide enhancements as soon as they’re available. When you roll out a product or feature in frequent iterations over time, customers can enjoy the benefits of the various elements much sooner than if you delayed everything till the whole package was fully completed. In fact, we’ve found that customers often realize that what they truly need is different to what they say they want. Delivering continuously reveals that Eureka Moment much sooner.
There will be occasions when clients request a roadmap because they’re hoping for a solution to a problem they’re experiencing. In that case, reframe the discussion to focus on the issue and not the timeline. Explore their specific problem and determine how to resolve it. Similarly, if customers anticipate an emerging need, figure out what features and capabilities they want. Build a robust, transparent Feature Request process and be sure to provide concrete feedback showing you hear their concerns and are investing appropriately, even if that means you won’t work on their request. Any time a customer offers product feedback, listen up! You will almost always get added context that will inform future development, and might even hear something that deserves immediate resources.
The advantage of fast, frequent updates
Once you understand your customers’ current and future needs, you can explain your product strategy – where you’re investing to meet today’s needs and solve today’s problems, and where you expect to invest next. That’s much more informative than a four-quarter timeline built on assumptions made today and possibly irrelevant tomorrow.
This strategy makes sense considering the basic concept of SaaS, which eliminates the purchasing of packaged or downloadable software that’s more or less frozen in time. A subscription allows customers to benefit from technology that’s always evolving and improving. Emphasizing that point helps your clients realize the inefficiency of date-driven schedules that actually stifle innovation.
Product roadmaps have become something of an anachronism in today’s high-speed tech world. That doesn’t mean you won’t get requests for them. But rather than shackling yourself to an unrealistic schedule, train yourself to explain what you’re investing in now, next and later. Concentrate on developing continuous product enhancements that you release frequently, addressing real needs as they arise. Customers will see that you’re moving ahead and ushering them into the future with you.
About DoiT
DoiT helps digital native companies implement cost controls and optimizations in the cloud to drive business growth. Sign up for a free trial of the product to learn how DoiT’s intelligent software and unrivalled cloud expertise can save you time and money.
