Continually delivering new product features is essential to driving the business value of digital products. However, many product teams work in functional silos that mirror internal business processes—product management, technology, project management, design, etc. Organizations that keep people tied closely to the business function of their role can drastically reduce the speed of their release cycles and minimize the effectiveness of their product owners and managers.
A Product-Oriented Delivery (POD) model is cross-collaborative and solves many issues that hamstring projects and ultimately hinder product success.
What is Product-Oriented Delivery?
Organizations typically structure their initiatives into discrete projects that get separate funding and an assigned project team, and focus on a fixed scope. POD focuses on the continuous delivery of a product roadmap. Unlike scope-based financing for projects, product-oriented budgets are focused on the funding capacity of the team capable of releasing product features.
POD is more flexible to the variables that inevitably come up during product delivery, which will change product requirements and release plans. Variables in a project-based approach, with a more rigid definition of scope and budget, will either be ignored since it doesn’t fit the original project definition or require a change in the project budget to account for differences in scope.
An agile POD, sometimes called a squad, is a cross-functional team with complementary skills and expertise to make decisions regarding product delivery and quality. This self-sufficient group collaborates over multiple Scrum sprints to meet specific product goals. This group is often divided into roles that include:
- Governance roles – Product Director and Product Owner
- Coaching roles – Agile/DevOps Coach(s)
- Architects – Enterprise, Application, Data, Cloud, Security, etc.
- SRE – Site/Service Reliability Engineering Specialists
What are the benefits of product-oriented delivery?
Enterprise companies, because of the complexity of their products and the size of the teams working on them, stand to gain a lot from moving toward a product-oriented delivery. Here are some of the reasons why.
Reinforces product best practices
A clear vision, product strategy, and roadmap are necessary for product-oriented delivery. For many organizations, this may expose gaps in their current process if there is no clear vision, strategy, and an essential starting point. Developing a strategy for a product requires research to inform decisions that will drive value to users and, in turn, the business.
Creating a clear vision requires design concepts, presentations, and technical exploration that pull forward design and technology conversations, which can have compounding benefits when creating feature requirements later on. Design and technology input in strategic discussions can create space for more elegant solutions, innovative ideas, and early consensus for the overall product strategy.
Accelerated product release cycles
As mentioned earlier, PODs can allow for greater collaboration between departments. This can be especially valuable for design and development teams that must work together to ensure what is built and released matches the intended design direction and is tested with users.
Including subject matter experts and business stakeholders in the POD structure enables informed decision-making at the POD level. This creates more nimble teams capable of adjusting requirements that meet user and business needs without escalation.
Predictable team utilization
POD teams empowered to make decisions about the features they are working on will ensure a steady backlog of work the team can work on. Since the cross-discipline team possesses the skills required to deliver product features, there will be little need for outside support. The team’s ability to drive feature work forward without reliance on additional support eliminated the risk of bottlenecks and extended lead times for delivery.
Flexible capacity of specialized teams
Some skills won’t be in total demand in each POD. This will require some adjustable support from specialists. Research, content strategy, and information architecture are a few capabilities that may function as a shared service across multiple POD teams. This has several benefits, including:
- The team will fully utilize the individuals within these capabilities across various PODs.
- These efforts often benefit from the shared perspective and knowledge across multiple PODs.
Moving to PODs
Moving your teams to a POD model doesn’t have to be stressful. If you’re already working in an agile team structure, you’re most of the way there. Restructuring existing elements of your team and bringing them closer to each others’ work and process can benefit your team members and your business.
Want to learn more about how to implement PODs to improve your product delivery? Schedule a free consultation call.
Send us a postcard, drop us a line
Interested in working with us?
We scope projects and build teams to meet your organization's unique design and development needs. Tell us about your project today to start the conversation.