During this week’s Product to Product episode, Amy Chyan, Product to Product podcast producer and host, chatted with Bryan Clark, Director of Product at GitHub.
As the Director of Product at GitHub, Bryan builds a tool used by millions of users each day. Bryan shared some of the challenges of building a tool for a large user base and how his development background influences his product management style.
Bryan shared a lot of great information and we highly recommend watching the full talk. If you’re tight on time though, we’ve pulled out some highlights below.
Highlights
(The highlights have been condensed and edited for clarity)
How Bryan transitioned from development → design → product (0:17)
Amy: So Bryan is currently the Director of Product at GitHub and previously he was a PM at Mozilla as well as a Designer at Red Hut. Bryan, let’s get right into it. Can you introduce yourself and how you got involved with the product world?
Bryan: Yeah, so I have a degree in computer science. I just wanted to put the snooze button on life for a little while and go for that masters. And then from there I became a designer because I really was focused on the human computer kind of interactions that people have and how people perceive software. I did a lot of extra psych courses and things like that under how people perceive and understand their world. And so I just kind of dove into that and that’s what I did at Red Hut and into Mozilla. I was a designer and then became a Design Manager. And at some point, I think a lot of designers experience this, where you want to get ahead of the curve, often you end up designing things where most of the decisions have already been made, that something has been built by engineers and then they want it to work nice and make it usable and things like that.
I was tired of feeling that way and that’s when Mozilla was really kind of building out their product org. So I took the opportunity to kind of make the leap from even doing management and design and went into product. And I started kind of at the bottom and worked my way back up in Mozilla doing various product management for Firefox, also really trying to figure it out because, and I gave a talk about this at a local product group here in Victoria, how there’s like no school of product management, right?
As designers, there’s design schools, right? There’s excellent schools out there like. Engineering, same thing. Computer science is kind of in that waffley area of like, software engineering. So I remember really struggling as a product manager of like, I’m using a design process, but no one else is, everyone else is doing their own thing. And how do we figure that out, it’s kind of a community thing right now, which I think is really interesting.
The GitHub product team (3:43)
Amy: Can you give us a high level overview of what GitHub does because some people may not know, and how your role fits into the organization.
Bryan: So GitHub, at the most basic level, GitHub works kind of like a Google Docs for developers, right? Developers need a place to coordinate and communicate and share their work with others. So I mean, my day is mostly in Google Docs and that’s where I develop product strategies and other things. And I share that work with others and people comment on it and edit it. And then we deliver those docs or presentations to others in order to kind of communicate and GitHub does that for code.
So software code needs to be stored in one place and organized in a way. And because computers are so finicky about being right or wrong, code really needs to be reviewed and evaluated before it goes into production. And so GitHub kind of addresses all of these concerns by hosting all the code and helping developers through kind of the communication process. As well as it has facilities for issues when you need to file issues for bugs and features and things like that. To track software and all the way into now GitHub offers solutions for continuous integration through our GitHub actions and as well as shipping software out for GitHub packages.
I am a Director of Product. I lead up the GitHub packages team at GitHub and packages is about how you group software that you want to ship into a logical organization kind of thing. It’s like when you want to send out a Google doc or something like that, you have to decide, is it going to be a Word doc or a PDF or something like that? It’s not almost similar to packaging and software, is like, you have to figure out how others are going to consume it, what’s the right way for that to work? And so we offer services like that for people to publish and then other consumers to have the best offering for consuming and updating and doing all those kinds of activities related to software.
Amy: What does your product team look like?
Bryan: Well, so GitHub has its own product org, right? Kind of structure we have is engineering org, which is by far the largest organization at GitHub. Alongside that as product where we also house like docs, marketing and other groups related to kind of product activities. And then my team, we reside in what we call, code to cloud, which is like my larger organization, which is alongside actions. And so there’s kind of a whole group of actions, much larger group, because actions is a much larger product than packages of product managers there.
I have two reports now, four packages team who do various pieces on packages. So if one product manager who focuses solely on npm, GitHub acquired npm this year, that’s on the JavaScript package management system. And then another product manager who’s focusing on the kind of core packaging offering. And I do a lot of that kind of customer interactions, strategy and planning for packages and the code to cloud and action side of the things.
And we are very new. When I joined GitHub almost three years ago, there was no product team. A group of us had to create a product group, like an org from nothing to figure out the process. There were some product managers kind of scattered within GitHub, but it’s all fairly new for GitHub. But we’ve been getting a lot of, kind of Microsoft product managers and others to help it out. So I think going from zero product managers in three years to, I feel like we’re at 150 product managers now.
Transitioning from an org without a product team to a product team (9:05)
Amy: I can’t imagine having a product company with no product managers, but seems so not within the box. I guess people worked very independently then.
Bryan: Yeah. I mean, GitHub, they’ve had product managers over the years, they had this kind of ebb and flow. And I talk a lot about this in terms of, they’ve experienced the all types of product managers. So they’ve experienced the CEO types, right? Where they own everything and product specs are delivered and engineering must comply and that generally in my mind creates poor relationships within the organization. So that product group kind of dissipated and then they have the product managers who are like the ideas product managers. They go on a walkabout, they have these ideas and they come back and we rip up the roadmap and we just do all these new things because those things seem really cool. And they’re kind of following market trends or something like that.
And so yeah. When we came in, at first I think when you’re joining a group that doesn’t have product management as a product manager, you’re really worried that the antibodies will reject you in the system, right? And that the engineers will revolt and so you have to really work hard to build relationships and try and figure out your place. But really everybody wants, all the engineers and everyone else, they don’t want extra process, but they do want some structure and some stability and a roadmap that they can follow and trust that it won’t shake up. They experience many times just working on things for months to then not ship because it finally got to somebody who said, “No, no, we’re not doing that. We can’t ship that.” I think GitHub had a Slack competitor for a little while, internal Slack application.
Then finally someone said, “We can’t do that. That’s not part of our core structure.” But I think a lot of dev tools organizations experience this. They’re built by developers, so developers feel like they understand their audience and maybe they don’t need that much. But GitHub has always had a really great design organization by Mark and others who have been here for a long time. So design has always been a core part of GitHub’s kind of philosophy and delivery.
And so I think, yeah. They were able to kind of skate by on this like, I’m a developer, so I understand the customer, even though it doesn’t always translate because they, definitely, they missed a lot of the enterprise business because they were developers and they understood developers, but not purchasers and everybody else involved in the process.
How Bryan’s development background has helped or hindered him (12:11)
Amy: You started out in development and then designing, how has your development background helped or hindered you in your current role? Because I know in our pre-interview we mentioned that it can be an Achilles heel because you sometimes think, you know more about the actual topic and we thought that was a great point, maybe something you could talk about.
Bryan: Yeah. Love to talk about this. I get this question a lot when I give talks and I definitely don’t use my computer science degree much anymore. It is a muscle that you need to maintain, right? I don’t go to the programming gym like other people do in order to keep that going. So I can’t keep up. At this point it’s like classical knowledge of computer science. I understand the algorithm still, I understand how databases work. Fundamentally, a lot of these things didn’t change and so I’m really glad that I do have that kind of classical computer science background in a lot of ways.
But yeah, there’s definitely a duality to that. Many times, especially when I mentor or work with young new product managers, they’ll ask like, “Should I go do computer science courses? Should I learn these things?” And the motivation sometimes is that they’ll be able to call bullshit on developers. Right away, I tell them, “That’s the recipe for a terrible relationship with your engineering team.” Is that, if you’re there to call bullshit on them, then you have organizational structural problems.
Your engineers, you should trust by default that they’re doing the right thing and that they’re the best people for that job, right? And if they’re not, then you should be working within the organization to figure out, how can we get a better team or a better structure or education so that we can all level up. So I never do that. I do try to write code sometimes and the engineers do think it’s laughable, even though I think my code is still pretty spot on, especially in JavaScript. But mostly, yeah, it helps me build out quick relationships because I can talk tech and so when I join a new team, I kind of understand the technology. I don’t make a lot of mistakes that make engineers really suspicious, right? I make complicated mistakes later on by assuming I really understand things.
When it comes down to how Kubernetes works, I don’t really know anymore. It’s super complicated things that I haven’t spent a lot of time. When I was in school, in university, I just had extra time to try things. We had a lab for open source and we have a Beowulf cluster and all these things. And I remember, you try these things and you learn them and that stuff is excellent for later on when you’re in the working environment because you had spent this time learning new tech and other stuff. But I don’t have my own Kubernetes cluster at home anymore.
That kind of stuff, if I did, that would really help me with my job, but I don’t have time for that kind of thing anymore. And I just, yeah, I learned to trust what my engineers are telling me to do. And it is hard to let go of that a little bit, but it’s better to build out this relationship.
Building relationships with your engineering team (16:05)
Amy: Right. And so you use the term relationship and I’ve spoken to a lot of PM’s who also say, “I like to cultivate a good relationship with the engineers. I would like them to respect me as a PM and even if they are non very technical.” How do you cultivate this relationship especially if you are a very nontechnical PM?
Bryan: That’s a really good question. So I think because I have a technical background, I get that kind of cheat where I can talk tech with engineers right away and they feel like I’m not going to overstate things that can be done or just kind of misstep on the technical bounds of things. Without that, I think it is a lot about just like building out a regular relationship. Really trying to trust by default that they’re doing their best and over communicating what your goals are and what the customer goals are and the things you’re trying to accomplish and spending time with people.
The challenges of building a product for a large user base & enterprise clients (17:55)
Amy: So moving on, GitHub has like 40 million developers using your tool. What are some challenges of building a product for such a large user base? And you sort of touched upon enterprise clients as well. How have you worked through these challenges?
Bryan: Yeah. Again, it’s a great double edged sword, right? So in my career, originally I started at Red Hut. I left Red Hut because it was focused solely on the enterprise. And the thing I didn’t like about the enterprise market is that the buyers, the people who purchased enterprise software, are not the users.
And so I have this weird thing where you do a lot of work to entice the management and the people who want to enact policies to buy the software. A lot of those policies are probably detrimental to the use of the software for the actual consumers. So I went to Mozilla because I was like, “I want to go to a place where it’s consumer technology. I want people to choose this.” Because that foot traffic model gives you a great barometer on whether people like the software and use it. And I’d always wanted to work for GitHub. And I think GitHub has this real duality of enterprise and consumer, right?
So on github.com, and actually just like Firefox in a lot of ways, we get this question where people are like, “How do you make money? I don’t get it. GitHub just gives away everything.” And the answer is like, “Well, yeah. We give away a lot of stuff.” Right? Open source and free users get almost all of the GitHub features to a certain extent. But we also sell an enterprise version of GitHub, several different flavors, right? So there is an enterprise price skew on GitHub where you can do enterprise what we call Enterprise Cloud, which is, you just get all the features, we run it, hosted environment. And that gets you all this extra security scanning, minutes for CI and things like that.
And then a bunch of different On-Prem GitHub and stuff like that. Enterprise customers, they want controls, they want policies and all these other things. Those things would really weigh down the average GitHub user. If you say like the 40 million number, most of those people are individual developers who or maybe work on teams, small projects. And then there’s also this kind of funnel or maybe it’s like a pyramid aspect to our users, which we tend to relate a lot like YouTube or something, right?
So in YouTube, you have these creators, which YouTube, I think, does a great job of treating their creators very differently than everybody else, right? There’s a totally different interface for YouTube creators and uploaders. There’s even different YouTube apps for uploading. And then on the consumer side, as a YouTube consumer, I’m not a creator, I’m not hip like that. But on the consumer side, when you just go to YouTube, you have a very different experience than the creators do. You’re just kind of like, you’re in their machine learning, machine system, right? Like watching videos and they’re suggesting different ones based on those attributes.
So we have that with software developers. We have these open source maintainers who spend a majority of their day on GitHub interacting with our software in a way that those 40 million people are not doing, right? So they are our creators. They maintain software that runs everything, right? Things that are part of this Zoom call is guaranteed, probably more than 50% of the code that built Zoom is open source software and it’s on GitHub somewhere. And those people, we listen to them in a very different way than everybody else.
And we are attentive to them, but then at the same time you have to balance that with the things that they want aren’t necessarily going to be good things for everybody else. They want more controls. They want more information about certain things that the rest of the people who are at GitHub just to consume, which is the majority of users aren’t… And I know, pretty much every product has this kind of duality shape to it. And so you really have to figure out how your process of taking information in and prioritizing slots in that kind of stuff. Like where you spend your time. Because our enterprise clients, that’s where we get all our money, right?
So if I want to earn more money for our group, I need to do enterprise features so that I’ll get more sales and do those things. Or spend more time with marketing to help market the stuff that we have or onboard enterprise users more quickly. But none of those features translate to greater numbers at GitHub. That doesn’t get me another 20 million GitHub users, right?
Audience Q&A period
(23:01) What are your strategies for balancing tech debt versus new features?
(26:24 ) Somebody asked, they’re currently working in a startup where priorities constantly change. How do you handle trying to plan ahead when it seems impossible? And I think that’s really relevant in COVID times.
Speakers
Bryan Clark is a father, brother, dedicated partner, and environmentalist. Currently a Director of Product for GitHub leading the GitHub Packages team and nearly celebrating 3 years with GitHub. Arriving at GitHub pre-acquisition Bryan helped build out the Product organization through hiring, mentoring, and developing product processes. At Mozilla, Bryan was a Product Manager for Firefox and Firefox developer tools but prior to being a PM Bryan worked as a designer and design manager for the Mozilla UX team. An Open Source vein runs throughout his career with nearly 5 years spent at Red Hat before Mozilla as well as developing an Open Source learning program during his Masters and Bachelors computer science degrees from Clarkson University. Originally from southern New Hampshire he is (recently) a dual Canadian / American citizen and lives with his family in Victoria, BC Canada.
Amy’s a Content Marketing Specialist at Roadmunk on the Marketing team. She produces Recess, the Product to Product podcast and video content. Prior to Roadmunk, Amy worked as a journalist in various Canadian newsrooms and wrote for publications like NBC, CBC, Vice and more.You can follow her via her website, Twitter, and LinkedIn.
Product to Product | RoadmunkFor product people, by product people.Follow