Product Management: The Key to Success of Your Product Date:   Tuesday , July 01, 2008 Industry leaders claim 80-90 percent of the product releases are failures as they don’t meet their anticipated goals. This may or may not be true, but the reality cannot be far off. Countless release cycles are wasted on products that are either not useful or not usable and these releases are mainly ill conceived. There are many reasons for these and one of them definitely is the lack of product management. This is precisely what is addressed here. Most of the product companies do not realize the need or value for a full time resource in a product management role. Reasons commonly attributed to this are the ones of convenience, like product manager’s responsibilities are fulfilled by the existing staff that are so close to the customers that they don’t need a product manager inserted into the relationship. It is not realized that this closeness will result in developing a product that is important to a few customers, instead of what might be most important to the organization’s vision of the product. There are several symptoms that indicate the need for having a product manager. These symptoms reach deeper than the defects and bugs that one encounters, like the product takes a lot of work to fit into existing IT ecosystem, it requires hours of explanation before the customer is comfortable about it, parts of the product are common-people aversive, active user base for the product shrinks faster than the revenue, consistently missing the target of release dates, chasing opportunities that look like a fit and do not focus on a defined target, and sales requests being directed to engineering team leading to unplanned features added to the product. These things simply mean that the product needs to be rebuilt and restructured before it can be successful and be profitably sold in a broader market. This stripped-out situation can be avoided with a clearly defined Product Management role. While the need for a product manager cannot be over-stressed further, but still the role of a product manager is an ill-defined one in software development today. The Project Manager (PM) lives more lives than the proverbial cat in a software product development company. He is responsible for different things at different times, like: * Writing of specifications * Decision making related to end-user requirements * Design of products * Usability of products * Testing of products * Planning of product release timeframe * People management * Handling minutes of meetings * Responsible for everything that goes wrong, the fall guy in the product roadmap * Supporting demos and writing proposals – playing the role of a sales engineer But the fact remains that product management is one of the three pillars that any successful product company stands on, the other two being product engineering and product marketing. Of the three, there is some traction going around product management and product marketing, whereas there is not much that is happening around product engineering, which is considered a non-core function for a product company. This is a topic for a separate discussion though. What works best is having the top management committed to a strong product management group, in line with sales and not subordinate to it. An organization breaks down when sales hit a slump and the top management panics and lets sales call the shots rather than identifying the root causes of sales shortfalls. This culture is very difficult to break. Now that it is understood that product management is one of the most important roles in a product company (this you would have guessed even without reading this article), let us endeavor to look at what role does a product manager actually need to play? 1. The PM is the face of the customer and he brings them to the discussion table. All product specifications should be based on customer requirements. 2. Designing features and writing specifications that are technology agnostic. Constraints of time and resources and difficulty of implementations should not be primary concerns while designing features. The PM should not base his or her judgment on these issues, lest there will be a product that can be considered complete but will have no-takers. Features can be further classified into finalized, in-process, and ideas. Finalized are those that the product cannot ship without, and ideas are those that are good to have but not critical to the functionality and can be done away with. 3. Study the market for what it wants and what it is worth. This is best done by interacting with your marketing and business development teams, for this would influence the result of the product lifecycle the most. 4. Decision making is the key to any successful product and this is one area that other functions expect from the PM. The need for taking the decision, repercussions of the same, tracking the decision made, justifications of the decision, and close looping of these are important roles of a PM. 5. Be open to new ideas coming in, for they mostly come from casual discussions with people in varied functions and from those who don’t decide on market trends. 6. Communications across the organization, as other functions look to the PM for product roadmap and company direction. Let us also assess some of the real scenarios that face product companies and how product management will address them positively. Scenario 1: Our product is quite innovative and hence we don’t find the need to assess competition. The real problem is that probably the product does not fulfill a market need and does not even provide a competitive advantage. It is essential to identify the functionality that would address the basic market need and provide a competitive advantage. This would also mean analysis of the competition. Scenario 2: Our product is implemented with multiple customers and we do enhance features of our product but this is based on “chasing the loudest customer” approach. This effectively means that 3-4 features are added to the product on a monthly basis and these are features accepted from the loudest customer. This means a lot of customer requests are not acted upon. It is very essential to keep track of every request, and also look at which requests are repeated by multiple customers and give them the priority. Scenario 3: Is it necessary for me to make public my product roadmap? This actually means that there is no product roadmap, and no long-term development plan. Developers are focusing only on monthly plans. It is essential to understand the bottom line here; some customers definitely want to know the product roadmap. Scenario 4: Everyone goes straight to development for every issue and request, if not, they go to the President. Development really would love this attention, whether or not it benefits the organization. Sales would enjoy being able to go straight to development. The process has to be, the product manager or someone performing the role of a product manager, should be contacted for every feature request. Else, it would be difficult for all involved to be in the loop on the product status. In effect, product management is a broad, multi-disciplinary pursuit in a world where it plays the intermediary between conflicting forces in the organization like sales, customers, and development.