Comprehensive software reviews to make better IT decisions
When Your Platform Dictates Your Roadmap
Platform product owners struggle to develop a product roadmap and prioritize backlog items when their system supports multiple external products across business lines. Teams are used to a LoB or consumer product owner defining and prioritizing changes, but how do you manage these requests when they are coming from many different product owners?
Examples: Underwriting system for insurance and loans, CRM systems, SOA platforms, collaboration tools such as Salesforce and SharePoint, billing systems
In Build a Better Product Owner we identified three product owner perspectives that need to be identified and represented when mapping your product owners to your products and services.
- Business Product Owner – LoB product owners focus on the products and services consumed by the organization’s external consumers and users. The role centers on the market needs, competitive landscape, and the operational support to deliver products and services.
- Technical Product Owner – Technical product owners are responsible for the IT systems, tools, platforms, and services that support business operations.
- Operational Product/Service Owner – Operational product/service owners focus on the people, process, and tools needed for manual processing, actions, and decisions when automation is not cost effective. Product owners in this space are typically called service owners due to the nature of their work.
In the case where the software platform supports many different LoB product owners and operational product owners, the technical (platform) product owner needs to own the primary roadmap and backlog for the shared system. Just like working with many stakeholders, the technical product owner needs to manage and communicate the roadmap, backlog, release milestones, and criteria used to prioritize change request.
This is best handled by leveraging a product management or roadmapping tool. Ideally, this tool should integrate into your delivery management tool. The key difference here is that we aren’t trying to use our sprint or Kanban management tool to communicate the product roadmap. Agile tools are excellent for managing delivery and releases but are too far into the weeds for strategic planning between consuming product owners and stakeholders.
Having a consolidated view will improve communication, increase collaboration, and reduce competition for changes. Make sure your prioritization criteria are clearly stated and aligned to your organization’s strategic goals and priorities.
- Shared platforms require the platform owner (Technical Product Owner) to own the primary roadmap and backlog.
- The platform roadmap must be coordinated with LoB and Operational Product Owner perspectives. They are your customers.
- The platform is more than the sum of individual Product Owner requests. The Platform Product Owner must create a product and vision that can grow and support future organizational needs.
Want to Know More?
- Build a Better Product Owner
- Strengthen the product owner role in your organization by focusing on core capabilities and proper alignment.
- Transition to Product Delivery
- Stop delivering projects. Start delivering products.
- Build a Better Product Roadmap
- Create a roadmap that suits your objectives, the characteristics of your product, and the environment it lives in.
- Product Roadmap Diagnostic Tool
- Product Roadmapping Tool
- Build a Better Backlog
- The quality of your product backlog is key to realizing the benefits of Agile.
Traditional accounting practices are tailor made for waterfall project management. Organizations that have transitioned to the use of standing product teams using Agile and DevOps need to transform their accounting practices as well or they will leave valuable capital expenditure dollars on the table.
IBM is changing the terms of its ubiquitous Passport Advantage agreement to remove entitled discounts on over 5,000 on-premises software products, resulting in an immediate price increase for IBM Software & Support (S&S) across its vast customer landscape.
So you’ve gone Agile. You do daily scrums, retrospectives, and all the “right” Agile ceremonies. But still your organization isn’t quite convinced. It is now critical to balance the drivers and goals of both Agile and traditional thinking in order to achieve organizational success.
Do you feel like your Agile teams are treading water – going through the motions but never going anywhere? It’s a risk, and practices such as daily standups, retrospectives, and demonstrations need to be used wisely or you risk losing discipline to meeting fatigue.
Stakeholders expect the speed and responsiveness of product delivery does not come at the expense of quality. QA tools offer retailers the ability to continuously ensure both business and technical quality standards are upheld, but these tools should not be viewed as a silver bullet.
When trying to implement Agile as a defined process, Scrum turned BAs or other roles into order takers with the title “product owner.” This undermines the entire value proposition of product management.
No matter how good your product roadmap and backlog are, they are only as good as your audience’s ability to understand your vision and priority.
The scrum master is like the conductor of an orchestra, ensuring that every piece fits together at the right time to create something greater than the sum of the parts. You don’t have to know how to play each instrument, but you do have to understand what each part contributes to the overall masterpiece.
Tools are important to product teams, but only when they support solid people and processes.