Cory Gaines, Chief Product Officer at Blackhawk Network joined our CPO Series to share his insights on setting up your product organization for success. As a seasoned product executive with extensive experience in building and scaling dozens of teams, he shares learnings on how to best structure your product organization with practical tips to put into practice. Let’s unpack those!
Why Product Organization Design is important
Organizational structures are the communication vehicles that enable teams to deliver the product vision. While this may sound like a simple concept, in reality, it’s often difficult to do successfully.
According to Conway’s Law, any organization that designs a system that is defined broadly will produce a design whose structure is a copy of the organization’s communication structure. So in other words, what you build and deliver will be highly correlated to how you’re structured.
Any organization is going to create and have natural boundaries within team structures. That’s why the important thing to remember is this: the goal when you structure your product organization is to minimize the friction caused by those boundaries, which keeps you from delivering value to your customers.
Common Types of Product Organization Designs
While there are many different ways to structure your product organization, there are a few common structures that you can ground on and build from:
- Product driven design
- Technical domain design
- Customer segmented design
- Customer journey and life stage design
- Performance metric or KPI design
We’ll go over the pros and cons of each. However, remember that no matter what design you choose, everything should always tie back to your product vision and mission.
Product Driven design
(ex: Mac, iPhone, Adobe Creative Cloud Suite)
Pros: clear accountability, clear objectives
Since this is a design based on a set of clearly defined products, you will have very clear accountability. It’s also easy to tell who owns each product and who’s responsible for each product, and you can expect the objectives of each product to be clear and fair.
Cons: cross-team collaboration, creating an integrated solution experience
There may be struggles with cross-team collaboration and a challenging integrated solutions experience. Say you’re a client that wants to access multiple products. When you organize based on product silos, sometimes the experience of cutting horizontally across the portfolio can be a challenge. It’s not something that can’t be overcome, but something to keep an eye on.
Technical Domain Design
(ex: bank checking, savings, and investment, Mac OS, iOS)
Pros: scaling of common services, clear accountability
It’s easy to scale common services or shared services between different application teams, and you know who owns and is responsible for each product with clear accountability.
Cons: challenging prioritization of application needs
This may put a heavy burden on the technical teams and common services teams, since they have a lot of consumers that demand their service. Those consumers may not demand exactly the same thing, so there can be a challenge sometimes in how teams prioritize their roadmaps and evolve their platforms.
Customer Segmented Design
(ex: Verizon for Business vs. Consumer)
Pros: customer/segment centricity, simplifies needs discovery
This is an extremely customer and customer-segment-centric design that simplifies needs discovery. For example, when you’re trying to understand what the needs are of a particular segment because you’re organized by segment, there is a strong ability to know and propagate what that segment’s needs are throughout the organization.
This is a very prevalent design in telecom and many businesses have the same kind of service, but they want to place a context around that service that speaks directly to a very specific customer segment.
Cons: prioritizing shared services, cross-team collaboration
There may be difficulty prioritizing shared services, similar to the technical domain design. For example, if you’re Verizon and you have a very specific software application or platform for your mobile devices, how you evolve those may present some prioritization challenges. Consumers need something slightly different than businesses, or small business versus enterprise.
Customer Journey and Life Stage Design
(ex: trial, onboarding, servicing, cross-selling, retention)
Pros: cross-domain/product applicability, institutional memory
This design is one of the best ways to maintain institutional memory across teams, since you’re not having to rebuild an onboarding, reporting, or servicing experience for every single product. There’s also cross-domain and product applicability. If you build a great onboarding experience, you can apply that to pretty much all types of product solutions.
Cons: context switching, over specialization
If you’re running an onboarding team, consider that you have to think about all the different contexts when developing the optimal onboarding flow and over-specialization.
Performance Metric or KPI Design
(ex: new client acquisition, # of product per client, revenue per client)
Pros: clear accountability, clear objectives
This is a very common type of product organization design. You can align your teams based on client acquisition, client retention, optimizing revenue per client, or even the number of products per client.
Cons: difficult to translate into product features
While this design is fantastic for accountability and clear objectives, keep in mind that it is sometimes 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.
Remember… always go back to your product vision and mission and consider what you’re trying to accomplish. How does the product portfolio serve the business strategy?
How to Structure your Product Organization
Team Factors to Consider First
Before putting product organization design into practice, Chief Product Officer should consider the culture of your company and what your talent base realistically supports.
Think about the skillset of your team. What’s the experience level of the team members? How would you define 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?
No organizational structure will be set up for success without considering those factors as part of the thought process. If you don’t think about what your product organization can accept and support, you’ll quickly end up with a failed structure.
Start with a “Plan on a Page”
After you have an understanding of your team, culture, and what your product portfolio is trying to accomplish, lay your foundation with a “Plan on a Page” framework.
Cory adopted the Plan on a Page framework from his earlier days at PayPal as a way to think about the various components and purposes of an organizational structure. Think of it like a playbook for setting up your organizational design.
This is a system that Cory’s used over and over again throughout his career, and it works for companies of all sizes, ranging from 10 to 250 people teams. His tried and true template lays out the key components that align back to the shared vision, all on one page.
The key components of your Plan on a Page:
- Vision and mission
- Key bodies of work
- Deliverables and outcomes
- Cascading jobs to be done
Your Plan on a Page is deliberate alignment across your teams on the work that you do, why it matters, and how to measure it.
Try it out yourself! Download the Google Sheets template to create your own Plan on a Page.
Automate your Plan on a Page in Dragonboat
Portfolio Planning + Collaboration
After re-organizing your teams and perfecting your product organization design, the work, of course, doesn’t stop there. Your teams have to be able to continuously collaborate and work together because as we know, product is not built by one person or one team.
Regardless of your organizational structure, portfolio planning is always needed in order to achieve your goals.
Streamline Your Plan on a Page with a Tool
Ready to move off spreadsheets? Dragonboat is collaborative and easy to use like spreadsheets, but with beautiful visualization, automated tracking, and seamless integrations with tools like Jira, Clubhouse, Azure DevOps, and Asana to keep your team in the know.
Check out Cory’s Plan on a Page in Dragonboat:
Dragonboat clears the clutter; aligns stakeholders, spots dependencies, and runs planning and tracking with ease. With OKR roadmapping, multi-dimensional planning, portfolio allocation, automated roll-ups, and cross-functional collaboration, you can seamlessly ensure that your work is always tied back to the product vision and company goals.
Beyond planning, Dragonboat gives you a birds-eye view into the entire portfolio to understand how your team’s work and metrics are progressing towards your goals. This insight allows you to dive into areas that are under or over-performing and responsively reallocate resources to drive the most impactful business results.
In the example below, you’re 65% towards your quality and speed goal with only 26% of your initiatives complete. And you’re only 9% towards your prototyping and experimentation goal with 62% of your initiatives completed. This gives you the insight to make a decision on whether or not to reallocate resources from the goal you’re on track to achieve to the goal you may miss. And this can happen in real time while there’s still time to adjust and replan.
