If you have spent any time reading any of my posts to-date, you will likely have gathered that I favor a “modern” approach to product management. This means that I agree with people like Marty Cagan and his colleagues at http://svpg.com/. If you have not read it already, I highly recommend Mr. Cagan’s book on building products customers love (available at Amazon).
More specifically, I firmly believe that in order to build great products, you need to actually put product ideas in the hands of the customer. It is then, and only then, that you can begin to become assured that your idea is a good one and you can start predicting things like revenue and growth. This model acknowledges that there is a relatively small amount of planning that is needed to get an initiative started, and that the final needed product will be discovered as it is iterated upon. It also acknowledges that further planning does not ensure that the schedule can be better defined or that the user growth or adoption rates can be more accurately predicted.
A traditional product management model focuses on the project management aspects of the product lifecycle. Some of the cornerstones of the traditional model are:
- A task list of deliverables for all parties involved from product definition through to launch
- A process heavy model for requirements gathering, documentation, and traceability
- An extensive use of market research as a guide for almost any decision making
- An assumption that all risk and unknowns can be “planned” away
There are some products and industries where bringing products to market simply requires this type of model. Large construction, public works, or aerospace and defense projects are a great example. You cannot iterate your way to a fully functional aircraft carrier. That has to be planned and at the end of the process the bolts have to align, the boat needs to float, and planes need to launch. With software products the traditional model simply does not work. It used to be a dirty little secret that 9 out of 10 software product launches failed. Now it is widely written about and most modern software companies that are product driven have adopted the modern model. This modern model is described as lean, agile, customer focused (instead of market focused), and a variety of other ways.
Most of you have probably experienced product launches that you (and your company at large) thought were the most well thought out and “planned” but proceeded to fail spectacularly. Maybe it did not fail out right, but the odds are in my favor (we know that 9 out of 10 software product launches fail) that it at least started to fail until some type of correction was made.
One of two outcomes came out of that failure. The best outcome would be a company wide recognition that all the planning in the world never will produce a “perfect” product, and a move to embrace the model that successful product companies follow. The more likely outcome is that the planning process (or the Product Manager directly) was in some way blamed and the organization agrees to attempt to learn from the experience and “continuously improve” the flawed planning process.
I am not going to cover why organizations cling to this traditional model. There are plenty of articles written by outstanding product managers such as Mr. Cagan and many others that cover how the traditional model, with precise roadmaps and quarterly closed door meetings to define those roadmaps, are doomed to failure. They also do a good job of explaining why companies (and individuals) cling to this traditional model.
Instead I am going to cover how to ensure that your organization keeps moving in the right direction.
Wherever your organization is on this spectrum of the traditional model vs. the modern model, there is always pressure to fall back to the traditional model. In some cases is it due to a simple initiative. Maybe the initiative is an easy problem to solve or there is a lot of pent up demand. Perhaps your team is uniquely capable of solving the problem. In instances like this you as a Product Manager are able to define the exact schedule and the exact adoption rate with darn near absolute certainty. Some industries have this happen more often than others. This tends to occur often in industries bound by extensive regulations. Artificial demand is created when customers are legally required to comply with regulations. Since the regulations exist, the requirements can be fairly straightforward leading to a simple product definition phase.
I find that one initiative like this often brings back nostalgia for the “good old days” where there was a clear roadmap and every initiative delivered exactly what was expected the first time. We know as Product Managers that the “good old days” failed 9 out of 10 times and that what people recall as good was the false sense of security that came from misleading roadmaps and unrealistic growth and adoption assumptions. It does not need to be an initiative internal to your organization that causes this discussion. Somebody from your organization may have seen a presentation at another company, or was speaking with somebody about their roadmap, and they saw or heard something they liked.
The grass certainly looks greener, and they assume that this other person or organization somehow figured “it” out. They of course are not asking about how often the roadmap is changed, and by how much. Nor are they asking about the impact of managing all the change is weighed into their COGS (cost of goods sold) calculation. They are just seeing the end result, which is a precise roadmap and they then think they want something similar.
So, how do you avoid slipping backwards and undoing all the progress you and your organization have made in successful product management? First, make sure that you call out those slam dunk initiatives as being that way upfront and often. Make sure that you compare it to your other initiatives that have risk in user behavior, miss-understanding of problems, and the unknowns of the competition’s strategy and how the simple initiative bypasses all of those problems.
Second, make sure that you bring up the COGS problem, and talk through with your finance team the actual cost to the company to adopt that type of model, and given the 9 out of 10 failure rate, what the expected return would be on that cost. I assume that you have already done this, so this activity might just be a refresher for everybody on it. If you have not done this, then this is worthy of your time right now. Think about all the people that are involved in a product definition in the traditional model. There are people that do all the work, there are new roles to manage those people and to manage entire processes.
Finally make sure that you are clearly documenting and promoting successful initiatives. You need to be able to point to recent initiatives where building, testing, and iterating has resulted in the expected outcomes. This will remind people that this way of bringing product to markets is widely successful, so much more so because the roadmap was more focused on the outcomes rather than on incorrect delivery dates or on incorrect requirements. When you do this well, people will have a different opinion about which side of the green grass image your company is on.