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 Perry, 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.
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 deeply, but it's not the right time for that.
That is a key part when it comes to success of any transformation.
When you do discovery and when you think about the future.
It's not all about understanding what you're going to do.
Sometimes understanding what you're not going to do.
It's just not like every single idea that you come up with is going to prove right.
In fact, I'd say that probably means that you're not pushing 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 two three, four years, five years.
From that, you probably need to immerse yourself and your team in data and anyone around you who's got a stake 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 going to do rather than the why and what they want to drive to start with.
So I would 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 a joint statement.
When it comes to.
These are the outcomes that we want to drive.
And we start thinking through how you're going to solve for those, how you're going to 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 And web.
Those teams are more focused on short to mid-term 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 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 the 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 outputs.
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 tests 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 going to be able to grow.
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 a 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.
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.
And then we start to think about what's needed to deliver that value and where are our boundaries.
So when I'm thinking of a couple of 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 want to 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 you usually have a dotted line to a GM or to somebody who's running that business line.
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 record 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 customers persona orientation as we get further down.
It could be a whole host of different ideas like that.
But you really want to 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 want to 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 will put a PO around it.
And what would happen is that 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 want to think about your value streams, your strategy and what your product portfolio strategy is going to 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.
Really, the learnings from that movement are really all about, let's find out what the value is.
Let's get 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 software delivery and operations, turns out that's basically the right way to do product as well.
It's very, very complementary.
Yeah.
So we've arrived now where we are today, kind of bringing together your work, particularly product operations and teacher bodies, and they're coming together.
They're very complimentary, I think, because they've got the same underlying principles.
It's start with user need 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.
That's how we do stuff effectively, which for you and me is obvious, but it turns out for lots of people it's a very different way of doing things.
As a concept.
I feel like I've worked with dozens, probably hundreds, of organizations at this point and seen these patterns over and, over and over again when it comes to product management at scale.
And I feel like the biggest naysayers of product operations always comes back to they haven't really done this stuff at scale.
Like they've never actually tried of.
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 VP's job to go and make sure that people know how to write this strategy correctly.
And I'm like OK, when I was at Athena Health, I 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 basically a product operations person.
Like I came in as a consultant, but I became the product operations person.
And I said, OK, I'll build the templates.
I'll make sure everybody understands this.
But I'm going to go around and figure out 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 in transformations When I leave as a consultant.
If you don't have somebody there to take over this, this falls apart.
It's not a swoop in, teach a lot of people stuff.
That was the first place I stood up product operations.
It was like, okay, this is your job now to take this over because my work's not done yet.
I came in for a year and a half.
We made huge progress, but they still have a long way to go, where 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.
What you were saying here too, i think, is 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 give you an example of it in a second versus no 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.
Um, 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 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 those pieces of you know, let's say, like healthcare, like what a nurse would need to be able to prescribe, or what you would be able to show in 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 somebody's going to be following.
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 Teams properties is called an enabling team.
And this is often where the expertise would sit.
So in a complicated subsystem, those experts will be building something like building a particular, like an engine for reporting or an engine for calculation or something.
They're using 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 does not build anything.
They're there to uplift the skills and capabilities inside a streamlined team.
So let's say they've got some expertise in compliance or in regulatory reporting or whatever.
And they're working with a streamlined team for, let's say, a few days or maybe a week or something, to help that streamlined team understand how they need to build things in that space.
The aim is always to leave that streamlined team independent and not dependent on the experts all the time.
So we're going to upskill them.
We would teach them about this thing, help them understand it better, work with them until they 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 out of 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're looking for these problems that are recurring, for which we can have a useful solution from a kind of central API or something like that.
There's a really good way thinking about things in these terms.
This example of how the Teams Apologies 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.
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.
