061 – Applying a Product Mindset to Internal Data Products with Silicon Valley Product Group Partner Marty Cagan

Experiencing Data with Brian O'Neill (Designing for Analytics)
Experiencing Data with Brian T. O'Neill
061 - Applying a Product Mindset to Internal Data Products with Silicon Valley Product Group Partner Marty Cagan

Marty Cagan has had a storied career working as a product executive. With a resume that includes Vice President of Product at Netscape and Ebay, Marty is an expert in product management and strategy. 


This week, Marty joins me on Experiencing Data to talk more about what a successful data product team looks like, as well as the characteristics of an effective product manager. We also explored the idea of product management applied to internal data teams. Marty and I didn’t necessarily agree on everything in this conversation, but I loved his relentless focus on companies’ customers. Marty and I also talked a bit about his new book, Empowered: Ordinary People, Extraordinary Teams. I also spoke with Marty about: 


  • The responsibilities of a data product team. (0:59)
  • Whether an internally-facing software solution can be considered a 'product.' (5:02)
  • Customer-facing vs. customer-enabling: Why Marty tries hard not to confuse the terminology of  internal employees as customers. (7:50)
  • The common personality characteristics and skill sets of effective product managers. (12:53)
  • The importance of 'customer exposure time.' (17:56)
  • The role of product managers in upholding ethical standards. (24:57)
  • The value of a good designer on a product team. (28:07)

Why Marty decided to write his latest book, Empowered, about leadership. (30:52)

Quotes from Today’s Episode

We try hard not to confuse customers with internal employees — for example, a sales organization, or customer service organization. They are important partners, but when a company starts to confuse these internal organizations with real customers, all kinds of bad things happen — especially to the real customer. [...] A lot of data reporting teams are, in most companies, being crushed with requests. So, how do you decide what to prioritize? Well, a product strategy should help with that and leadership should help with that. But, fundamentally, the actual true customers are going to drive a lot of what we need to do. It’s important that we keep that in mind. - Marty (9:13)


I come out of the technology space, and, for me, the worlds of product design and product management are two overlapping circles. Some people fall in the middle, some people are a little bit heavier to one side or the other. The focus there is there’s a lot of focus on empathy, and a focus on understanding how to frame the problem correctly — it’s about not jumping to a solution immediately without really understanding the customer pain point. - Brian (10:47)


One thing I’ve seen frequently throughout my career is that designers often have no idea how the business sustains itself. They don’t understand how it makes money, they don’t understand how it’s even sold or marketed. They are relentlessly focused on user experience, but the other half of it is making a business viable. - Brian (14:57)


Ethical issues really do, in almost all cases I see, originate with the leaders. However, it’s also true that they can first manifest themselves in the product teams. The product manager is often the first one to see that this could be a problem, even when it’s totally unintentional. - Marty (26:45)


My interest has always been product teams because every good product I know came from a product team. Literally — it is a combination of product design and engineering that generate great products. I’m interested in the nature of that collaboration and in nurturing the dynamics of a healthy team. To me, having strong engineering that’s all engaged with direct customer access is fundamental. Similarly, a professional designer is important — somebody that really understands service design, interaction design, visual design, and the user research behind it. The designer role is responsible for getting inside the heads of the users. This is hard. And it’s one of those things, when it’s done well, nobody even notices it. - Marty (28:54)




Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill, and today I have one of the, probably, the strongest voices in product management, Marty Cagan from Silicon Valley Product Group]. You’re a partner there, and you have a lot of knowledge in this space, which I can’t wait to unleash on our data science and analytics and data product leaders who are listening to the show. So, Marty, welcome to the show.


Marty: Oh, thanks very much. Thanks for inviting me.


Brian: Yeah, yeah. So, I’m going to jump in. I have so many questions to ask you, and we don’t have tons of time so I’m going to go right into it. So, my first question for you is, is there even something there, there in terms of this role of what I’m seeing more of the data product manager or the AI or machine learning product manager that sets it apart from traditional software product management? Is this just a trendy modifier that’s going on, or is there something significant that’s different there that we need to be aware of?


Marty: Well, I would think it’s a little tricky because you can sort of talk about that at two levels. One level, I would argue the principles and what’s hard about product aren’t really different. And whether you’re talking a product manager for a consumer internet service or a product manager for a hardcore enterprise B2B service, or you’re talking about a product manager for a native app, like Clubhouse, for example, or you’re talking about a product manager for a machine-learning-based solution, the principles really are the same. If you’ve got someone who’s good at any one of those, they would probably be good at all of those. [laugh]. 


On the other hand, if you have someone who’s really not prepared for any one of those, they wouldn’t be prepared for any other of those. So, that’s what I think is the overarching dynamic. It doesn’t bother me when somebody says, “My particular interest is machine-learning-based technologies,” or, “My particular interest is mobile-based technologies.” Or one, I talked to somebody just recently who said, “My particular interest is the consumerization of the enterprise, bringing consumer-caliber apps to businesses.” That’s fine because that’s sort of the person’s real passion and interest. But as far as how they do that job, not so much.


Brian: Got it. Got it. Where are the hang-ups, or let’s say you’re leading a data science or analytics team within an enterprise, and you kind of have this itch that product thinking, in general, is missing, let alone titled product owners. And you’re wondering, “Well, do I build this from the staff that I have? Is my job to build some product—to evolve some product managers and train people who I have now who are great at the technology piece? Do I need to bring in outside help?” Where would someone be getting stuck with developing that skill?


Marty: Mmm, big question. So, the first thing I would say, though, is to be very clear on what—you know, this has always been one of the challenges when we talk about data is at the highest level, there’s the two major ways to think about and use data. One is to use data to make decisions, which is really what you were getting at there: you’re trying to teach the organization how to make good choices based on data, or at least largely influenced by the data. And that’s not what we would mean by a data product manager, that would be mostly called data analysts. And these people are there to basically make all the product teams smarter and more effective. 


Now, it’s not just, in fact, the product manager they’re helping; they’re helping the designers, and they’re helping the engineers as well. But that’s great. That’s our—you could say—original use of data. On the other hand, the other big bucket is data to power specific products. So, when you’ve got a product that is literally driven by data—think TikTok, think Amazon Recommendations—then that is—you are now not there to help teams make good decisions, you are there to help power a great product experience. 


So, you are a full-time member of a product team. You might be a product manager on that data product team, you might be a data scientist on that data product team, but you are on a product team and your purpose is to help create an amazing product as opposed to, with the first example, your purpose is to help other teams make good decisions.


Brian: Is ‘product’ the right word when we’re talking about teams working on internally-facing solutions—things for their colleagues or vendors or whatever it may be—is that the right mindset to have that we should think of these things in terms of products, especially if it’s a enabling capability? Let’s take, for example, an experimentation platform. So, you’re trying to use artificial intelligence or machine learning on the website, or some other digital products, and you’re trying to run experiments. Well, in order to even run experiments with that, you need a fair amount of plumbing and enabling technology put in place. Is having a product owner or mentality, is that a smart way to frame that problem, when that’s not something we’re going to be selling, it’s not a piece of commercial software?


Marty: Yeah, good point because you’re really bringing up two different issues. And let me untangle them because they’re both important. The first one is, for example, an A/B testing infrastructure, which is critical for basically any company that I work with. When they’re early-stage B2B, they often can hold off a little bit because they frankly don't have enough traffic to drive anything. But once they do, that’s an important piece of our infrastructure. 


Now, to answer your question directly on that, though, it kind of depends; if we are just using a third party off-the-shelf product like Optimizely or one of your favorites, then no, you don’t need a product manager for that; you don’t even need a product team for that. That is just part of the tooling. On the other hand, if you’re a company that does a lot of this kind of experimentation and you are not satisfied dealing with the limitations of any specific tool and you decide it’s worth your while to build an internal tool to run these experiments for you—which by the way many companies have done so I’m not dismissing that at all—now, then the question is, is it a product or is it internal technology? Meaning, it doesn’t have to face your customers—although in that case, it really does face your customers—but it doesn’t have to be considered a product. The litmus test is straightforward: if it goes down, does it immediately impact your customers’ experience? 


And if you roll out a lot of your changes in an A/B test to make sure things are working as they’re supposed to and that goes down, you’re going to impact customers. So, that would be considered product even though you’re not selling that tooling. On the other hand, if it’s irrelevant, let’s say it deals with your HR staff, you know, it’s a piece of technology that your HR staff uses to track hours or something like that, and if that goes down, none of your customers are ever going to notice, then that is not product and we wouldn’t treat it as such.


Brian: Yeah, I should probably frame this. I know there are teams that they understand that at the end of the road, there is a paying customer who’s usually transacting money in exchange for some type of value, or service, or product, or whatever it may be. They also tend to think of, “I have internal customers,” because so many of these teams service internal users, whether it’s sales, or marketing, or something like that. I think the struggle sometimes is figuring out how do we balance just doing order fulfillment and Jira—“Give me a dashboard for this,” or, “I want some AI that will do X, Y, and Z for me,” versus how do we get the sales team to actually use the pricing that we’ve actually generated with data, and we’re figuring out where does the salesperson get pricing information now? How do they make a quote? 


How do we get them to actually use the data-driven solutions that we’re providing there? And so they tend to see, in this case, the salespeople as being part of their customers. Ultimately, yeah, there’s a paying customer at the end. So, when there’s the poll of other business priorities wanting to have them run on to the next project versus some other project, how do you recommend teams navigate that space when it may require significant technology investment to get to the point that you even have something that theoretically a sales team would even consider using?


Marty: Yeah, well, the first thing I’d get out of the way is, we try hard—and this is a little bit of a pet peeve of mine—but we try hard not to confuse customers with internal employees. Like for example, a sales organization, or customer service organization. Now, they’re important partners, but when a company starts to confuse them with real customers, all kinds of bad things happen. [laugh]. Especially to the real customer because what you’re getting at is, really, prioritization and how do you decide, especially if you’re a platform or an infrastructure team—a lot of data reporting teams are—and you’ve got all these requests coming at you; you’re being—in most companies, you’re being crushed with requests. 


So, how do you decide? Well, of course, your product strategy should help you with that, your leadership should help you with that. Fundamentally the actual true customers are going to drive a lot of what we need to do. So, that’s important that we keep that in mind. But it’s not unusual to feel crushed as a platform team with all of these different requests coming in. 


There is a role called a platform product manager—so this is orthogonal to the concept of whether it’s a data service or anything else; when you have a platform team, and you’re getting lots of these requests from all over, and you need to have a better understanding of the context and you need to have a better understanding of the priority, that’s when these platform product managers are very helpful.


Brian: Do you think—I mean, regardless—and I get the confusion on the terms there. I guess the thing for me is the worlds of design—coming out of the technology space, the worlds of product design and product management are kind of, for me, there are two overlapping circles. Some people fall in the middle, some people are a little bit heavier to one side or the other. The focus there is there’s a lot of focus on empathy, and really understanding how to frame the problem correctly, not jumping to a solution immediately without really understanding the customer pain point. So, is copying the model of this technology product group, is this a good strategy for internal teams to leverage as well, or do they really need to be thinking about it differently?


Marty: You know, what you’re really getting at here, if in your experience you have seen overlap and confusion between a product manager and a product designer, you’re probably talking about what we call feature teams. And unfortunately, a lot of the industry is feature teams, where they’re just there to pound out features. There should be no confusion between those roles; they are very different roles in a true product team. As different, certainly, as an engineer is from a designer, as an engineer is from a product manager. We’re all concerned with very different things and we bring different skills to the table. 


When we talk about product teams, we refer to customer-facing product teams. So, something like, if you’re building amazon.com, the e-commerce site, that would be customer-facing. And then customer-enabling teams. In fact, most at Amazon are enabling teams; these are order fulfillment, and returns, and pricing, and inventory management, stuff like that, and those don’t—actually, your customers never actually see that. 


But if it wasn’t working well, you wouldn’t get anything delivered. So, that would be a problem. Those are the two kinds of product teams. They’re still first-class product teams. Well, two of—those are the two kinds of experience teams, I should say. And then we have a lot of platform teams which provide a lot of the common infrastructure that’s used by both kinds of experienced teams.


Brian: Is there a common trait or characteristic that you see resides in the best product managers that you’ve worked with? I mean, they come out of—at least in my experience, I’ve seen them come out of sales, out of marketing, out of design, out of engineering. And it’s probably not that title that makes or breaks a good one, so I’m curious, do you see some common personality characteristics? Is it just an appetite for learning and being with customers? What is it that that makes a great one?


Marty: Well, yeah, and I pretty much have seen the… engineering is maybe the most common source but they come from all over the organization. And so the background is less important on this role. It’s not like engineering or design, where you get a lot of specific competency-based training. For the product role, it’s different because, sort of by definition, you have to be able to learn a lot of different kinds of parts of the business. In fact, to me, when I interview potential product managers, I’m looking for somebody that’s that’s learned at least two or three of the major functions on a product team, they should have learned, for example, let’s say, how to engineer, how to design, how marketing works, how sales works. 


They should know—they should prove that they have the ability to learn how the different parts of the business really work because the product manager is responsible for two big things: whether the product you ship is valuable—people will use it or buy it, choose to use it or buy it—and viable, which is that it works not just for our customers, but it also works to sustain our business. So, whether it handles the legal issues, the privacy issues, the sales and marketing issues, the financial issues. So, it’s a hard job. I argue it’s the hardest job on a product team, and none of the jobs on a product team are easy. But I think it’s the hardest job, and value and viability are two of the hardest risks that exist on a product team.


Brian: Is there a particular gap area that you think particularly people coming out of the technology space need to learn or unlearn about becoming? Is it the business side, I know from my experience at least, one thing that concerns me, or at least I’ve seen frequently is that designers often have no idea how the business sustains itself. They don’t understand how it makes money, they don’t understand how it’s even sold or marketed. They are relentlessly focused on user experience, but the other half of it is, as you said, making a business viable thing so we can show up tomorrow and increase the value and keep following the mission. And maybe you disagree with that on the designers, I don’t know, but from a tech person standpoint, someone trying to move into this space, is there something they need to unlearn or be ready to change?


Marty: Oh, it’s usually everybody. You know, depending on where they come from, they have a different set of gaps. So, for example, I came from engineering. So, I might have—I did have a head start on the technology side, obviously, but I knew nothing about customers. Even worse than that, I thought I knew more about customers than I really did. 


So, that’s a common problem for somebody coming from engineering. I also knew nothing about the financial side. I had to really study hard to come up to speed on sort of the language of business, not just the language of technology, not just the language of customers. So, everybody’s got different gaps there. As long as the person is willing to put in the effort, this stuff is typically learnable. 


But it does take real—I mean, it really takes two things: it takes the person, the person who’s in that role to be willing to put in the effort, and there is a lot required. But it also generally takes a manager who is committed to coaching you and guiding you on that sort of journey of becoming competent at your job.


Brian: What does someone in an executive leadership group—and again, I’m, I’m framing this probably more from the world of data teams, but how if they’re not necessarily trained in that, but they see, hey, this is an area, we need someone to occupy this role. This is missing here. Is it, bring in outside help, is that the first step? Is it, give this person the ability to experiment and go on their own? If they can’t model the learning, or model the work, how do you recommend someone—how does a business proceed with that?


Marty: Well, what I tell CEOs that are in that situation is that your most strategic hire is going to be this manager of product managers. And I tell them the same thing on the engineering side if they don’t have an engineering leader, but that’s less common. Because without those people, I mean the company is—it’s hard enough as it is without having this. So, this is really step one, make sure you’ve got that person in place because that’s the person then you hold accountable and make sure you either hire the right people or develop those people to the level that they need to be.


Brian: Mm-hm. I want to rewind a little bit back to something you said there. And this gets into, like, knowing what we don’t know [laugh] and all of that, and you said, “I thought I knew customers well, and I didn’t.” So, there was some realization that you had there. Can you unpack that? What is it that you thought you knew about it and then later realized that you didn’t?


Marty: Well, yeah, the specifics in my case—but I could give many, many examples—the specifics where I had worked for ten years as an engineer, building software products for other engineers. So, software tools; so languages, environments, tools. I still love that space, it’s one of my favorites. But when I wanted to learn the product management side, I figured, well, look, I have a huge advantage. We’re going to be building more products for developers. 


I know developers so well. And the person who was coaching me on product was like, “Oh, you think you do, but I’m sure you don’t.” And it was amazing, he said that even though he was from a totally different part of the business. He was coaching as a favor, uh, me to—because my manager was an engineering manager, not a manager of product people. And he was right. 


He said, “Look, you’re not allowed to make a single decision for your product team until after you go and visit some real customers.” And he said he wanted me to visit 30 customers—I was at HP Labs at the time, and it was a pretty well-established company. So, he made two phone calls to salespeople he knew, he wanted me to visit 15 in the US, 15 in Europe. And it only took three weeks. It was a single three-week business trip, and I visited 30 customers. 


And I came back totally changed. I learned that the developers that would be buying our products were so different than the developers that we had in our little bubble in Silicon Valley, right in Palo Alto, right [laugh] across the street from Stanford. We could—it was so ridiculous. When I—I laugh at myself when I think what I thought back then. Because I remember one of the companies he had me visit was Walmart in Bentonville, Arkansas. 


And they are so cheap when it came to hardware; they had this pathetic equipment for their people, their people didn’t have—I don’t think I met anybody that came from the same universities that we were hiring into, and so they had very different backgrounds and technologies they were used to and turned out I really loved—I felt like their problems were much more meaningful to solve than our problems were. So, it’s not that I didn’t think they were worthy problems; they were more worthy, really, but they were so different. It was one of those things, I didn’t even know what I didn’t know. And the person who was coaching me was pretty sure that that’s what would happen. And he was right. And I made friends in both the customer base and also in the sales organization that I leveraged for years. So, this is what a good manager will help you with. They know what you don’t know, they see your blind spots. And that was a big one for me, for sure.


Brian: This whole idea of customer exposure time, I think is so critical. It’s something I advocate for heavily in my own training and stuff with these teams. So, one recurring thing I hear is still the—especially in the enterprise space—it’s getting access to the horse’s mouth: real customer time, real—or end—we’ll call it end-user time, whether that being a paying customer or some internal person. But there’s always another organization in the way or the salespeople don’t want you talking to the—“Don’t scare away my customer,” and all this kind of stuff. Do you have any ideas for strategies to help relieve some of that? 


Is this something where really it’s an executive leadership problem where we want to be customer-centric, but we also don’t want to give enough exposure to the people who are making the decisions with the technology these people are going to live with? How do we break some of those walls down?


Marty: Well, the good news is, this is extremely rare today to run into those objections or blockers. It’s not unheard of, but it’s pretty rare because most leaders have got the memo at this point. This is really the absolute foundation of any kind of modern innovation-based product. In fact, the typical product teams are interacting face-to-face or over Zoom with their customers every single week. So, this is not the objection it used to be. 


Occasionally there is some misguided head of sales, which is not that unusual, actually, but what’s more unusual is that misguided head of sales is reporting to a CEO that has never worked at a product company. So, the combination is there like, “Yeah, you can’t go—we don’t want anybody talking to our customers.” Even way back, I’m reminiscing here when I learned product at HP, they knew—because of the founders, Dave Packard, Bill Hewlett, they understood the importance of connecting engineers with real customers. Now, they also had a very successful direct sales organization that was justifiably protective of their customers. So, they worked out a deal many, many years ago that we had to all abide by, which was any engineer, designer, product manager can go sit and visit face-to-face with customers, as long as they first attend what was actually called at HP, ‘HP Charm School,’ which was a short—naturally, I have to say it was really fun and educational. It was put on by the sales organization to teach somebody like me from engineering that didn’t really know, I didn’t even know what was the right clothes. Do I have to go buy a suit? I didn’t even know anything. And I certainly didn’t know the entourage that goes out there. There are all these people in the sales. It wasn’t just one salesperson, and I didn’t know what they did. And so it was a half-day curriculum that they made really interesting and entertaining, and you just had to attend it if you wanted to go visit customers. And I’ve instituted that myself at companies that I’ve run product at. And so it’s not hard to work out something like that, but I will say there’s very few times that I have recommended to somebody that they find a different company to work at. Almost every case it’s been because of ethical issues in their leadership, but a couple times they worked for a CEO that does not understand this and is completely not open to it. And I’m like, “Well, there’s just no way you’re going to be able to do successful product work here, so best for you to find a company that understands this.”


Brian: Got it. Got it. You mentioned the word ethics. This obviously comes up a lot, particularly in the AI space. And I’m curious, we can kind of say, “Well, ethics is everybody’s job,” right? But if product management is such a critical hire, and it is in a critical role, how much responsibility do they have for the software that we’re using, particularly on the consumer side, that these applications come out the door with some kind of ethics in mind; they’ve been through some type of deliberate process to understand what could be the ethical ramifications of these solutions? Are we shipping too fast and kind of waiting for stuff to hit the fan? I think it’s clear enough work is not being done upfront. Is this an education problem? Is this a culture moving too fast? What’s your take on that?


Marty: I don’t think it’s a culture moving too fast. But I do think it’s very much a reflection of values and culture. And so, for example, I contrast early eBay—that was my last, sort of, real job, with eBay—but the founder, Pierre Omidyar, understood from day one the risk of bad actors on eBay, and from right in the beginning, he designed in protections. In fact, when I joined, there was four main product teams: buyer team, seller team, platform team, and a trust and safety team. The point was, this is front and center; it was part of the ethos of the early company. 


And you contrast that with a Facebook where they just… I mean, I don’t know if it was just negligence or incompetence. I don’t know. But it was, I think, absolutely avoidable. And they’ve continued to cause these problems. So, I think what you’re really seeing is a difference in the principles of the founders. 


The truth is, the problems really do, in almost all cases I see, originate with the leaders—the ethical issues. However, it’s also true that they first manifest themselves in the product teams. And the product manager is often the first one to see that this could be a problem, even when it’s totally unintentional, which is most of the time, it’s unintentional. But that doesn’t make it less bad for children, less bad for society, for the environment. So, we do need product teams and product managers to step up on that. 


You mentioned one thing which I would like to see, I’m hoping we’re starting to see a trend. You pointed out that ethics is one of those things is supposed to be everybody’s job, but it often becomes nobody’s job. And in some companies—Airbnb is a good example—they have a chief ethics officer. And I like the idea of having a stakeholder explicitly responsible for ethics so that the product teams have a partner they could go to and say, “I’m nervous about this. I’m not sure what the consequences will be. I’m not sure we can anticipate what will happen here, and I would love to talk about this with you.” So, having that partner, I would love to see that become more of a standard thing rather than the exception.


Brian: Yeah, I would, too. I know some teams have a sounding board, or they’ll have a separate team made up of people from other departments who have no responsibility to deliver that particular solution or anything, and they kind of play that role as well, so it’s actually living in a diverse team of individuals who—almost an oversight group, but they’re not there to just police, right? They’re also there, I think, to service those requests before they come up, to have that objective lens because they’re not in the trenches all day, they have that fresh viewpoint on things. So, I’m with you there on that. I want to ask you about your books, and particularly if there’s one that you would recommend for this audience. But before I did that, just selfishly, I’m curious, is there one or two things that you’ve learned from all the designers you’ve worked with that have helped you become a better product manager?


Marty: Yeah, I mean, the truth is, my interest is actually not product management. My interest has always been product teams because every good product I know came from a product team. And I’m not saying that to be politically correct; I mean, literally, it is a combination of product design and engineering that generate great products. So, I’m interested in that, the nature of that collaboration and, sort of, nurturing the dynamics of a healthy team. And to me, having strong engineering that’s all engaged with direct customer access is fundamental. 


Similarly, a professional designer, not just somebody who does graphic design, not somebody that just implements wireframes, I mean somebody that really understands service design, interaction design, visual design, and the user research behind it. Because the designer role is responsible for getting inside the heads of the users, to understand their mental models. This is hard. And it’s one of those things, when it’s done well, nobody even notices it.


Brian: Right. [laugh].


Marty: But if it’s not done well, it’s like, “What a horrible product.” And so it’s a hard job. And the product management job is a hard job. So, I don’t know, other than I learned the value of a great product designer early in my career. There was the head of design at Netscape—that’s where I was after HP—but he had come from Apple, Hugh Dubberly. 


He was one of the best design leaders in the world, and he made a big impact on me and sort of showed me—I kind of had the classic engineer perspective, which was, “Oh, I can design an interface. It’s not that hard.” But you start to see the data on the difference between good experiences and most experiences, and you see how valuable it really is.


Brian: Yeah. Yeah. Tell me about your latest book, and if you could share, maybe it’s a particular anecdote or something that stood out in the process of writing it.


Marty: Well, the latest book is called Empowered, and it’s for leaders. The earlier book I had written, Inspired, was for product teams. It’s all about how product teams solve hard problems in ways customers love, that work for our business. To me, that’s what’s fun about product and that is my favorite topic. But what happened was I met a lot of teams and companies—especially as the book spread internationally, I met a lot of places where the teams wanted to work the way good teams work at the best companies, but the leaders were often not allowing them to work that way. 


The leaders had other ideas in their heads, usually driven by where they worked before, none of which were at good product companies. And so what happened was, I realized that just as Inspired shared the techniques of great companies with other product teams, I needed to share the techniques of great product companies with the same companies, for the leaders. And that was missing, so I spent the last few years now focused on the leaders as really the leverage, and so that the leaders provided the environment that the product teams need to do good work. And so it’s a harder topic. I mean, for years I did this as an advisor, and I still do, but leadership topics, honestly are much easier to do one-on-one with a whiteboard and just talking with the leaders. 


And to put it in book form, these are big topics. Turned out to be even a bigger book than Inspired. And it has some hardcore topics, like team topology, and product strategy, and product vision, and team objectives. And so these are not minor topics. And so I didn’t know how many people would have, sort of, the focus and discipline to really think through those hard things. But so far, I’m pretty, I’m pretty happy with how many people have.


Brian: Awesome. Well, that, just to reiterate, the book title is Empowered. That’s your new text. And Marty also has a book called Inspired. Empowered—was Inspired, I forget, was that written with Chris Jones as well?


Marty: No. Although Chris has been a longtime partner at SVPG. He was my first partner, and so, even if he wasn’t a co-author on Inspired, he was a big help on it.


Brian: Yes, yes. Awesome. Well, you can get—if you’re listening, if you want to grab those books, you can do that as the SVPG—Silicon Valley Product Group—.com. They’re the first two links up in the menu, so definitely check those out. And Marty, if someone wants to follow your work, do you have a mailing list, or LinkedIn, Twitter? Where’s the best place to find you?


Marty: Yes. Well, on Twitter, it’s @cagan—C-A-G-A-N, and also on LinkedIn. But the best way, there is a newsletter that goes out once or twice a month with articles. And svpg.com, you can sign up for that.


Brian: Awesome. Marty, thank you so much for coming on Experiencing Data and sharing your thoughts. I appreciate it.


Marty: Well, thanks very much, Brian. I enjoyed it.


This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Subscribe for Podcast Updates

Join my DFA Insights mailing list to get weekly insights on creating human-centered data products, special offers on my training courses and seminars, and one-page briefs about each new episode of #ExperiencingData.