From engineering to product

Hey, everyone! I hope you’re doing well. We are super-excited about today’s show. We’re gonna be talking about a really important topic for software engineers who wanna be happy at work. We’re joined by my lovely former co-worker, Liana Leahy. Actually, Liana, I always mispronounce your name. How do I appropriately pronounce your last name?

The family says Leahy, but it’s an Irish name and it should be pronounced Leahy. So we pronounce it wrong, too… So whatevs.

Alright. Well, Liana Leahy/Leahy… Liana Awesome, that could be your last name, because I think you’re awesome.

Oh, thank you.

Liana is a product manager at Indigo. And on the panel with me today is Kball. Welcome, Kball.

Hello, hello. Nobody has trouble pronouncing my last name… Though I have had people ask “Wait, how do you spell that?” I’m like “Ball. Like a basketball. B-A-L-L.” But people still struggle.

Oh, that’s so funny. I mean, I would never have guessed that you have issues with your name, because you have a really common first name, Kevin, and then your last name is literally used in the English language, so… [laughs]

People just can’t believe it could be that easy.

Yeah, exactly. Those people might be engineers, right Kball? They’re like, “What’s the twist?”

We’re familiar with engineers, right? You wanna put all the fun complexity in there. We’ll build our static site with React, and… [laughter]

Oh, my God. I feel attacked. No, anyways… [laughter] So Liana, we’re so excited to have you today.

Me too. I’m excited to be here.

[04:13] Yeah, we’re gonna be talking about your transition from engineering into product. So you were like this principal-level senior engineer that made the pivot into product many, many years ago… And I think even before that at some point you were singing Broadway, which - like, I really wanna hear that story. So in your own words, why don’t you tell us a little bit about yourself?

Sure, sure. So, to start with the Broadway spin - I grew up in a family where my father was in music, he was a jazz pianist, and he used to gig in Manhattan, in the cat schools, and stuff. And my mom was a very fast typist, so she ended up becoming a keypunch operator in the ‘80s, and she was debugging mainframes, and stuff like that… So only naturally did I major in both computers and musical theater. So I always had the idea that – I mean, my dad had a day job, and gigged on the side, so I always figured that that was what my life would be. So I was doing computers. Do computers is what we said in the day. I was programming in Manhattan during the day, and then auditioning, right before work, because you got up at five in the morning to go to a cattle call, go to work, and then be at rehearsals and stuff at night. So it was a fun time; I loved it. I was doing off broadway I did a regional tour; good time. And then I turned 30 and went “Okay, thanks. I’m done with that. I wanna actually settle down and have a family, and a real life”, so then I started to work in computers in earnest. So that meant transitioning from desktop development- now I’m dating myself - to web technologies. I spent a lot of time doing that, and… Yeah, then I was doing Ruby on Rails for a number of years, and that was really great.

But yeah, I’ve been doing software for many years before I actually landed a startup that had formalized the role of product manager. I had never seen that before. I was like, “Oh, what is this? This is cool! This is my job. I’ve been doing this all along! I had no idea.” I had always been that person who was the glue. There’s a couple blog posts about being the glue person; that one who likes to be the liaison between development and the business, and talking to everybody… I was a very social person, so I had always been that person who was writing requirements, and trying to understand what the business really wanted… I was like, “Really? You want this? Are you sure? It’s gonna take a long time if we just do this little tweak. It’d be a lot faster. Oh, awesome!”

So it was just a natural progression into product management. So when I reached out to my folks at the company that I’d really like to make this transition, they were like, “Great!”, mentored me, and then I was on the path. But we can talk more about that as we go along.

Working in computers or with computers is such a great dayjob. It’s way better than waiting tables. I know so many people who are in performing arts of some form or another, that use software as like “That’s how I pay the bills, and then I do my thing.”

Yeah, I was really – at the time, there wasn’t a lot of computer scientists in theater. I’m sure there’s more now… But back then, it was just me and – it was great; I could pay for my acting classes, and my headshots, and… Being an actor is expensive. So it was very helpful.

I for one would really like to see that be normalized, where tech is a job, and not your full-time passion… Because I feel like people have the opposite mentality, where they feel like in order to be successful in tech you have to be this super-passionate engineer, and you have to live and breathe this stuff… And I feel like it’s perfectly fine to normalize it and say “Hey, this is a lucrative industry, and a high-paying job, and you can use this to help fund your perhaps less lucrative passion.”

I love computer science. I miss programming. I love it. I wouldn’t say that I wasn’t passionate, or I’m not passionate about it… I just have multiple passions.

[08:05] Right, exactly. That’s exactly what it is, I think, is making room for multiple passions, and this not being the dominant one. So yeah, I’ve got a pinned tweet on that… And speaking of glue person - your whole concept of being a glue person is very true as a product manager, but I think even just in any engineering work I feel like there’s glue people with many different titles, that are the folks that know where all the bodies are buried, and they know who’s good at what; they are the ones that can redirect you to the right person, and get stuff done… So I’m curious what really was the catalyst for you making that formal transition into product? When did you realize this was something that you maybe were more excited about, or…?

Yeah, I had done software for a while, and I guess I just needed a different challenge. And when I saw this role and the way that it was done, it just seemed exciting to me to formally have that as a job, as opposed to just doing it as an engineer. Because it does suck up a lot of your time when you’re that glue person, to spend time making those connections and talking to people and understanding the business. It’s all valuable work, and I know that a lot of engineers do that today. But when you have someone whose job it is to do that work, it leaves you free time to actually do the programming.

So that’s where I think product management can help out engineers, and it’s really important. I just hadn’t seen that before. It was always on the tech staff to try and figure out what is it that the business wanted… And they didn’t really tell me why they wanted something; they were always handing us solutions, like “Go build this thing”, and we would just kind of like “Okay…”, just kind of guess, and then it wouldn’t be the right thing, or it’d be super-waterfall and you’d spend months planning something out, and then of course, by the time it was built, they didn’t need that thing anymore… It was just not an awesome way of creating software.

So that was why I was being that person who was trying to make those connections, because I didn’t like – you know, no one likes building something that no one’s gonna use, right? I want to build something that’s useful, that is gonna work, and people are gonna be happy with… So that’s why I was going to the business going “Why am I building this thing? What do you want it for? Who’s using this?”, and asking those types of questions, which are very product management questions.

Can we maybe divert a little bit and just kind of flesh out for folks what exactly we mean when we talk about product manager work, product manager types of things… The product manager role. Because I feel like many engineers have never worked with a product manager, or at least have never worked with a product manager who was actually good at their job and making things easy for the engineering team.

Sure. I mean, it’s a tough and challenging gig. There’s a lot to do. You need to understand your industry and your company, and you need to know your users. I mean, that’s number one - who are your users? And if you’re in a company that makes software for everyone, like Facebook, it gets a little harder. I worked at the MBTA for a while, which everyone rides the T so who is your user? Getting to really understand the jobs to be done is one of the frameworks that we use… Like, “What is it that the user is trying to do? What are they trying to accomplish with your product?” and understanding that need and that niche that you’re trying to fill with your product - super-important.

Also, as a PM, you’re aligning stakeholders around the vision, so you have to have a real good picture in your mind and be able to communicate that picture of what you’re building, and not just that feature, but the overall, like “In a year from now, what is this product gonna do and be? What is the strategic direction of what it is that you’re building?” And how is that gonna help your company? Why should they invest in building this product? How is that going to help the company move their needles?

And then you’re prioritizing what you need to build. So you’ve got like a list of features that you know that you need, that’s on your roadmap… But when does this fit in? How do I put that all together? And then you’re rallying the team around all of that work.

[12:10] You’re prioritizing the product features, capabilities… And then in a lot cases, some product managers depend on the organization, but you’re helping to deliver that feature. So being that person that can help remove roadblocks, get people the answer to questions that they need… Really championing the team and letting them focus on the development work, while you’re chasing down answering their questions about the feature from commercial teams or operational teams of the business.

Yeah. That’s a really great summary. I also feel like being the internal voice of the customer is a big thing for product. You’re always the litmus that’s like, “Hey, I’ve spent a lot of time getting into our customers’ heads…” Like, you know, engineers, designers, whoever, really, when you wanna understand “Is this important to our customers? I’m a good litmus for you to maybe kind of bounce off ideas with initially.”

And it doesn’t mean you’re always gonna get it right… But I think for the most part, I always feel like my product managers have always been the folks that are really the advocates for our customers inside the business. And it sucks, because sometimes what your customers want isn’t also what the business wants to do… So I think striking that balance and negotiating with business on like “Hey, how can we make this work?” is something I’ve seen product managers do quite well.

So I’m just curious, at what point do you feel like our industry being so young - I think Kball alluded to it… Maybe some engineers listening to this podcast haven’t even worked with a product manager directly. So this role has kind of birthed out of software getting bigger, and us wanting to create more and more delightful user experiences… What’s the kind of tipping point for product managers, and how do they fit into an org? Is there ever a time where a product manager isn’t needed? Because it’s a fairly new(ish) role, right?

Yeah, that’s interesting… I mean, I’ve certainly been the only person developing the software where I was “devsigning” everything, and trying to figure out what features to build, and doing all of it… Certainly, the things that I designed as an engineer were nowhere near as fantastic as the stuff that you have a proper designer work on, and I think it’s – like, for product management, especially as an engineer, I didn’t understand the economics behind what it was I was building, or the Why, or the industry, really. Because I’ve worked in - gosh, almost everything… Games, and finance, healthcare, agriculture… All these different industries. And as a product manager – for an engineer you don’t need to go too deep to understand that industry. You’re just building software. You need to go deep on what tech stack you’re working on. Before product manager, you really need to go deep on that industry and understand that industry inside and out, to give the best user experience. To truly be able to understand your users, and also understand “How do you bring value to this industry that no other competitor has?”

Yeah, that makes a lot of sense. I think the distinction between technical expertise and domain expertise that’s specific to an industry is key. And I think that’s where maybe you see some teams getting away with the lack of a product manager, or formalized role, because perhaps someone in that organization is playing that domain expert… And as someone in that organization is saying, “Hey, I know this. This is what we should be building, engineers. Go do it.”

So I think that’s a really good distinction, so I’m curious what are some of the – you mentioned the how and the what, right? So we’ve talked about this a lot in our industry, where product folks are responsible for the What, and engineers are responsible for the How, and that’s the clear line between these two disciplines that have to often work with each other. So if you ever wanna know “Hey, is this my job, or someone else’s job?”, you should ask yourself “Is this a What, or is this a How?” Has that distinction generally worked, and is it actually still even relevant with super-agile organizations and fast-moving projects?

[16:11] Sometimes as a senior engineer I’m having to often make that decision, that maybe a product manager would make, right? Because I’m not going to tap my product manager on the shoulder every five minutes, so…

Yeah, we were talking about this at the beginning of the call… I think a lot of it depends on the people and the relationships that you have. So being that I’m a product manager that has come from engineering, I’m the type of PM that is going to help you through that. But I think when you have someone who is maybe more of like an MBA type, or someone who has more of a business standpoint, they’re going to approach it a little differently.

So I can help you through a little bit of the how, whereas maybe someone with a business background can’t… But they will be able to flex on those muscles, and be able to give you a lot more business strategic stuff…

So I think as a – I’m kind of coming around in a roundabout way, but a product manager has to be good at so many different things. You’re working with design to create a product, you’re working with technology to build it, and then you’re working with the business to bring value… And all of those things you have to have some ability to do very well. And at any given time, you can flex on any of these different pieces, and it depends on what is needed in the moment.

So when you’re working with a tech lead, there might be moments where the tech lead is taking on more of that producty role as they’re trying to answer things on the fly and get things done, especially if you’re in an environment that has to get things done really quickly… I don’t mind that, when an engineer is trying to get it out the door, because we’re all trying to ship things quickly and iterate on them and learn from that… But at the same time, I think it helps that engineer if you understand very well the user that you’re building for, and why are you building this feature in the first place, and having the context of all the user research. If you have the context around it, then I think the engineer can make so much better decisions. I trust that engineers can make better decisions when they understand that and can make those micro-decisions.

Liana, you said something there that I wanna double-click in on a little bit, which is you mentioned the word Why. I think the What is often a collaborative endeavor between product, between maybe the tech leads, maybe the design leads, whoever it might be. But to me, what sets a really good product manager apart is they always have that context, they always have that Why. “Why are we doing this? Why are we trying to decide on this What? Once we’ve decided on the What, why are we doing it now, instead of later, and why are we doing this What, instead of that What?” All of those different pieces live somewhere, and it’s the product manager that, in my mind, pulls all those pieces together.

That’s right. I think that’s the vision that I was mentioning earlier. I have to have a vision in my mind that I’m communicating out to everyone multiple times, over and over again, so that everyone continues to carry that picture of what we’re building, and why we’re building it.

User research is just really a cornerstone of project management. You need to be understanding what’s going on with the folks you’re building for, and why they need that thing, why is it important, what kind of value does it bring to their life, so that you’re building the right thing. And if you can carry that vision to everyone else and let them understand “Where’s the user coming from? Why do they care about this feature?”, then those smaller decisions are easier for folks to make.

[20:00] I like to do something called a stortytime. In another company we called it a User Goal Meeting, and it’s the meeting before you even solutionize anything, before you create mockups or designs. You come to that meeting with a bunch of user research, and a problem to solve. And you get everyone in the room, and when I mean everyone - every stakeholder; that’s engineers, content writers, any medical folks, or stakeholders, folks that know about the industry… Put them all in a room and share the user research that you have around this problem… “Let’s agree on the problem. Let’s all just agree on, like, this month we’re going to tackle this problem, and get agreement there”, and then understanding the user research around what is that problem.

Then at that point we start thinking about “As a user, to solve this problem, what do I want? What is the goal? What, as a user, I want XYZ to satisfy, to fix that problem?” And we’ll step through a bunch of list of “I wants.” It sounds a lot like user stories, right? That’s what you’re getting at, is trying to kind of understand the goals of what you’re trying to accomplish with this feature. And when you do that with everybody in a room, you’re not only outlining all of these goals that you can eventually use on stories, but you’re getting a shared context between all of these stakeholders around what the problem is, and what the goals are, so that everyone walks away understanding the complete context around what you’re gonna build.

So that’s the point when I go away with this as a designer, start working on mock-ups and ideas, and then when we bring it back to the team, we’re talking about “These are the goals.” And we might not hit every single one that we identified in the meeting, but we’ll prioritize the most important ones, and point to like “Here in the design is where that’s reflected.” And then you’re having much better discussions at that design review, because everyone already has that context. And then once you break that out and folks are going off to engineer that… Like, I can go move on to the next feature, and get that queued up for folks while they’re working on the first piece, but I can trust that my tech leads and everyone has a really good idea around what it is that we’re building.

And when I skip that step, every time I’ve ever skipped that step, you suffer at the other end. You end up spending more time communicating that why to folks, because things weren’t right, or there’s confusion, or folks don’t know what they’re building… And it’s always a problem. So it’s never worth it to skip that step. It’s really important.

Liana, that was fascinating. That was a really good breakdown of how to do product, and how to do product well. I think that the Why reasoning that you and Kball were riffing off of was really cool. I’m really curious to know, how does the Why help you, not just in the way that you explain a product, but I’m curious, does your intersectionality affect the Why? I feel like you’re a theater person, you’re an engineer, there were so many things… Your intersectionality - does that help you tell a better story to engineers?

Yeah, I think so. Certainly, my software background helps me communicate with engineers more effectively… But I did wanna talk about my theater background and how that helps, because it absolutely has helped my in my career, both as a software engineer and as a product manager.

Obviously, I’m someone who can speak well. I enjoy speaking in front of large groups, I’ll enjoy signing in front of large groups… So I have no fear in front of chatting with folks, and that is kind of what led me making that step from engineering to product management. So definitely the oral communication skills were important.

But also, the problem-solving that has to happen, as in being quick on your feet… I will not say I’m the quickest person on my feet, but when a problem arises, you have to deal with it in the moment and be very present.

I was just telling this story actually to my son, which is kind of funny… I think we’re all familiar with West Side Story; another remake of the movie is coming out…

Yeah…

I was in a production where if you’re familiar with the story, Chino comes out with a gun and kills Tony, and Maria has a whole monologue about the gun… And there was one night where a prop person put the gun away, Chino could find the gun… A couple of things he could possibly have done in that moment, but he was panicking and he grabbed the knife from Act I, and stabbed Tony. So Maria is left with the knife, going “Every single line I have after this is about shooting people. What do I do?” So she had to think on her feet. And we all had to just kind of run with it and be present… And I was never more present than I was in that moment, because like “What is she gonna do?” But yeah, I was all like – I think the lines are “How many bullets are left in this gun, Chino?” “Enough for you, enough for you…” So she’s like, “How many people can I stab, Tony?” Yeah, it was just ridiculous. It was a wonderful, wonderful moment in theater where everybody was just like “Why did you change the ending?”

But I think that ability to think on your feet and be willing to roll with the punches and be flexible is just so important in life and in your job… And also being willing to laugh about it. Things go wrong, and what are you gonna do about it? I think your reactions in those moments are super-important.

There’s some fundamental lessons there, too… I’ve done a – nowhere near to the level that you have, but I’ve done a fair amount of improv theater, and things around that… And some of the lessons around – essentially, everything is about relationships. And I think especially engineers tend to fixate on the What, on the concrete objects, and the things that we’re building. but the way that work gets done is about the relationships and the interactions, and who’s talking to whom, and how are you co-defining this thing… And working in theater and in the arts - that teaches that like nothing that I’ve ever seen.

Absolutely. I love that idea of co-defining. That’s how I enjoy working with anyone; it’s a very collaborative environment, because that’s how you get the best stuff. And when you’re working in an environment of trust, and everyone’s working together - and that’s not to say that we’re not passionate, and don’t have opinions, and voices might not be raised, but it’s all in service of what you’re building together, and you can all be proud of it. That’s what makes me love building software.

[28:07] It’s almost like you knew what I wanted to talk about next, Liana, because you kind of hit on this really important topic of trust. I’m really curious about what makes for a good product manager? And I’m not saying this because Liana is here and Liana is my friend, but really, Liana, you are one of the best product managers I’ve ever worked with… You’re really well organized, you’re able to relay information… I would say you give us almost too much information, in the sense that there’s never a stone you leave unturned, which I love… Because everything you put together is always gonna be a good resource while the project is going on… And I feel like you’re incredible at that. So I’m curious, what makes for a good product manager?

Also, it seems like – you know, your theater background, your engineering background I think have helped you build empathy in different ways as well. So I’m just curious, what’s the secret sauce to a good PM?

When I think back to our relationship and some of the things that we worked on, Amal, it really was about me putting myself in the shoes of the engineer… Like, what would I need to know if I were building this, and what would I want to know? That really helps a lot.

The types of questions – like, if I were staring at a blank screen, what kind of questions would I have? So that’s how I start.

And then I definitely am someone who is documenting the heck out of everything, and I think – we use Confluence at my job right now… I know people have a love/hate with that tool… I really actually enjoy using any tool where I can just organize my thoughts. Because if I can put that down on paper… I’m not really great thinking on my feet when I speak, but I certainly can write a good damn paper. That’s where I think it’s helpful to me to put my thoughts down and organize them just for my own self… And then you’ve got a document that you can share around with other folks. So I think definitely starting to collect materials that are helpful is an important part of being a PM.

Like a one source of truth.

Yeah. Well, I mean, those things get out of date so quickly and whatnot… But in the moment - yeah, I mean… I’ve written so many pieces of collateral, it’s ridiculous. And they’re gone in the ether. It’d be cool to look back on my life when I’m 90, look at “How many one-pagers did I write over my lifetime?” It’s ridiculous. But at the time, it helps me collect my thoughts and communicate them out to other folks. And I love the collaborative nature in some of these tools now, that we didn’t have 10-20 years ago. It’s great… You can have folks making comments, and changes, and you just kind of work async on a document and come into a shared vision, a shared communication around what it is that you’re doing. I think I went off-track of your question there…

No, you – yeah, I mean, I certainly think having resource materials, having a single source of truth, even though it might get irrelevant later… But I think having something you can point people to at any given time… Like, “Here, look at this.” That’s very helpful, I find.

What are some of your biggest challenges? What’s really hard about being a PM on a day-to-day basis, weekly basis, monthly basis? I’m sure that changes, but I’m curious what’s hard.

Actually, before we go there, can I hijack slightly and go a little deeper on one of the things?

Oh, hijack away, KBall.

Well, so - some of the stuff you’re talking about got me thinking about this sort of core challenge of being a PM and working well.. So, I especially highlighted – I think we were talking earlier about how much of a planner you are, and I think a lot of what product managers end up doing is planning, and documenting, and pooling everything together. But I think one of the really interesting challenges there - and I say this as someone who’s not a good planner - is how do you do that planning and coalescing, while still leaving room for co-creation in the moment? So we’re going down this, we’ve created all these things, we have this big plan, and suddenly, for example, the tech lead says “Hey, if we do this piece of work that you’ve already highlighted here, that actually opens up this whole additional set of things that we could do.” How do you manage the divergent pieces, while still trying to converge back to a coherent source of truth and plan?

[32:18] That’s a fantastic question. It’s the difference between waterfall and agile.

I feel like it’s also a polite way of saying “How do you herd the nerds back to the right direction when they’re going off in different ways?”

[laughs]

Yes and no… Because I think that sometimes those diversions or those new possibilities - that’s where the magic ends up being.

Certainly, certainly. In software we have rituals, right? We have the daily standup, we have grooming sessions, retros… And that’s a process. Having a strong product process is where the rigidity is… But it allows for the creativity outside of that.

For example, that storytime meeting is super-important. That’s that moment where we get to do that kind of brainstorming and just let ourselves go wild with all kinds of different ideas, what might the user want, and start to really be creative. And then we go away and I go with my designer, and then we start to kind of confine that a little bit more.

One of my favorite designers that I ever worked with - she would call her design “her dream Barbie design.” She would take the feature and build out this – not just the feature, but how should this entire section of the application look and feel. “If I had unlimited time and resources and abilities, what could I build?” And that’s what we would start with; like, “Okay, we’ve got all this magic”, and then we would bring that to the tech lead and go “Okay, but we’ve got a month to build this. So what does that look like? If you were only given a month, what pieces of this are the most important pieces for us to tease out of it?”

It’s kind of a push and pull. It’s like allowing people to be creative and expand out, but then reining them back in again, and out and in.

So from an engineering standpoint, I will carve out pieces of the dream Barbie design and will focus on that piece, but then we’ll go into grooming and talk about the different ways you might architect that, and what might it look like, and have those broader conversations that start to lead to “Well, gosh, we could architect this thing, and I need to refactor that”, and all of those… Which are really important and necessary conversations. Then we come back to the timebox, and like, “Okay, these are things that we wanna do, and let’s keep those in mind”, and I’ll find places to archive those ideas, so that we don’t let go of them… But like, “Okay, now in the timebox, what can we reasonably achieve, given this broader vision?” But if you don’t have that broader vision and you’re only focused on the small thing, you never get a chance to innovate or be creative, and you’re never building – like, you’re building the okay thing, but not the awesome thing.

For me, I can tell you that as an engineer, I always want as much context as possible. So the “dream Barbie design” is what I wanna know. I’m like, I wanna know where we’re trying to go now, but I also know where would we like to be next year? Because I think for me, when you’re in the coding, you’re making those micro decisions, and you can design with tomorrow in mind. So you don’t have to build this rigid system where you’re coding everything to be statically for today. Like, “How do I make this an open design that’s extensible?” And I think having that context is really important, and that comes from, again, working with a good product manager that is able to share “Hey, here’s what we need to build today, because of constraints.” And again, constraints are super-important and healthy, but “Here’s what you’re gonna hopefully be building tomorrow. So don’t make the code that you’re building today - don’t make it difficult to get to the next place tomorrow.”

To Liana’s point, be agile about it, too. Imagine you’re going to revisit. One of my favorite things about software is when I build a piece of software and people start using it and it uncovers the fact that it’s incomplete. Our vision may have been complete in itself; we built this thing. But when people get their hands on it, they start to get excited, and they say “Oh, wait, what if we could do this? Can I do this with it? Can I do this with it? Can we make it do this?”

[36:15] That is successful software. Software that the act of using it is driving new ideas for how to improve it. But that’s like changing your Barbie house and saying “Okay, my Barbie house is beautiful, but it needs a turret over here, now that I’ve played with this part of it.” Like, how do we keep moving and iterating on that vision?

That’s why you should never actually build the dream Barbie house, honestly. You should have the dream in your head, but the dream is gonna morph and change over time as you build different pieces. So yeah, eventually there could be a turret. And a moat.

And a moat. [laughs] Yeah, I’m really liking this concept of constraints, but leaving room for magic, but then also not leaving too much room… There’s so many different factors here. It seems like this is baking, or something; like, we’re trying to make the perfect cookie, or we’re trying to make a meringue get all the balance of the science correct…

I mean, it’s organic, right? We’re creating a garden, or something. We’re growing things. Some things will go as we planned them, and some things will develop turrets.

Right, yeah.

This is how you can build software. This is what I did at the MBTA. We knew at the time that I joined that the website really just needed a lot of help. It hadn’t been revisited in a lot of areas. We really needed to touch every single area of it. So there was so much to do, it was just like, “Oh, there’s so much. Where do you even start?” But after creating a roadmap and timeboxing things, it’s like “We don’t have to get it 100%, or make everything perfect all at once. Let’s just get the best 80% out of it.” Or just how far, given that timebox - I’m doing this with my hands, making a little square… With that timebox, how far could we get? And if we solve enough of the problem that we were trying to correct, let’s move on to the next thing that’s on fire. And the next thing.

So you’re doing what you can, given the constraints that you have, but keeping this dream Barbie vision in your head, and moving along… And you’ll be surprised at the end of a year, or even less than that. When you look back – I love doing retros… Like, “What did you do over the last year?” Because you’ll be shocked – I’m always shocked at how much we were able to accomplish in that last year, just by being focused and keeping this vision in our heads, and trotting along… Certainly, it’s a painting that is never complete, but it’s a pretty damn fine painting by the end of the year. And certainly there’s more that you’re always gonna wanna do, but as long as you’re pretty methodical and careful about solving as much of the problem as you can given what you have, it’s amazing what you can accomplish.

Alright, Liana, that was pretty magical, if I say so myself… I think this whole concept of building in iterative chunks and never being done is really the core thesis of software development… And I’m really curious how you deal with that, like, never being perfect, never being done. Software is this living, breathing thing, and it’s never, ever done, right? There’s always another unit test you could write, there’s always another thing that you could do, another language that you could translate and add to your website. There’s so many things. So how do you deal with that backlog management, but also, how do you deal with focus as well? Because backlog management is this focus exercise, right? And so how do you figure out what the most important thing that you need to work on next is, and how do you balance than with tech debt, and all these other competing priorities? I’m curious.

Yeah, great questions. I mean, it’s not an easy thing to keep space in your plan for refactoring. It’s not an easy sell to the business… But having come from the engineering background, it’s something that I always try to make space for, make room for. I liken it to a chef in the kitchen; if you’re cooking and you leave all the pots and pans around, eventually you won’t have any pots and pans left, and it’s all dirty, and it’s a big ol’ mess, and you’re gonna have to clean up at some point. And that’s appropriate when you’re trying to whip up something quickly, like a prototype, to see “Is anyone even gonna eat this cake?”

But at the end of the day, at some point you’ve gotta clean up after yourself, and if you want to have some code that you’re gonna maintain or keep over time, if you’re cleaning as you go along, it’s just an easier and a better time for everyone. I was a girl scout back in the day, so it was always “Leave the place better than you’ve found it.” That was one of our mottos. So when you’re touching a piece of code, that’s when you refactor.

Yeah, I couldn’t agree with you more. An analogy I like to use is like brushing your teeth every day, versus once a month… Big difference. Once a month for like an hour is not the same as like every day for two minutes.

It’s so important to leave space for product managers to keep in mind that they need to make space for refactoring. And one thing I like to do, which is always a hard sell, but I will sell it no matter what, is that December should never be a month where you’re shipping features. I just don’t believe that. We’re all in holiday mode, folks are focused on other things… It is the perfect month to be thinking about a refactorpalooza. Like, let’s just take all of the things that have been annoying us all year, or the backlog that has accrued over time, and just kill it throughout the month of December.

Inevitably, there’s always some small feature, some need that the business needs at the end. Always, always. But try to slim it down or keep it as small as possible so that we’re making space for that… But I don’t just wait until December, honestly. If we finish a feature early, or we get to a good stopping place in our timebox and there’s room left for a refactoring, I let folks do that. But when we’re building our estimates, or trying to figure out what we’re gonna accomplish in that timebox, we’re always going to have a conversation of “Okay, what areas of the code are we touching, and how can we refactor that, and how can we fit that in as part of what we’re doing?” Because part of building a new feature is fixing what was left behind, and making it better; that backend cleanup is part of building the frontend feature.

[44:04] Question related to that… So there’s kind of a couple fundamental layers that one could take that. So there’s this ongoing maintenance, refactoring; this thing didn’t get quite done, or didn’t get quite cleaned up, or we were in a rush… And I think leaving some space between projects, we’re planning an infrastructure week, that type of thing - that’s a great way to deal with that, is just leaving space, leaving breadth when you finish early… Like, if that ever happens in engineering, then you have time… But the question I have for you is how you think about prioritizing larger-scale changes.

An issue has come up, something similar keeps happening over and over again, and it’s starting to look like actually our infrastructure under this feature is not good enough. Or we need to pull in or create a new system to handle a whole class of problems. It’s not gonna be feature-facing, it’s not something that’s actually going to deliver immediate business value, at least in a way that the business is used to thinking about it… But it’s gonna take, let’s say, a solid month, a full project of this engineering team, or it’s gonna take some other time. How do you think about prioritizing those types of projects relative to business features?

Yeah, I mean, you’ve hit on the answer partially there in the question… You need to find what the business value is of that work. Because if there is no value to the business, there isn’t a point in doing it. So why is it valuable to do refactoring work? Why is it valuable to build out infrastructure in a better way, or in a new way, and what values is that gonna bring? How much development speed comes out of that, how much money are you saving because now you’re not paying for third-party services? Things like that.

We did some work at MBTA where we had been using Google Maps, and they’re incredibly expensive. And we wanted to swap to using something that was open source and was free… But it was a big project, that was spanning a large amount of time. It was an easy sell, because I’m like, “Hey, I’m gonna save you $10,000. Can you give me some time to do that?” Like, sure.

When you can add the financial value there, or the benefit eventually to the user, and make that apparent, that makes selling those projects easy. And I think it’s easy to sell too on refactoring. The business never says, “No, please don’t refactor and make code beautiful.” They just don’t understand the value of why that’s important. I like to work for organizations that do value that and understand why that’s important. Certainly, there’s a balance between everything being perfect and beautiful in code, and having no value to the user. You’ve gotta just balance those things. But that’s why they say PM-ing is kind of like juggling. You’ve gotta juggle all of these different priorities and concerns at the same time. But that’s what makes it fun.

Yeah. I mean, PM-ing is like juggling knives, I would say, while being in the air and moving at 100 mph, up and down. It’s a hard job. You’re like at the tip of the spear.

Wait, when are we gonna just start selling people on moving into this, and now you’re saying I’m catching knives?

Oh, yeah, sorry. PM-ing is great. It’s like juggling flowers, and sitting in a bed of roses, getting your feet massaged. [laughter] Actually, I do wanna say though… This point that you’re making about tech debt refactoring, you need to kind of tie it to the business value, right? Like, “How does this improve the business value? How does this help our customers?” I’m totally with you, but I don’t think it’s necessarily an organizational thing though… Because yes, organizations that I think are maybe more engineering-oriented and less business-oriented will understand the value of tech debt, they will understand the value of testing, they’ll understand the value of software quality, and being able to obviously ship without breaking things.

I think it’s a marketing problem too, and I think the marketing problem is actually on the engineering side… Because so many engineers will say, “Yeah, I need to refactor this thing etc. because this code is bad.” But what they should really be saying is “Hey, I need to refactor this because this is slowing down every single release of ours, which means that our customers have to wait this much longer to get a feature.”

[48:05] So I think the framing is on us as engineers to make sure that we understand how this ties into the business value. And quite frankly, if you can’t explain that, then should you be working on it at all? Especially at work, is my question. So if you can’t find the business value…

Many engineers are bad storytellers. But the good ones maybe should go into product management.

It seems like that’s the going trend, Kball… [laughs]

But there’s another question that I ask an engineer when they wanna refactor something, like “Oh, this thing is bugging me…” Like, “Why is it bugging you?” “Oh, because I can’t do XYZ.” “Well, great, let’s expand on that.” Or if they wanna work on something, like “This is really cool, and it’s be really cool–” Great. Like, what kind of value would that bring?

If you were me, and you had to tell the CEO that you are gonna spend your month working on this, what should I tell them? And usually, even asking that question, lots of times folks just don’t even think about that. Like, “Oh, yeah, if I were to talk to someone about why I’m building this…” Then they tell me, fine, and I can put that into a story to sell.

Yeah. Well, what’s funny about that is I think there’s the exercise of the five Why’s. As a product manager, I’m sure you’re very familiar with it… But if you just ask Why five times, like, for every answer, “Okay, I need to do this.” “Okay, why?” “Because I need to do this.” “Okay, why?” Usually, by the fifth Why, the theory is - and sometimes before that… Like Liana said, she’ll get to it before that… But sometimes by the fifth Why you kind of really get to the core of the problem. And I feel like that is so much of product management, is really kind of sussing out, “Why is this really broken?” And I can share some experiences of product managers I’ve worked with.

I run to my product manager and I’m like, “We need to do this, this and this etc.” And they get me to understand why we can’t do it now, just by asking me why, why, why, and reminding me – like, it’s this amazing ability of knowing what the most important thing to do is, and understanding “How does this actually help us with our current objectives?” Because there’s lots of things you can do that’s important, especially at a startup. But especially in a startup environment though, you need to find what’s the right five things I should be doing right now. Because it’s not like what you should be doing, it’s like what’s the right –

Yeah, you’re talking about prioritization.

Yeah. It’s tough. It’s a really tough thing. It’s not easy to find the right thing to do in any given moment, and I think exercises like that maybe help you refine it.

They say that a product manager’s job is to say no, and protect the team. I try not to ever say no. I don’t say no, I ask the why’s… Like, “Why is this important?” and “Are you willing to sacrifice A for B?” Like, “Hey, we have a plan. How important is this to you, and to the business, and what value is it bringing? Is it more valuable than what we’re working on right now?” And sometimes the answer is “Yes. We’ve gotta drop everything and do that thing, because it would be just so beneficial to the company to do that.” But more often than not, it’s like, “Oh, well you know what - we have that planned, and we’re gonna put that in the backlog, and we’re gonna do that later”, because that’s where it fits.

But that constant revising and revisiting of the roadmap is what being agile is about. You learn things over time, you learn what’s important over time, and that’s how you prioritize things.

So if one of our listeners is listening to this and thinking, “Huh… Well, that sounds kind of interesting.” How do you know if you should investigate being a product manager? Say you’re an engineer, maybe you’ve been working in engineering five years, three years… I mean, let’s face it, most folks haven’t been in the industry that long yet. Like, how do you know, “Hey, I should actually go and think about becoming a product manager”?

I made, Amal, a list of “You know you’re a PM if…” and a bunch of statements. That said though, before I launch into that, I will say that if you’re a software engineer, stay in software engineering for as long as you can, because that’s invaluable.

[51:55] This is counter to the advice I thought we’d be getting, Liana. [laughter]

I mean, before I made the transition, I’d been doing software for nearly 20 years, and I have a lot of experience and stories that I can draw back on for my product management… But not that you should wait 20 years to become a product manager, but certainly all of that experience is really helpful. And the more engineering experience you have, the more helpful it is.

But let’s say you’ve been in the field for a number of years, and you’re looking for your next challenge. So if you’re the type of person who likes to know what features are on the roadmap, you might be a product manager. If you’re questioning why the new feature is gonna be useful, that’s a clue. If you like to understand the problem that a feature is trying to solve, and if you like to be involved into finding the solutions, if you care about the quality of the customer experience, as well as the quality of the code, you might be a product manager. If you love measuring success with quantifiable analytics and you don’t mind talking with users and other stakeholders, if you make sure the conversations that get alignment across teams happen, you’re the glue, and you might be a product manager. And if you’re comfortable with the 80/20 rule, and can solve for the most common use cases and balance the trade-offs and edge cases, if you have a calm and upbeat demeanor, even when chaos swirls around you, you might be a product manager.

Okay, but say I said yes to all of those things and I’m not a product manager… [laughs] Asking for a friend here, what might I know that would say I shouldn’t be a product manager?

Well, do you wanna do it? [laughter]

Liana’s like, “I’m hiring.” [laughter]

The hottest new job I guess in Silicon Valley is to become a PM… I’m like “Really?” I don’t know…

Actually, you know what’s so funny? I have this in my show notes, but apparently, the hottest new job at business school, at people getting an MBA, is product manager. They’re actually less and less interested in entrepreneurship these days and they’re more like, “How do I be a PM at Facebook? How do I be a PM at Google?” Which is interesting, that these business grads are more interested in becoming product managers than starting a business.

Actually, that makes sense to me… I mean, if you’re coming from a business background, that makes sense to me. If you’re coming from an engineering software background, it makes a little less sense to me, because – I mean, honestly, I miss programming. I miss it a lot. It was just really fun, and I don’t get to do as much of it; any of it. I still have my GitHub account, and I will peek into people’s PRs, and sometimes make a comment, which is usually just a thumbs up these days… But yeah, I do miss it, and I think – if you’re a software engineer who just really enjoys making software and talking to different areas of business and pulling people together, you find that you’re making less and less code, and you don’t mind, then that might be a clue that you’re okay with making the switch over.

Yeah. It makes sense actually, because the – there’s a big overlap also between senior engineers and product managers, and I think we were discussing this with Kball earlier… Basically, we almost have to define the boundaries of when is it a product manager’s role, versus a person on the team’s role. So there’s a little bit of a grey area Venn diagram.

Yeah. When I was brought into product management - product managers are incredibly technical and very deeply embedded in the teams; and yet, when I moved on from that role to other companies, the reverse was true. The expectation was on the tech lead to take on a lot of that product owner/project management piece of it… So much so that I wasn’t expected to write tickets or even attend stand-ups, which I think is crazy. Like, I need to know what’s happening, and what’s going on… I think the only way to keep things on the rails is to understand what people are building, and answer questions at stand-up. I just can’t imagine not showing up for that.

[55:57] But it really depends on the organization, and also the people involved. There are some tech leads that I can absolutely trust with that, and I can walk away and go focus on more strategic stuff. It just really depends on the situation.

But who should do what - it’s very cultural, around ownership and where those lines are drawn.

People come to product management from a variety of fields. I’ve seen your background - folks come from engineering; I’m seeing PMs who come from a design background… We were just talking about PMs coming from a business background… And actually, one of the PMs I work with now, who’s phenomenal, is coming from a behavioral science background.

Oh, fancy.

So I’m kind of curious what you see as 1) the advantages of coming from an engineering background, because many of our audience are engineers… But also maybe what are the blind spots or challenges you might have coming into product management from an engineering background, and how would you go about remedying them?

Absolutely. Coming from an engineering standpoint, I was able to hit the ground running on so many things in product management. It was great. And a lot of engineers do make that switch. Because I understand how to break apart a story, how to communicate to engineers and help them build the right thing. That’s awesome.

But where my blind spots are - and I’ve had to learn this over time, and it’s been difficult, is that business side. I don’t have an MBA, I don’t really wanna get an MBA…

It’s okay… This is a safe space. I don’t think anybody else – highly likely that nobody listening to this… I mean, very few people –

[laughs] I haven’t spoke to anyone who has an MBA. Actually, if you are an engineer with an MBA, that is a fantastic resume builder and a fantastic thing to have.

Yeah, I might be the only other person on this call that wants an MBA, actually. I don’t really want an MBA, I want an SDM, but anyway… I’ll put a link in the show notes to the program that I wanna join.

There’s actually one you can get now – there’s MBAs you can get that are software management-focused. That I might be interested in, actually. But the skills that you’re trying to flex there are understanding your industry. Understanding – like, can you figure out how much do you charge for your product? How do you figure out what kind of team that you need, and how do you pay for that team? How much is that team gonna cost? How much is a project gonna cost, and how many people do you need, and how much is all of that gonna cost?

And then there’s the marketing side. So there’s the business side, but then there’s the marketing… Like, how do you build a go-to-market? How do you let people know about this piece of software that you’ve built, and train your commercial teams, your operation teams, your users how to use this feature? All of that is more like salesy-marketing stuff, that it’s been very difficult for me to pick that up over time, just because that’s just not one of my brain spaces, so I’m constantly trying to challenge myself to be thinking in those terms, because it just doesn’t come natural to me.

Yeah, I can totally see how that is a huge mental shift… And quite frankly, it’s the deterrent for me when it comes to product, really… I don’t enjoy making slides, I don’t enjoy having to constantly pitch, and I don’t enjoy writing oodles of documentation, which is a key thing that you need to do as a product manager, because otherwise…

As a tech lead too though, don’t you think? Tech leads need to write architectural documents, right?

Yeah… Let’s just put it this way - it’s the thing that I like the least about my job. I would much rather like “Can I just put this into an audio doc, and then somebody else type it up for me?” It’s a hard job.

I totally hear you, Amal. I love about of things about product. I love collaborating with product folks, and I’m not enough of a planner or an organizer to be an excellent product manager. I partner really well with those folks, but… Yeah.

Yeah, that’s the space that I’m in.

There’s a lot.

Yeah. I’m a really good partner, I think… And I think trust is important, because –

You are a really good partner, Amal.

Oh, thank you. I appreciate it. But you know, you have to be able to lean on each other and trust each other and understand when it’s that other person’s job, and when it’s your job. So that’s the relationship I think between the tech lead and the PM.

So Liana, this has been a really, really insightful and really interesting discussion. I wanted to say, thank you so much for all of the insights. I think we have an Easter Egg surprise, which I’m not sure where we’re going to insert it, but… Let’s just put it this way - Liana is a singer…

We have a history of incorporating singing in our podcast, though most of us are not nearly as talented as I think Liana is.

[laughs] Well, I told you that I like mash-ups, so it’s always been important to me to bring all my passions together… So I tend to sing about tech issues, or technical things. or just goofy technical things. So I’ll leave it at that…

Yeah, exactly. And maybe the surprise Easter Egg is something about Unix… And I’ll leave it at that.

In a very old and tired meme.

Old and tired meme, yes. That, too.

I’m excited. I haven’t seen this.

Yeah. So where can folks connect with you on the internet, and where can folks find you?

I’m @lleahy on Twitter, and liana.org. I got that back in 1995…

Yes, this is where I’m starting to realize, Liana is like an Eternal. I don’t know if anyone is familiar with Eternals. This is like a new Marvel spin-off… But they are these people who live forever, and they all look like they’re 33… So you know…

[laughs] Yeah, we’ll see how long I can pull that off.

[laughs] Anyways. So Liana, thank you again. It’s been an absolute pleasure.

Thank you!

And we hope to have you back on the show in the future. Everyone, have a wonderful, wonderful day. Take care.