Congratulations! The senior leadership team and the product leadership group have approved your business case and you are now ready to engage the product team, including engineering, user design and product ownership who, with your leadership, are responsible for delivering on the product concept. In your approved business case wire frames, mock-ups, product requirements, and sprint estimates were presented and approved. Now, with your product team, it is time to turn to the road map and prioritization of the schedule and the product build. Three factors will impinge upon and determine your success in delivering on your successful product launch: 1. Competing priorities, 2. Scope creep and 3. Pressure to meet a deadline.
Competing Priorities
Successful product teams are always managing a product portfolio and the ongoing and iterative process of maintaining and improving existing products. Newly approved products must find space on the road map unless you find yourself in the rare circumstance of being part of a newly formed team created specifically to launch a major new product; this is a rare event and consider yourself extremely fortunate if you are so blessed, but know that the scrutiny that comes with such good fortune will be significant. In the majority of cases, however, product managers and product teams are navigating competing priorities. There are many ways to organize and manage the product road map including, Kanban, Objectives, Features, Now-Next-Later and more. In the specific context of content-based products for learning and research delivered to libraries and learning institutions, my preference is a road map organized to address user groups: patron interface, librarian/administration interface and content provider interface. Patron interface/user experience will include the majority of the critical product requirements that will define your successful launch. That said, the librarian or higher education administration users of the product and the publishers and content providers that fuel the product will have specific product requirements from admin controls to usage dashboards that will be critical to the success of the product. Engineering teams may be divided to address each of these users’ sets of product requirements, or work intermittently across these requirements. And, often, the requirements will merge as with, for example, usage dashboards that will be adapted to satisfy the product requirements of librarians and publishers. The successful product manger will need to manage engineering resources to meet critical product launch requirements of multiple product users while managing an existing product portfolio.
Scope Creep
Offering a warning against succumbing to scope creep in managing the product road map is a bit like admonishing a friend to engage in healthy eating and exercise to stay healthy; it feels obvious and perhaps unnecessary. But, across my 20+ years in product management, I have seen far more scope creep than fidelity to a core set of features required for a successful launch. This is not to say that critical launch features cannot and should not change after a business case is approved; the purpose of a discovery partner panel of leading customers is to test and refine the releases and product requirements leading up to launch, and this often means adaptation and change. Scope creep, however, most often comes from outside the controlled environment of the product team and the discovery partners. The most common source of scope creep is influential customers and influential sales people finding a sympathetic ear with senior sales leadership. Another frequent source of scope creep is unexpected feature and product releases from competitors. Finally, from within the product team and, especially from engineering, great ideas will emerge in the creative process of building the product. A critical responsibility of the product manager, as leader of the product team, is to digest all of these possible new features and product suggestions, consider the source, and then take decisive action. Decisive action means pressure testing the proposed added feature against the business case. Does it increase the first year revenue estimate? Does it mean moving an assumed required feature for launch to a post launch enhancement? Or does it mean tabling the idea or placing it in the “nice to have” category; a place I often refer to as the road map parking lot. In the end, great product strategy, like great strategy in general, is what you DO NOT do.
Pressure to Meet a Deadline
As a general rule, I believe high performing product organizations should define optimal product launch windows in terms of months or quarters and avoid specific deadlines. For example, commit to launching a new library subscription database in the fall so that decision makers can trial and assess for at least 90 days before making a commitment at the end of the fiscal budgeting period in May/June in North America. This approach allows for considerable latitude in estimating sprint releases and assessing the success of those releases with discovery partners and lead users. However, organizations and leadership teams often ask product managers to commit to a launch date based on key events, such as annual sales meetings, investor calls, board meetings or major industry conferences and events. This is stake-holder driven roadmap management and it is often a recipe for disaster or, at minimum, a subpar product launch. There will be exceptions where the product team must commit to a specific launch date to meet a very high level commitment for the organization. High level commitments will be rare and will come with the unwavering support of those most senior people in the organization; meaning, if you are the product manager leading the product team that is making the high-level commitment to launch to a specific date, then you should be doing so with the knowledge that the CEO and her team have made your new product priority one for the entire company. In all other cases, avoid all pressure to meet deadlines over delivering to the set of features and functionalities described in your business case necessary for a successful product launch.
I started this eight part series on new product development practice by noting that new product development is hard. It is difficult work for many reasons, ranging from running an effective discovery process, to building organizational support for the new product, to defining and sticking to a set of core features that the new product development process has identified as required for a successful launch. Manage the competing engineering priorities, the risk of scope creep and the pressure to meet externally-imposed deadlines and you will have overcome the hardest bit of all in new product development.
Please subscribe to get a simple notification when new posts publish. I invite you to read the complete series here: New Product Development for Content-Based Products.
If you want to work together on your new product development strategy, contact me directly.
Published by: on
Read more about: New Product Development Process
Photo by Andrea Piacquadio from Pexels