Let’s say, for a moment, that a survey of executives was conducted focusing on their most common questions about the product development process.  What would the most common questions be?  At Venturis Partners, product and R&D organizations are our firm’s focus, so we hear a lot of those questions and right at the top of the list are the following: “Why does our product development process take so long,†and “why does it seem like we overcomplicate things?† Undoubtedly, there are myriad factors that can contribute to limited product velocity, but one common root cause is a lack of organization clarity on acceptable risk.  Fear of failed product/market fit, especially when stakeholders aren’t clear on the cost of a “miss,†can really slow down the flow of opportunities into the development machine, regardless of the philosophy you adhere too.  It also leads to over-engineering during the build phase to protect against customer complaint or confusion.
Product Management and R&D, as observed by leadership, don’t need to appear to be a black box where hooded figures enter with secret knocking sequences only to emerge with spreadsheets and slides conveniently explaining away development delays.  In fact, the greater the transparency between executive leadership and Product Management, the less likely it is that over-built or mis-positioned products will rob capacity or launch to the market.  Unnecessary market validation, solution definition, feature development or backsliding can be eliminated just by clarifying how much risk the organization wants to take.
There are a few questions to consider:
- How often does the executive team expect product managers to pitch new market opportunities ? Â Is that expectation memorialized somewhere?
- What minimum requirements for market data are required before an investment decision can be made ? Â Where are those requirements written?
- How much money is your organization comfortable spending on some number of misses in order to launch a successful product?
Bottom line: if you read those bullets and find yourself answering with either “I’m not sure,†or “it’s not written down anywhere,†then you can be guaranteed people are spending more time than desired to protect against the backlash of pitching the “wrong thing.”
Fortunately, there is hope that the fancy hooded cloaks can be thrown in the trash and that product teams’ secret clubhouses can be demolished.  Adjustments to structure, process, or people can make a significant difference, without needing to make any changes to development philosophy.  If you implement SAFE or Agile, then think of these people and process elements as scaffolding around the Agile machine.
- Point people who want to focus on market problems to opportunity exploration. Â Be clear about how well they should define the urgency and pervasiveness of the problem, as well as the target segments willingness to pay. Â What data will facilitate executive decision making? Â How quickly can iterations be delivered based on the types of solutions you deliver to market?
- Align incentives to either velocity or accuracy, but not both. Â For those exploring share growth or market transformation (as opposed to product maintenance), measure them on thoroughness and accuracy. Â For those focused on near term customer satisfaction, particularly in pure software environments, measure velocity.
Ultimately, the inputs to development don’t need to involve wizards, water diviners, or fortune tellers, although employing some of those folks would be entertaining.  Eliminating confusion surrounding opportunity definition requirements will facilitate acceleration for the entire machine.  There will be less backsliding from the build phase back to definition and less frustration over the lack of progress.  Market problem definition or development iteration (based on some acceptable misses) can be perceived as both progress and velocity.  When those statements are true, then you, the executive, can clear signals to field employees, customers, and the broader market and you won’t even need a Cryptex to do it.
If you want to learn more learn more about defining acceptable risk for new development projects or about aligning teams based on where you do, or don’t, want to accept risk, call us at (888) 503-3546.
