How many times have you heard a seasoned product manager describe their product failures as a learning experience? In job and client interviews, in podcast and press interviews, and over drinks at conferences, I told the story of an early product failure of my making. The specific product and the failure itself are less important than the larger lesson I took from the experience, albeit many years later (and if you want to know the details, reach out to me at the contact link at the end of this post). Here is what I eventually came to understand: big product failures are not okay and not “glory day” stories to be shared. Big product failures follow from a flawed development process focused on major product launches, months or even years in the making. Small failures are okay and even good and necessary.
My perspective on new product development is based on constant interaction with customers on an iterative basis, with the goal of introducing and testing new product solutions with those same customers. This is an iterative new product development process based on bringing the minimal, salable product to market with the understanding enhancements are coming. When an organization commits to iterative product releases following the validation of a minimally viable product (MVP), and after releasing for sale a product market fit PMF), (You can find definitions in Part 6 of this series for: Product Market Fit and Minimum Viable Product), it has committed to cementing into its organisational structure and strategy a new product development practice that will not yield big failures.
Iterative product releases in the context of new products for learning and research are not random. The customer discovery process will reveal features and requirements of varying importance and value to customers. The first launch is built to satisfy early adopters and subsequent iterations will widen the customer base beyond early adopters. Iterations will also be undertaken to address different market opportunities.
Possible Product Features and Requirements
Engagement with customers and users of the products your team launches will yield an endless supply of possibilities for features, tools, solutions, and improvements to the product. I never reject any item that my product team feels worthy of discussion and consideration for testing and/or a future release. But I am relentless in my focus on prioritizing release of those new features, enhancements or fixes that are most likely to move the needle in terms of new sales, higher usage and/or improved customer sentiment scores. There are many sources of information that will lead to the selection of the biggest needle movers: number of customer requests, number of customer complaints, number of inquiries from the sales organization, competitor product releases, etc. And, of course, product feature testing, such as releasing a proposed feature to a subset of customers to produce an A/B test can be used to prioritize a next release. Regardless of how the list of possibilities is generated, tracking and recording is critical, especially in anticipation of the launch of the MVP and the PMF. I recommend using some version of the following chart to maintain a record. And, of course, there are excellent tools built for product managers that do just this. Check out www.monday.com for a great example of helpful roadmap and iteration tracking tools.
Feature | Date Entered | For MVP/PMF | Critical Post-Launch | Parking Lot | Notes |
---|---|---|---|---|---|
“Rate This Video” | May 2018 | X | Impact measure loved by dev partners | ||
“On Screen Annotation” | Dec 2018 | X | Much verbal support but A/B tests, so far, have yielded no usage engagement |
Moving Beyond Early Adopters
A successful product launch is achieved when the most basic version of the product can be brought to market for paying customers. These early adopters will be satisfied with the launch but will expect an improving experience and soon. This is the “critical post launch” category of feature releases that cement the early adopters as customers and advocates with the wider customer community. As you broaden beyond the early launch and subsequent releases, you will engage with customers that are further and further out on the new technology or new product adoption curve. These customers will be less forgiving of technical hurdles or feature deficits than the early adopters. What is “nice to have” for an early adopter will be a “must have” for this broader group of customers. For example, early adopters might purchase a new subscription video product without searchable transcripts, but the wider customer base will not. The product team must be very clear what these “must have” features are and use the validated product launch with the early adopters as a platform to justify the investment in bringing critical post-launch features to the market.
Moving Into New Markets
A special case in new product development for learning and research solutions is moving out of the core market for which the product was initially conceived. For example, a product built to serve the higher education library market may well have potential in the K-12 or public library market. Or a product built to serve the North American curriculum and learning market might have potential in the UKI or Asia Pacific region. I pose this as an iteration issue because, very often, I have seen product teams struggle with balancing a release strategy designed to more deeply penetrate a core market when challenged to consider an adjacent market. This is an issue that should be solved by assessing the market opportunity, which is a function of the size of the adjacent market and the product feature change, addition, or enhancement requirements. If the product team knows the customers in the adjacent market and knows what is required for an early adopter launch, then the calculus is simply where best to iterate for the desired mix of new sales and increased usage against the investment needed.
No Big Product Failures
This concludes my eight part series on new product development for the research and learning market with a specific focus on serving the higher education library. Returning to where this article started, there is no reason to have major product failures on your resume and there is no reason to wear big product failures as a badge of honor because you “learned so much.” Small failures, product feature tests gone awry, bungled feature releases and missed delivery dates are all okay and to be expected. Share these stories with me and I will tell you all about my one, big, embarrassing product failure!
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:
Read more about: New Product Development Process
Photo by New OldStock
Thank you for sharing David. I’m looking forward to reading 1-7. I’m more than familiar with the badge of honor stories you are referencing. I have my own and they are terrible, unnecessary learning experiences. There are so many KPIs along the journey of developing a PMF and MVP that failure of that magnitude can and should be avoided and the learning should occur within the journey. When the indicators reveal more time and budget, they can easily become ignored or dismissed. To me this is why so much due diligence must occur and be challenged at the proposal stage.
Indeed! Check out Part 4, Components of the Business Case: https://parkerthepublisher.com/developing-content-based-products-for-learning-and-research-part-4-the-components-of-a-business-case/