Software Product Management Basics

What Is Software Product Management?

Software product management is the process of managing software that is built and implemented as a product. It is also the business process governing a product from its inception until its delivered to market in order to generate the highest possible value to the business. It can be a combination of systems, solutions, materials, and services.

Product management provides guidance to the project and portfolio management process. For example, a "project" is a temporary endeavor such as one undertaken to create a product. The project manager focuses on delivering one specific product or release while meeting time, budget, and quality requirements.

The Product Manager

The product manager looks to the overall market success and evolution of this product together with its subsequent releases, related services, etc. Another way to look at it is that the product manager has to be more involved with the overall business and product strategy of the company than the project manager does. So, the product manager focuses on achieving strategic value for the business. To achieve this, the product manager needs to take into account the following five factors (see diagram above):

• The Customer
• The Market
• Industry Trends
• Development
• Competition

What is a Product Road map and what does it mean to a Product Manager?

Well, I like to think of a product roadmap as series of product releases that gets you to specific strategic goals or objectives. For me this helps reduce the anxiety of whether or not you are building the best product possible. Here are the steps I like to follow:

1. Create a feature play book (this maintains a feature list so that everyone knows features that are being driven by clients or by market forces in general, etc.) Just keep in mind that not all plays in a Playbook need to be used.
2. Decide on a product roadmap as a series of releases (the strategic goals will filter out some lower value features or components).
3. Create the Framework BRD. This is a requirements documents but only covering basic plumbing and features that can be delivered rapidly for the first release.
4. The key is that enough foundation must be included so that it can be built upon in following releases.
5. Therefore first release should provide the key components with a target of providing at least 80% of target value. The key of course is the release must add value and must be functional.
6. Test the release as a prototype.
7. If the release is acceptable (functional) it can be pushed out to beta or production and further enhancements can be targeted to the next release.
8. If the first release is quarterly, then we can speed up the releases to get to the point of having monthly releases (bi-monthly if everything lines up perfectly)

Product Management Team Dynamics

We must also take into account the product management team dynamics. So there are four key steps that should be followed to make sure that a team is engaged correctly and to streamline communication. They are as follows:

1. Set up a core team that consists of stakeholders such as from product, marketing, engineering, and operation to make sure all areas are represented and understand their responsibilities.
2. Follow the Product Life Cycle.
3. Review Needs and Requirements as a team. In other words, stay on the same page.
4. Make sure the Product Roadmap is dependable and consistent. If not maintained properly the Product Roadmap can become unreliable due to constant changes.

What about Customer Feature Requests? Do they always need to be implemented?

Well, since businesses are in business to make a reasonable profit then it must be followed that feature requests are accepted or denied based on their business value and their benefit to the overall business strategy.

Now if customers are requesting features that are not practical at the moment, you don't want to just ignore them, or just keep de-prioritizing them to the next release cycle especially since many requests for solutions can actually provide insights into possible problems. Here are the things I consider when dealing with requested features.

1. I try to log all the requested features I can into my "Play Book". This way should the question of certain features comes up, I have the details. I try tosee if there is a way for it to fit in. It’s the job of a product manager to think about those problems and figure out which ones will fit in with the company's long-term strategy.
2. Also a feature that may not be valuable at this time may suddenly become priority on a future release and wherever possible we would want to be able to acknowledge that feature request were reviewed and included whenever possible.
3. In the playbook basic data about the features deployment should be included. For example:

• One should describe the cost (in developer hours, lost opportunity cost, investment in obsolete technology, etc.)
• If it does not match the company vision, highlight the lack of connection to the product/company vision.
• If possible define actionable next steps that could be done instead or in the near future so as to turn it into an opportunity.

So again the key questions that need to be answered are:

• “What are we here to do?
• "Does this feature request help us do that?"
• If no then "why would we do it?”

If the answer is "Sort of" then we place a priority value on it and go back to attacking the feature prioritization list starting at the top.

Efren Duarte is Managing Director, Products & Services and AVO Chief of Avocera Consulting and principal of the AVMI Group, a market research firm and think tank primarily focused on the business technology. You can read more blogs at http://www.avochief.com.