Product Mgmt Rule #40 from the best-selling book, 42 Rules of Product Management, was written by Christine Crandell, Senior Vice President of Global Marketing, Accept Software
By helping, you tap into a vast pool of knowledge that would not otherwise be available; a fully transparent development process brings a number of important advantages.
Product creation and enhancement has evolved into a high-speed, market-driven undertaking.
Product makers are becoming leaner and more agile in their approaches to product development as well as in other facets of their business. And during the past few years, their pace of innovation has accelerated into a steady drumbeat of incremental innovations and refinements involving multiple iterations and numerous stakeholders.
Keeping on top of the constant stream of ideas—weighing them, balancing them, prioritizing them, and eventually integrating them—is a task that no individual or product management team can do alone.
Indeed, a product manager’s greatest fear today is overlooking, and as a result missing, a requirement that provides a key competitive advantage.
Misunderstandings, conflicts, and lost opportunities occur routinely because, without a comprehensive view of the process, members on the same team can end up working at cross-purposes, to the frustration of everyone in the organization—especially its C-level executives. It is a problem exacerbated by changing market conditions including shorter product cycles, higher customer expectations, and more intense competition.
Linking together stakeholders so that everyone has access to the same information at the same time is the essence of transparency.
Creating the opportunity for that to happen involves building a central repository for ideas, suggestions, requirements, and the comments associated with them—a single source of truth that everyone in the process can see. It involves providing stakeholders, both within and outside the organization, access to as much of that information as possible and the ability to collaborate on that information across every life cycle phase of the company’s product line.
Naturally, people who are asked for their input insist that they want what they want. But whenever the basis for a requirements decision is made transparent to everyone who has a stake in the outcome, people tend to accept the result—even if it’s not the one they had hoped for.
Where they can see for themselves and understand the reasons supporting a decision, the potential for negative reactions is greatly diminished.
By helping you tap into a vast pool of knowledge that would not otherwise be available, a fully transparent development process brings a number of important advantages to the task of defining the right product for the right market at the right time. But it also requires accepting a greater degree of flexibility—including greater latitude in setting timetables—and the recognition that some of what you attempt may not pan out.
Even then, however, a transparent process gives you the opportunity to fail early rather than late. It’s faster, better, and a whole lot cheaper to get feedback early and then change course.
For the producer of any product, it is far better to discover early on that the direction in which they’re going is not the right one than it is to go through a full development cycle only to find out in the marketplace that they were wrong.
Transparency offers a gut check, a feedback loop, a backup for the product manager’s instincts, which can become overwhelmed by the surge of requirements that an active community of stakeholders is capable of generating. That enables you faster time to market with less rework, and makes you better able to hit the target on the first pass as a result of the extensive upfront input and validation. Cost of development, as a result, is lower and the return on development investment increases dramatically.
Competitive advantages also flow from being faster to market with the right products. And your customers, in turn, claim greater satisfaction with the products they receive.
Product Management Rule #40 from the best-selling book, 42 Rules of Product Management