- Product managers are responsible for the long term aspects of the product. They are more strategic and project oriented than on-going operationally oriented.
- Understand how investment in product correlates to revenue.
- May own product (line) P&L, but this really depends on the organizational structure and size of the company and the role of the CEO (who ultimately owns the overall P&L). If a Product Manager owns the P&L, they're really more a business unit (subordinate CEO) manager.
- Focused on product futures
- Domain and product expert, including market and competition.
- This typically requires research and analysis, and producing briefs and presentations to keep the rest of the business in alignment with product and market vision.
- This may include evolving government, regulatory, and licensing structure
- Support sales and bizdev opportunities to a certain level of product depth, and certainly in the context of a competitive selection (a Product Operations Manager will typically know the current product in a greater depth than the Product Manager)
- Documents roadmap including setting feature/backlog priorities and asserting timing aspirations.
- Requests, aspirations, and priorities should be gathered across the business and customer base. These are synthesized, traded-off and put together with product strategy and technology requirements.
- Maintain an evolving roadmap to be constantly prepared to communicate vision, strategy and plans.
- The roadmap isn't just features over a time period, it's also the key drivers and ideas behind feature priorities and timings.
- Lots of communications - with bizdev/sales about what's coming up, with marketing on new and updated features
- Drive consistent use of businesses cases and related process expectations.
- Create new and improved product business cases
- Educate product stakeholders what is required to get a new feature, product, or bug fix into the product backlog
- Must know when to break/bypass the process when a unique and compelling opportunity is presented.
- Identify how to identify and monitor business case assertions (KPIs)
- Document requirements and non-technical business logic
- Set expectations into the business about what is required by a delivery team or supplier for that team to effectively deliver new and improved products
- Create visual mock-ups and prototypes to help communicate requirements.
- Champion the user and commercially-sufficient-quality user experience
- Works with a project, solutions delivery and/or software development manager to deliver new features and functions. The Product Manager is the domain expert that the technologists consult for feature/function decisions.
- Customer of delivered product from in-house development or suppliers
- Guides schedule-scope-resource-quality tradeoffs
- Understands and monitors technical debt level and makes short/long term technical investment decisions and priorities
- Verifies results against requirements (directly or using a QA team by proxy)
- Post delivery, measure business cases against reality. Create enterprise knowledge around what deliveries create revenue and who is driving them.
- Supplier selection, negotiation, and management, particularly the commercial/legal aspects.
Should product managers have staff or be like programme managers that tend to rely on other's staff and influence to get things done? My view is that as organization and product complexity/diversity grows, product managers must build out a team support all of the above responsibilities. Using influence to contend for (often precious) resources increases time-wasting political challenges. In particular, appropriate staff are:
- Business analysis. People that can develop deep domain knowledge, produce market/product competitive analysis, and create specifications.
- Project/Programme managers. For larger projects, you need staff to glue together all the moving parts and manage aggregate progress and risks.
Note that Product Management can really overlap with IT, in particular with PMO and QA teams. It doesn't really matter where the Product Management functions sits, although in an emergent and high growth area it's probably worthwhile to keep it separated from technology to facilitate overall scaling of the business. As the competitive advantage of product differentiation that comes through excellent product management decreases, it may make sense to merge it into Marketing or IT as a potential cost savings.
- Product operators are focused on extracting maximum value and efficiency out of the platform as it exists today. They understand the current product better than anyone else - they're using it every day. They feed operational inefficiency issues and new feature requests into the product manager.
- Focused on day-to-day operations of a product
- Current product experts - they know how the product works, all its quirks and foibles
- Uses backoffice systems to:
- Manage live product configuration
- Produce reports, analyze live data and product performance
- Solve customer problems
- Maximizes product revenue within the constraints of an existing product
- Own a tactical backlog of improvements and fixes that would improve product operational efficiency
As organization and product complexity and diversity increases, it's important to separate out operational, execution, and tactical excellence from futures and strategic excellence. I find time and again these two ways of thinking pop up in all areas during business growth and need to be separated to work well together.