Software product management or product ownership is vital companies that produce software products for commercial purposes and for organizations producing software for internal consumption. They both have the same underlying goals of creating something that provides value either by generating revenue or optimizing costs and gaining efficiencies for customers or the internal organization. Both begin with a business strategy or market imperative that is identified by someone in the organization or by customer demand. Both require identifying the reasons for considering the product and placing it in the organization’s portfolio of possible products to build and assigning relative ROIs, either explicit or intuitive. These things happen regardless of how proactively an organization manages its software products so why not assign someone to do just that. How effective would it be to have someone keeping the business strategy in mind, understanding the business domain and the market in which the business operates, and understanding how and when to communicate with software development teams, project managers and business analysts while keeping all stakeholders apprised of key business and technical decisions along the way?
All this makes sense of course but sometimes it can be a significant challenge depending on certain factors within the organization including its distributed nature, its size, its area of expertise or its ability to dedicate resources to this full-time role. If the organization has issues that seem to be prohibiting them from establishing a product manager role then another approach I’ve taken is to identify the things that a product manager would be responsible for in a particular organization and then bring in someone from the outside the organization to build a product management plan and work that plan as they would a project or any other plan. This would involve an outside consultant specializing in software product management who on a regular basis meets with people familiar with the business strategy and business domain and those responsible for the technical aspects of building software for the organization. They would also potentially interface directly with customers or customer proxies and in general be the de facto product manager but strictly from a perspective of meeting with the right resources at the right times to help the organization work together to fulfill the key goals of that role.
Another benefit of this approach is that employee/resource turnover becomes less of an issue. If you have one person who is responsible for all these aspects then there can be a lot riding on their continued involvement with the organization. Having someone from the outside put together a documented plan of attack for managing a particular product and identifying and working with the key people inside the organization that possess the information required to help manage the product management process means that you have more people familiar with what’s going on at the product level. If the organization matures and brings on a dedicated product manager or another outside resource, both scenarios are less disruptive and much easier to sustain over time.
So consider dedicating someone to the role of product management regardless of if you’re building software that is customer facing or business centric. And if you don’t feel you have the resources currently to establish that permanent role or if you’re just interested in testing the waters, consider hiring someone from the outside to put together a product management plan and help you identify the resources you currently have to help serve that crucial product management function in your organization.