post

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

mission statement

Deep dive: Crafting your product vision and mission

Podcast

Connecting fans to creators at Spotify (Dariusz Dziuk, Product Lead, Spotify)

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

Join us at #mtpcon London in 2025 – mark your calendars

How Google makes AI work at Enterprise scale – Miku Jha (Director, AI/ML and Generative AI, Google Cloud)

5 ways to invent and simplify as an AI/ML product manager

Why teams often struggle with OKRs: A conversation with Jeff Gothelf

Building your own user experience and software stack: This week’s product news

Panagiotis Goros is the VP of Product at Dialectica. He has over 20 years of professional experience in technology companies, having worked across multiple industries, in both enterprises as well as startups.

VP Product

Panagiotis Goros

The world is full of examples of well engineered products that have failed to make an impact. What is common to them is that they failed to resonate with customers because they lacked the delight factor &#8211; the capacity to offer delightful user experiences.
Such products can feel like a collection of features rather than a product with a focused value proposition. Or if this is not the case, it may be that their value proposition is based on weak assumptions that do not hold true in real life.
I think that the way that product teams are organized can contribute hugely to this problem.
This is because product development teams are often optimized around software delivery or optimal resource utilization. In a poor interpretation of what Agile really is, teams in many organizations are set up to to focus on delivery and miss product discovery.
<h2>What&#8217;s the Problem?</h2>
The problem is that you get what you optimize for.
If you optimize for software delivery and optimal resource utilization then (in the best case) you will get exactly that.
What you are not guaranteed to get, is an extraordinary end-to-end customer experience.
Take this example. In a company where there are multiple product development teams and each one has a product manager, there is a meeting about a feature that touches many product areas. More often than not, there will be many product managers present, each one standing up for their own product area of responsibility.
But who among them truly owns the end-to-end user experience?
This statement by computer programmer Melvin Conway in 1967 is very relevant (it’s known as <a href="https://en.wikipedia.org/wiki/Conway%27s_law" target="_blank" rel="noopener noreferrer">Conway’s law</a>):
<blockquote>Organizations which design systems&#8230; are constrained to produce designs which are copies of the communication structures of these organizations.<cite>Melvin Conway</cite></blockquote>
In our example that would mean a user experience that mirrors the communication mess between different teams. If there is no true ownership of the user experience then the result will most probably be a disjointed product, like taking multiple pieces and stacking them together.
If you optimize for software delivery, the product development teams may be efficient, have optimal resource utilization, and produce clean software quickly. However that will not matter if they are not building the right thing.
<h2>Organizing Around Customer Experiences</h2>
An alternative worth exploring is to focus product teams on producing exceptional customer experiences.
There are two basic ingredients needed for this. The first one is cross-functional teams with skills that span components and technologies, also known as feature teams. Such teams should be responsible to take ideas from inception to validated customer value.
There is a second element that is often missed. Note that I did not say “from inception to implementation”. In many organizations an addition or change to the product is considered completed when it has been designed, coded, tested, and delivered to production. But just because a feature is in production does not mean that it is finished.
Product managers who think this way miss the understanding of whether that particular feature should have been included in the first place. Is this particular feature furthering the product mission or is it just adding to the feature clutter?
But even if we accept that the original idea was in the general right direction, is the form that it was delivered in the best and most effective one? The truth is that this will not be known until it gets measured.
So, lean startup thinking has a place even in non startups. Using the &#8220;build &#8211; measure &#8211; learn&#8221; mentality to guide product development is a powerful way of iterating towards actual validated customer value.
Going to production should be the first step in order to get the feedback loop working. From there the teams should view their delivered work as an enabler for the discovery phase that will allow them to validate the original idea and optimize the customer experience.
<h2>Practical Issues</h2>
Having teams that touch many product areas and components inevitably leads to many planning and integration issues. Planning and integration may be easy with one product team but it will become exponentially hard as more teams are added to the mix. Dealing with such issues inevitably takes up a lot of time.
There will also be challenges in the technical decisions about individual components. If no team is dedicated to evolve a component, then who has its technical ownership? There is a danger that, in a complex setup of many teams and even more components, the evolution of individual technical areas will follow a Frankenstein pattern, where every team adds what they need to each component they touch until it becomes non-maintainable.
In addition, if two separate teams work on two different experiences there is the possibility that there will be different approaches on how to deal with specific features in the product. Product managers should be proactive in their communication and constantly in sync so that they can take joint decisions early on such issues.
All this means that, in order to optimize for user experiences, teams will have to sacrifice some of the efficiency in delivering software.
It’s important to bolster horizontal communication and push for constant inter-team synchronization so that issues can be addressed early. Product architects who work in cooperation with the teams will need to drive the hard decisions about how the architecture of each component will evolve. Horizontal functional groups will need to be formed so that expertise and best practices can be spread across teams. Product managers will need to make sure that they over-communicate and are constantly aligned with their peers. And all this takes time.
<h2>Is There a Silver Bullet?</h2>
There is no universal organizational setup that works everywhere. Anyone who claims that they have a “best-practice” product team setup that can be blindly adopted is either misinformed or lying.
You have to go through the hard work of discovering the best setup for your organizational context. It is important to have clarity on the purpose that you are organizing your teams for. Are you organizing for delivery? For product discovery? Both? Or are you just copying what someone else did and hoping that since it worked for them it will also work for you? (hint: it probably won’t).
Along with the purpose, there are also many variables that need to be considered: company and department size, company culture and how it has evolved over the years, the presence of experienced people who can assume leadership, and so on. Executive sponsorship is also vital.
You must not assume that once a good setup has been found &#8211; or even one that doesn’t suck &#8211; that you are done. As the company and its people evolve and mature, so will be the optimal setup for organizing their work.
<h2>A Step Further</h2>
One way to think of this would be to treat the exercise of organizing product teams as a product itself.
This may sound like a stretch, but bear with me. Consider the following marketing adage (which I like very much): “People Don’t Buy Products, They Buy Better Versions of Themselves”. In that sense, where the product is the organizational structure and the consumers are the employees, we could draw the analogy that:
“A successful product organizational structure is one that helps team members to thrive and grow in their work while producing better products.”
An interesting proposition. Along with the intentional team setup, there are two elements that need to be present for this to happen.
The first one is the product discovery feedback loop that fuels the “produce better products” part and it starts with a culture of validating assumptions and ideas. To that end, there should be opportunities for product teams to get close to the customers for real end-user validation. Teams should continuously invest in product discovery and validation activities and treat everything as an assumption unless proven otherwise.
The other is an organizational culture that enables the “thrive and grow” part. Products are built by people. And people evolve and mature. As a product leader you have to foster a culture where there the focus is on personal and professional growth. Keep in mind that your &#8220;A-players&#8221; will definitely and relentlessly pursue their growth and they can do it either in your company or in a competitor.
<h2>Is That all?</h2>
Not quite. I said that it doesn’t matter if your teams are optimized for software delivery if you are not building the right thing. While there is truth to this, the reality is a bit more nuanced.
It does matter that you build the product right, otherwise you won’t be able to change it fast enough according to the feedback you get. And changing and iterating will ultimately lead you to build the right thing.
So you need to be focused on delivering extraordinary customer experiences while also striving for delivery excellence. There is no black or white solution &#8211; the best way is somewhere in the middle and will be constantly moving as your company evolves.
In other words, you have to organize your teams so that they can build the right thing and build it right.
Difficult? Definitely. Worth trying? Absolutely.

core/freeform

Reduce risk, fail faster: Experimenting across the product development lifecycle

Why you Should Organize Product Teams Around Customer Experiences

Panagiotis Goros

Read more

Comments