CPO Series: How to Build Your Product Structure Org

Read the Full Transcript

The following transcript has been altered for readability. 

Becky Flint: I am delighted to introduce our guest today, Cory. Cory is a very seasoned chief product officer. Currently, Corey is the Chief Product Officer at Blackhawk Network, which is a FinTech company. He can share more about that.

Prior to that, he was the chief product officer for Lively, which is a health tech company. And prior to that, he was a SVP of a product leading Change Health, and took the company from startup to scale up and all the way to IPO. You can hear a lot of his experience there.

Cory and I actually met back in the days at PayPal, where Cory was leading the global business and taking the product into over 5 billion in payments. So, a wealth of experience, a wealth of knowledge.

Super excited to hear more from Cory today, on how to build our product organization structure.

I’m sure different sizes, different times, and lots of insights. So without further ado, I’m going to stop share. Cory, take it away and share your insights and learnings, please.

Cory Gaines: I will definitely do that. Thank you, Becky. I see some of the folks on. I think I even know some of the folks. So for those that I know, great to see everybody again.

I appreciate the opportunity to spend some time and chat with you about my learnings over the years, of setting up and hopefully building and growing product teams. One of the trickiest things is, how do you get the organization right?

So Becky, thank you for the introduction. I love when people use the word seasoned. That’s code word for old, which I am definitely now.

Look, I put together a couple of thoughts. I’ll try to keep my comments to about 20 minutes, hopefully even less, and then open it up for questions.

Cory Gaines: Perfect. Okay, great. So let me jump right in. I think one of the trickiest things that I’ve come across in my career is, whether you run an entire product organization or simply just a product, if you have more than one person, you’re constantly challenged with, how do you organize and structure in such a way that you basically get what you want out of that product effort?

I’ve refined an approach over the years. I’ll share with you. Hopefully it works for some of you, but it really comes down to, I would say maybe three basic principles. Then I’ll provide an example of how I put it into practice.

So, first is always coming back to your product vision and mission. You always need to figure out what you’re trying to accomplish and how that focus on the product side is going to align with the business strategy.

The second thing is, I think there’s some organizational principles that are really helpful, to ground the effort. So, I’m going to share with you how I view those principles. And then finally, how do you come up with the right design?

Like I said, I’ll try to put all this together when we get to, how do you put this in practice?

First, starting with a vision, and the first question you probably would ask is, why is that important? It’s important because an org structure will play a critical role in how the development team…

When I say development team, I’m broadly speaking about the entire cross-functional team that comes together to build a product, is charged with bringing that product and product experience to life.

Org structures, if they’re anything, they’re basically communication vehicles that help teams, enable teams to deliver on their product vision.

It’s a simple concept, in principle, but it’s very difficult to get right, because org structures have to triangulate that communication effort between team members which are constantly changing, in terms of personality, maturity, their knowledge. And then you throw in time zones and locations, and the fact that we all are living on zoom.

Then if you add another complexity on top of that, is basically marketing competitive dynamics, which sometimes force a change in your tactics, sometimes force you to pivot.

I think lastly, the size of the team, generally, the greater number of people, the more complex the org design will be.

So an org structure has got to keep all those things in mind, which is one of the reasons why you see companies reorg awful lot. It’s not because they didn’t quite get it right the first time. It’s that there’s a lot of things that an org structure’s trying to solve for.

So what I try to do is to come back to, who do you serve? What value do you deliver, or what problem do you solve? How does the product portfolio or the product features support the business vision? Always keep those in mind.

Then I came across a principle years ago, called Conway’s Law. Conway’s Law is basically… This is an image. If you go onto Google and you search for Conway’s Law, this is an image that comes up very often. If you can read some of these things, it’s actually comical, in many ways.

When you think about the things that an org structure has to deal with, who doesn’t like whom? Who gets along with whom? Is there resentment? All these things are part of the challenges of creating a great org structure.

But essentially, the principle was set forth by a gentleman named Melvin Conway. In paraphrasing, he says any organization that designs a system defined broadly, will produce a design whose structure is a copy of the organization’s communication structure. In other words, what you build will be highly correlated to how you’re structured.

Sometimes over the course of my career, I hear these expressions, that if you look at a company’s website, it will tell you exactly a reflection of how it’s organized, be it good or bad.

So, I think the goal of Conway sets out for any organizational guide, should be to deliver the desired product solution by minimizing the friction that’s caused by the natural boundaries any structure creates, on value delivery to the customers we serve.

I’m going to say that one more time, because there’s a lot in there. I think it’s important to think about it. Any organization is going to create natural boundaries. The goal of an organizational structure is to minimize the friction that’s caused by those boundaries, that keeps us from delivering value to the clients that we serve. That’s a really important thing to keep in mind.

So what are our options? What are the principles that we try to lean into? First of all, there’s many different ways to design an organization. I’ll give you a couple of options that you can ground on.

The first one is, you could actually design based on a products, a set of clearly defined products. There’s some pros and cons to each one of these options.

Product-driven design, the pros are very clear accountability. It’s very easy to tell who owns which product, who’s responsible for that product. The objectives of each product hopefully will be fairly clear.

But when you take that approach, there are some negatives to that. And again, it comes back to, what are you trying to achieve? What’s your vision and mission?

One of the cons that I come up with on the product-driven [inaudible 00:07:38] is that you tend to have struggles with cross-team collaboration.

It’s also hard to create an integrated solutions experience. So, if you are a client that wants to access multiple products, when you organize based in product silos, sometimes that experience for cutting horizontally across that portfolio, sometimes can be a challenge. Not something that can’t be overcome, but it’s just something to keep an eye on and watch out.

I threw a couple of examples in there. Apple is very driven through a product design structure, Adobe the same thing. Both companies by the way, have figured out a way to streamline the horizontal experience that their customers see and achieve. So, it’s definitely possible.

Option two is to organize based on technical domain. The fantastic pros to this is that, it’s very easy to scale common services or shared services between different application teams. Again, clear accountability.

When you think about the challenges though, it does put heavy burden on the technical teams, or I would say the common services teams, because they have a lot of consumers that demand their service. Those consumers may not demand exactly the same thing. So, there’s sometimes a challenge in how those teams prioritize their roadmaps and the evolution of those platforms.

Great examples of this in the banking industry. We’re all familiar with banks. They tend to organize around checking accounts, saving accounts and investments.

If you’re on the software side of things, think about running a browser service, but having different teams assigned to different technical platforms, that that browser should work across.

You guys probably can think of other examples. I’d love to hear them, but that’s not an uncommon way to structure a product organization.

The third option is customer segment. This is very prevalent in telecom and many businesses that have the same service, but they want to place a context around that service that speaks directly to a very specific customer segment.

Obviously, it’s extremely customer and customer-segment-centric. It simplifies needs discovery. I think when you’re trying to understand what the needs are of a particular segment, since you’re organized by segment, there tends to be a pretty strong ability to know and propagate what that segment needs are, throughout the organization.

Again, I’d come back to the technical domain option. You sometimes have difficulty prioritizing shared services. So, if you’re Verizon and you have a very specific software application or platform for your mobile devices, again, how you evolve those may present some prioritization challenges, because consumers need something slightly differently than businesses or small business versus enterprise.

Option four, customer journey and life stage. Actually, in some of my time at PayPal, we did organize part of my product team, based on life cycle stage.

Pros are fantastic cross-domain applicability. If you build a great onboarding experience, you can apply that to pretty much all types of product solutions.

I’d like to call it one of the best ways to maintain institutional memory. Since you’re not having to rebuild an onboarding or reporting or a servicing experience for every single product, it’s a great way to maintain institutional memory across teams.

The cons are context switching. If you’re running an onboarding team, just think about all the different contexts you have to consider when you’re trying to develop the optimal onboarding flow.

Anyway, some examples. Trail, it should be trial… sorry, my spelling’s terrible, onboarding, servicing, cross sell and retention might be one way that you might want to organize that team.

Then option five, another option would be organized based on performance metric or KPI. I see this a lot. You can align your teams based on client acquisition, a team focused on client retention, a team focused on optimizing revenue per client or even the number of products per client. I do see a lot of organizations organized that way.

Fantastic for accountability. Fantastic for clear objectives. But again, sometimes it’s a little difficult to translate into specific product features.

It’s hard to say, I’m in charge of new client acquisition and then roll that directly into a series of features that actually help you acquire new clients.

But again, come back to your product vision and mission. What are you trying to accomplish? How does the product portfolio serve the business strategy? All these things that are important where you think about options that you might want to lean into.

Before we put this into practice, I think the last thing that we need to consider, and this is something that is usually ignored in any org structures and that is, what can the talent base support? What’s the culture of the organization?

It seems a little bit soft, but it’s one of the most important factors to determine whether any design is going to work for your organization. Will the body reject the organ?

If you don’t think about the skillset of your team, what’s the experience level of the team members? What’s their business maturity? What’s their domain industry maturity? What’s their skill level and set? What drives motivation within the organization? How does the organization develop or encourage engagement?

I don’t think any org structural will work, unless you really consider these factors as part of that thought process.

I included in here, an old TED Talk. It’s probably now going on 15 years old, which I still, once in a while look at, which is Daniel Pink’s What Motivates Us?

I constantly come back to that, when I think about setting up OKRs or having major organizational changes and shifts that are ahead of me.

Come back to, what drives us as humans? What motivates us as humans? Whether you agree with Daniel’s framework or you have other frameworks, if you don’t think about what the organization will accept, then you’re probably going to have a failed org structure.

Now, what do you do? You have all these options in front of you. You have an understanding of what the product portfolio is trying to accomplish, but where do you start?

Long time ago, I worked with a gentleman at PayPal that brought a framework in from Intuit, which I still use to this day, which is what he called Plan on a Page.

It’s a way to think about the various components and purpose of an org structure. It basically is a playbook for setting up your org design.

It consists of essentially three parts, with a notion that this same framework would cascade down throughout the organization.

It starts with understanding your vision and mission. What’s the statement that articulates, why does the team exist? Who is the team there to serve, and what is it there to accomplish?

Then when it says, okay, in doing that, in trying to accomplish that vision, what are the essential bodies of work that we need to get done? What are the jobs that need to get done, to actually produce that vision?

We flipped that and said, that really is the organizing principles for how we do the work. So, if you think about the org structure as a reflection of the jobs to be done, that is one of the best ways to at least set up the foundation of the house.

Then, within that foundational structure, if you really align on those three or four critical jobs to get done, then you start to say, okay, for that individual part of the structure, what are the big rocks? What are the outcomes and deliverables or major enablers, that this part of the org should set out to achieve?

If you take that same structure and you propagate it from your leadership team to the next level down to the next level down, all the way throughout the org, it should be a way to have a structure that’s very clearly articulating the jobs to be done and the levels of accountability throughout the organization. No matter how big or small the org is, it should hopefully articulate that pretty well.

Now I didn’t want to just drop a template on you and not give you some idea of how you go out and fill this out. Don’t worry. The template, I’ll share with you. Becky will make sure everybody gets a copy of that.

I’ll share with you how I used this at a smaller company I was at, just recently, Lively an HSA provider.

I only had a very small product team. It was only about 10 folks, but I still used the same structure and the same principles to try to build the org structure there.

I’m going to read some of this because it’s going to be hard for you to absorb it. But essentially, the charter we had at Lively for the product team, was articulated this way. Leverage modern design and development techniques to enhance our customer’s ability to confidently handle the rising complexity and cost of healthcare throughout their life.

Specifically, we provide a broad range of savings and investment options, along with user interactions that build confidence, help them save and accelerate the growth of their assets, to stay ahead and keep ahead of the rising cost of care.

We also extend those same capabilities to their employers, investment and retirement advisors, really with the hope of bringing Lively services and their products into an integrated ecosystem, to manage their wealth over time. Then, I go on to say to extend the platform and scale and things like that.

But essentially, an HSA account is no different than a 401k account. It’s a wealth development technique to help you save for your healthcare, in your later years.

Then we put a series of measures that we’ve created, your ability to create wealth or generate wealth. Basically, it’s just a ratio of, how much are you saving versus how much you’re spending on your healthcare.

Account acquisition, our ability to acquire new client accounts. And then we had some metrics around customer service and then the speed of moving money and transferring money to pay for care or to save for care.

So, that helped us kind of articulate, okay, what are the jobs that need to be done for an HSA account holder? Well, first there’s an experience. Just like a 401k, you need someplace to log into and monitor your account, your wealth of your account.

One of the jobs to be done, was to make sure that the account owner had the features and tools and capabilities to help them self-manage their health savings account. So, that became one of the pillars of our structure. And in fact, at one of our org structures, we had a leader of the account owner experience.

We also knew we had to integrate. Again, like a 401k, you have a 401k administrator, where we have HSA administrators, which basically is your employer that’s contributing or matching investment funds into that account, but they need to administer. They need to let you know when somebody’s left the workforce, or we had a new employer join.

So then, we had another job to be done, which was to make the administration of these accounts for the employer, really easy to do. That became another pillar of organization.

Then, a lot of what our account did was move money around. We gave people the ability to pay for health bills, save for health bills, transfer money in, transfer money out. HSAs or investment account, so you can invest your savings in different funds. So, there was this whole job to be done around financial management.

Then we created a part of the organization that was really around money management. Then we had a bunch of other things around data analytics and risk mitigation and things like that.

So the structure, the template essentially allowed us to go in and say, here are the critical jobs that be done and then, here are the key deliverables in each one of those areas, which is expressed here in the gray.

We tacked on, how do you measure whether you’re effectively getting those outcomes you want? Then we codified that in this artifact.

Now what we did is, the account owner team, which at the time was only another two product managers, took this same template. They blew it out for the individual outcomes that that team was responsible for. So, they had their own template, but it was just focused on some of the outcomes in gray.

This is a system that I’ve used over and over again. It seems to work. It can get very complex, depending on how big the product organization is.

This worked for an organization that was only 10 product people. I manage an organization right now, about 250 product people. We’re doing the same thing.

The cascading function, it feels heavyweight. But let me tell you, when it’s time to do your OKRs, it makes it really easy to articulate, what are you trying to accomplish and how do you measure those things?

Anyway, I will make sure that Becky gets you a template. I’ve included some templates here, to help you out, but I would love to open it up and see if anybody has any specific questions that I might be able to answer.

Becky Flint: Fantastic, Cory. This is amazing. I already started to see some of the question coming in. Just be before that, I want to just do a quick recap.

I realize that amount of the information you cover is more than just org structure. It really is the how to run a product organization, the thoughts around it. So, thank you so much for that. Would you like to stop sharing so we can… Yeah. It’s great.

A couple of questions that I have here from the audience, one is, you mentioned org structure and sizing. Also, you have the charters and the Plan on the Page. It seems the change is more frequent than it seems to be.

So how often or when do you think that the product organization need to be adjusted, reorganized?

Cory Gaines: Yeah, it’s a great question. I think many of us manage a rolling roadmap, where every quarter you might be updating that roadmap for the next four to five quarters.

But a natural cadence for me, since we tend to compensate our teams on the annual basis, would be at least every year, to go back and revisit the org structure. Go back and revisit your objectives, because it’s just a natural time, that coincides with budgeting and planning and corporate readouts, company readouts.

So at minimum, I would say once a year, you should come back to and look at your product vision, product mission. Make sure it’s still aligned to the business strategy, which hopefully hasn’t changed that much.

Then, go back through your org and ask yourself, are these still the outcomes I’m trying to achieve, or has something changed in the market or in our competitive position or we think we need to pivot?

That would always be a natural time to go back and look at your org structure and make sure it’s still trying to get out what you want to get out of it.

Becky Flint: Right. That makes a lot of sense. You shared a couple of the models of the thoughts around it. It looks like nothing’s perfect. There are always some sort of collaboration and connection happens.

So, how do you connect some of the directions that are not naturally connected, just through the org structure itself?

Cory Gaines: One of the reasons why I love Conway’s Law picture is because it clearly articulates how difficult this is to do.

There are many org structures that I wanted to put in place, but I simply didn’t have the right personalities or talent to do that. So, you make compromises. You do the best you can.

If data’s a critical part of your strategy, but you don’t really have good data analysts or somebody that can lead that effort, then you got to find accommodations and take a different route.

So like you said, Becky, it’s never perfect, but it is something that you constantly should try to evolve and improve upon. So, I would say, don’t get discouraged if the structure’s not quite what you’re looking for. Trust me, things change quickly, and an opportunity may present itself later on.

I think the other thing that I will say is, I have never been dissuaded by having a piece of the org structure not report to me. This is an important distinction in, again, personalities of organizations.

I’ll give you a great example. Solution consultants or sales engineering, I believe should be really strongly and deeply affixed to the product organization, but some organizations don’t believe that. Some organizations believe it needs to be in the sales group.

I am not going to the perfect be the enemy of the good or vice versa. So, I will work cross-functionally, to try to adopt and align with those teams, even if they’re not part of the organizational structure and create a shadow or dotted line structure, to still get what I need accomplished, even if they don’t report into the product team.

I think that what I’ll leave you with is, just be flexible. Don’t think that everything should always be exactly as you want it to be. Sometimes you make compromises and that’s fine. Because again, at the heart of an org structure, it’s a way of people communicating with each other. That needs to change, as people change and the elements change.

Becky Flint: Right. That sounds cool. I just realized what that question was. Someone asked, how have you used the POP to share goals and deliverables with the GCM team? Now I realized POP is the product operations.

Have you or how do you use product ops to tie in, share the goals and deliverables, given there are inherent silo or whatnot, due to any type of organization?

Cory Gaines: Let me think. In product operations as an organizational team?

Becky Flint: The role?

Cory Gaines: The role?

Becky Flint: Yeah.

Cory Gaines: That’s fascinating, because I literally just hired my first head of product operations about a month ago. I’m just trying to bring her into the fold here.

It’s a great question. I don’t think I’ll have a great answer for you. I established her goals as really helping the product managers be as effective as they can be, through either better data that’s at their fingertips, training and skill development and better just transparency over what they’re trying to do.

So, I’m still in the process of working in product operations, into that framework. But if we added another goal to my framework, another job to be done is to make sure you have a very highly effective product team that’s very market aware, but tied into the go-to-market activities.

I would probably have a series of outcomes that I’d want product ops to roll into and an ability to measure that. They would just fall right into the tree of our Plan on the Page objectives.

Becky Flint: That’s cool. I think we are kind of running low on time. There are a couple more questions that I’ll follow up with you. We can get questions through emails and sent out to everyone else.

We do have a standard question for every guest on the call, on the session. So, want to send it to you as well. Which is, in your experience as chief product officer, you definitely have been to and worked with many. What do you think are a couple of the top factors and things differentiate a good chief product officer from a great chief product officer?

Cory Gaines: Well, I don’t know if I’m great or good. I think my boss will have to tell you what she thinks. I always come back to the same thing, which is be extremely customer focused, not necessarily customer responsive. Meaning, I’m not going to just do what you think you want me to do, but I’m going to get behind what it is you’re trying to accomplish and solve for. I’m going to come to you with a innovative and differentiated approach to solving that problem.

That means you have to know your customers inside and out. I think those product managers that have a pulse on both the emotional, contextual and functional things their customers are trying to solve for, I think they’ll use usually be ahead of the game.

So my mantra is, if there’s a debate internally or uncertainty or ambiguity, come back to, what do you think that customer really wants? Hopefully, you know the customer well enough, that pretty much anything you come out with would be accretive to that customer’s life. So, that’s what I’d start with.

Then I’d probably fan out from there, in terms of market awareness and things like that. But I try to be with my customers as much as possible.

Becky Flint: That’s amazing. Thank you so much for a wonderful session, very, very informative. It’s very rarely you can hear from seasoned Chief Product Officers, on how to structure organization.

Now we know, through working with thousands of Chief Product Officers across the globe. We know not only, they have a system, they have the people, they also need the right tool.

Dragonboat is a tool built for outcome-focused organizations and Chief Product Officers. So if you’re interested in more, log on to Dragonboat.io/CPO. The session is recorded. Additional questions will be answered through emails.

So, thank you for joining us today. Thank you so much, Cory, for sharing with us, your experience and wisdom.

Cory Gaines: Thank you for inviting me, Becky. Nice to see everybody.

Becky Flint: Thank you. Bye, everyone.