Episode 262: Organizing Product Teams Around Value
Creating strong product organizations means aligning teams around outcomes, not outputs, and designing systems that enable learning at speed. In this episode, Melissa Perri brings together insights from multiple product leaders to explore what it takes to anchor on business outcomes, structure teams around value, and build the psychological safety required to learn through experimentation.
You’ll hear from Jose Quesada, VP of Product Management for Mobile and Web at American Express, on why timing matters in transformation, how starting with outcomes changes decision making, and how experimentation only works when teams feel safe to fail. Melissa then expands on how organizing teams around value streams rather than architecture creates better incentives and clearer ownership as organizations scale.
The episode also features Matthew Skelton, co-author of Team Topologies, who connects product thinking with team design, product operations, and enabling teams. Together, these perspectives highlight how structure, governance, and capability building must evolve together if product organizations want to move faster without sacrificing quality or trust.
You’ll hear us talk about:
Starting with outcomes instead of solutions
The discussion explores why leading with vision and desired outcomes creates better alignment than jumping straight to features or roadmaps, and how focusing on what not to do is just as important as deciding what to build.
Psychological safety and learning through experiments
Jose Quesada explains why teams need permission to run experiments that fail, how mistakes build product intuition, and why softer skills matter more than perfect execution in uncertain environments.
Organizing teams around value streams
Melissa Perri breaks down how value streams become the foundation for product team design, covering ownership, reporting lines, and why organizing around architecture often leads to busy work instead of customer impact.
Enabling teams and product operations at scale
Matthew Skelton and Melissa discuss how enabling teams, product operations, and Team Topologies help large organizations manage cognitive load, place expertise effectively, and support long-term product strategy.
Episode resources:
Check our courses: https://productinstitute.com/
Episode 230: Structuring Product Teams Around Outcomes with Jose Quesada: https://www.produxlabs.com/product-thinking-blog/episode-230-amex-product-outcomes-jose-quesada
Episode 260: Avoiding Common Mistakes in Org Design: https://www.produxlabs.com/product-thinking-blog/episode-260-org-design
Episode 211: The Power of Team Topologies with Matthew Skelton: https://www.produxlabs.com/product-thinking-blog/episode-211-matthew-skelton-team-topologies
Jose Quesada on LinkedIn: https://www.linkedin.com/in/josequesadamedina/
Matthew Skelton on LinkedIn: https://www.linkedin.com/in/matthewskelton/
Follow/Subscribe Now:
Facebook | Instagram | LinkedIn
Episode Transcript:
[00:00:00] Melissa Perri: Creating great products isn't just about features or roadmaps, it's about how organizations think, decide and operate around products. Product thinking explores the systems, leadership and culture behind successful product organizations.
We're bringing together insights from multiple product leaders, pulled from past conversations to explore one shared topic, offering different perspectives and lessons from real world experience.
I'm Melissa Perri, and you're listening to the Product Thinking Podcast, by Product Institute.
Today we're exploring what it really takes to build product organizations that deliver anchoring on outcomes instead of solutions and creating the conditions for fast learning. We're starting with Jose Quesada, the VP of Product Management for Mobile and Web at American Express. He explains why transformation is all about timing, how to align teams around a clear vision and business outcomes, and why psychological safety is a must when you're learning through experiments. Let's hear from Jose.
[00:01:01] Start with Outcomes, Not Solutions
---
[00:01:01] Jose Quesada: Just because you can do something, it doesn't mean that you should do it. You really need good timing. The context and the timing of transformation matters quite a lot. Sometimes you may have a great idea to transform your business digitally, but it's not the right time for that. That is a key part when it comes to the success of any transformation.
When you do discovery and when you think about the future, it's not all about understanding what you are gonna do, sometimes understanding what you're not gonna do. It's not like every single idea that you come up with it's gonna prove right. In fact, I'd say that probably means that you're not pushing, you know, enough.
So you need to start with a vision that needs to be ambitious and something that you may want to get to within the next 2, 3, 4, 5 years. From that, you probably need to imerse yourself and your team in data and anyone around you who's got a stake, uh, on what you're trying to achieve. And from there, really come up with some hypothesis on what you want to drive. And ultimately start with, we want to drive this outcome rather than we want to do this thing.
And when you start with the outcome and we want to drive, for example, I don't know, let's say acquisition revenue, that really drives the set of things that come after, which is how do we get there? I think the problem in many organizations or many teams is they start with the what they're gonna do rather than the why and what they want to drive to start with.
So I'll start with really the vision. What is the opportunity or what is the challenge that you want to, address or really exploit, really look at data and come up with that joint statement when it comes to, these are the outcomes that we want to drive. And we start thinking through how you're gonna solve for those, how you're gonna drive them. Just bring your partners along, they need to be there.
So we've come a long way at Amex when it comes to that. So we are very much aligned with business outcomes and really business partners right now. But the two things I would share, one is we enable through that the structure that we've got. So we are really organized around journeys, not around channels, so people have got value streams and they're responsible for a value stream across two channels that is mobile and web. Those teams are more focused on, Short to midterm business outcomes. But we also realized that we need to have a team that sits horizontally who's really responsible for the overall product strategy and is more focused on the future and really keep pushing the envelope when it comes to the experience, the framework that we've got et cetera.
And, that happens to be my team and I'd say that ultimately it's not really about balancing product long term needs with the business and outcome needs. I think those two need to become the same thing, Really. And you can do that through co-creation, alignment of OKRs and really outcomes, which I think that's been an area where we've improved quite a lot, the way in which we do product development by focusing on outcomes rather than um, outputs. I,
[00:03:54] Experiments and Psychological Safety
---
[00:03:54] Jose Quesada: I think you need to be cool with your teams making mistakes. And in a way I'm very happy with sometimes when we run experiments and everything looks red and my team comes to me and they're super worried, I'm like, that's fine. That's the reason why you experimented in the first place. So I really think about test as a way to reduce uncertainty as much as possible. And also there are many times where I see my teams maybe coming up with solutions or strategies that I don't necessarily agree with but I just let them go and do it and make the mistake. Because I just think about when I was starting and that's how I grew as a product manager. That's how I, maybe got the product intuition that I've got right now. And I personally feel quite a lot that softer skills are way more important than hard skills as a product manager, and if you don't let your team make mistakes, they're not gonna be able to grow.
[00:04:41] Melissa Perri: What we just heard from Jose was a reminder that strong product work starts with outcomes, not solutions. Get clear on the vision, anchor in data, and be just as intentional about what you are not going to do. And he also touched on something a lot of teams miss. You need enough psychological safety to run experiments that come back red and treat that as learning, not failure.
Now let's jump to a clip from in previous Dear Melissa episode where I go deeper on the practical side, how value streams can become the organizing principle for your teams and why that matters when you are trying to scale. scale. So
[00:05:16] Organizing by value streams
---
[00:05:16] Melissa Perri: So, when I think about building and structuring product management teams, I like to think in terms of value streams. So what I do is I map out what we deliver to our customers and what value it brings, and then I try to connect it all the way back to the platforms and the people who are building it.
Then we start to think about what's needed to deliver that value and where are our boundaries. So when I'm thinking of the couple different factors around those value streams, I think about ownership. So who's owning the long term and the short term roadmaps? Do we have good coverage over that? Is there a head of product around one of those pieces of value that can really see it through end to end, so that it feels like we can deliver on it fully?
I also wanna look for clear reporting lines to functional leaders, and then there's usually dotted lines back to the business. So product management should go all the way up to the C-suite, into our chief product officer, but in a business line with different divisions usually have a dotted line to a GM or to somebody who's running that business line.
[00:06:14] Don't organize by architecture
---
[00:06:14] Melissa Perri: So then there is the how do we allocate PMs around the problems to solve or around the parts of the product for that ownership.
And usually it manifests in a variety of ways. Two very common ones is to organize by customer. And you would do that when there's clear differentiation in the products or tools that they use. So for example, electronic health records system, sometimes the back office, not doctors and nurses, are using the billing systems.
And they're gonna have very different workflows than the people who are treating the patients, which would use more of a clinical system. So in that way, you might be organized by persona so that everybody has what they need to be able to get things done. Or you could be organized by jobs to be done, which is a very common allocation as well, if there's a lot of overlap in the personas and what they use.
When we talk about jobs to be done, that could be, for example, reporting maybe many different personas, access reporting in different ways, but it's highly customizable or configurable to each one of those personas once they get in there. So when we look at that too, at scale, in larger organizations, it might be both. It might be a combination of it. I've seen it where there is jobs to be done at the top, and then we get into customer's persona orientation as we get further down. It could be a whole host of different ideas like that, but you really wanna make sure that you anchor it back to the value streams and figure out what makes sense for your context.
One thing you do not wanna do is organize by architecture. So when people first started to introduce product managers and product owners out into their company, I saw a ton of companies organizing by architecture. So it was like there is an API, we have to manage that. API, we'll put a PO around it, and what will happen is that the product owner would sit there and try to optimize that API to death and find all this work that would be needed for it just so they could keep their job. Now that API may have been solving a problem, it may have been good to go like a year before, but somebody will always invent work if you put them around every single little component.
So instead, you really wanna think about your value streams, your strategy, and what your product portfolio strategy is gonna be, and that's how you're organizing your teams for scale. There should be good coverage over many components, many technical components from a product manager, so that they have choices and those different areas can be moved to solve different problems in a large swath of a job to be done.
All right, so this served as a good reminder. That structure creates incentives. If you organize around the wrong thing, like components or architecture, you can end up optimizing busy work instead of customer value. Next we'll hear from Matthew Skelton, founder and CEO at Conflux and co-author of Team Topologies on what it takes to support product teams at scale through product operations, team design, and enabling teams.
[00:08:52] Team topologies mindset
---
[00:08:52] Matthew Skelton: really the, all the, the learnings from that movement are really all about, let's find out what the value is, let's get the, let's get the, the changes out of the door as quickly as possible, nice tight feedback loops understanding user needs, all of this stuff, which is the right way to do kind of software delivery and operations, turns out that's basically the right way to do product as well, or it's, it's very, very complimentary. And so we've arrived now where we are today kind of bringing together your work, particularly product operations and team topologies,
and they're coming together. Because I think they're very complimentary, I think, because they've got the same underlying principles. It's start with user needs or start with the value consumer, understand what the value is, set things up in your organization. So it makes it easy to deliver that value in the right way. And rinse and repeat.
Like that's, that's how we do stuff effectively, which for you and me is it's obvious, but turns out for lots of people, it's, it's a very different way of doing things. And
[00:09:51] Product Ops at scale
---
[00:09:51] Melissa Perri: as a concept, I feel like, you know, I've worked with dozens, almost like probably hundreds of organizations at this point and seeing these patterns over and over and over again, when it comes to product management at scale.
And I feel like the biggest naysayers of Of product operations always comes back to they haven't really done this stuff at scale,
right? Like they've never actually tried like, what, you know, we were talking about this a little bit before we jumped on. But like, what if you're the chief product officer of a bank?
Like, I know many CPOs at banks and I work with them and they have 500 product managers reporting up through them. Like, A lot of the pushback I get is, oh, you know, some of this work, it's almost always around the governance and the processes pieces, but, like, I go, oh, you know, that should be the, the chief product officer's job or the VPs job to go and make sure that people know how to write this strategy correctly.
And I'm like, okay, like, when I was at Athena Health, I, you know, Worked with the chief product officer, but I did not expect him to go train our 365 product managers on how to write an Epic in the right format that was going to allow us to roll that up into a strategy that he could interpret and then be able to look at what's our progress towards our business outcomes.
Right. That was my job. I was
[00:11:08] Matthew Skelton: madness.
[00:11:08] Melissa Perri: The product operations person. Like I came in as a consultant, but I became the product operations person. And I said, okay, I'll build the templates. I'll make sure everybody understands this, but I'm going to go around and figure out what's, you know, what's breaking our flow here and help with that transformation.
And I feel like a lot of the work that I've been doing along the way and transformations, when I leave as a consultant, if you don't have somebody. there to take over this, this falls apart, right? Like it's, it's not a swoop in, teach a lot of people stuff. So that's why I transit, like that was the first place I stood up product operations and it was like, okay, this is your job now to take this over.
Cause my work's not done yet. Like. I came in for a year and a half. We made huge progress, but they still have a long way to go, right? They still have platforms and tools and functions to do it. And now, you know, Tim is their head of product operations and he's still going. He's still building out amazing things there, but there's so much pushback, I think, from people who haven't seen this work effectively, especially around those enabling pieces, when it comes down to like process and tools or anything like that.
[00:12:14] Placing Subject Matter Experts
---
[00:12:14] Melissa Perri: Even what you were saying here too, I think it's really interesting because this is a huge debate we get into, in product management, about whether product managers need to be domain experts or from, and I'll, I'll give you an example of it in a second versus know the product really well.
And while I always say there, there are thresholds to that domain knowledge, like, you want somebody to know what types of products you're working on and you want them to be able to learn the domain.
I see a lot of organizations in highly specialized areas, finance, healthcare, for example, insurance, where they will bring people in who have like deep insurance backgrounds and no product management background.
And then they'll run the whole product line because they say, well, they're the ones who know the inner workings of insurance. So they have to build the product. And what I've done is, is pulled a lot of those subject matter expertise out when they don't know product and put them into those complicated subsystem teams, like, you're talking about so that they can advise on the.
Those pieces of, you know, let's say, like, health care, like, what a nurse would need to be able to prescribe or what you would be show an electronic health record system for, let's say, the medicine you're dosing or, like, be able to surface those insights, but they're not necessarily around the entire interface design of a product, or the flow, or the workflow is going to be following.
[00:13:31] Enabling teams in action
---
[00:13:31] Matthew Skelton: Exactly. We're thinking about knowledge. We're thinking about awareness. We're thinking about cognitive load. We're thinking about, yeah, knowledge work effectively and where capability should sit. the other type of team that we talk about in Team Topologies is called an enabling team. And this is often where the expertise would sit. In a complicated subsystem, those experts will be building something like building a, a particular like an, an engine for reporting or an engine for calculation or something for the using experts, their expertise inside that quite specific sort of bit of the product, if you like. But there's another way to use expertise, which is what we call an enabling team. The enabling team doesn't, does not build anything. They're there to uplift the skills and capabilities inside a streamlined team. So let's say they're, they've got some expertise in compliance or in, in yeah, regulatory reporting or whatever. And they're working with a stream aligned team for, let's say a few days or maybe a week or something to help that Stream-aligned team understand how they need to build things in that space. The aim is always to leave that Stream-aligned team independent and not dependent on the experts all the time. So we're going to upskill them, we're going to teach them about this thing, help them understand it better, work with them so they've got a good understanding or better understanding, and then detach if you like, like leave them so that they can be independent again. Or maybe that team detects that we really need some upskilling and need some training. Okay, cool.
Or we really need to actually have a company wide policy of hiring people with increased awareness of a particular thing, like financial regulation or something. We actually need more people with that kind of expertise. Okay. Let's go and hire some more people. They could also detect the fact that like 17 after 20 teams have all got the same kind of problem relating to regulatory reporting, something, something. Okay. Well, we probably need to have a service like an API that all of those 17 or 20 teams can actually call to do this thing because they're all struggling in the same way, then it makes sense to build something in a platform and provide it as a service. So we've got that kind of detection. We've got that, we're, we're looking for these problems that are, that are recurring, but then for which we can have a useful solution from a kind of central API or something like that. There's a really good way, of thinking about things in these terms. This example of how the Teams Topologies language and patterns helps us think through like where we place capability in a dynamic sense. It's not just about like an org chart. It's about how we respond to changing technology regulations business challenges, whatever, how we respond to that on an ongoing basis.
[00:16:06] Melissa Perri: That's it for today. I hope you got some value from this episode.
If you're looking to grow as a product manager or level up, how your team works. Head over to Product Institute to learn more about our programs and resources, and if you want to hear the full conversations, check out episodes 230, 260 and 211. Thank you so much for listening to the Product Thinking Podcast, we'll be back with another episode, sharing practical insights from across the product world.
Make sure you like and subscribe so you never miss an episode. We'll see you next time.