A recent conversation on the Agile Iowa slack group inspired the post for this week. The question basically came down to how do you identify your product for the purposes of which team will own it and who the product owner should be.
For small products that you sell, this question is easy. It starts to get complicated when you have a large product that you need multiple teams to create, or internal product situations where the definition is not quite as easy.
There is no right answer.
That said, here are some things to think about as you try to decide how to identify your product(s) and organize your product teams and product people.
Products for sale
When your organization’s main activity is developing and selling software, your product is your software. Melissa Perri in her Product Institute class on product management defines a product as “A distinct vertical functionality that solves a problem or performs a utility function for a customer for which our business purpose is furthered, either through monetary remuneration or advancement of organization objectives.”
If you develop android or ios apps that serve one purpose it is pretty clear cut. Your product is your app.
If you’re Microsoft, your product might be Office 365. Or, your products might be Word, Excel, Powerpoint, Outlook and Notes.
If you’re a SaaS like Slack your product is the service of helping teams communicate where the software is a big part.
So when you sell software, your initial definition of your product is pretty clear cut. What do you need to solve a customer problem and earn money as a result.
But when your product becomes complicated enough that you want multiple teams to keep improving it, defining your product becomes a little more complicated. You’re no longer defining your product for the purposes of slapping a price on it, you now need to figure out how to organize the team that works on it, and the product people that work on it.
And that’s exactly the challenge that you face with internal products. Here are three different ways you may go about defining products in an internal product setting based on what I’ve observed in different organizations. I’m sure there are other ways, and I’d love to hear your thoughts.
Organize by Business Process
One way you can identify a product for the purposes of identify product team and product people responsibilities is to align based on business processes. This approach is likely to translate to a strong outcome orientation – business processes are often centered around delivering a specific outcome.
One example of this is where you have a product team that supports everything needed to run a specific business process, let’s say claims administration. It should be fairly straight forward to identify the right product person, at least in terms of business knowledge and decision authority in this setting, It’s someone that owns or has a great deal of responsibility for claims administration.
One big downside? Defining business processes can sometimes be as tricky as defining products. And you’re also likely to decompose business processes into smaller processes. Depending on how much work is needed to support the overall business process, you may need to do the same thing with your product team and product people.
Organize by System
You could always organize your product team by system so that a specific team owns one or more systems. The product person in this case will generally be aligned with the product team more so than the stakeholders that use the system (the business analyst in Product Ownership Model 3).
The benefit to this approach is the team becomes very familiar with the system and you’ll always know who to turn to when you need changes done to a specific system.
The big downside is that the team will inevitably be output focused. Due to their area of responsibility, they will always be inclined to view success as delivering specific changes. You can sometimes get around this if you only need a single system to deliver a specific outcome.
This is the way we organized the team that works on the Agile Alliance website. To get specific outcomes, we often need to make changes to the website and other things, but the team that works on the website only sees changes they need to make there.
Organize teams by technology; product people by business unit
A third approach I’ve seen is when you have a central IT organization that wants to adopt an agency model for staffing work on on systems. They create teams that have an expertise in a specific technology (mainframe, data warehouse, web applications, mobile apps). Those teams then effectively “bid out” for work to various business units that need work done.
These teams often have product people on each team but then also get product people involved from the business unit that is having work done. This is Product Ownership Model 4 where the business analyst stays with the team from one effort to the next and the product owner comes from the business unit.
The advantage to this approach is that you have a great deal of flexibility when it comes to attacking a specific initiative. The big downside is this structure reinforces an output focus and a project based way of thinking.
How to decide which approach works well for you?
So if you find yourself trying to decide how to organize your product teams, how do you go about doing that? Here are some questions that you may find helpful.
- Are you serious about working in an outcome based manner? If so, you may find organizing your teams around those outcomes, or business processes to be a good route.
- Are you just starting down the journey of having stable product teams? If so, the first step may be to organize around systems. Chances are when you operated in a product based approach you tended to have specific people who frequently worked on the same systems. That may give you some idea of initial teams to form.
- Does your organization need a lot of flexibility and tend to look outside for help just as much as inside your organization? You may find organizing by technology to be a good first step.
As I said before, there is no right answer, so it’s important to be aware of the options and your current context and consider what might work best for you. Once you think you know what that might be, try it. Also be willing to inspect and adapt. Sometimes your first instinct will be spot on, other times not so much.
What approaches have you seen?
I’ve suggested three models I’ve seen in the wild, but I fully expect that there are other approaches. If you’ve organized product teams successfully, please share your experiences in the comments. Even if you’ve been involved in an approach to organize teams that didn’t work, share that as well, along with what you’ve learned.