Where does Product sit?

Where the Product (including UI, UX and UR) function sits in the corporate structure can play a major role in determining a company’s ability to develop and deliver products effectively and therefore become a successful business. Depending on the industry, culture, and lifecycle stage a company is at, some arrangements may be more suitable than others. In this piece, I want to explore four (arguably five)?configurations for organising the Product function and set out some advantages, disadvantages, mitigations and some thoughts on the ideal stages of use.?

I also stick my neck out and say which one works best, based on my own personal experience.

1. Product within the Technology team under a “CPTO”.?

This is a very common set-up in SaaS businesses for obvious reasons: if your product is tech, then ensuring that the wider Software development and Product teams are one team under one C-level exec can make a lot of sense.?For instance:?

?Pros?

• Technical Alignment: Seamless integration with the technology stack, development and delivery processes, and Engineering teams, (as long as measures of success are aligned) can be a sweet, sweet, sweet way of working. With Product/UX and Engineering two-sides of the same coin a team set up like this can really motor along and the cross-functional sparking of ideas makes it. loads of fun.??
• Faster Iteration: Close proximity to Engineering teams allows for quicker feedback loops, and easier cross-functional collaboration. Theoretically.?

• Resource Efficiency: Reducing duplication of roles and resources and reducing (although not entirely eliminating) use of one of my bug-bear phrases “The Business”. ?

But, and it’s a big but. There are potential major Cons?

• Strategic Misalignment: Risk of focusing too heavily on technical issues rather than customer needs. ?
• Innovation Challenges: May prioritise existing technology over new product ideas. This can be?particularly true in later-stage start-ups or scale-ups where growth has been rapid, with priority has been given over in the past to rapid feature delivery. Tech debt could become a huge problem if not dealt with earlier with a robust and sustainable approach, and any later re-platforming, if mishandled, is going to strangle any Product team’s ability to innovate. Scale-ups beware. ?
• Limited Market Understanding: May not have a strong enough customer-centric focus due to being sucked down into an Engineering-led gravity well. This can mitigated by including engineers in customer calls and in product discovery activities.?

• C-level Limitations: Any CPTO is likely to either be a Product specialist OR an Engineering specialist (most often the latter), and not equally balanced over both. This can lead to biases in management approach toward one function or the other to the detriment of the overall business. ?

When to use? ?

Early stage companies where technology is at the core of their product offering. ?

2. Product as part of Marketing under a “CPMO”.?

Going back to the roots of Product Management here...?

Product Management as a discipline (I know you already know this) sprung out of “brand men” in 1931 at Proctor & Gamble via a memo from Neil H. Proctor himself. Mind the Product has a great overview of this if you need to refresh your memory. So, it begs a question, does taking Product back to its origins make sense today? ?

Pros?

• Market-centrism: Strong alignment across customer needs, market research/trends, and competitive intel. Obviously, there are immense potential benefits in?combining market outreach activities and inwards customer and market intelligence.?
• Branding and messaging: Integration with marketing can result in consistent branding and UI/UX?look and feel. In addition, a really deep understanding of end-users drives more effective communication of the value propositions offered and the problems being solved.?
• Go-to-market planning: Improved, nigh on seamless, coordination around pricing and releases of new products and feature enhancements.?
• Customer intel: Marketing teams often have direct access to customer feedback from campaigns, data from website usage, and outreach that can be easily absorbed by Product teams in this structure. Data from the entire customer journey is now all in one place. It’s not hard to imagine how powerful this could be.?

Cons?

• Resource allocation: Potential conflicts in resource allocation between new product development and marketing activities. ?
• Product innovation: May prioritize market-facing tactics over strategic product innovation.?
• Limited technical input: Reduced technical ability in the Product team compared to a Technology-focused structure.?

When to use? ?

Companies in growth stage and those that are more mature, in a crowded market which are looking to stand out by maximising customer awareness, brand presence and messaging.?

3. Product in the Revenue team under a “CPRO”.?

In addition to, or perhaps because of “CPRO” reading like a contraction of a well-known broad-spectrum antibiotic (to me at least), this was the least voted for choice in the poll I posted. I am going to try to be objective here, but I apologise in advance if my biases leak out.?I’ll do my best...?

Pros?

• Revenue: Strong alignment with revenue goals and customer acquisition and retention strategies.?
• Commercial synergy: Collaboration with Sales and Customer Success teams can lead to better, and faster, product-market fit.?
• Customer-centricity: A focus on addressing customer wants/needs to drive revenue growth can be really powerful.?

Cons

Four main ones for me that are all, pretty much, flavours of the same core issue.??

• Tactics v Strategy: Potential tensions between tactical short-term revenue goals and long-term strategic product development, as well as a higher risk of falling into the ever-present spectre of the feature factory. ?
• Bespoke work: There may be an increased risk of larger customers dragging a Product roadmap off into the hell of one-off/bespoke work in the chase towards revenue targets. This is a particularly toxic flavour of the Tactic v Strategy tension above.?
• Product neglect: Risk of underinvesting in product development and software quality should commercial interests dominate.?
• Narrow focus: May prioritise revenue generation, lose sight of the broader market horizon and so fail on the delivery of a coherent product strategy.?

When to use?

Growing businesses aiming to accelerate revenue growth and capture market share from more established competitors. But this may be risky if it's a long-term arrangement.?

4. Product as a standalone organisation under a "CPO".?

This was the winner in the poll which stands to reason given the biases of a self-selected cohort of Product enthusiasts. Having said that, putting Product on an equal footing with Technology, Revenue, Marketing, Operations, etc., does have distinct advantages. ?

Pros?

• Product excellence: A dedicated Product organisation can more easily prioritise product development and innovation without distractions.
• Accountability: A CPO has direct responsibility for product success, providing a clear chain of accountability through them into the whole Product team.?
• Flexible x-functional collaboration: Product teams can work equally closely with all other functions like Engineering, Marketing, Sales, People, etc.?

?Cons?

• Cost: Supporting a separate Product organisation can be expensive. CPOs do not come cheap and then there’s all the other admin overheads associated with a larger C-suite.?
• Isolation: Risk of isolation from other key business functions if not managed well. This may increase the possibility of tensions arising with other teams that ultimately will waste creative energy and slow you down. ?
• Reduced scalability: May struggle to scale efficiently in small or rapidly growing companies. Siloing of Product skills may reduce the likelihood that other teams will jump in to help out in the shorter term. ?

When to use?

Larger, more mature companies that are reliant on product innovation and excellence and have a well-functioning C-suite. Or in smaller companies that value flexibility.

So that’s the four options covered. ?You may disagree with my Pros and Cons, dive into the comments and let me know.

But there is a fifth, as I hinted at the top of this article, that is another version of the CPO case but at the beginning of a company’s journey. It’s not a really a choice as every company has to go through this stage, but I have added it here for completeness.

5.?Product under a Founder?

In tech businesses it’s always (is "always” too strong?) the case that the first Product person is one of the founding team. The idea was theirs and they nursed it through from concept to its first early iterations and customer successes.?Arguably then, a founding team can be viewed as a Product team, albeit a strangely scrappy, and poorly defined one. But that scrappy definition is part of the charm and can be highly effective.?

Pros?

• Strong alignment: A small team all pulling in the same direction, with the same mission, and being tightly bound together enough to air and resolve differences in a relatively constructive way. Fantastic!?
• Easy collaboration: That same small team huddled round shared problems, solving the hell out of it, and shipping cool innovative stuff. This is the model for all high-performing product development teams in any industry.?
• High flexibility: The ability for everyone involved to do a bit of everything saves time, resources and can be super effective, if tiring.?
• In-house ability: When the first Product hire is made then the founding is an invaluable source of customer and market knowledge particularly in the early days of a new Product hire’s career. ?

Cons?

• Code quality: Software quality can be pushed to one side in the name of speed. If you are not shipping clean code from the outset it’s going to bite you on the backside further down the line.?
• Tactics rule: Product development?can be a bit like watching a flock of starlings as product-market fit is chased, pivots are made once or twice (or more), as the first customers are acquired.?
• In-house expert?: Founders can bring their own biases into the Product development process. While in-house experts can be a huge benefit, the answers to Product problems are best looked for outside in the market and customer base. ?
• Letting go: And of course, once the first Product hire is made, the founding team must let go. This is always hard and painful for them?

When to use?

Early stage start-ups or businesses heavily reliant on product innovation. It’s messy, fun, dynamic, fraught with risk, long days and late nights. You will (or should) outgrow this.?

?

My personal view?

Reflecting on my own career in Product and the various companies I have worked at, with different Product arrangements, my view is that Product is most effective when it is tightly bound to Marketing at any stage, whether that is under a CMO or a CPO or CPMO or some other C-level acronym. The initials are not what’s important. What is important for me are the strong connections between brand, customer messaging, value propositions,?market intelligence, customer journey data, acquisition funnels, UX, and an outwards looking viewpoint that is extremely powerful. I have seen this drive considerable commercial success when done well. ?

A very close second would be Product as a standalone organisation. If relationships are functioning well at the top then bringing in a CPO as early as it makes sense to do so can offer the best of all worlds. A standalone Product team can more easily shift focus as a business matures and strategic aims change over time. Alignments with other business units can wax and wane as required and deliver what the business needs, when it's needed. ?In fact, the dream could be a CPO who also owns Marketing.

And third would be Product in a broader Technology team. But with extreme caution if the tech debt burden is high. ?

And finally...

It’s always worth stressing, wherever Product sits within a business, it has to work with all other functions in order to effectively ideate, create, build and ship successful products. Whichever structure a business chooses, ensuring siloless operations is fundamental to the success of a Product function.?

There may not be one absolute right way I don’t think, but there are some that might work better than others at certain stages of a company’s life.

And consider, if you feel your Product team is not smashing it right now, don’t necessarily look to them as individuals to fix things. It's possible that they not are doing anything wrong as such, it could be that they have been put in the wrong place. ?

?

?