I just got back from INDUSTRY The Product Conference 2019 organized by Product Collective. As I reflect back on the sessions I attended, the people I met, and the discussions I had, there are a variety of ideas that keep floating around in my head. Over the next few weeks, I’ll explore those ideas and their relevance to product people.
I should note that these ideas weren’t necessarily the intended messages of any one session, rather it’s a synthesis from all of the interactions I had. Nonetheless, I think product people will find these ideas helpful.
One thing that people who do product development constantly try to figure out is how to organize to deliver product.
There is no one right way to organize the people who are doing product development, but it doesn’t stop teams from looking for that silver bullet product team structure.
I’ve written about how product people can organize in relation to their customers and their teams, but avoided saying which one was correct, preferring to say “here’s different ways you could organize, which one you pick depends on your situation (playing in to the context idea below).
In his talk about product leadership, Rich Mironov chose to take it a step further. He explained that one of the key responsibilities of product leaders is to design, build, and nurture product teams. He shared his view of a good product team structure, a not so good product team structure, and a really bad product team structure.
A good product team structure
A product team structure that Rich likes is one in which a product person (title isn’t necessarily important, but it could be product manager, product owner, business analyst) has roughly equal interaction with both users/customers and a team. “Team” in this case means a stable, focused cross-functional team that has all the skills needed to create the product (or part of the product) that the team is charged with delivering.
The interaction the product person has with customers and users is for the purpose of learning about the users problems and any constraints around the solution.
In an internal product situation, those interactions are not about users and stakeholders telling the product person what solution to build.
In an external facing situation, those interactions are not sales calls.
When your product gets too big for one product person to handle the entire product with one team, you slice your product into valuable slices. Each slice has a team that’s focused on that slice and a product person who can spend an equal amount of time with the team and talking to customers.
A not so good product structure
The good thing about this product structure is that you still have stable, focused cross-functional teams with all the skills that you need to deliver your product.
The not so good part is that the product person (people) talking to users/customers are separated from the product person (people) working with the team.
You run the risk of a disconnect between your user’s problems and the solution that your team puts together. You also lose much-needed context when understanding why your users face the problems they do and why it’s valuable to solve them.
You may be able to overcome the game of telephone your product people are forced to pay in this situation, but only if your product people can work very well together. If you have a choice, it’s probably better to go with the structure suggested above.
A particularly dysfunctional application of this structure are when organizations (often for their internal products) pull a subject matter expert from the business unit to be the product owner, but don’t allow that person to focus on actually being a product owner. Because this product owner has to fulfill their regular duties they only spend so much time with the team, often don’t talk to users or customers much, and generally don’t have a lot of general product management knowledge. The result? You’ll often see someone who does have experience as a product person working closely with the team, but unable to have meaningful conversations with users and customers.
A bad product structure
Does this one look familiar?
Unfortunately for many readers of KBP.media, particularly the business analysts out there, this probably looks painfully familiar.
Gone is the stable, focused, cross-functional teams with all the necessary skills. In its place is a group of people who happen to be working on the same project, some of the time. Chances are they are also asked to work on three or four at the same time.
Gone is any direct relationship between the team and its users/customers.
Gone is any idea of solving a problem and the team having the flexibility to identify potential solutions.
This structure reinforces the pattern of product people and teams as short order cooks asking “what do you want?” and delivering exactly what the business unit exec tells them.
In fact, when the team involved is pulled from “resource pools” instead of being truly cross-functional, the model where the head of a business unit gets named as product owner becomes this model.
This structure is so undesirable, I didn’t even include it in one of the models I explored for Product Ownership
If you find yourself in an organization that still operates in this fashion, your best bet may be to polish up your resume.
How is your product team structured?
This particular topic may have stood out to me due to recency bias. I focused on delivery, feature, and product teams inside organizations in a recent newsletter. While I was at Industry, Gordon Weir published a post sharing his thoughts on empowered product teams in reaction to that newsletter. It’s a good read, I recommend you check it out.
So I may have been primed to catch on to additional viewpoints about team structure. Ok, I’ll own up to that.
At the same time, I think it is one of those things that product people continue to try and figure out.
Are you trying to figure out how to structure your teams and your product people? Have you found a way that works? Let me know what about your experiences.