Who owns the product? For a long time, most technology firms delivered products in a waterfall method, a fairly straightforward way to define, build, test and deliver products. Product management, development and product marketing roles and titles were clearly defined and ownership was fairly clearly understood.
But as the majority of development organizations moved to iterative development methodologies—such as agile and scrum—new titles, deliverables and processes emerged. It’s true that these changes often result in improved team interaction, greater visibility of project progress, greater flexibility to adjust to change, and more inclusive, open organizations. But there’s often a downside too: The new processes introduce resource and expectation gaps, causing confusion about ownership and accountability.
With this shift, organizations see two significant challenges:
1. New roles are introduced without changes in staffing. These roles are fairly well defined and are important in the new processes, but they don’t come free. To be effective, they usually demand additional time and new skills. Yet, existing personnel are often asked to cover their old roles while taking on new ones. Specifically, product managers are also asked to be product owners; project managers are also asked to be scrum masters; business analysts are asked to track development velocity; and user-experience designers are required to spend more time in the office and less time with actual users.
strong>2. More time is spent on internal meetings than on the market. This increased emphasis on process often results in companies losing touch with the market and becoming more inside-out in their thinking. Pragmatic Institute emphasizes that nothing important happens inside the office (NIHITO), but internal demands and new processes (e.g., daily stand-ups) move many organizations even farther from the market.
One way to reduce this confusion and ensure we don’t lose touch with the market is to clarify ownership and expectations by identifying key activities, outputs and deliverables, and then selecting the most suitable person to own each of them. Let’s focus on outputs and skills, not titles. This helps us answer questions like:
- Can the business analyst act in the role of product owner?
- Do we need a project manager and a scrum master?
- What are the “handoffs” between each group, and who approves them?
This partial list of release activities on the following page will help you get started. Sit down with the cross-functional team, review each item in detail and assign a primary owner for the function. Download >
By following these steps, organizations can more clearly articulate the expectations of each role. Leadership will not only become more clear about ownership and accountability, but it will be better informed about where teams are spending their time and can make the necessary tradeoffs to ensure there is still time in the market.
