What Is a TPM, and Why Does the Job Feel Harder Than Ever?

Danielle0:00So, welcome everyone, and thank you for being here. Today is the first in a series from Understory Collaborative, and today we're talking about what it actually means to be a technical product manager, and why the job feels harder right now. This is a conversation our panelists, have been discussing amongst themselves. And, today we're going to just have them, responding to each other as much as to me, about challenges, what they see on the horizon, and, how we can move forward And the great unknown of technical product management. So, without further ado, I'd like to start off with our panelists. Each one of you guys, if you would start by, giving us one to two sentences, how you would describe, technical product management and, this to someone outside of tech. So, let's start with Al, since that begins with A. A few words about who you are, a little bit about your background, one sentence, and describe technical product management to us.

Al1:15I've been, and I only added it up, about 10 minutes ago. I've been in either startups or, large companies, For about 35 years, working in some sort of technical or leadership capacity, which is cool, but also humbling. So, you know, I've seen a thing or two in my lifetime. right now, you know, working with all these great technical product managers and learning a lot, I love that. And I've always been between, somewhere between the… in this netherworld between technical and leadership and marketing and sales, and… which is kind of perfect for our technical product managers, since they need to be able to speak all these different languages. The bridge between business intent and technical ability.

Danielle2:04Wonderful.

Al2:04translator, I guess.

Danielle2:06Yeah, yeah, I think that's a really important role for a technical product manager, or a TPM. I'm going to start saying that, because technical product manager is a mouthful. Let's go with, Jess. Won't you introduce yourself and tell us a little bit about TPM?

Jess2:24Yeah. Hi, I'm Jess. Every job that I've had really comes down to one question. Can you trust where this data is going? For the last 20 years, I started out leading an audit team for law firms on large class action cases. We handled HIPAA-protected medical records, where one mishandled file was a legal problem, not a bug. And then, in the last 13 years, I've really spent it mostly in ed tech, where the data became student records. In my first, TPM role. I own the integrations roadmap, so single sign-on, rostering, connections into learning management systems. Today, I'm a TPM on a college and career planning platform, and it's still all integrations, under the hood. So, I care about TPMs, because in regulated spaces, the risk isn't inside any one system, it's in the seams in between them, and somebody has to own those. I really like, what Al said about the, translator for any of the Farscape fans, if you're into sci-fi, right? That translator microbes, that's really where TPMs tend to need to excel. So my version of what does the TPM do in plain English is really, we make sure that all the pieces fit together, and that nothing sensitive leaks out in between the gaps. when, whatever the problem is, when a student can't log in on the first day of school, nobody really cares which system along the path broke. The TPM's the one who knows where to look, and how to get it back on track quickly.

Danielle3:50Thank you, that's wonderful, and I'm already seeing, some… some linkages between translation and also, you know, looking at the spaces in between and finding out where the solutions lie. Webs, you're up next.

webs4:07Hi, I'm webs, and I'm speaking to the spaces in between in this translator. of it all. I actually started my career many years ago in education, and then moved into tech. I wasn't always a TPM, I started out as a developer, but I think part of that technical expertise is what supports the type of TPM that I am, in that very similar to what both Al and Jess said. It's the paying attention to the seams of things, because that's where they're… where processes and projects can be the most fragile. and also making sure that we can do that translation from business into technical and back, so that nothing gets dropped and nothing gets lost. I would add on to that, probably, that, There's quite often an aspect of… Making sure there is accountability, traceability, and a bit of cat herding. That, for some reason, is a recurring phrase whenever someone seems to want to talk about technical product management things, is the herding cats of it all, because you kind of become this person who, Has all the little bits and pieces of a given, project or product strategy, and you make sure that they all stay aligned so that things can get across the finish line. I think that's the importance of the purpose that a TPM serves.

Danielle5:35Great, so… translator. the space in between, and cat herder is what I'm hearing a TPM is. All right, so, I neglected to introduce myself. My name is Danielle. I am a service designer and design strategist, and I think that, the qualities of TPM, kind of overlap with the work that I do, and looking at The overall structure of a problem or an organization, and finding out how improvements can be made, at what points in the journey, and how the service that, is being designed, can be improved, and I think that a technical product manager, really does have a role in looking at, not only the structure of the program that they're working on, but also the user as well. introductions having been made, let's move on to our first question. What's the difference between a technical product manager and a product manager? What is it that… what's that technical part that, differentiates it?

Jess6:50Alright, so the textbook answer, right, is a product manager really decides what's worth building, the, like, why of what's being built, and a technical product manager is really all about making sure it fits. And then this really changes depending, like, the line between the two, changes depending on the org. So, we're probably all pretty familiar with that Venn diagram that has, like, product managers on one side, technical product managers on the other, there's a cute little overlap, right, where we're sharing strategy and road mapping and features and go-to-market. And in that idea, the product manager is supposedly customer-facing, and the TPM is internal. They overlap on just the strategy and the roadmap. In a small company, those lines might blur together, but in a multi-platform company, someone has to own kind of what we talked about before, the seams in between the products, and there are a lot more seams. I would probably, to that Venn diagram, kind of push back, on the idea that TPMs are really only internal-facing. When I owned, rostering integration from 0 to 1, that included shopping for a vendor, building, working with, you know, a development team from a technical aspect to make sure they had the information necessary, and that was really more the how to build against that vendor's API. And within one fiscal year, we were offering secure connections to over 100 different, student information systems, and that really turned integrations from a sales blocker at that company into a selling point. Those districts went on to become, some of our first beta districts went on to become success stories, and, I presented with them at Learning Impact, which is, one of the EdTech Industries interoperability conferences. At a similar company, I also helped consolidate 8 products on 6 platforms, down to 4… on 3, which was really table stakes for winning the 2 largest clients in that company's history. And so, the idea that technical product managers are really just internal-facing, or they just write user stories, or just work within a sprint team. Really doesn't fit for the way, that companies, businesses, expect and need technical product managers to. Exist and help out today. I'd love to hear from webs or Al. Have you seen the TPM cold, kind of, customer side like that, or what has your experience been?

webs9:23Do you want a paper, rock, scissors for it, Al? Okay. I think it's actually really interesting, because I find that… more and more, especially given how ai is changing things, that, the lines are being blurred. into where the actual boundaries are. For example, I've seen quite a few job postings lately that are technical product management postings that are… which I view technical product management as more of a strategic level, at least it should be more of a strategic level role, and yet these job descriptions are asking for tactical-level skills, things like being able to work with a development team, or two, or three, and being able to kind of even step into, an agile coach role in order to do that. Personally, I think there should be a… there should be a stronger separation if you want to go that route, and also, maybe everybody should have a little bit of Agile Coach in them, because I think, as… Paula Paul, has famously said, the people, or the technology is the easy part, like, the people part is what makes it more challenging. So, for example, when I was a TPM at a previous in a previous role, I did serve at that really broad end-to-end, you're working with the companies every day, doing Scrum meetings, you're kind of serving in that agile coach role, and on the positive side, it moved those teams from Producing at a rate of, like, 8 points per sprint up to, like. 70, 80 points per sprint. Not that that's everything, but also that overall quality of the team and how they work together improved over that time. And I don't think that's a typical thing that a lot of people think of as a technical product management role, right? Or a skill. It's something that's more, that role is something that's more strategic, and… I think that's one of the things that maybe makes it a bit different, because I don't know too many product managers who are asked to step into that role of being that close to the development teams. So, I guess that's one of the differences that can occur, but… kind of what Jess had started to say, it really depends on the company, depends on how they define the role. I think if we're talking, like, what my philosophy on it should be, it would be that that division is, that the… Technical product manager owns, sort of, the more… The communication with the team, but also all the things that come with the technical perspective of, like, how are we building this architecture? How are we advocating for making sure that the product itself, so not thinking in a project mentality, but a product mentality, that the product itself is being cared for, including things, technical things, like ensuring that the technology stack is kept up to date, so that things can keep running. Making sure to be able to have that conversation about advocating for those things that May not be shiny new features on the front end that customers see, but ensure that that product is reliable, resilient, and dependable for the customers, so that as we build shiny new things on top of that platform, it continues to delight our customers. I think that's probably the biggest difference that I see between a PM and a technical PM.

Jess12:59Yeah, I would definitely… Sorry, Danielle. I was just gonna say, I would definitely agree with that. I think I've heard it phrased before that TPMs really, they come with that kind of Mary Poppins-style bag, right? And depending on what the team needs, or what the organization needs, right? Like, what the ask is, that role and that individual often is having to hold together what you were speaking to, webs, with those two pieces of, here's everything that we need to do from a technical perspective, and to keep everything Up and running in the way it should be and secure. And then also, the… we can't forget about the outcomes. Right? Because it can't all just be, we are perfectly polishing it, delivering it exactly on time, if that never actually moves the needle for the company, because at that point, we're kind of missing it altogether. And then advocating for… for whichever, side kind of needs to hear that more at the moment, depending on what's going on. I love the way you phrased that.

Danielle14:08Al, I saw you nodding, at different points, that webs and Jess were talking about, and I was wondering if you could Expand on that.

Al14:18Oh, very… no. I'm glad they answered first, for one. And if you'd asked me this a year or two ago, my answer would be different. But there is so much overlap. There might be people in here listening, that are product managers, and when you describe some of the tasks of technical product managers, and you think, wait a minute, they might be thinking, that's what I do. Right, because you live in that overlap, and every organization is a little different. Not bad. Maybe if you're overworked, then maybe we need to look at, you know, how work is structured. But there is… but I think that for me, and every… they answered it better than I could have, but… In my head, the thing that sticks out most of all is scope. The product manager is typically focused on the product, whereas a technical product manager might have many different products that they need to keep in play in many different architectures, and keep the architecture people happy, and make sure the thing can grow, and… Can we, you know, make a big sale and bring in all these, you know, do we have the technical capability to house all these customers, which as I worked with webs, we came up with one very large company where the answer is no. And all of us was like, what? Like, yeah, and here is why. That's why you need a technical product manager. But yeah, they answered it far, far better than I am. I could…

Danielle15:43I think that the points that you brought up kind of summarized a lot of what webs and Jess were saying about having a strategic overview of Not only the project at hand, but the product as a whole, and also the business goals, of the client or the company that you work for. Webs, you brought up, ai, and, these days, everyone is saying ai makes them more productive, and they find it really helps them think things through. So what I'm wondering is, you know, how does that affect TPMs? Are they seeing better product outcomes, or is there, a gap for them?

webs16:32I think there are… definitely benefits and downsides, and I don't know that they're… I don't know that they're unique to the TPM role. So, one of the benefits is things like, in a previous role, I was able to, produce mock-ups for teams. much more high fidelity, much more quick, and make changes more quickly as well, because of ai tools. So I think that's one benefit. Another benefit is you, depending on the structure within your company and how you've set up your ai tools, you can have, answers at your fingertips. And I think, Al can probably talk a bit about Databricks, maybe in a little bit, but, and Genie. But, Having those answers at your fingertips and not having to, distract a development team to get the answers you need can be really helpful. The downsides, however… Are you… there is still value in keeping that expert in the conversation, when it comes to things like spelunking for answers. So say, for example, I'm looking for an answer, trying to find out if… how the code works, and if I were someone… if I were a technical product manager who didn't necessarily read code, and I asked my ai, I wouldn't have a way to validate that that was the case. I would still have to go to a developer, and it does shorten the conversation sometimes to say, hey, this is what I found, does this sound right to you? And they can validate what you found, or they can push back and say, oh, that does not seem at all right. But there's danger there if you don't realize that that's a check you need to do. personally, I can read the code, so that's really helpful. But not everybody can, so I think that's one place where it can kind of be dangerous. The other place can be in, if you're not refining the outputs, say you're producing a document, maybe a strategy document or a deck or something, if you're not working hard to refine those documents so that they are concise and speak to your very specific audience, they become these big, long ai slop things that nobody's ever gonna read. So I think you always have to keep in mind, like, who is your audience here, and what are you trying to communicate to them? Even when you're using ai tools.

Danielle18:52Al, did you want to expand on that? Databricks, and… I think you said something else? webs?

webs19:01genie, and just the access you can get to a large dataset built into that particular platform. Pros and cons and things to look out for.

Danielle19:11Right.

Al19:11So the genesis of the question was, everyone says ai makes them more productive, and how does this affect TPMs, right? And then webs brought Databricks, because I'm currently working on a… Teradata to Databricks migration. And the expectation that now that it's on the cloud, and now that we have ai, we will be faster. The lower you go down the corporate food chain. The fewer heads in the room will be nodding to that thesis, because it takes a heck of a lot of setup, and… and… and can we do it? Do we have the people? What are the best practices? I… there was something that came up last week, and I've been poking people about it for the last two weeks, and finally it got up to the right people, and we got somebody in, and we asked this Spends all day in Databricks. Okay, what happens in this situation? And he said, I don't know. I need to come back. Okay, well, look at that, you know, he's the expert, he's been doing this for, like, three-something years, and migration all throughout the company, and he doesn't know. He's not bad, we have a unique situation, but the expectation that Ai will make us more productive. That… I'm not sure yet. It makes it more productive in some ways. There's a study that came out that said, yeah, they're from Harvard Business or somebody. Sure, you're writing more code, but the bottleneck now is code review. Okay, now, as a TPM, what do you do now? Do you automate that? someone's gotta be responsible, you cannot… can you? Do you change your… so there's a whole architecture, there's a sea change, and there's a bunch of different ideas And nobody knows exactly what to do, because this is so brand new. And so we've got to be comfortable with making mistakes, but also got to be comfortable with telling the executives who read stuff like… Time, or Barron's, and you're… that ai… wow, look at this, I can… this ai thing, man, I can lay off 20% of my company. Doesn't work that way, you know, you need to… see where it fits, where it fits with your architecture and your people, and your training. There's a whole mess of things you gotta be changing. It… from our standpoint, in code anyway, it sped up one part. The other part… the other parts, we're trying to figure out how we can… we can unblock that. And even the parts that it sped up, is it better? Does it affect your DORA metrics? Are your failures less? Can you push code faster? And if you can't, and it's all the same. Well, that's not ai's fault, that's your organizational structure's fault. Again, something you… but the people who don't look deeply into these things might be like, oh, but I gave you ai, you should be faster. That's the big lie that is going on, and… and like I said, people who are… who got their hands on their keyboard, they… they… huh, yeah, sure.

Jess22:15Yeah, it can make some work faster, but it definitely doesn't make the handoffs faster, right? And so that those handoffs between teams, between different parts of the org, even between just people who maybe, like, if we use the the dreaded, bad RACI word, right? Even if you are responsible versus accountable, and you are a team passing that ball back and forth, that handoff still takes time, and it should. There should be some intentional friction there, because humans don't think at the speed of ai, and they're… Ai should be one of those things where we are handing off the paperwork, but we're never handing off the accountability, right? So, sure, we can stop writing status reports or meeting recaps. Maybe we let ai handle the shitty first draft of release notes by hand, but there's still a human who's going back through We're never handing off deciding who sees our data, where it goes, who's accountable. in legal audit work, the rule was always that a fast review basically meant nothing. If a record reaches the wrong party. That's it. Ai can draft the answer, but it can't own it, and that is where, having individuals, teams, TPMs with experience in knowing what is, bringing me back to what webs said earlier, knowing what is, actually useful and valid versus just looks really good.

Danielle23:40Yeah, I think that, you know, the question of productivity and handoff, and the choices that, a TPM has to make. When it comes to ai, is a topic that… deserves a lot more discussion, and, is probably going to be evolving over time, as Al was saying. If you all had to give, you know, advice to a TPM about one thing they should never hand off to ai? What would that thing be?

Jess24:17I'm going to go with, I already gave my answer. So the, the, like, I wouldn't hand off the accountability part, right? Or that, that piece, I wouldn't even hand, hand off that very final, review, like, maybe ai does… after our… the human has already checked through all of those critical pieces, sure, ai, we can use that, like, spell check, right? Like, it can be that kind of thing where it is checking the pieces that maybe, you know, executive function, you've already pulled your 16-hour day, right? So you're not necessarily getting all of the periods in the right place. Those are important, but also ai can totally help you out there.

webs24:57Okay, I have my answer.

Danielle24:58Yeah, sure.

webs24:59So, I was actually thinking a couple weeks ago about… what are… what is my, sort of, in the… in the spirit of the Agile Manifesto, like, what is my manifesto around ai? And one of the rules that stopped, because I… I also wear the hat of security specialist. is… was, doing risk assessments in security, and, doing threat modeling in security. And so, one of my tenets is, risk over rules. So, when I'm thinking about what is the most important thing to hold onto, I'm thinking about what damage does it cause if I were to hand this off to ai and not look at it again? And that's kind of the… ironically, like, a rule. That I kind of… or a consideration that I have when I'm thinking about, is this a thing I should and can hand off, or should I keep this in my purview, to be the final say on what this is, is what harm could it possibly cause if I were to let this through? So, if it's something like, you know, drafting an email response. that's… it's probably fine for it to draft the email response and me to edit it and then send it off. If it's just firing off the email. maybe I don't want to accidentally send some nonsense or some, like, very obvious ai slop to a bunch of people, because I think, kind of echoing what we've been… what we've said in this group of responses, I think the connection between humans is one of the most important pieces to continue to hold in your, purview, because those relationships, you know, technology's the easy part, those relationships are the things that are really important. Those are the things that make it so that if something happens, and you need to get it done quickly, usually you can go to another human and say, hey man, I have this situation, it's… can I call in a favor, and you can help me get this through, and it's that human relationship that you're relying on in those situations. And I think that it's the human at the center of everything that's the most important, generally speaking, as ai becomes more ubiquitous and pervasive.

Danielle27:11I think that's an excellent point about the human, and, you know. as far as I'm concerned, you know, experience and the user are always at the center of, my thinking, so I'm just a little bit biased when it comes to that, but having said that, let's, like, you know, let's talk about the human. You know, we've been talking about the TPM, but, there is also a question of the people that the TPM work With? And, specifically, you know, we're hoping that we have some non-technical leadership watching this, and if they're wondering, you know, if their department or whether or not their department or organization would benefit from having a TPM or working with a TPM, What advice would you give them? in… Considering whether or not they need one, and how to select one.

Jess28:08I think one of, so, like, one of the things that comes to mind, if the… if your problems are showing up between teams, right? Not necessarily just inside of them, you might need TPM thinking, right? That… that translator, microbe piece of it. Three signs could be deadlines are slipping because of dependencies, but not effort. You can tell you've got a team that you're pretty sure they're working really hard, but you can't really figure out where is that breakdown, right? If you have something or a large workstream coming up, Where sensitive data is processing vendors or systems, and you really need someone who's able to map that all the way through and understand from multiple lenses what are the key pieces to sequence at the right times. And if nobody is able to answer who owns this, right? We've all been in those rooms before, where you've got an entire group of really smart, talented people, and they're just sitting there pointing at the problem, right? Lots of times, TPMs, step into that space. You don't always need a, full-time hire to fix that. Sometimes you just need someone to own the seams long enough to get them right, to really, teach the teams how they can better work with each other, put some good processes and practices, and really, you know, see one do one, teach one. In that… in that respect, that might be, how I'd phrase it for… for a non-technical leader.

Danielle29:37Awesome, thank you. I think that's… that's a really good starting place for someone who may not be familiar with TPMs and the kind of work that they do. Al, do you have any thoughts about that?

Al29:49No, Jess said it, great. If you've got dates that are slipping, you got vendors that can't make their dates, or there's some integration that's not… going on, if you've got status updates that don't match with reality, you, you know, look at the TPM. But this is a message also for the people that are hiring, the deciding if a TPM or a PM, replacement or whatever is needed. Those people also need to have the humility to hire someone That has the ability to tell them no. That's the hard part of a TPM, one hard part of a… the whole job is hard. But… but one hard part is… Sometimes the stakeholders are unreasonable. Let's take ai that we're everyone… you know, but you have ai now, can't you push it out by Friday? No, I can't. And you have a seat, close the door, and let me explain to you why. So when you're hiring that, you also gotta look at yourself and go, okay, you know, are they missing deadlines? because of, like Jess said, they might be just working and very smart, very dedicated. But it might be some of the deadlines that you've imposed on them are unrealistic, or some of the things you promise are unrealistic. It could be some of the things in another department that you don't know about had promised. That now, the bill, you know, that someone in sales promised something to a customer, now someone in the technical department has to pay for that bill by developing, you know, a feature that has never existed before, you know, by, you know, 3 o'clock. Okay. These are the things that a TPM would not only look at, even though it's as technical in the title. They have powers beyond the technical, because they need to be able to go out and touch, and sometimes, higher up the food chain and say, listen, you gotta prioritize these things. You gotta, you know, be reasonable with these dates, because if you're asking for all this stuff. Tell me which of these 3 fall off. Because everything's high priority. But, you know, our capacity is this much, but you're asking for that much. Anyway, sorry, I… as you can see, that is a sore point for me. But you gotta be humble, you gotta be really realistic. These… people are honest, they're trying to… they're trying their best, but sometimes, you know, you got people that don't understand the tech. making the decisions for the people who do understand the tech. Yeah. That's what the TPM gotta balance. They have to balance.

Danielle32:15And I think you raise a really good point about, humility and, the relationship with the decision makers, I think a TPM really is someone that not only do the executing teams trust, but also the decision-making teams trust, so that they can bridge that divide and provide the kind of feedback and pushback sometimes. That, you know, executives need. Webs, is there anything that you wanted to add?

webs32:45I would say… I'd answer the… when you're… how do you know if you need one? I've noticed, like I mentioned before, that there are a lot of, especially with ai, there's a lot of expanding of the continuum of responsibilities for given roles, like. One of the things I'm seeing more commonly is a development manager taking on some of the TPM skills, and I would argue that a development manager is a type of TPM, but that's a whole other story. But you want to think about what is the zone of expertise for that person. So in the case of a tech leader or a dev manager, their zone of expertise is working in the code, writing code. And if you're asking them to extend outside of their zone of expertise to get into things like business-facing language and, customer-facing, go-to-market, those types of things. you're probably putting them in a position where they're gonna be… like, if you're thinking about skill levels, they might be a 5 in their development skills, but when it comes to that, they're gonna be, like, a 1 or 2 in most cases. That's not speaking for everyone, obviously. But, but they're probably gonna be a 1 or 2 in most of those cases. And so now you've put them into this position where they're not really… you haven't set them up for success. So if you're asking people to go pretty far outside their zone of expertise. That's probably a good sign you need to start thinking about a different shape of skill-leveled person to fit into that role. I think also for non-technical leaders. If you sit in meetings, especially if you're at, like, a small to medium-sized company, and you're sitting in meetings, and you're just sort of nodding along, and the whole time your inner monologue is going, I don't understand a word that they're saying, what is a Kubernetes cluster? How do you even spell Kubernetes? Like, what is a data lake? Do I go swimming there? If that's your internal monologue, consider getting a TPM. We make fabulous accessories for those conversations, but that's where we really step in and say, like, we do understand that language, and we can sit in an architecture review and give pushback on where there are going to be problems. So, that would be another thing I'd think about if I were a non-technical leader who was trying to decide, like, is a TPM something that might fit my organization. And I think, too, with ai becoming more and more common, we'll see… the TPM role become more common in non… engineering departments, because I really think that it's helpful, especially if you're in a situation where, like, your department is starting to vibe code things. Having a TPM and a dev within your organization, even if you're, like, finance or marketing, is gonna be a really strong asset so that you can ensure, as you're doing those vibe-coded projects, you have someone with that technical expertise to, have your back and really make sure that what you're putting out isn't putting your customers and profitability and everything else at risk.

Danielle35:43I think that's, a great place, to stop, stop. I want to thank all of you guys for your insights, and, for your humor, and for your forbearance with our first of many to come, hopefully, segments on, you know, TPM and where we're going in this fast-paced world of ours. If anyone is watching and is interested in, you know, TPM and, looking to figure out whether or not you could use a TPM, we would invite you to take our TPM self-checklist at Understory Collaborative, understorycollab.com, that's understorycollab.com. Or if you'd really like to speak to a human, because we did talk a lot about speaking to humans, we have office hours, and we'd be happy to answer any questions that you might have. You can book those office hours on our website, that's understorycollab.com. We'll see you next time. Thanks.