To Be Continuous - Ep. #47, Product Management with Adam Gross

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

Basically, people are either a poet or a librarian. Poets need librarians and librarians need poets. Having a few simple shared metrics that everyone in the organization can understand and keep in their head at all times. 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.

Hi, I'm Paul Berger, founder of CircleCI.

I'm Edith Harva, CEO and co-founder at LaunchDarkly.

And you're listening to To Be Continuous, a podcast about continuous delivery and software development.

You can get in touch with us anytime at our Twitter handle @continuouscast.

The show is brought to you by Heavybit. To learn more, visit heavybit.com. And while you're there, check out their library, home to great educational talks from other developer company founders and industry leaders.

So what do you like best about continuous delivery?

My favorite thing about continuous delivery is the community. That there's so many interesting people working in the space in terms of tools, in terms of processes, in terms of people implementing it and reinventing product delivery organizations. It's just a really kind of fun and interesting area that attracts a lot of good people.

Well, you're certainly somebody who's reinvented many organizations, so now would be a great time for you to introduce yourself.

Sure. My name is Adam Gross. Couple notable facts/trivia questions. I had a startup that was one of the first Heavybit companies. It was called Cloud Connect. And most recently, for about the past 3 years, I served as CEO of Heroku, which is now part of Salesforce.

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

That's an excellent question. I think the way that most people get into product management, at least from more the startup point point of view, which is accidentally and not realizing that they are one. So 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. It was my—

In a galaxy far, far away.

Far, far away. We all had '70s haircuts and there were two suns. It was an early web analytics company and it was me and 2 other people, and I was certainly doing product management then along with others, but truly I don't know that anybody had ever— I'd had a conversation at that point with anybody about like, 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 kind of intersection of a lot of different fields. And, you know, I studied a little bit of computer science, just a tiny bit in school, but I was always more attracted to the kind of, you know, more problems that kind of cross boundaries and the business and the user and the experience and the opportunity and what I now know is product management, but I didn't know that in college that that was a thing. I didn't know it was a discipline until much later. And again, I think that's probably an experience that a lot of people have.

So 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?

Product management can be a lot of different things, and I will use this opportunity to tell a story, which is the kind of two flavors of product managers that I think there are. And I think in my experience of kind 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 kind of most basic management philosophies, which I owe to a former colleague of mine, Trevor Ruble, is this idea of poets and librarians. The idea is that basically people are either a poet or a librarian. Poets need librarians and librarians need poets, but it's always important to know which one you are and which one you need and you're looking for. And 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's gonna make the trains run on time. Content provider is the person who's going to entertain the passengers en route. And both are essential. And I use that somewhat tortured story to say, I think product managers kind of fall into one of those two camps. I think there's always kind of a blend. But in my experience, you tend to have people who are a little more process-oriented and who are really essential at keeping the organization in sync, in tune, making sure that there's a really kind of holistic notion of what the product is and that all the pieces are in place in order to kind of deliver that ultimately for a 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. And yeah, you need both.

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

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

Mm. I mean, yes, I agree with that, but you definitely need a poet before— like, if you're going to have a startup that's innovative anyway, it feels to me that there has to be a poet on board.

I think they could be the same person, but I think where I've seen early-stage, the two-person startup fail is that they're poets and they never ship. They just keep being like, oh, let's keep— it basically becomes their hobby of let's keep adding another feature before we're ready to show it to anybody.

Well, reflecting on my startups, at Circle, I was much more poet than librarian, and we didn't really 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, really good mix. We've talked about this a lot, me and her.

What kind of language do you use to talk about these distinctions?

So this is language I would never use about myself, but it's language that Ellen uses. And she says that 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.

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 kind of contribution to kind of so firmly delineate those, use that kind of language.

So you've been involved in several startups. Do you feel like you were a poet or librarian or both?

Oh, I, you know, I will never admit this, but I'm a poet and only a poet. Like, that's always going to be my kind of 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 kind of complement 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 kind of art and act of getting a whole bunch of people to act collectively as a team is just such an interesting one and is one that— more things they don't teach you in school. Like, where's— you know, there's not a lot of places where I've learned other than doing, well, gee, how do you do that? And what does it look like successfully? And you think of, you know, the delta between success and failure for so many organizations and so many startups. It's just that kind of basic being able to get your act together and the kind of fidelity and quality of discussion that we have as a community around what are good processes and bad processes, how do we kind of 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.

I think there's an allergy in a lot of software engineers. Like 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 sort of thing?

I think everybody has a process.

It's just sometimes a shitty undocumented process that nobody likes because they don't like the process bringers. They don't like librarians to come along and, and tell them their, their poems belong in books.

Yeah, and librarianship rightfully sometimes gets a bad rap if it's done unempathetically, which, you know, 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 kind of frustrated the introduction of processes into those environments. And at the same time, you have the very kind of unique nature of software development as kind of an individual act. And there's a little bit of the single-person myth, hero—

Yeah.

—that is propagated in our culture and our understanding of what it even means to be a startup. That kind of classic heroic organizational behavior that at times is even necessary. So it's understandably kind of confusing.

Adam, I mean, 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 realize now were product managerial?

Yeah, 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 kind of completeness and doneness, kind of very clumsily having discussions around, you know, what represented kind of 1.0, when you ship, when you don't ship. I remember vividly having, you know, pretty heated discussions about what was kind of good enough for 1.0. We subsequently have kind of 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.

Yes, when you started slipping into this, was it a natural thing of, oh, I enjoy this, or was it because nobody else was doing it?

Oh no, it's always where, at least personally, my center of gravity has been, 'cause ultimately it's, here's a, there's a bunch of technology change, and there's a bunch of interesting problems to solve, And how do those ultimately kind of fuse to create something? And what do all those intersection points look like? And something that's kind of come up a little bit more as kind of PM is another kind of branch of this very kind of complicated and amorphous field is then there's kind of another element of that, which is kind of the go-to-market, right, piece, and how those all kind of synthesize into here's a good idea for a thing that can kind of get some loft. Those kinds of problems are always the most fascinating for me. And, you know, just of course, just the raw creativity of it. When you use a beautiful product and the kinds of, you know, just respect you have for its thoughtfulness and how it kind of embodies a— it's a physical representation of an elegant solution to a problem. And I think that's very attractive too. People like us.

Yeah, 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. Yeah. I like building a product. And even though I don't code anymore, I'm still building.

And then this is to confuse our analogies even more, at least for me personally, you kind of get to the stage where what you're PMing is your org organization.

Yeah, well, that was the next thing is like, now I'm, well, I mean, Adam, you have so many great stories. I mean, how did you build a great org? How did you build great product.

I'm trying to like, what are some of the really horrific ones? And, you know, I remember there was an interesting thing that happened in kind of the field of PM-ness. I mean, it's just so fascinating. Like, software development is such a strange and unique art because, especially doing it as a team, because all of the core conditions are constantly evolving. Yes. And If you roughly, clumsily kind of break up the different eras of software product development into decades, you know, in the '90s we had pretty traditional, what we could consider kind of traditional, rigorous, you know, waterfall style modalities, which themselves, just the core act of taking bits and putting them on a CD and, you know, shipping them off to the customer and the kind of nature of that being your product boundary injected or required all kinds of physics in the process that kind of, you know, rippled through the organization. So then in the 2000s, when we moved to what today we would call cloud models, the nature of the product delivery far outpaced our ability to backfill it with kind of new coherent organizationals and ideas and principles for product development, which was why if you think back to the, you know, I think modern PM-ness and, you know, really kind of started, you know, probably like an Eric Ries and what's that like '07, '08 kind of 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, okay, well, we've got to pause long enough at least to rack and stack routers, right? 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. A lot of people just saying, I don't understand what these people do. If we don't, 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, you know, why do we need these people to go interview customers or, you know, be this kind of mechanized ear? You know, these are just wasteful bureaucrats. And that was a dark time.

At best overhead and at worst the pointy-headed boss. Exactly. Yeah.

And then you got this other phenomenon that came after that, which was— and this is what I'd say is kind of maybe the early 2010s mode where people are like, okay, you know, we get that building experiences is hard. Then we had the rise of the hero PM. The hero PM was an artifact of consumer technology companies, where there was the one PM who could— because the PM to user ratio was so high for the first time in PM history, that one PM was representing 10 million users. Their ability to synthesize product direction or experiences out of that, imbued them with this kind of godlike character, and they became idolized. And if you remember, kind of, maybe we go back in TechCrunch 5, 6 years and look at like the PMs at Twitter, right? They all took on this, you know, or Instagram. Yeah, exactly. That kind of like, idled PM thing that it's just this, you know, special magic skill, which I'm glad PMs got more respect, but then I thought it was, then it just became, well, this is irreproducible. You just, you know, lucky if you have a magician on staff. And I think hopefully now we've gotten to a little bit more of a normalized, place, but we're probably missing something that I can't see now.

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

Which is a great thing. I mean, engineers being— 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. As obviously our ability to slice and dice all kinds of user data increases, there's a natural tendency to want to kind of measure more and kind of report more. And the hard thing for— I do think this is a PM's job too, 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. So a classic example is just something like activation rate, right? And so 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, understand 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. Then as a product manager, those engineers start doing, they're aligned 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 kind of old blind implementer mode.

I think it's a sort of artifact of people actually being able to quantify what it was anymore. In the old days, when 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 that that you can have numbers and have, like, direct reports to act on as an engineer, which allows the PMs to a certain extent to focus on higher value. It's really amazing.

It's amazing how much we don't talk about this, right? How totally radically different— Oh, yeah. Mm-hmm. —building software— now I'm talking more like SaaS versus enterprise software and CDs— those practices are as different as like, you know, aeronautics and medicine. And yet we treat them like— organizations treat them as they're largely interchangeable. This fallacy that you can do both or that you can kind of move from one modality to the other. They could not be more different.

Well, I made the transition. I had a really humbling experience last week where I, for whatever reason, I went home and I looked at my LinkedIn profile Mm-hmm.

And does that happen a lot?

That I go home and look at my LinkedIn profile?

That's Tuesdays. Well, that's— sitting at home with a glass of wine and my LinkedIn profile.

So the embarrassing thing is—

how was that experience for you?

Um, all this stuff that I was extremely proud of from early in my career. Um, so like I managed the supported platform matrix. I ran a release a year. Everything that it had put on literally made me cringe. No, it made me cringe with embarrassment because I was like, everything has changed so much. Like, so 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.

I mean, we have it today. We have what version of Android are you supporting? Which browsers are you getting?

Yeah, but it was just like, so I literally, I took a hatchet to my LinkedIn profile. I'm like, it's like all the skills I thought were so great then I'm like, these are all obsolete.

Yeah, but they're, you know, it's pride. You've like, you know, you fought some old wars. You don't retire your medals. You wear them proudly.

I guess. I mean, I can press undelete, but like— Undelete. The stuff I was so proud of, I'm like, that's not relevant anymore.

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 FogBugs, and they talked about the ability, 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 you could have the log and you could go fix it, maybe even before the engineer got it or before the user saw it. And I think this is about 2000 I read this, and it just blew my mind. It was just like, oh, wow, this is how software should be built.

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'm reminded, I don't know what the numbers are now, I remember like learning, I don't know, 8 years ago or something, that the PM to engineer ratio at Gmail was something like 300 to 1. You know, there's like 1 PM. And it's like, okay, well that's not a culture that—

That explains a lot about Gmail.

That does explain a lot. And it's not a culture that values PM. And it's like, okay, that's okay, you know, Gmail is what it is and it's good at what it's good and I use it every day. Maybe that ratio has changed, but you know, you can get by. You know, you can build products.

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

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

I think of them as very different disciplines, but I mean, 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—

It's made it harder 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, well, you know, if these people are designing the screens and, you know, responsible for the experience, then You run the risk of the PM being back to paper.

Well, very often you'll ask a designer what their role is, and they describe it very much as a PM role. As like they're the voice of the— maybe not the voice of the user, but they're the person who understands the experience and designs the experience. And it's like, well, that's a PM role. And how do you decide? How do you split up those responsibilities?

Yeah, I mean, I'd love to hear. So you said before you saw that the PM's role had totally, I'd like to say migrated rather than diverged. How do you think it's changed?

Yeah, I hope that what's happened is that PMs can be part of, you know, relatively small teams that have a lot of autonomy. One positive effect of kind of all these core technology changes and kind of, you know, the, the, just the increased kind of fluidity of things like cloud infrastructure is it makes it easier for there to be more kind of more heterogeneity in architectures and in kind of underlying technologies. 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, you know, 5 years ago, not that long in the grand scheme of things, if you're working on some, pick your favorite SaaS or developer application, you probably had to use like a relational data store or maybe a Mongo, whatever. But like your core data primitives were probably set. The idea that a development team of 5, 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 kind of much more constrained technology environment. Today, my hope and my experience, certainly at places like Roku, is 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 that can have— and an eng team as well, but a PM in their own function— 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 kind of decision-making and autonomy happening at a team level— net a good thing— it can be harder for the PM to have repeatable processes that they're inheriting from the organization that helps them make them successful. I found this cuts both ways. You can have a PM who in some ways represents the kind of 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, you know, just heterogeneous between the teams that because you have a very kind of local team environment, you haven't created standardization from. So there's a balance between in the kind of modern technology, milieu, how you ultimately construct these teams and I think set them up to be successful.

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

That's a good question. I don't think I started at Heroku in late 2013 and I don't, you know, developer, 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. And 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, you know, it was a process of helping the organization understand what that role is, and we had to, you know, untangle a lot of stuff, like what's the PM's role in architecture decisions? Yeah. And, you know, some of these things can have a pretty meaningful impact on user experience or capability. 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 kind of repeatable model for what the PM can be in a function like that?

So how did you untangle that? I mean, I certainly was on the other side of it of some people expected a PM to basically— they were at the level where they were doing object diagrams, and I thought that was a huge mistake. And other PMs were basically there and they're like, I don't really know what the product does. I just show up for work every day.

One of the things that I certainly instituted follows both my style and it's something that I would do again is to really have the PM lean on communication skills. That the PM's job at its most bare is to represent the kind of North Star of the product. And be able to kind of 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 can think of, I'll pick a random product that we worked on, maybe like Apache Kafka on Heroku or Heroku Connect, a product I was intimately involved in. If the PM can't communicate clearly where this product is going, including the uncertainties, then the likelihood that that team knows where it's going and that this thing even has a kind of reasonable direction versus is just kind of circling around is— that's just kind of the ultimate test. So that ability to really be able to think about the North Star, to be able to think about the business problems that you're solving, reasonably be able to connect that to some prioritization of things that you're working on, that for me is kind of the ultimate test.

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

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

Yeah, and I'm a big believer in, you know, the idea of whole product that you'll hear, and that's kind of the responsibility of the product manager is the ultimate success of customers using this thing.

And that's why it's not just a designer.

Exactly. And whatever that entails. There is, at Heroku at least, PMs wrote a lot of documentation. Which 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, is the customer advocate inside of the organization. And that's their job, is they are the person who is the proxy for all the people 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.

One of the issues that I always have with designer as PM or engineer as PM, and you get this a lot in open source, is that fundamentally the designer as PM or engineer as PM, the job that they like to do is they like to code or they like to design. and when it comes down to ensuring or sort of the accountability for that user empathy, it's hard to bring that in when you think of your job as being fundamentally different to that.

I'll say something maybe a little more controversial, because I know that you like something 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 beyond— 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 that you have that you're solving in a useful way. And so 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. But— which is a mistake. It probably is. You know, there are things that are just kind of 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, very different things and with very different missions and very different purposes. And it's that ability to solve problems beyond problems that you intrinsically understand. That is where a PM is so urgently required. And I, 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 yeah, that just that just is a terribly disappointing state for an organization to be in and frankly, a very kind of egocentric place for an organization to be in.

Very many of these, of the open source projects out there are almost diametrically designed in the exact opposite direction from that because there's this expectation that if you're going to want to change, you're going to have to come with the code for it. Rather than having an individual who learns about all the needs that their users have and forms it into some kind of roadmap documentation or whatever, it's like whoever arrives at the pull request, that is an opportunity to go in that direction or to not, but that's the only opportunity you have.

And this is where there— 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 those 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 kind of fantasy of laurocracy, right? Which is just, you know, where in the world we got the idea that this kind of self- organization. And the reason why it's, again, 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, you know, might be able to build. I think at the end of the day, all software development processes are trust management mechanisms. And it's another way of looking at— and I'm a big, big believer that to have an effective software development process, you need to have a high-trust environment. Yes. Because you can't have good teams without high trust. That's so interesting. Yeah. Holacracy is a mode of operating that says trust no one. I would have thought the opposite personally. Oh, yeah.

The assumption is no trust. I totally agree with you on the first part that like I think the best teams are the ones where you have a degree of trust. Yes. I thought the idea of holacracy is that you trust people to self-organize.

Uh, 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 or persuaded 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, 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.

No, I think, I think it's so true. I mean, so much of our company is like, hey, I'm gonna do this, and I trust that you will do this other part.

Mm-hmm. Yeah, and trust is an essential part of team behavior, and either you view what we're doing as a team sport or not. And this again gets back to that. There are many, 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 kind of scale or scope or depth or empathy, I do think you need team trust. Yeah, it's—

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. Like, 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. Hasn't failed.

The James Webb hasn't failed. We're all very, very hopeful that it will succeed. It's being delayed. It's being delayed. My heart would break if it didn't happen.

Oh no, but did you read the same article? I did. And like they talked about like the simple failures, like when they— nobody read the directions when they were assembling it, and then they used on these special valves, and then they used the wrong cleaning solution. Destroy the valves.

Nobody can see this because we're on a podcast. I'm crying right now. Yeah. And then another—

because this thing has to work. Yeah. And then another thing was like they have this very complicated sail, and then in the assembly they put the wrong hooks and eyes together. Like, so like a $500 million sail because somebody didn't line up the hooks and eyes correctly.

I'm glad they caught the problem.

But that goes back to like, you can't trust holacracy. Like somebody has to, like, there's so many failures.

I doubt that Northrop Grumman is a holacracy, but yes, it's, uh, that is complicated stuff. Or as they say, rocket science for sure.

But it wasn't like, I'm like, the failures that happened weren't complicated math. It was literally putting the wrong sails together.

So there's, uh, something that you talked about earlier, the, the, the sort of the idea of, uh, manufacturing versus, versus creative in, in, in software. And I, I think that this applies especially in the open source model, that everyone wants to be a creative and no one wants to be part of a manufacturing line that other people put out there. And as a result, they're, you know, everyone's trying to be creative even if the tasks that they have available for them are manufacturing.

Yeah. Yeah, it introduces another failure mode that I have seen that's kind of interesting where we, you know, our environments are so fluid because the technology is so fluid and so rapidly changing, and, you know, there are a lot of really smart creative people involved in these things, that 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 software companies.

Well, this whole flatness thing went on for several years in the 2011-2012 time where where every company, and Stripe, GitHub in particular, sort of screwed themselves with this— Yes. I forgot, was Stripe holacracy? They didn't call it that. They didn't last long. But it was some sort of flatness thing.

Yeah, greatest minds in our generation lost to holacracy. Yeah.

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

Yeah, they did, of course, brilliantly. But no shortage of pain along the way.

For sure. Yeah, I felt that.

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 lieutenants. You know, as soon as you get to a certain stage of a company, not just for product, but you need people who will just run things.

I find that framing problematic. It's going to happen necessarily in any startup where you have— and I believe in strong founder cultures, obviously. I would want to the greatest degree possible to hope that PMs feel empowered to own, you know, kind of the vision locally. And obviously, I think we've all worked with PMs who are at their best doing so.

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?

I think that's a— the moment, and certainly 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 like, your ideas about— or feature flagging, you're just like, I mean, you cannot, you know, you know, shut your eyes without having a thousand insights into that. And then all of a sudden you really have to transition yourself to your main thing that you're really focused on and passionate about, is how you build and structure an organization, which you're kind of like, I didn't really entirely sign up for that, nor is that my nor 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 in that is that you have those thousands of product insights, but you can't just tell someone else, right? 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 sort of shut your mouth and let them take their jobs and go with it and produce what they're going to produce, even though you can't— even though it may physically pain you in certain occasions.

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

Trust is the worst word. Really? 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, well, you know, we're in a phase of company where there's like trust but verify, or where, you know, 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.

I use the 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. And, you know, its absence or abundance is present. And by not speaking about it explicitly, we're not able to kind of resolve those issues. And we see its implications in a thousand organizational misbehaviors. And— I'm not saying that there shouldn't be trust, but it's the word. But explicitly, like, I think talking about it— I mean, there's a better word, God bless, but like, 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 kind of like saying, and I don't mean to beat up any of this too much, but like, you know, I'm not going to use the word performance in talking about my code. It's like, you know, because the word is— has a million— performance means a thousand different things. Yes, it does. But if we have to have a culture and a way of recognizing this as a value, and so—

Yeah, so I completely agree that you need to be able to talk about it 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 just very, very good at it, and I'm not. Talking about trust and situations in which it needs to improve perhaps, without indicating a whole lot of extra messiness and negativity.

Well, sometimes there is all that. Super hard. Like the worst, the worst, the worst thing I saw was when, um, there's engineering, then there's engineering program managers, there's product managers, there's marketing. And the reason why this was this is the engineering just fundamentally did not trust the product side.

It absolutely You know, involves a fantastic amount of emotion and difficulty, and I would offer and hope that by understanding the relationship between software development practice and trust, you can find a much, much easier way of kind of having those difficult conversations where you don't have to say, you know, 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 whatever kinds of function work together? Frankly, a lot of the kinds of continuous delivery processes and practices we work on are those things. How to do these things. Right. They rely on them. Yeah. In a trusted way with teams. 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 going to kind of, you know, we're doing our job. And a lot of it is how— that's, you know, why we have visibility. That's why I can see what you're doing. All these things are important as well.

And I think that that's exactly it, right? 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.

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

I'm sorry, if somebody came up and said, "Do you trust me?" Don't you trust me? Like you're giving them feedback or direction or something, and they're like, "Don't you trust me?" I would, if I were particularly on my game that day, have the insight to say, "It's not my trust that it'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." That's a solid, solid answer.

That's a high five right there.

Yeah. That's why if it was a particularly good day.

On a good day, yeah.

Normally I would just say, "Get the hell out of my office." Because I said so.

Clear out your desk.

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

I mean, um, yeah, this has been wonderful.

Thank you for entertaining my random musings.

If you have any final takeaways on product management—

there's so much more we can talk about. Oh, anytime. Should we do a closing of my 3 favorite books about product management? Because like, it's— it doesn't— one of my 3 All right, can we— how about we do a real quick lightning round? Favorite books for people who want to be great product managers? Oh my, yeah. I'll open with Innovator's Dilemma, the actual book. As much as the thing's like a cliché as a term, the actual book Innovator's Dilemma is— was one of the most like mind-rattling, like, oh my god, somebody actually wrote down and formalized all the stuff that I kind of intuitively thought. About thinking about the implications of prioritizing different features and products. Amazing, amazing. If you haven't read it, go back. Mm-hmm. Yep. It will rock your world.

That's two thumbs up for me too.

I'm gonna go with Inspired, Marty Cagan'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— He is doing God's work.

In helping create the field.

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 design for engineers. Like, you know, that's how you end up with the classic joke of the VCR with 30 buttons. You know, it's just kind of like everybody shows up with code to check in. Everybody has their button versus thinking about like, I haven't read that.

I'll have to check that out.

Well, he's like, the engineers designed this VCR. Instead of a person being just like, I just want to watch Punky Brewster again or tape The X-Files tonight. Punky Brewster.

Yes. That's all right.

I'm, I'm not, I'm going to pretend I don't know what that is. You surely know what the X-Files are.

There's a lot of millennials listening to this who are like, I've never heard of this.

I dropped Pac-Bell Park in an all-hands and I didn't realize what I'd done. Okay.

That one I haven't heard of.

Oh. Yeah. I'll just— That's what it's called. But that's for a topic for a different day.

OK. So one more lightning round, or any other books? I can do one more.

The Four Steps to the Epiphany. Oh, OK. Classic. Yeah, it taught me how to do customer development. I didn't know there was such a thing. And just that's what startups are. And that book is just fabulous on it.

I'll go super old school. On you guys. Technologies of Freedom, Ithiel de Sola Pool, 1983. Oh, wow.

It's classic. I actually like a lot of Dan O'Reilly's books just on people are irrational. Mm-hmm. So you can't make all decisions with data. Hmm. And it's kind of a cliché now, but there was this book called Data Crunchers that came out about 11 years ago, and it was the first time that anybody really explained that you could be systematic about stuff like Google Analytics. Awesome. So Adam, thanks so much for coming.

It's been lovely being here. Thank you guys so much.

Thanks for listening to this episode of To Be Continuous, brought to you by Heavybit and hosted by me, Paul Bigger of CircleCI, and Edith Harbaugh of LaunchDarkly.

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.