ProductFTW #24: Building Great Product and Tech Relationships

A key component of successful teams

Note: Today, we are featuring a guest post from our friend, Todd Zino. Todd has 20 years of experience leading product, data, engineering, and design functions on both sides of the Atlantic, from seed-stage startups to profitable companies. 

Building a great product requires great relationships across an organization's various builders. This is particularly critical when it comes to the relationship between product and tech roles. Most of us have had experience with conflict in these areas, both the healthy and unhealthy kind! 

As a lifelong technologist who loves building products real customers will actually use, I am unfortunately old enough to remember what it was like to be a manic coder in the days before Product Management became a key part of team structures, let alone everyday concepts like cloud automation, agile process, continuous delivery, and other improvements we now take for granted. 

All of these things have vastly improved the developer experience, but they also require an evolving mindset to ensure that the right bits are being built at the right time with the right resources (people and otherwise).

What, Why, How, & When are a Continuum, Not a Sequence 

The biggest collaborative challenges often come from a mistaken belief that there is a clear separation of autonomous responsibilities to define ‘what’ and ‘why’ (product manager) and then sequentially figure out the ‘how’ and ‘when’ (engineering team). This is immensely disempowering not only to developers but also to product managers.

That “double diamond of design” visual you may have seen only further leads to this misinterpretation – if you merely read it from left to right and assume product wholly owns the first diamond and tech the second:

Image of a double diamond with "Discover", "Define", "Develop", and "Deliver".



In reality, there is a cyclic and codependent relationship across these concepts that require shared ownership and reconciling the “top down” and “bottom up” views of building products. In my experience, I’ve found the biggest wins when there is a shared understanding of current capabilities vs. desired capabilities for prioritizing outcomes now, next, and later. This requires tech and product leaders on a team putting in the time outside of ceremonies or standing 1:1s to really challenge each other on this alignment.

Capabilities and Gears

In the ideal agile world, speed to outcomes and learnings are the “north star”. This assumes that any outcome can be engineered with a few tweaks to an existing resource set (people, codebase, vendor tools) under the remit of the team. Reality is rarely this simple, and often leads to either ‘feature factory’ churn or mounting ‘tech debt’ to achieve the smallest iteration possible that delivers value within one ‘sprint’.

A better approach to product-tech collaboration involves seeing the product lifecycle as a continuous gearset of capabilities and outcomes that can operate as concurrent swimlanes:

Image of a large and small gear working together.

In this model, the ‘small gear’ is the continuously tested, delivered, and measured work that can be done with existing capabilities. The product manager and tech lead on a team are ultimately accountable for keeping this wheel moving fast, but tactical delivery and measurement work can often be delegated to other roles (a specific engineer, an analyst, or a designer) to free up the leads to consider the big gear.

So what is the big gear? This is the team’s capabilities that allow for rapid delivery towards outcomes and better experience or proposition tests. Prioritizing these capabilities requires aligning the “top-down” view of ultimate strategic outcomes (be they OKRs, the mission of the team, KPIs of a business unit) with the “bottom-up” view of effort required, build-vs-buy solutions, external team dependencies, data models, etc. 

A product and tech lead need to constantly harmonize to challenge, propose, and prioritize this view together rather than throwing them back and forth over an imaginary wall between fiefdoms. In my experience, this has been brought to life with collaborative visuals of the current and target ‘product architecture’ (i.e. more focused on data flow and interfaces than the specific microservices and cloud components in a traditional tech architecture), or a RICE model of initiatives that really probes on effort vs reward at different timescales. 

In summary, any team at any level – from cross-functional agile teams to the C-suite of a company doing quarterly planning – should think of the capability changes they want to bet on (big gear) and the iterative outcomes they want to accelerate by continuous delivery, testing, and learning (small gear). All roles across a team (particularly its leadership) have a shared responsibility across these conceptual gears.

Building Good Product-Tech Relationships at Every Level of the Organization

So, how does this shared responsibility manifest itself at leadership levels above and across individual delivery teams?

In a well-designed organization (ideally one that respects Conway’s Law :) ) with enough distinct product delivery teams to warrant layers of functional leadership (e.g., Head of Design, VP of Engineering, Director of Product) below an executive team, there will likely be ‘vertical’ ways of dividing the remit of teams across business areas (e.g., marketing or operations support) or customer needs (e.g., onboarding, retention, or app experience).

These product and tech leaders heading up a functional set of teams need to be aligned on the distribution of resources across those teams and the performance of the people within those teams, ideally using the same capabilities vs outcomes framework I outlined above. 

The gaps in understanding I’ve most consistently observed are:

  1. Product leadership being unaware or unaccountable for ‘back office’ or ‘platform’ engineering teams that have no resident PM (this is a whole topic for another day!)
  2. Tech leadership being unaware of the fundamentals and research that underpins financial growth and market development. 

Improving this calibration requires not only agreement on the strategic goals of their area, but on the gory details of quantifiable effort required vs. the resources currently allocated and the “return on investment” these bigger initiatives will ultimately yield for the business. 

One area that consistently bites even well-intentioned organisations is the selection and integration of vendor tools that enable non-technical teams to build and iterate on customer journeys (e.g. CMS and CRM software tools). This is a great place for product and tech leadership to achieve joint understanding with their senior management counterparts in marketing, operations, finance, etc. and continuously leverage the right tools for the right outcomes in their roadmap.

Closing these gaps requires putting in the work to achieve shared understanding and sense of urgency, whether this comes in the form of workshops, strategy days, or reallocating the right balance of tech and product roles to tackle these ‘known unknowns’.

Advice for aspirational product-minded CTOs or CPTOs

Over the past decade, more organizations have elected to split or combine the executive roles for product, technology, and even data or design on the C-Suite. This has given rise to the role of Chief Product & Technology Officer, which I’ve had the pleasure of serving in at a few scale-ups in the United Kingdom.

There is no right or wrong answer as to whether organizations need one or more roles covering these functional areas, nor does it wholly depend on the industry or stage of the company. It’s correlated a lot more to the vision and skillset of the CEO, and the ideal spread of skillsets and decision-makers at the C level. The CPTO role often works best when there is a clearly shared or mandated vision coming from the very top, and therefore tightly coupled strategy and delivery across the most expensive resource in most digital-first companies (engineers, designers, PMs, data practitioners)

For aspiring CPTOs, my biggest learnings are to: 

  1. Delegate and upskill a balanced senior management team reporting to you
  2. Foster great relationships and ideal team structures at each level
  3. Treat your data, platform, and infrastructure as a product just as important as customer-facing outputs, and apply the same PM and customer mindsets wherever possible
  4. Ensure you balance the strategic needs of your executive peers and ruthlessly focus on ROI across the distributed investment of resources you will be accountable for

And for CTOs who want to really succeed strategically in their role: never adopt or accept a passive role that is restricted to managing delivery costs, speed, or uptime. Whilst all C-Suite practitioners should take a service-oriented customer-first approach not only with the company’s end users but their executive colleagues, it is equally important to be highly engaged in the ‘what’ and ‘why’ and question ‘wants’ vs ‘needs’ when it comes to betting on achieving the company’s vision.

About ProductFTW

ProductFTW is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it.

 

Subscribe to ProductFTW

Don’t miss out on the latest posts. Sign up now to get access to the library of members-only posts.
[email protected]
Subscribe