Each year publishers spend countless hours crafting lengthy Requests for Proposals (RFPs) that exhaustively detail their ideal online publishing platform. There is a sense that before a platform migration can occur every aspect of the functions, features, and capabilities must be identified and explicitly defined. Yet in other market segments the approach to revising business and technology strategies has shifted to make use of evaluative tools that enable A/B Testing, measurement of usage impact, and iterative revisions. Why shouldn’t publishers also benefit from these mechanisms that provide ample opportunity for sanity checking their assumptions (technology and otherwise)? And just as importantly, why wouldn’t a publisher want to turn their users into invested stakeholders that contribute to strategy…after all the users are the ones that need to be surprised and delighted?
One very specific way to think about this user-driven approach to development and deployment is in the context of the “Minimum Viable Product” (MVP) borrowed from The Lean Product Playbook. The flexibility that the MVP approach provides publishers with is invaluable. MVP allows fleshing out of your various roadmaps along the way rather than many months or years in advance which also allows for discarding of incorrect assumptions and rapid responses to sometimes surprising user feedback. In the context of platform development, this means that we identify the minimum set of features and/or functionality that will constitute the platform or solve a problem and we deliver that to publishers and their users as quickly as possible. We then pay close attention to usage data and direct feedback, and iterate quickly to provide an optimal solution.
Publishers are increasingly sensitive to the necessity of looking outside of the industry for trends that are shaping the global marketplace, not just the publishing segment. And this brings to mind a talk given by John T. Chambers, Executive Chairman of the Board of Cisco Systems, at CES 2015 this past January in which he said, “This is not a technology discussion…Even the most powerful company in the world knows they have to move dramatically or risk getting left behind.”
We’ve all come to grips with the fact that publishers are no longer just content providers, but have become technologists, content consultants, and publishing service providers. This multidimensional role requires that decisions be driven not by perception of market need, but by supporting data that validates stated market needs. For this reason, users need to be integrated as a core and active part of business planning…now. And this brings us back to the concept of building a MVP which creates the framework for including users in building new platforms, sales and marketing initiatives, educational programs, editorial products, and much more.
Today, we find that publishers still, quite understandably, are focused on partnering with vendors to develop products with a complete feature set. Although it may not be possible to have a world where publishers and vendors can agree to start on a project(s) without a fixed budget or sense of the full feature set, there are some things that we can do to help create a more MVP-like collaboration, specifically:
- Get early versions of the product or enhancement into the hands of users as early as possible. When developing a new product consider forming an advisory group and bringing the group along throughout the course of the project. Present the earliest designs and proposed feature sets when feedback can still be taken into consideration and can have a real impact. Show working versions when they are available and include users in testing throughout. Getting direct user feedback important and you will build a group that is invested in the success and can help evangelize the platform (or other product/initiative) once it goes live.
- Ensure there is a way to quantify use of each feature. The best way to have rational discussions about the usefulness of a feature is to have direct external feedback. This can come in the form of either qualitative feedback or quantitative feedback. Do not forget to continue monitoring usage post-launch. If a feature is not being used, try iterating on how it is presented. And in the end, be prepared to strip away anything that isn’t working.
- Concentrate on the ‘what’ not the ‘how’ of a feature. When discussing features with technical folks spend focus on explaining the goals that need to be achieved. Place less emphasis on possible implementations. If a specific mechanism is suggested, it’s easy to lose sight of the “what” when you focus on the “how”. So it’s critical to makes sure someone is in charge of the “what” throughout the process.
Clearly there are some constraints when working with vendor partners, but if you keep these ideas in mind, you will find that you are able to be more nimble and can better focus your efforts.
For more on the ideas behind lean development and producing MVPs see The Lean Product Playbook.