Improving Product Development and Management through Governance: CPO and CTO, Product Engineering and Software Engineering.

In current society, when we hear the term “product” it can mean several things. This can range from the hair care products under the sink in your bathroom to the “products” that you purchase to wash your car. Your car is technically a version of a product. Product(s) exist all around us and are relevant to the industry and target audience they serve. Within the technology and software sectors, the titling can become a bit daunting. Add to that, many are familiar with the Chief Technology Officer (CTO) within their organization but are still acclimating to the Chief Product Officer (CPO). This eventually results in blurred lines related to roles and responsibilities, in organizations where this has not been clearly defined or articulated to internal staffing.

Over the last decade or so, digitization of documentation processes, artwork in the form of NFT and so many other tangible processes increase the need for innovative perspectives surrounding how we work. This is without adding an additional layer of the capabilities extended and improved upon through AI driven innovative solutions. Incorporating a CPO to oversee the development and management of your product portfolio has never been more critical to innovation.

As with any other role, within any layer of an organization, it's important to understand who the CPO is, what they do, how they do it and why they do it, to ensure that you employ the right individual when it is necessary! Further understanding the role will not only help you to employ the right individual, but ensure the need is not rooted in needing more or less from your CTO and will ensure that your organizations avoids the expensive chance of both roles overlapping in responsibilities. Let's discuss the similarities and differences of each role in more depth.

Who is the Chief Technology Officer?

The Chief Technology Officer (CTO) is an executive reporting to the CEO about the development and management of the organizations technology mission and vision. This includes status reporting, as it relates to the progress of strategic technology objectives and the hardware and processes used to support achieving them. They are typically very knowledgable surrounding the industry and relevant competitors. They are also responsible for driving the organization’s technology strategy related to internal technical infrastructure. This includes the technology used to build the products outlined within the scope of building the organization’s “product”. In many organizations, you will hear they are responsible for the “how”. How does the organization achieve successful development of a product, through technical resources.

This does not limit the CTO to internal technical initiatives, however their impact and decision making greatly influences how things get done. This can also include creating technical programs and initiatives for to ensure technical teams remain knowledgable, skill-up, and competitive within their respective domains.

Who is the Chief Product Officer?

The Chief Product Officer (CPO) is a lateral colleague of the CTO within the C-Suite. The title is a newer role that tends to gain more visibility in organizations that want to prioritize software and technology as products, while incorporating customer-centricity. In many organizations you will hear they incorporate the “why”. Many are used to a marketing executive being responsible for the associated tasks required to market a product, however, product tends to handle the entire lifecycle of a product. We'll discuss this a bit more later in this article. This does not remove the need for Marketing, product is definitely not going to market the organization for you. Your marketing executive is responsible for that. However, the channels, methods and guiding principles through which this happens is where you will see both executives thrive best through cross-functional collaboration and alignment, ensuring the principles used within product align with broader organization principles.

The CPO is the executive that is dedicated to ensuring internal structure and logistics for managing an organization's product portfolio. Within product, these teams are responsible for the end-to-end product lifecycle, including setting the initial strategy. In the scope of software and technology, there has been an increased adoption of digital products, increasing the need for CPO’s. The 2023 CPO Insights Report reported that 30% of Fortune 1000 companies employ a CPO. The statistics also show 42% of the CPOs observed, were within the IT Software-As-A-Service (SaaS) industry, with only 19% of them being women across all industries. These numbers are expected to increase greatly as the market continues to innovate.

Supporting Organizational Strategy

Both roles provide similar responsibilities within different scopes to support the organization achieving its over-arching goals. This includes creating and managing the mission, vision, strategy, and downstream dependencies for seeing initiatives through. If the organization employs a Chief Operating Officer (COO), they may collaborate with them for resource allocation and other tasks related to accomplishing set goals from a human and budget standpoint.

The CPO, based on reports, tends to be more prominent in larger organizations managing a product portfolio or product line. This does not mean they do not exist in smaller organizations. However, in a startup, you’ll likely not see both executives, instead you'll see one where their responsibilities and expertise align with the direction the organization is heading in. This raises a need for awareness between the two roles, due to daily operations may include product roles that report up the CTO pipeline, where once an organization scales, they shift the product roles to a CPO to function in a product centered way for their respective product lines.

Within the product domain, many are familiar with the role of product managers in managing technical products, somewhat overlapping with responsibilities of project managers, and even the Head of Product or (VP). If the organization does not employ a CPO, these are the roles that you'll see indirectly reporting up to the CTO’s management team. In organizations with a CPO, the internal organizational structure would look something like below, with their respective VP's and organizations extending, as necessary:

Where it tends to get confusing is when an organization employs product roles that report into the CTO and later incorporates a CPO. From experience, it’s easier to employ a CTO and allow it to function with more traditional roles, like your project and program managers and more common roles responsible for seeing a technology initiatives through. When the need arises, hire a CPO and allow individuals to apply within to the org, or hire as necessary. While, the CPO’s organization, since they are managing the strategy for a group of products that likely makeup a catalog or portfolio of products, it should function more like a smaller organization that focuses on “Product-Led Growth”. Product Led Growth is the practice of letting the product's capabilities do the work of selling, expansion and retention. In, Product-Led Growth: How to Build a Product that Sells Itself, by Wes Bush, it's defined as, "...a go-to-market strategy that relies on using your product as the main vehicle to acquire, activate, and retain customers".

Product-Led Growth is a go-to-market strategy that relies on using your product as the main vehicle to acquire, activate, and retain customers.

The Chief Product Officer's Product Organization

It might seem daunting to think of two executives, responsible for software and technology within a similar scope, seeing things through using separate implementations. That’s the headache they signed up for, what they get paid to figure out, and an upfront headache that will foster long-term success. A few Excedrin’s in the beginning stages is a lot cheaper than the long-term impact of incorrect resource allocation, implementation, and redundant work that does not meet the customer's needs.

Within an organization, where the CPO and downstream direct reports function as a micro-organization, instead of focusing on software engineers with relevant backgrounds in a specific language or stack, you will see a shift towards a product engineer that has this experience, but within a relevant domain. If you’re organization is creating a portfolio of security products, you’d want product engineers that focus on security or are interested in developing a background in security. They are likely experienced with industry competitors, customer pain points, relevant communities, and market research. This applies to the development of products within other domains. If I am developing my own haircare line, yes, I probably am going to need a scientist. Most scientists have similar fundamental training. However, I want a scientist that focuses on dermatology, specific to the scalp and hair. Some might even specialize in different ethnicities or cultures, due to DNA and the impact of nature vs. nurture.

Based on experience, within the product organization exists your typical managers, product managers, product engineers, designers, incorporating other roles like DevOps and QA engineers. No, everyone in the business group won't have product appended to their title, because they specialize in what they do, not a product. However, these individuals at that point in time are responsible for a specific product or suite of products for the entire lifecycle. The lifecycle does not end until the product is deprecated. You are also likely to see “product line” managers, to highlight this fact, or rather, the product they support. The organization may look something like this:

Within the product team(s), you’ll find your product line managers, product engineers, this may include product designers, depending on the structure, and product managers. A director may be responsible for more than one product, with considerations. Due to the structure of the team, and the team being responsible for the end-to-end lifecycle of the product, they are likely required to have a high-level understanding of several of the responsibilities outside of the scope of their role, to better understand how each feed into one another.  

Success Metrics for the CPO

Ultimately the performance of your product, product line, product portfolio will determine the success of your product or broader organization. However, the CPO is still responsible for ensuring the team tracks metrics that are meaningful to their specific business group and in alignment with the broader organization’s metric system. In many organizations today, there is an adoption of Objective Key Results (OKRs) to efficiently set objectives (goals) and track key results in a way that aligns internal strategy throughout the organization, to improve visibility of the status of key initiatives and possible blockers.

This is not to be confused with Key Performance Indicators (KPIs) which are the metrics used to capture business performance of relevant components. OKRs function as a framework to set, manage, and align goals, which should keep you on track and result in improved KPIs, if efficiently structured.

Due to the increase of customer-centricity and engagement with the customer, within the scope of product roles, the CPO will want to remain updated regarding metrics that capture the following growth areas:

Acquisition: Metrics that enables the assessment of acquiring new users. This includes analyzing which channels increase awareness and attract new users towards your product or service.

Engagement: Metrics that capture how much or little your target audience engages with certain products or features of a product. This includes assessing specific touch points to determine when or if something causes them to become more or less active.

Retention: Metrics which capture rates at which users or buyers of your product or service leave for a competitor or stay and remain loyal. This includes assessing the data on the reasoning behind churn rates.

Expansion: Other methods for expanding the purchase of your product or service. This can include referrals, upselling and other methods to increase expansion rates.

This does not mean metrics related to revenue are not important, however, teams that report into the CPO are going to be more aware of metrics that fall into these categories, among others, due to being responsible for the end-to-end lifecycle of the product. This helps to improve iterations on developing new features or even when it is time to deprecate a product or product line, as well as for what reasons.

Final Thoughts

Leading an organization, especially in the software and technology sector is not a simple task. Neither is running a business group of individuals with various roles and responsibilities, working cross-functionally to achieve common goals. Communication, status updates, and so many other components can go overlooked, resulting in missed deadlines or delayed product releases. At a time where the Voice of the Customer is becoming increasingly more relevant and important, it’s important that organizations not only fill roles with the right people, but also fill their tables and seats with the right roles, at the right time. It’s even more important to understand how these roles function together and how they work separately to reduce the chances of redundant, misaligned or overlapping work.

Even more important is being able to express the necessity to direct reports and to ensure they understand how the daily operations of the work they do, tie into and contribute towards the success of the broader organization. When there is clarity, understanding, and assurance, it’s easier to receive buy-in. Buy-in from external customers is important, but internal buy-in from those moving the organization towards success is critical.

If your organization is looking to scale or has scaled and you're executives are overwhelmed while looking to expand your product portfolio, ensure you take into consideration the internal governance structures and the methods of which you communicate it with them prior to!