In an ideal agile world, the team would work directly with a customer. When you have a small product that serves maybe three types of customer (new, expert, admin for example), and that customer is down the figurative hall, you might not need any product people. You can create short feedback loops with your customer. (See Part 1 for more info.)
The larger the product and the more diverse your customers, the more a single person cannot encompass all the strategic and tactical roles as a single product owner or product manager. I see people drowning in all the work. Or, they finesse some part of the role. They lurch from one emergency to another. They aren’t satisfied. Neither are the teams nor the organization.
Shorten Customer Feedback Loops
Let’s talk about why we have any product people at all. Product people:
- Create and refine the strategy behind the product/service. They do this because they know the customer(s) they want to acquire or retain.
- Verify that the problem is the problem the customer needs to solve.
- Verify that the product does solve the problem the customer needs solved.
All of these reasons require shorter feedback loops if we want to benefit from an agile approach.
Strategy helps the organization refine which product solves which problem for whom. Strategic thinking helps organizations separate products so you don’t end up with bloatware—a product that no longer solves the problem for the original user. (Sometimes, any user!)
When we verify we understand the problem or that the product solves the problem for a specific customer, we need short feedback loops. We need strategy feedback loops and tactical feedback loops. These feedback loops often have different cadences and needs for information.
A startup might need both strategic and tactical feedback every day or every week. One person might need to ask for that feedback and invite the team to work with one specific customer to get that feedback.
However, once you have several kinds of customers or a larger product with several teams, one person cannot manage all the feedback loops. Too many of us incur a multitasking cost when we try to consider strategic and tactical issues at the same time. We can’t track the big picture or the details. We can’t move easily from either to the other.
The job is too large for one person.
Consider the Product Value Team
Instead of one person attempting to think at all the various levels about the product, why not create a team? That’s the product value team.
Note that we have teams for everything else in an agile organization.
The solid lines are the direct interactions. The product manager and customer interact directly for feedback purposes. That interaction refines the product strategy. The product teams (feature teams) work together in their small-world network.
The product manager and customer have defined interactions at reasonably frequent intervals. The teams and their POs have defined interactions daily in their teams.
The POs and the Product Manager dashed lines mean frequent interaction, but not defined interaction for feedback.
(As with all images, projects, and programs, your mileage will vary.)
Notice that the POs also interact with the customer. I expect that the product manager and the POs discuss how to interact with the customer so that everyone finds value in the interactions.
When POs and teams interact with the customer, they can gain fast feedback on features, such as MVEs (experiments) or MVPs (validate business hypothesis).
Teams Might Need to Work Directly with Customers
Sometimes, the team needs to learn by watching a customer. Customers might work differently than internal people acting as customers. Or, from people who think they represent the customers’ problems.
POs and teams need the opportunity to work with a customer. Every team has different needs. That means that part of the product value team’s work is planning when teams can gain information from the customer.
Product Value Teams Can Replan as a Team
I’m not fond of big-room planning only once a quarter for programs. I find the (tactical) work needs to change more often than that. And, I don’t like the two-three weeks of prep that too many teams require for that meeting.
Instead, I’m fond of small-world networks to help information move around the organization. Sometimes, those networks are formal. One formality might be a biweekly roadmap or replanning between the teams in a program. (I’m assuming the program is longer than three months. You might need more meetings if the program is short.) The biweekly meeting helps maintain a rolling wave.
I wrote about rolling wave planning for a quarter and how to move it to a shorter wave before. The shorter your customer feedback loops, the smaller your rolling wave needs to be.
With short feedback loops, you don’t need detailed planning for an entire quarter. Instead, you might plan for two to four weeks at a time.
The product manager maintains the business value of the product’s strategy. I often see product managers needing to revisit the strategy anywhere from once a month for early-in-life products to yearly for late-in-life products. The POs maintain the business value of the backlogs.
Do they ever need the teams to also plan? Yes, if they don’t have feature or product teams. I’ll address that in the next post.
Series so far:
- Product Roles, Part 1: Product Managers, Product Owners, Business Analysts
- Product Roles, Part 2: The Product Value Team
- Product Roles, Part 3: Product or Feature Teams
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Product Roles, Part 2: The Product Value Team Opinions expressed by Java Code Geeks contributors are their own. |
