To Be Continuous: Product Management with Adam Gross

In episode 47 of To Be Continuous, Edith and Paul are joined by Adam Gross, former CEO of Heroku, who explains why people get into product management and how the role has evolved alongside continuous delivery.

ABOUT THE GUESTS

Adam Gross is the former CEO of Heroku and has led marketing and product at Salesforce, Dropbox, and CloudKick.

This episode of To Be Continuous, brought to you by Heavybit. To learn more about Heavybit, visit heavybit.com. While you’re there, check out their library, home to great educational talks from other developer company founders and industry leaders.

TRANSCRIPT

Edith Harbaugh: So, what do you like best about continuous delivery?

Adam Gross: My favorite thing about continuous delivery is the community, that there’s so many interesting people working in this space. In terms of tools, in terms of processes, in terms of people implementing it and reinventing product delivery organizations. It’s just a fun and interesting area that attracts a lot of good people.

Edith: Well, you’re certainly somebody who’s reinvented many organizations. Now would be a great time for you to introduce yourself.

Adam: Sure. My name is Adam Gross. A couple notable facts/trivia questions. I had a startup that was one of the first Heavybit companies, it was called Cloudconnect. And most recently, about the past three years, I served as CEO of Heroku which is now part of Salesforce.

Edith: That’s really cool. So you started off as a product manager, how did you get into product management?

Adam: That’s an excellent question.

There are probably a lot of people, and I’m in this category, who are product managers before they knew what product management was. I started my first company a long, long time ago–

Edith: In a galaxy far, far away.

Adam: “Far, far away.” Yes. And we all had ’70s haircuts and there were two Suns. It was an early web analytics company, and it was me and two other people.

I was certainly doing product management then along with others. But truly I don’t know that anybody had ever had a conversation at that point with anybody about, “This is what product management is,” or was. Which is a shame, and I’m sad about that. Because I’ve always been at the intersection of a lot of different fields.

And what I now know is product management. But I didn’t know that in college, I didn’t know that was a discipline until much later. And again, I think that’s probably an experience that a lot of people have.

Paul Biggar: That’s interesting. I think a very classic definition of what a product manager is, is that intersection of UX and business and tech that you just described. Is that, for you, what a product manager is?

Adam: Product management can be a lot of different things. I will use this opportunity to tell a story. Which is the two flavors of product managers that I think there are.

In my experience of building teams and hiring people in general, it’s really important to be explicit about which kind you’re looking for. One of my most basic management philosophies which I owe to a former colleague of mine, Trevor Rubel, is this idea of poets and librarians. And the idea is that basically, people are either a poet or a librarian.

A different way of thinking about that is there are people who are content providers, and there are people who are process providers in an organization. Process provider is the person who is going to make the trains run on time. Content provider is the person who is going to entertain the passengers on round. Both are essential.

I use that somewhat tortured story to say, I think product managers fall into one of those two camps. I think there’s always a blend. But in my experience you tend to have people who are a little more process-oriented and who are essential at keeping the organization in sync, in tune. Making sure that there is a holistic notion of what the product is and that all the pieces are in place in order to deliver that is ultimately for good customer experience.

And then there are people who are more content-oriented, which is they maybe have a little bit more of the vision. They’re going to have maybe a little more of an experience orientation. They might be more involved in the actual functionality of a given feature.

Paul: This is a super interesting definition to this poets-versus-librarians thing, because I think it comes down to what you need at various stages of startup. You see a lot of startups that have librarians before they’re in product-market fit, and they never hit product-market fit.

Edith: I disagree. I think sometimes you have a lot of poets wandering off in the wilderness. And they never ship anything.

Paul: I mean yes, I agree with that. But you definitely need a poet if you’re going to have a startup that’s innovative in any way. It feels to me that there has to be a poet on board.

Paul: Reflecting on my startups, at Circle I was much more poet than librarian. And we didn’t have a librarian until much later on. And then Jim who took over for me as CEO is an excellent librarian, and it was exactly what Circle needed at that stage. But in my new company, Ellen is the librarian and I’m the poet. And that mix is a really good mix. We’ve talked about this a lot, me and her.

Adam: What language do you use to talk about these distinctions?

Paul: This is language I would never use about myself. It’s language that Ellen uses and she says, “I’m the one with the product vision,” and that, “You need someone with the vision.” And that’s absolutely language that makes me feel uncomfortable.

Adam: I agree with that, yeah. It abdicates the other person’s role, and what I think is the person as the visionary wanting that other person’s contribution to be. To firmly delineate those, and use that language.

Edith: You’ve been involved in several startups. Do you feel you are a poet or a librarian, or both?

Adam: I will never admit this, but I’m a poet and only a poet. that’s always going to be my center of gravity. I’ve become better at being a librarian and I’ve become, as good managers should, more mindful of the kinds of skills that compliment me.

But it’s interesting, I’ve become more interested in librarianship as I’ve advanced in my career and as I’ve been responsible for larger organizations. Because the art and act of getting a whole bunch of people to act collectively as a team is just such an interesting one, and is more things they don’t teach you in school.

There aren’t a lot of places where I’ve learned, other than doing, “Gee. How do you do that? And what does this look like successfully?” And you think of the delta between success and failure for so many organizations and so many startups. It’s just that basic, being able to get your act together, and the fidelity and quality of discussion that we have as a community around, “What are good processes and bad processes? How do we make this all work?”

We will go on endlessly about the different ways of storing a JSON document in a non- or semi-relational data store, and the merits of that pro and con. But as a community we’re not as good about having discussions about what kinds of processes and models and org ideas–

Paul: There’s an allergy in a lot of software engineers. They’re allergic to process and anyone who brings it in and suggests it. I don’t think in functional orgs, but we’ve definitely talked about this before on the podcast, about why engineers are often so against this thing.

Edith: I think everybody has a process, it’s just sometimes a shitty undocumented process that nobody likes.

Paul: Because they don’t like the process bringers.

Adam: Yeah. And librarianship, rightfully sometimes, gets a bad rap if it’s done unempathetically. Which, the unique nature of software development and the fact that it’s ultimately a creative act as opposed to a manufacturing one, I think historically has frustrated the introduction of processes into those environments. At the same time, you have the very unique nature of software development is an individual act.

There’s a little bit of the single person myth, hero, that is propagated in our culture and our understanding of what it even means to be a startup. That classic, heroic organizational behavior that at times is even necessary. So it’s understandably confusing.

Edith: Adam, I’d love to hear some of your stories about, you said you were a product manager but without knowing you were. What were some of the things that you started doing that you realized now are product managerial?

Adam: That’s a good question. I think it’s ultimately, and I go back to my first startup, really trying to define features in a way that had notions of completeness and doneness. Very clumsily having discussions around what represented 1.0, when you ship, when you don’t ship. I remember vividly having pretty heated discussions about what was good enough for 1.0.

We subsequently have all kinds of new language that we can use, like MVP that talks about these product development styles. But all of those are fundamentally product management kinds of questions.

Edith: So when you started slipping into this, was it a natural thing? “Oh, I enjoy this,” or was it because nobody else was doing it?

Adam: It’s always where, at least personally, my center of gravity has been. Because ultimately there’s a bunch of technology change and there’s a bunch of interesting problems to solve. And how do those ultimately fuse to create something? What do all those intersection points look like?

Something that’s come up a little bit more as PM, as another branch of this very complicated and amorphous field, is then there’s another element. That we’re just the go-to-market. How those all synthesize into, “Here’s a good idea for a thing that can get some loft.” Those kinds of problems are always the most fascinating for me. And of course just the raw creativity of it.

When you use a beautiful product and the respect you have for its thoughtfulness and how it embodies its physical representation of an elegant solution to a problem. And I think that’s very attractive to people like us.

Edith: I didn’t get a software engineering degree, I got a classical engineering degree. So I like to think of myself as, I like building things. I like building a product.

Adam: Then this is to confuse our analogies even more, at least for me personally. You get to the stage where what you’re PMing is your org.

Edith: Yeah, well. That was the next thing. I mean, Adam, you have so many great stories. How did you build a great org? How did you build a great product?

Adam: What are some of the really horrific ones, and things that I can remember. There was an interesting thing that happened in the field of PM-ness. It’s just so fascinating.Software development is such a strange and unique art, especially doing it as a team, because all of the core conditions are constantly evolving.

Edith: Yes.

Adam: And if you roughly, clumsily break up the different areas of software product development in two decades, in the ’90s we had pretty traditional what we today consider traditional rigorous waterfall-style modalities. Which themselves, just the core act of taking bits and putting them on a CD and shipping them off to the customer, and the nature of that being your product boundary, injected or required all kinds of physics in the process that rippled through the organization.

So then in the 2000s when we moved to what we would call cloud models today, the nature of the product delivery far outpaced our ability to backfill it with new coherent organizationals and ideas and principles for product development. Which was why if you think back to the modern PM-ness, and really started with probably an Eric Ries and that ’07-’08 timeframe, which is also co-emergent with cloud infrastructure, AWS, stuff like that.

And you’re removing so much of the natural slowness from the system. It’s such an acceleration to not have, “We’ve got to pause long enough at least to rack and stack routers.” Instead it’s just this incredibly fluid, fast environment where you now have ideas about iteration and all these things that didn’t exist before.

I think in the late 2000s there was a revolt against PM. And a lot of people just saying, “I don’t understand what these people do. If we’re not operating on these cycles, we have direct input from our customers because we can see what they’re doing and not doing. Then why do we need these people to go interview customers or be this mechanized ear? These are just wasteful bureaucrats.” And that was a dark time.

Edith: At best, overhead. and at worst, the pointy headed boss.

Adam: Exactly. And then you got this other phenomenon that came after that, which was what I’d say is the early-2010s mode. Where people are like, “OK. We get that building experiences is hard.”

Then we had the rise of the hero PM. And the hero PM was an artifact of consumer technology companies where there was the one PM could– because the PM-to-user ratio was so high for the first time in history, that one PM was representing 10 million users.

And if you remember and maybe go back in TechCrunch five, six years and look at the PMs at Twitter or Instagram, that idoled PM thing. That it’s just this special magic skill. Which I’m glad PMs got more respect.

But then it just became, “This is irreproducible, you’re just lucky if you have a magician on staff.” And I think hopefully now we’ve got into a little bit more of a normalized place, but we’re probably missing something that I can’t see now.

Paul: I think that transition that you described in the early 2000s where people revolted against the PMs was almost the democratization of the of the user data. That suddenly engineers could see user data for the first time themselves.

Adam: Which is a great thing. This is a whole separate topic but I’m a huge fan, and this is something that we absolutely implemented at Heroku, was having a few simple shared metrics that everyone in the organization can understand and keep in their head at all times.

The hard thing ultimately for a PM to do is to measure less and to find the few key things. And I say this because when you do that well, it’s very easy for an engineer to fit that in their head and bake that into their thinking every day. A classic example is just something like activation rate. That means different things, obviously, for different organizations. For Heroku it means, “Have you actually pushed code?”

And by understanding what our activation rate is, understanding how it’s trending, to get an email every day that just has that one number in it or one small set of numbers. It’s really easy for all the engineers to put that in your head. And then as a product manager those engineers start aligning to your goals. Which I think is this new, modern, healthy, symbiotic relationship between PM and eng. I don’t want to say that’s a bad thing, that engineering has so much more involvement. As opposed to just that old blind implementer node.

Paul: I think it’s an artifact of people actually being able to quantify what it was anymore. In the old days, and you’re shipping CDs, do you really know if users are having a bad experience? What does a bad experience even mean?

Whereas now you can measure failure rates, you can measure activation rates, you can measure all these things. you can have numbers and have direct reports to act on as an engineer, which allows the PMs to a certain extent to focus on higher value–

Adam: It’s amazing how much we don’t talk about this. How totally, radically different building software– I’m talking more SaaS versus enterprise software in CDs.

Edith: I made the transition and I had a really humbling experience last week where for whatever reason I went home and I looked at my LinkedIn profile and–

Adam: Does that happen a lot?

Edith: That I go home and look at my LinkedIn profile?

Paul: No, that’s Tuesdays. Sitting at home with a glass of wine and my LinkedIn profile.

Adam: How was that experience for you?

Edith: All this stuff that I was extremely proud of from early in my career, I managed this supported platform matrix, I ran a release a year. Everything that I had put on literally–

Adam: Kids today, they’ll never know.

Edith: No, it made me cringe with embarrassment because everything has changed so much. A supported platform matrix, that was a vestige of you cared about what database people were using, what app server, and you had to manage all this.

Paul: I mean, we have it today. We have, “What version of Android are you supporting? Which browsers are you getting?”

Edith: I literally took a hatchet to my LinkedIn profile because all the skills I thought were so great then, I’m like, “These are all obsolete.”

Adam: Yeah, but it’s pride. you fought some old wars. you don’t retire your medals. You wear them proudly.

Edith: I guess I can press undelete.

Adam: Undelete!

Edith: But the stuff I was so proud of, I’m like, “That’s not relevant anymore.”

Paul: I remember the first thing I ever saw about SaaS, and it was an old Joel on Software article about how they now host, I think it was FOG bugs. and I think they were writing C++ code. They talked about the ability that when a segfault happened, you could log it and know that it happened.

And this is about 2000. I read this and it just blew my mind. It was just like, “Wow. This is how software should be built.”

Adam: Yeah. And it’s interesting how different organizations, and for anybody working on their product management career, building an aesthetic for how different organizations view product management and what that job is, is something that’s helpful.

I don’t know what the numbers are now, but I remember learning eight years ago or something that the PM-to-engineer ratio at Gmail was something like 300 to 1. There’s one PM. That’s like, “Well, that’s not–“

Paul: That explains a lot of it, with Gmail.

Adam: That does explain a lot, and it’s not a culture that values PM. And it’s like, “That’s okay. Gmail is what it is and it’s good at what it’s good at, and I use it every day.” Maybe that ratio was changed. But you can get by. You can build products.

Paul: I think Google is a very specific animal with regard to PM. They have their own school of thought on it. I think it differs from almost anyone else in the industry.

Adam: It’s also interesting how UX and PM have become conflated in a way. I’ve always found that a little bit confusing.

Edith: I think of them as very different disciplines. But I think of the designer as somebody who is responsible for literally the experience Like, “What do people see when they log in?” I think the PM is responsible for the overall–

Adam: It’s made it hard for people to understand the PM role. Because all of a sudden you factor out this design function, which is appropriate obviously. But it’s like, if these people are designing screens and are responsible for the experience, then you run the risk of PM being back to–

Paul: Very often you’ll ask a designer what their what their role is, and they describe it very much as a PM role. Maybe not “the voice of the user” but they’re “the person who understands the experience and designs the experience”. And it’s like, that’s a PM role. How do you decide, how do you split up those responsibilities?

Edith: You said before that you saw that the PM’s role had totally migrated rather than diverge. How do you think it’s changed?

Adam: Yeah. I hope that what’s happened is that PMs can be part of relatively small teams that have a lot of autonomy.

And that in turn gives a team and their PM the opportunity to employ more and different things in order to come up with whatever solution they’re coming up with. So random example is, five years ago, not that long ago in the grand scheme of things. If you’re working on some, pick your favorite SaaS or developer application, you probably had to use a relational data store or maybe an Mongo or whatever.

But your core data primitives were probably set. The idea that a development team of five, 10 people could introduce new data primitives into the solution was probably going to introduce a level of operational risk or complexity that would be prohibitive for the organization. And so you had a much more constrained technology environment.

Today my hope and my experience, certainly at places like Heroku, was that a team can have much more autonomy in what they’re able to effectively vendor into their solutions. Because they can utilize all these new cloud services that companies like ours are making. And as a result you get a PM, and an eng team, but a PM in their own function, with much more autonomy and ultimately creativity and impact than you might have found previously.

The downside to that heterogeneity is that if you have more decision-making and autonomy happening at a team level, not a good thing. It can be harder for the PM to have repeatable processes that they’re inheriting from the organization that helps make them successful.

I found this cuts both ways. That you can have a PM who in some ways represents the local CEO of a business, which is a great and empowering thing. Except when they have to reinvent a whole bunch of non-core functions and processes that are just heterogeneous between the teams, that because you have a very local team environment you haven’t created standardization from.

Edith: What were the ratios that you had when you first started out of PMs to eng, and where did you end up? And how did you try to ensure continuity between the different teams at your prior jobs?

Adam: That’s a good question. I started Heroku in late 2013 and we could go on a whole branch about how developer products are special cases, because it’s the one case where developers are their own customers. And so that further complicates what it means to create a PM culture in an organization like that.

I think in the best possible sense of that, Heroku suffered from that. That our developers were so good at creating products for developers that we had never built a strong PM culture. That’s one of the things I think we were able to do well, and I now think it’s a great place to be a PM and we have a lot of amazing PMs who’ve been hugely impactful there.

But it was a process of helping the organization understand what that role is. And we had to untangle a lot of stuff. Like, “What’s the PM’s role in architecture decisions?” And some of these things can have a pretty meaningful impact on user experience or capabilities.

But at the same time, a PM isn’t an architect, and that’s a failure mode. So how do you avoid that, and how do you create ultimately a repeatable model for what the PM can be in a function like that?

Edith: How did you untangle that? I certainly was on the other side of it. Some people expected a PM to basically be at the level where they were doing object diagrams. And I thought that was a huge mistake. And other PMs were there and they were like, “I don’t know what the product does. I just show up for work every day.”

Adam: One of the things that I instituted follows both my style and it’s something that I would I would do again, is to have the PM lean on communication skills. the PM’s job at its most bare is to represent the North Star of the product, and be able to characterize where the product is on that journey at any time. And be able to articulate that clearly in a group setting, where this thing is.

I’ll pick a random product that we worked on. Maybe Apache Kafka on Heroku, or Heroku Connect, a product I was intimately involved in.

That ability to be able to think about the North Star, to be able to think about the business problems that you’re solving and reasonably be able to connect that to some prioritization of things that you’re working on, that for me is the ultimate test.

Edith: I have a question. Paul, I feel like I’m so interested in product management because I started off as an engineer and then I was a product manager. So it’s something I have a lot of affinity for.

Paul: Yeah. My own path has not been product manager except accidentally. And it’s interesting to hear when people have actual ideas of how it works, rather than me and the many people who just end up in that role without any idea of how we got there or how it is done.

Adam: And I’m a big believer in the idea of whole product. that’s the responsibility of the product manager. it’s the ultimate success of customers using this thing.

Edith: And that’s why it’s not just a designer.

Adam: Exactly. And whatever that entails. At Heroku at least, PMs wrote a lot of documentation. One could argue how scalable that is, but it requires a degree of user empathy. That’s pretty deep. And at the end of the day, the PM is the user’s advocate, the customer advocate inside of the organization.

And that’s their job. They are the person who is the proxy for all the people who are going to use this thing every day, who needs to make sure the, “Why does it work this way?” can always be reasonably answered.

Paul: One of the issues that I always have with designers PM or engineers PM, and you get this a lot in open source, is that fundamentally the designers as PM or engineers PM. The job that they like to do is they like to code, or they like to design.

Adam: I’ll say something maybe a little more controversial. Because I know that Edith likes it when I get a little more controversial. In a way what PMs are, are empathy providers. And if you look at open source projects they rarely elevate themselves to products. Certainly rarely beyond the immediate and passionate interests of the most active participants because they don’t require any empathy in their creation.

And I don’t mean that they’re not thoughtfully designed. I mean, true empathy in the sense of solving a problem in a way that entirely puts yourself in somebody else’s shoes, rather than just being able to think creatively about a problem you have that you’re solving in a useful way.

This can be especially challenging in developer facing companies because we all now naturally borrow from and come from open source communities, where again that PM role can be so frustrating or confusing because there aren’t PMs in open source culture.

Paul: Which is a mistake.

Adam: It probably is. There are things that are just intrinsic to the nature of open source projects that separate themselves from the kinds of problems they’re going to be able to solve, that maybe ultimately doesn’t make it appropriate. But an organization that’s building software, as opposed to an open source community, are two very different things with very different missions and very different purposes.

And I say this with some passion because I think we’ve all seen organizations fall short in their ambition because they are incapable of working successfully on problems other than the ones that they themselves experience. And that is a terribly disappointing state for an organization to be in, and frankly, a very egocentric place for an organization to be in.

Paul: Very many of the open source projects out there are almost diametrically designed in the exact opposite direction from that. Because there is this expectation that if you’re going to want to change, you’re going to have to come up with the code for it.

So rather than having an individual who learns about all the needs that their users have, and forms it into some road map documentation or whatever, it’s like, whoever arrives with the pull request has as an opportunity to go in that direction or to not. But that’s the only opportunity you have.

Adam: And this is where, again, I offer no critique of any open source project for the way it conducts itself. I just say that the intentions of an open source project are distinct enough that you should be very mindful when applying those to a normal and commercial software venture, which if you are charging money or have taken money you are.

And I’ll take a cheap shot at the worst failure mode of this which is this fantasy of holacracy, where in the world we got the idea that this self organization? And the reason why it’s disappointing is because it’s that egocentricity. It’s this idea that I can somehow understand all of the problems completely in a way that I don’t need to trust that somebody else might have some ideas or opinions about how this thing might be able to be built.

I think at the end of the day, all software development processes are trust management mechanisms. It’s another way of looking at it. And I’m a big believer that to have an effective software development process you need to have a high trust environment. Because you can’t have good teams without high trust. holacracy is a mode of operating that says, “Trust no one.”

Paul: I would’ve thought the opposite, personally.

Adam: The assumption is no trust.

Edith: I totally agree with you on the first part. I think the best teams are the ones where you have a degree of trust. But I thought the idea of holacracy is that you trust people to self-organize.

Adam: I look at it differently. I think it’s that, because you don’t trust anybody, you can’t be compelled to do anything. There is no manager that will tell you what to do because managers are untrustworthy. And so because nobody is trustworthy, nobody can be coerced into doing anything. I can only do what I am personally compelled to do.

Edith: Or persuaded.

Adam: Or persuaded to do. Because my default position is, “I don’t trust you. And so I will only do what I agree actively and explicitly,” as opposed to allowing a broader governance of trust that says, “We’re all on the same team, and we’re going to play baseball. And if you throw the ball at me I’m generically going to agree to catch it.” Versus every time the ball is thrown, assess whether or not I like you as a second base person or whatever.

Edith: I think it’s so true. So much of our company is, “I’m going to do this and I trust that you will do this other part.”

Adam: Yeah. And trust is an essential part of team behavior. Either you view what we’re doing as a team sport, or not. And this again gets back to that. There are many modes of operating and organizing software development projects, and not to say there’s one perfect one, but to solve problems of a certain scale or scope or depth or empathy, I do think you need team trust.

Edith: I care so much about this. It’s funny because you talked earlier about how people talk about the right format of JSON and nobody talks about organizations. I think about organizations all the time. There was this article over the weekend about a huge failure of an $8 billion, billion with a “B”, telescope that NASA was having built by Northrop–

Adam: Hasn’t failed. The James Webb hasn’t failed. We’re all very hopeful that it will succeed. It’s been delayed.

Edith: It’s been delayed.

Adam: My heart would break if it didn’t happen.

Edith: I know, but did you read the same article?

Adam: I did.

Edith: They talked about these simple failures when nobody read the directions when they were assembling it, and then they used these special valves and they used the wrong cleaning solution and destroyed the valves.

Adam: Nobody can see this because we’re on a podcast. But I’m crying right now. Because this thing has to work.

Edith: And then another thing was they have this very complicated sail, and in the assembly, they put the wrong hooks and eyes together. So a $500 million sail because somebody didn’t line up the hooks and eyes correctly.

Adam: I’m glad they caught the problem.

Edith: But that goes back to, you can’t trust holacracy. Like, somebody has to. There are so many failures.

Adam: I doubt that Northrop Grumman is a holacracy, But yes that is complicated stuff. Or as they say, rocket science for sure.

Edith: But it wasn’t. The failures that happened weren’t complicated math. It was literally putting the wrong sails together.

Paul: So there’s something that you talked about earlier, the idea of manufacturing versus creative in software. And I think that this applies especially in the open source model.

And as a result everyone’s trying to be creative even if the tasks that they have available for them are manufacturing.

Adam: Issues is another failure mode that I have seen that’s interesting, where our environments are so fluid because the technology is so fluid and so rapidly changing, and there are a lot of really smart creative people involved in these things. They end up wanting to take that creativity and apply it to how they’re organizing themselves, and they view it as part of their job to invent new ways of organizing–

Paul: The whole flatness thing went on for several years in the 2011-2012 time. Where every company, Stripe and GitHub in particular, screwed themselves with the fantasy of–

Adam: I forgot. Was Stripe holacracy?

Paul: They didn’t call it that. But it was some sort of flatness thing.

Adam: Yeah. Greatest minds in our generation lost to holacracy.

Paul: Well, they seem to have made it out the other side.

Adam: Yeah, they did of course. Brilliantly. But no shortage of pain along the way, for sure.

Paul: Yeah, I felt that.

Edith: Well, it’s funny, because at the beginning you talked about poets and librarians. We used to call it the innovator’s dilemma. Where you have the visionaries and the lieutenants. As soon as you get to a certain stage at a company, not just for product, but you need people who will just run things.

Adam: I find that framing problematic. It’s going to happen necessarily in any startup where I believe in strong founder cultures, obviously. but I would want to the greatest degree possible to hope that PMs feel empowered to the vision locally. And obviously I think we’ve all worked with PMs who are at their best doing so.

Paul: So when you’ve got that innovator culture, the founder culture, and now they’re starting to bring in PMs and you’re trying to provide them with the local trust, but you’re also trying to provide that holistic vision about what the product should be. How does that work?

Adam: I think that’s the moment most if not all founders I’ve talked to at some point have that realization that ultimately what they’re PMing is the org itself. And it’s a very unique challenge. Because let’s say you’re just unbelievably passionate about container virtualization, and you are just–

Edith: Or feature flagging.

Adam: Or feature flagging. You cannot shut your eyes without having a thousand insights into that.

Which you’re like, “I didn’t entirely sign up for that, nor is that my North Star, but this is what I need to do to be successful.” That transition is one where it’s very important to be supporting startup leaders because it’s real challenging.

I mean, the hardest thing that I found is that you have those thousands of product insights. But you can’t just tell someone else, you can’t just tell them what their job is. and of course they’re not having the thousand product insights because they haven’t been living and breathing it as you have for years.

And so now as a leader you have to shut your mouth and let them take their jobs and go with it, and produce what they’re going to produce, even though it may physically pain you in certain occasions.

Adam: And, to get back to a theme I like talk about a lot, trust. How do you as a founder trust these random PMs?

Paul: I hate the word “trust”.

Edith: I love the word “trust”.

Paul: “Trust” is the worst word. It has so many meanings. There’s no way that you can tell someone that you don’t trust them.

There are versions where you’re like, “We’re in a phase of company where there’s trust, but verify,” or where, “I want to see what you’re doing before we maybe commit the whole company to it.” But you can’t use the word “trust” to describe that.

Adam: I use that word very explicitly because I don’t think we talk about it enough in organizations, and I think it’s present in a thousand different ways and unspoken, it’s absence, or abundance, is present. And by not speaking about it explicitly we’re not able to resolve those issues. And we see its implications in a thousand organizational misbehaviors.

Paul: I’m not saying there shouldn’t be trust, but it’s the word.

Adam: But explicitly, I think talking about it– maybe there is a better word, God bless. But I think we should be using organizational psychology language more actively in talking about our teams, so that we can become better at building teams.

It’s like saying, and I don’t mean to beat up on you too much. But I’m not going to use the word “performance” in talking about my code. Because the word “performance” means a thousand different things. Yes it does! But we have to have a culture and a way of recognizing, “This is of value.”

Paul: I completely agree that you need to be able to talk about that, and that it’s important. The issue that I have with the word or with how people discuss it is that it’s almost impossible to. Or perhaps one needs to be very good at it and I’m not. But talking about trust and situations in which it needs to improve, perhaps without indicating a whole lot of extra messiness and negativity.

Adam: That’s super hard.

Edith: Well sometimes there is all that. The worst thing I saw was when there was engineering, and then there was engineering program managers, there’s product managers and there’s marketing. And the reason why this was this, was that engineering just fundamentally did not trust the product side.

Adam: It absolutely involves a fantastic amount of emotion and difficulty.

Where you don’t have to say, “Why doesn’t person A trust person B?” I wouldn’t want to have that conversation. I would want to say, “How can this process help eng and release management or whoever runs the function work together?” And frankly, a lot of the continuous delivery processes and practices we work on are those things.

Paul: Right, they rely on them.

Adam: In a trusted way with teams. And these are trust frameworks. It’s, “How do we scale a function beyond the ability of an individual to do it, in a way that I can depend on you picking up the ball and have faith that we’re all doing our job?” And a lot of it is why we have visibility. That’s why I can see what you’re doing. All these things are important as well.

Paul: I think that that’s exactly it. The trust is built on things like transparency, and visibility, and accountability and that sort of thing. But to tell my awful story involving trust, was the day that someone asked me, I was their manager, “Don’t you trust me?” And there’s no way to answer that question. If you answer it “Yes,” then you’ve given them a free ride to do whatever the hell they like. You answer it “No,” they’re going to quit.

Edith: All right. So, Mr. Gross, how would you have handled that?

Adam: I’m sorry? If somebody came up and said, “Do you trust me?”

Paul: “Don’t you trust me?” You’re giving feedback or a direction or something and then, “Don’t you trust me?”

Adam: If I were particularly on my game that day, I’d have the insight to say, “It’s not my trust that’s important that you have. It’s the trust of the people on your team.” And that, “My job is to help make sure that you have that.”

Paul: That’s a solid answer.

Edith: That’s a high five right there.

Adam: Yeah, that’s why I said, “If it was a particularly good day”. Normally I would just say, “Get the hell out of my office,” on that. “Because I said so.”

Paul: “Clear out your desk.”

Edith: If it was a video game, a little level up would have happened right then. Well, thank you so much, Adam, for coming by.

Paul: Yeah, this has been wonderful.

Adam: Thank you for entertaining my random musings.

Edith: If you have any final takeaways on product management?

Adam: There’s so much more we can talk about.

Edith: Well, any time.

Adam: Should we do a closing of my three favorite books about product management? How about we do a real quick lightning round. Favorite books for people who want to be great product managers.

Paul: Oh my.

Edith: Yeah.

Adam: I’ll open with Innovator’s Dilemma. The actual book. As much as the thing is a cliché as a term, the actual book Innovator’s Dilemma was one of the most mind rattling, “Oh my God, somebody actually wrote down and formalized all this stuff that I intuitively thought about,” thinking about the implications of prioritizing different features and products. Amazing. If you haven’t read it, go back. it will rock your world.

Edith: Yeah. That’s two thumbs up from me too.

Paul: I’m going to go with Inspired, Marty Kagan’s book. I have to say, I didn’t read the book, but I did his seminar. His seminar was the greatest thing I ever did. I presume that–

Adam: He is doing God’s work in helping create the field.

Edith: It might sound like a designer book, but it’s not. The Inmates Are Running the Asylum by Alan Cooper. Total classic about how engineers designed for engineers. That’s how you end up with the classic joke of the VCR with 30 buttons. Everybody shows up with code to check and everybody has their button, versus thinking about, “How do we–“

Adam: I haven’t read that. I’ll have to check that out.

Edith: Well, the engineers design this VCR, instead of a person being like, “I just want to watch Punky Brewster again,” or, “Tape the X-Files tonight.”

Paul: Punky Brewster?

Edith: Yes.

Paul: All right.

Adam: I’m going to pretend I don’t know what that is.

Edith: You surely know what the X-Files are.

Paul: There’s a lot of millennials listening to this who are like, “I’ve never heard of this.”

Edith: I dropped Pac Bell Park in an all-hands. And I didn’t realize what I’d done.

Paul: That one I haven’t heard of.

Adam: That’s what it’s called, but that’s a topic for a different day.

Edith: Okay so one more lightning round, or any other books?

Paul: I can do one more. The Four Steps to The Epiphany.

Adam: Classic.

Paul: It taught me how to do customer development. I didn’t know there was such a thing. And that’s what startups are. That book is just fabulous.

Adam: I’ll go super old school on you guys. Technologies of Freedom by Ithiel de Sola Pool, 1983 classic.

Edith: I actually like a lot of Dan Ariely’s books on how people are irrational, so you can’t make all decisions with data. And it’s a cliché now but there is this book called Data Crunchers that came out about 11 years ago, and it was the first time anybody explained that you could be systematic about stuff like Google Analytics.

Paul: Awesome.

Edith: So, Adam, thanks so much for coming.

Paul: Yeah, this was great.

Adam: It’s been lovely being here. Thank you guys so much.