10: Ep.10 | Collaborating with product with Hirsch Singhal

Erika (00:00) Welcome to the Overcommitted podcast where we talk about our commits, our commitments, and everything in between. I’m Erica, your host today, and I’m joined by Bethany, Brittany, and John. We’re a group of software engineers who first connected working on the same team at GitHub and quickly discovered our shared passion for learning and building.

Even though we’re scattered to different teams and companies now, we still come together regularly to talk about technology we’re interested in, share what we’re learning, and explore our lives as developers. So whether you’re committing code or committing to new challenges, we are glad you’re here. Let’s dive in. Today’s episode is about healthy collaboration between product and engineering. And we are thrilled to welcome our special guest, Hirsh, on experienced and skilled product.

manager at GitHub. So we will start by having you introduce yourself Hirsh. Tell us a little bit about yourself and what drew you to product management.

Hirsch Singhal (00:57) gosh, so yeah, I’ve been a product manager for my entire professional career, effectively. I was paid to be a dishwasher and a dev for a hot second, but basically since leaving college, I’ve been a product manager the whole time. I got into it because during my first internship interview,

know, Microsoft was on campus asking people to interview. And I was saying, you know, don’t, I don’t know if I want to be a PM or an engineer. can sort of do both. And halfway through, maybe not even halfway, a quarter of the way through the interview, my interviewer said, okay, yeah, you’re going to be a PM. I don’t know if it was a compliment. He was himself a PM. So we’ll see.

But that was sort of where I started. Thankfully, having a strong engineering background, you I went to school for computer engineering, I think helped a little bit. But the fact that Microsoft still had that ability to bring in like early in career PM really helped make that possible.

Erika (01:55) So, well, great. So now that you are where you are, what is your favorite part about working with software engineers to create a product? And what is your least favorite part?

Hirsch Singhal (02:07) gosh, probably one in the same thing. My favorite engineering product management experiences are the one where we’re vibing effectively and kind of building on, yes, and in the ideas from each side. I think.

Sometimes engineers don’t get enough credit for understanding the systems that they’re building and understanding the capabilities of them. so I’ve got patents on the shelf and stuff that all came from basically, okay, we’ve got a really hard problem to solve. You know what’s possible. know most of what’s possible, but also kind of…

the full picture of what we’re trying to solve, let’s go at it and figure it out. And those moments are fantastic, because they feel like you’re flying. The hardest part is the don’t touch the keyboard rule that you kind of, or discipline that you have to have sometimes.

where it’s like, I know how to do this. I’m just going to get in there and roll up my sleeves. And it’s like, no, you don’t. You don’t actually fully understand what is going on here. I might have probably the second or third highest contribution count amongst PMs at GitHub, but that doesn’t mean anything. You cannot actually do that. And it can be very frustrating looking from the sidelines being like, just.

And then like, hey, reminding yourself that you don’t actually know what you’re talking about. shut up.

Bethany (03:23) That’s super interesting. I wonder how you separate that like engineering part of your brain with the product part of your brain, or if it’s not even a separation, is it something that you kind of use in tandem?

Hirsch Singhal (03:32) Definitely in tandem and a lot of that has to do with picking the right teams to work on and with. I’ve only ever worked on developer tooling or developer facing things my entire life. So I started off in Windows working on developer tooling. I owned like the F12 tools for Internet Explorer. And then I went to the developer facing protocols for identity. And now I’m here, which like, especially Erica’s team is.

100 % thinking about developer and the engineering uses here ⁓ is critical. And so it’s like…

Erika (04:01) you

Hirsch Singhal (04:04) using that as intuition, but not as like here, I’m going to write a spec for you that says how it, how the code should work. Stay back.

Erika (04:11) As somebody who does work with you pretty closely, I can vouch for your engineering brain being very useful in these product, like collaborative discussions where like you understand.

at least conceptually what it takes to implement the feature. So going into a discussion of scope or technical requirements, you’re already kind of thinking about like the implementation level versus like purely theoretical. And you also like do jump in with like a

really strong knowledge of the limitations of the system because you’re so familiar with where those choke points and technical debt areas are, which help us out a lot depending on the level of experience of an engineer on our team. You bring that brain, which is super helpful for us overall.

Hirsch Singhal (05:07) Glad to hear it. I think it can be a bit of a crutch at times though, because it

It reduces the amount of space that people innately want to think about whenever they’re approaching a problem too. which means that, you know, I worry about this one a lot is,

How do we make sure that these engineers with all their talent and insight into even broader systems, even deeper problems, not in the same vein as a thought-terminating cliche, but if I put too much on paper, are we missing out on a chance to do more by thinking broader?

And there’s a trade-off there that I always worry about.

Jonathan Tamsut (05:43) Yeah, that’s interesting. I guess, like I think with developer tools, it’s interesting to be a product manager because in a sense, developers are like uniquely positioned and experienced to build developer tools and have opinions on them as opposed to like some other product that developers don’t really know a lot about. like.

What do you see as kind of the responsibilities of a product manager? What do see, like what do you think the sort of product responsibilities of an engineer are? Especially in the context of like building developer tools.

Hirsch Singhal (06:14) So it’s interesting because what Eric and I work on isn’t for developers, right? It’s something that actually a lot of engineers here try to stay as far away from as possible. like, just, I don’t want to deal with identity and authorization and all the bits that make, like, that let me do my job. I want to focus on, you know, opening a PR. I want to write some code. I want to run tests. Like what we’re working on is

Jonathan Tamsut (06:19) Mm-hmm.

Hirsch Singhal (06:37) targeted mostly at administrator personas, not just the developer persona. obviously, a product manager’s responsibility is to bring that broader view into the room and be able to explain, like, hey, this is why it’s important for an admin to be able to understand who all can see the repo.

Here’s why that’s a really critical job for them because that intuition that makes developers really great at building developer tools isn’t necessarily there in that scenario. For more…

on the line developer tooling. I think that that’s a place where PMs should a, if you can’t, like, Thomas said this during an all hands a couple of months ago, like, if you’re a PM and you can’t code.

you’re not somehow writing code, even if that just means using like copilot and saying, go work on something. What are you doing? Because you can’t build empathy for your customers. And I think there’s a bad habit sometimes in PM of like, yeah, I work at the widget factory and I ask the customers what color widget they want the box.

or what color box they want the widgets to come in. And then I tell the team to put the widgets in the box. I don’t know what the widgets do, like whatever. like, you’re just a conveyor belt. And I don’t think there’s a lot of value provided there. So doing what your customers do and building that empathy and then having a broader vision over…

not just what the product itself is doing, but like what is the entire ecosystem doing? So, you know, Tim Rogers, right? He’s a PM for the Copilot Coding Agent. You know for sure he is sitting there and testing out every single product on the market that does that thing to actually build that context and bring it back to the team and say, like, here’s what works. So that not every person on the team has to go do that themselves. So.

I think that’s the PM’s responsibility.

Erika (08:26) I’ve heard like a version of that that you mentioned that Thomas said with coding, but drawing it out to either coding design or sales background and those being prerequisites for some kind of product management role where like you’re bringing that experience to, like you said, bring a…

be a connector and have that empathy for the end user, whether your end user is a developer. And then from the design perspective, you build that skill of reviewing designs. if you’ve created design before, you’re going to know what goes into that to bring that to your dev teams and give them a wider perspective.

Yeah, it’s an interesting take for sure and definitely highlights the need of product managers to give that wider vision and be that connector.

Jonathan Tamsut (09:29) And I think one interesting thing, like from my experience is, you I worked at a company that built, like, it was like a fintech tool for bankruptcy, Chapter 11 bankruptcy, you know, processes. It basically allowed people to buy and sell bankruptcy claims. And, and Chapter, you know, bankruptcies are like incredibly complicated legal processes and

The entire time I was at that company, there was just so much I didn’t know. I I learned a lot about bankruptcies, but it was like, there were so often the case where we would come to sort of some decision juncture and I would hear like, well, this is a product decision. Like we need to, you know, go consult products. So I think it’s like, it’s interesting. Like the inverse is also true, right? I mean, you know, with developer tools, obviously developers have unique expertise, but.

Pretty commonly, it’s like developers don’t have the context to really make product decisions and should developers, should it be incumbent on developers to kind of educate themselves more? I to an extent that’s maybe not really feasible, but.

Hirsch Singhal (10:26) A little bit. mean, the best engineering teams I’ve worked with, when I talk about like that flying feeling, is where they themselves are subject matter experts. And again, that’s a lot easier on like…

being in the weeds of the scenarios that are being solved. So when I think about my, one of the teams I worked with at Microsoft, they owned the core token issuance engine for Azure AD. So anytime you signed into anything, it routed through them and they were responsible for the linchpin kind of, of every single connection between every single user and app and resource in the system.

And so that meant that they had tons of experience looking at all the different ways that you could connect things together and like having strong opinions about the right way to do those things. And I think it’s that last bit there that was the most impactful is like, I understand the goals and requirements of the platform that I own and can continue to represent them over time instead of having to

in a sense, like be reminded of them at every juncture. And so being able to ingest the…

Erika (11:23) you

Hirsch Singhal (11:27) the reason for your product to exist is, I think, critical to being a strong engineer on product that you’re not innately familiar with.

Erika (11:36) Thanks.

Bethany (11:36) I agree with that a lot. I think it reminds me a lot of a book we read, Domain Driven Design, on that collaboration or that understanding even what you’re working on. I think throughout my career, it’s always been like, oh, you provide the code, and that’s the most amount of contributions you have to this product. But what I really liked about the book, and I feel this at GitHub as well, is that engineers should intimately know what their

writing for, what they’re coding for. And that code almost serves as the language to talk about the product so that everyone shares a shared understanding and language for what they’re building. And also not shielding product or non-technical folks from the code either, because that only serves to silo certain knowledge. So I appreciate that take on kind of the engineers.

role in the product portion as well.

Hirsch Singhal (12:30) I like that about not shielding PM from the code. If you’re not adding your PMs to your pull requests, come on. And sometimes that just looks like, hey, fix the wording. you know how to add a commit to my PR? Let’s go. We do not need to round trip this through a Google Doc. Be comfortable with understanding how this works.

and why you can’t just ask for, you know, 18 different ways of putting this phrasing together.

Erika (12:55) Yeah, we’re kind of already touching on some of these things of like characteristics of a healthy collaborative working relationship between product and engineering and also some of these like flip side elements of what the breakdown looks like. I know I’ve had similar experiences to what you were talking about, John, of the sort of…

throwing it over the wall to product and then having products throw it back. yeah, like, I feel like it can be a really lazy way to…

outsourced decision making from an engineering perspective and say, hey, not my problem, product, tell me what to do. And then come back and like, okay, well, I’m going to implement exactly what you say and only that. And if it’s not what you want, then it’s your fault because you told me wrong.

Yeah, and like what we’re talking about here is a more like integrated approach of like, okay, together we’re going to like describe the model, describe what we want to see, have a shared vocabulary, have a shared language, and like share some understanding of what it takes to get there too between product and engineering.

Yeah, but to your point, Hirsch, it requires including product in those discussions, from a design perspective, and then also engineering taking responsibility of understanding the wider context.

Hirsch Singhal (14:19) Yeah, there’ve definitely been some times where you get to the end of the epic, you get to the end of the initiative, and you go to click around and you just go, my, why would you ever do this? And it’s like.

Okay, you can either start the blame game or be like, okay, well, clearly something didn’t get communicated. And generally that looks like something didn’t get communicated from product to engineering. Sometimes it’s the other way around, right? Like, we had to build it this way because of how the system works. And obviously when you told us X and Y, like this would be the outcome, right? But, and usually it’s the other way around in my opinion.

product hasn’t done enough to bring engineering on the journey so that they understand the implicit.

expectations. And sometimes that even just looks like, again, Erica kind of using our area, for example. You know, I asked one of my teams to go work on something that Erica’s team is building and built previously. And I didn’t explain how what Erica’s team built works. And I didn’t explain how the back end works. I didn’t explain how the front end works. I didn’t explain like, okay, yeah, because like,

this word has a defined meaning and all of the implications of that you should just know. That’s not a reasonable expectation perhaps. And so they invented a whole bunch of extra requirements that didn’t need to be there because like, again, yeah, that full picture wasn’t brought over.

Jonathan Tamsut (15:31) I’ve also been in situations where, you I think sometimes people try to justify the existence of their jobs and there’s also maybe like power struggles that emerge. So product really does view engineering as sort of like a widget factory resource. they’re sort of, you know, product is sort of the arbiter of like what gets built, how.

And yeah, that generally doesn’t feel good. And I don’t think it’s like sort of maximizing the potential of the team. And I think like, you know, I’ve also seen engineers, like the product is what matters, right? The code is sort of incidental or, you know, I like the quote, code is not an asset, it’s a liability. Like, I mean, the code exists to sort of help the customer do something. And I think some engineers,

can get really lost in sort of the technical details and forget about or excited about the technical details and forget about sort of the reason why this exists is to serve.

Brittany Ellich (16:26) Speaking of that, have you seen any good methods of creating more trust and psychological safety between the product and engineering side of Teams? Have you seen anything that works really well or anything alternatively that works very poorly?

Hirsch Singhal (16:39) I was hoping somebody else might have something. That’s a hard one. Overcommunication is a big one. It’s not very much in my nature, but I know a lot of successful PMs that are sort of the cheerleader slash news correspondent from the front, in a sense, of like, hey, you did all this great work and let me bring you the report.

saying how impactful it was, how great it was, know, major customer cited your feature as one of the reasons they signed a deal with us. You know, here’s the VP of sales saying, all right, like we landed this deal because we finally unblocked them after your work got done. And I think that does two things. It like, again, it attaches engineering to the actual outcomes.

because they actually get to learn about them. But also in a sense, I think that does help prop up the credibility of the PM to their team and is like, hey, remember this thing I asked you to work on and we did this thing and like, yeah, see it worked.

Yeah, it’s something honestly I need to get better at.

Erika (17:38) Yeah, I feel like another area of like trust breakdown that we haven’t talked about is timelines. And this can come from both directions where engineers have this like inane habit tendency, I don’t know what it is to underestimate timelines. And then like I have also worked with product teams who don’t really ask

or consider the implementation scope when setting timelines. So I feel like that is a vector of the product life cycle where trust can really break down and having a…

having a sort of go-to strategy for addressing blockers, addressing timeline estimations, not assuming from either side that the timeline is fixed, but continually addressing it as it goes and being as upfront and honest about what’s going on at each stage.

I think is a helpful thing to keep in mind.

Hirsch Singhal (18:43) Yeah, I think the biggest one there is always coming back to the fact that like, we are a team. It’s not the engineering team in the PM. Like it is, but it’s collectively we are a team and we are trying to deliver this work. And when are we going to get it done? That’s not a single person.

question ever. Yeah, nothing nothing breaks trust more like, yeah, I said a bunch of stuff on your behalf. I wrote checks that you have to cash. Absolutely not. And you know, the flip side is like, there’s a king mattress of padding in there somewhere. Okay, so

Do you actually know how long this will take? Like, what can we do to get more confidence in these dates? And again, that needs to be like, you know, I hear a lot like, you know, if I give you an estimate, like you’re basically gonna try and fire me if I don’t meet it. And it’s like, no, like the point of the estimate is so that the docs team doesn’t.

get spun up on something six weeks before they actually needed to. Other teams need to know when this work will get done so that they can then build on top of it. It’s so that we can just coordinate amongst ourselves. That’s it, but that requires high trust to believe. That’s organizational as well.

Erika (19:53) Well, and there’s one other actor too that you connect with the engineering teams with, is leadership and upper management. And you are that go between a lot of times, in addition to engineering managers at GitHub, but you communicate with them about priorities and then bring that back down to the engineering team. So how do you like see that role for yourself and how

you manage the flow of communication upwards and downwards?

Hirsch Singhal (20:24) depends on what.

the overall culture of the company looks like. I know that, you when I worked at Microsoft, like I got told what I was working on. There is none of this like PM led. you know, I, a subject matter expert in my area, you know, this is, I’ve talked to my customers and I know, no, let’s be clear. Accenture or JP Morgan or somebody with more money than God.

like has gone to my CVP and told him, you need to build this and I’m gonna pitch a fit if you don’t, right? And it’s negotiation, but okay, that’s what we’re working on. And in those situations, I think it’s about.

trying to explain that situation to the team and try to mitigate as much whiplash and like, you know, if you can get your CVP to say no, like, and that’s a tall cliff to climb because it’s whiplash, it’s chaos, it makes everybody lose faith in the rest of the system. Like what was the point of having a roadmap if anybody with a C in their title can?

from any company that is our customer can basically disrupt it at any time. Did that mean that LT doesn’t have faith in our roadmap? Do they know what we do? Like it brings a lot of really insidious questions. And if you can explain like, no, no, this one’s really important. It can help maybe. Otherwise, yeah, it’s about representing the work and the challenges of the team upwards to try and, you know, get additional funding.

if I can’t explain adequately, like, it’s really important that authorization works correctly.

then we don’t get more headcount to make sure that it continues to work correctly and trying to attach the, trying to help LT connect the dots between like, hey, you asked for a bunch of stuff and we have this much to deliver it with. Highlighting those challenges to LT in a way that they understand and believe is probably the biggest thing there. And we can’t do that without understanding what it is that you do.

Erika (22:10) Yeah, for sure. Well, I’m going to ask one more question before we wrap up to our fun section. My last question is, if you could give one piece of advice to any software engineer you work with, what would it be?

Jonathan Tamsut (22:11) ⁓

Hirsch Singhal (22:24) try to talk to customers. Like, we don’t do this enough. You know, every so often we’ll bring in a customer to like an all hands and they’ll talk at really high level about what it is to like use GitHub. But you know, I’ve got admins that want nothing more than to go talk to the API team specifically about like, why is this returning a 403 instead of a 429? Listen to the pain in my voice and like,

actually getting that empathy across and even building those relationships. like it creates touchstones and serious actual understanding of, know, the reason of the product, which I think can help you empathize with the PM and also like, hey, wait a minute, didn’t this other thing and you get to start drawing the dots yourself. And I think that can be a real level up.

Erika (23:10) in the face.

All right, so our fun section today, we’ve done a version of this before with web acronyms, but there are a lot of acronyms in the product management space, and we don’t always know what they are. Some of these I didn’t know, so we’re all gonna jump in on this and take a guess at what these acronyms mean. So…

I’m going to start with Britney. There is an acronym AARRR. What do you think that stands for?

Brittany Ellich (23:40) A A R R R I feel like one of the Rs has to be for revenue. But I just keep immediately thinking of AARP, which is probably not the same at all. So I’ll need to phone a friend on this one.

Erika (23:52) Does anyone else know?

Jonathan Tamsut (23:53) A? So two A’s followed by three R’s.

Erika (23:56) Yes, and it is pronounced R.

Jonathan Tamsut (24:00) Arrrr. Okay. Is it pirate related?

Hirsch Singhal (24:02) I was gonna say, is that

Erika (24:02) It refers to, in full context, it’s the R-Pyrometrics framework. But it does stand for something.

Jonathan Tamsut (24:11) the R pirate metrics framework. That’s fun.

Hirsch Singhal (24:13) That ruined my entire guess.

Erika (24:15) All right, I’ll give it away. It stands for Acquisition, Activation, Retention, Referral, and Revenue. And it is a framework for user behavior metrics that product-led businesses are tracking. R. Y’all revenue, yes. All right, this one I’ll kick over to

Brittany Ellich (24:29) I got the revenue part. 20%.

Hirsch Singhal (24:30) Yeah, that’s

Yeah, it’s your funnel.

Erika (24:40) Bethany, QFD.

Bethany (24:43) Okay, QFD,

I’m going to say…

I don’t know. So I’m gonna take a random guess and do queries for data.

Erika (24:52) I like it. It’s wrong, but.

Jonathan Tamsut (24:54) Bethany is really good at this game. I remember last time we played you got them all Bethany.

Bethany (24:58) I think I cut, I pulled all of them.

Erika (25:00) Yeah,

cheat code. ⁓ So it stands for quality function deployment. And it is a model for product development popularized in Japan in the 1960s, which translates customer needs and expectations into technical requirements by listening to the voice of the customer. You can tell how familiar I am with these acronyms by the attention to detail I need in reading the definitions.

Hirsch Singhal (25:04) Bye.

Erika (25:27) Alright, Jonathan, I’m going to give you this one, which is not an acronym, but describe the concept captured by this phrase in product development. The user is drunk.

Jonathan Tamsut (25:39) The user’s drunk, interesting. I’m gonna say…

I’m gonna say it is in reference to the fact that the interface and the user experience should be so simple and push them into a pit of success that they could in theory be drunk and still be able to effectively use your software. Okay, cool.

Erika (26:00) That is exactly right.

Hirsch Singhal (26:02) Nice

Erika (26:03) All right, and the last one I’m gonna give to Hirsch, NPS.

Hirsch Singhal (26:09) Net promoter score. He gave me the easy one. We actually use that one here.

Erika (26:13) Yeah, I feel like I should give you another one. I feel like that was kind of a soft a softball. Uh, ASD?

Hirsch Singhal (26:20) I I only know the one about spicy brains.

see.

Yeah, something something design ASD.

Jonathan Tamsut (26:23) Wait, can you?

Can you elaborate on spicy brains? What is… Okay.

Erika (26:27) Yeah.

Hirsch Singhal (26:28) ⁓ Autism Spectrum Disorder

Erika (26:30) ⁓ yes.

Hirsch Singhal (26:31) is ASD. Which probably not related to PM.

Yeah, I got nothing on ASD.

Erika (26:38) So this is an outgrowth of RAD.

which is rapid application development. And then AASD stands for adaptive software development, which are both agile frameworks that respond to customer needs. Yeah.

Hirsch Singhal (26:43) Okay.

There you go.

Erika (26:53) Yeah.

Brittany Ellich (26:54) Classic, nobody knows what agile means anyway, so it’s…

Erika (26:57) It’s true. It’s true.

Hirsch Singhal (26:59) I was gonna say, like

which of these is not involved in Agile? Scrum stories, Kanban and something.

Erika (27:02) Yeah.

I know. Yeah, I feel like there’s a whole host of spicy acronyms that I did not plumb the depths for for this. So we might have to do a take two where I find some more exciting sounding acronyms. But R was good. Drunk users.

Hirsch Singhal (27:20) R was pretty good. I like that one.

Erika (27:23) Well, with that, we’re going to wrap up for today. And thank you all so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky or your social media app of choice. And most of all, share with your friends. And until next week, bye-bye.