The Clever Task of Product Managing Backing Services, with Laurel Gray

Episode 121 · 50:29 · SRT · archive.org · all Tanzu Talk

Hey, we have a guest on. You want to introduce yourself briefly? Hi, I'm Laurel. I'm a product manager at Pivotal. Here's my question for both of you. Now, you know, here in Amsterdam, the spring is back, which means from my desk, starting at about 3 p.m., the sun is directly in my eyes. Now, I have blinds, but they're a mystery to me. I figured out how to get them to go all the way up, but I can't get them down. So my question to you is, is this because I am blind deficient, or does everyone have trouble with blinds? I definitely have trouble with blinds, especially if they're the ones that have multiple lines in them. Oh, yeah. Yeah. Yeah. Sounds like you have to move. Yeah. I mean, you just have to burn the house down, salt the earth to get a new house. Yeah. I mean, it's a great house, but these blinds are intolerable. No, it's a losing proposition. How about yourself, Richard? How are your blind skills? Not good. They always seem, yeah, I mean, you're right, Laurel. When it's got the two handles, I mean, I actually just opened the blinds here in our Seattle office, and they just have one little thing that, a little metal chain to pull them up and down. That's straightforward. But when there's like the open, close, and up and down, that's a lot of sophistication for me. Exactly. That's what I have is you can, these blinds can come down from the top. You know what I mean? Like you can put a hole, not a hole, but you know, you can have the top of them come down. Or you can have the bottom of them come down. And I think something got all confused. That's so fancy. Yeah. I'm impressed. Yeah. See where this fanciness got me? I just need some good old, good old, are they Venetian blinds? That would be funny if you were in Venice and had those, but just, I like those ones that just make a lot of noise when you move them back and forth and have a big dumb chain on them. They always work well. I feel like next week's podcast will be, I have a sheet in my window now, and that's how I now block light. That's right. I'm going to be like my country friends back in Texas and just put a bunch of foil up in

the window. I was never really sure what that does, but that was very popular. You just line your window with foil. We're a week away. That's right. Maybe the theory was that like deflects the heat. I don't know. It seems like it more like it would cook you inside. Well, anyhow, well, we have, we'll come back to a longer introduction to our guest, and per usual, we have a few news items to go over before that. Feel free to weigh in if you are anyway thrilled by that guest, or maybe now you're consumed by trying to get your blinds to work, which I know I would be if I hadn't given up hope on these blinds. I think maybe another indication of the trouble you're going to have with blinds is the pull. There's always a dongle thing at the end of the pull. I think the fancier it is, the worst your blind experience is going to be. You know, because when I was in college, you would just have that really cheap kind of like white bell at the bottom, you know, the little pull. And this one has like, it's got like a little black thing with a contoured finger thing, and then it has some clear plastic dropping down, almost like a little sample perfume bottle. And I don't know, I don't trust it. Anyways. Seems like Europe's really agreeing with you. It's a good move for you. Other than that, everything's working out great. You should just move to London, where we could work together in the same office, and you don't need blinds because we don't have the sun. Oh, yeah. Huh. Solve it at the root. That's right. Get to the base of it. This is our cosmological solution to this problem. I think that's a good idea. It sounds like a lot cheaper and a lot more efficient than just figuring out how these damn things work. Anyways, you know, the opposite of that, things that work really well, a new version of Pivotal Cloud Foundry came out. Now, I saw one of the things listed was Steeltoe has been modified, maybe updated, improved. What's the story with that .NET guy? Yeah. So Steeltoe, part of a lot of different parts of this release. So there's, you know,

if you want to talk to MongoDB, you want to do more health profiles for your .NET apps, you want to have different service discovery, like your HashiCorp console, instead of using some of the pieces that already came as part of the Netflix stack. So some good stuff there. There's some great things for platform automation and PCF25. The first introduction of things like Istio for service mesh capability, be able to do weighted routing. So you could have some traffic go to this version, some traffic go to that version. So lots of good stuff in this release now available. We announced that a couple of weeks ago at the Cloud Foundry Summit. We're actually bumped into Laurel, so it's all fortuitous. Yeah. I was interested to see the weighted routing there because I've been at several spring tours recently. I was down in South Africa last week. And, you know, the question of, uh, so if you're going to be deploying things frequently, isn't that going to break everything? And then I'll have to find a new job. You know, the first thing I tell them is that programmers are in high demand, so it'll be fine. Uh, but, but yeah, it's nice to have sort of a secure ways of releasing things, especially like blue green deploys. And then I guess you could also do like your AB testing, not only, uh, you're deploying, but being able to have multiple versions of something, whether it's for rolling upgrades or, uh, testing new features is, uh, quite thrilling. That's a, that's a new thing that we've got to use in the past few years. Are there any other exciting things in, uh, that new release? No, tons of, uh, different parts of, Hey, sure. Windows Server 2019 support and other pieces like that. I also noticed that last week after the release, we followed up with some cool open source stuff. There's some posts on the pivotal blog about the new metric store that we added to open source cloud foundry for a time series database on, on log and metric information that you can use to analyze. And then we also kind of quietly announced that we added support for sidecars in the cloud foundry platform so that you can have containers deployed with sort of side containers that might do, you know, analytics stuff or monitoring stuff. And it's a cool service mesh pattern. I think it might surprise people that that's coming to the cloud foundry itself. That will be nice. Now at the same time, uh, last, well, that was at the same time, but

during, since we recorded last time, that period of the passage of time, uh, there was also a bunch of, uh, there was Google next, I guess they call it Google cloud next. Is it just Google cloud next or Google next? I think it's Google cloud next. Yeah. Yeah. Yeah. You know, I was watching the coverage from there and I was thinking like, I bet if I was still an analyst and living in Austin, I w I would be down there. I wonder that that's not the one they give out free stuff at though. Right. I don't know if there's as much of that anymore. You remember like five, 10 years ago, like, Hey, reach out to your chair. Oh, it's a laptop. Like that used to be the thing at these big conferences. I don't see that anymore. Yeah. That was like the only, I mean, you know, speaking many years, I think the, uh, the statue statute, it's not a statue. It'd be fun if you went to a park and there was a statue of limitations, uh, somewhere, but the, the, uh, the statute of limitations I think is expired. So really the only reason I wanted to go to Google IO was to get the free stuff. Uh, when I was an analyst, I don't know, just have people walking around with those, uh, those gloves on their feet and other things like that, but you get a free Chromebook. It's pretty awesome. Uh, anyhow, uh, they had their, uh, their Google cloud next thing. And I think, I think for me, there were many, many announcements, but there was, uh, how do you say it? Anthos. They had their, uh, a multi-cloud, um, manager thing, which I think having read the docs more extensively than when I rambled on about it unknowingly last week on my other podcast. Uh, I, it's, it's basically a, uh, let's see, a multi-cluster Kubernetes manager, uh, which, which sounds like, uh, sounds like fun. And then there's also a, uh, I forget the name of the startup it's based on, but there's a way of mark migrating, uh, workloads, uh, between various clusters, which also seems, seems handy. And, uh, it struck me as like all the way back to, um, I mean, we, uh, ourselves and many other people and, you know, with there's, there's a whole little community of people who work on this multi-cloud problem. And, uh, it was reminding me that in the past couple of years, all the work, this larger community has been doing, we're finally delivering on

like what people wanted from cloud in like 2009 or 2010. Like, remember they used to talk about bursting all the time. And then you had, uh, you had things like in Stratius and right scale and you had all, I mean, you still have those, but, uh, or right scale at least. And, uh, you had all these things that were going to be, as we used to call it, the, uh, manager of managers, the mom for your cloud. But that seems like a normal thing that you do nowadays. Yeah, no, it does. So it's interesting. We'll see how well they can pull off the sort of, Hey, we'll run this platform on every cloud sort of deal. It's obviously increasingly a popular thing. They also announced, uh, cloud run kind of a version of K native. That's just running kind of containers and serverless fashion, which is pretty neat. There's a blog post we'll link to in the notes. I think they have 122 announcements from the conference. Some of those are like, we serve salmon on Thursday. Like that was, I don't think all of them were tech related, but it was a pretty impressive set of stuff as, as these shows are getting to be the for same with Microsoft, the same with Amazon, just a blitz of information, probably a lot of long tail stuff that some people may not use, but it's just the sort of overwhelming set of announcements to show how serious they are. Salmon on Wednesday, uh, pork belly on Tuesday. That's, that's getting, that's getting to the, uh, the, uh, not category, the, the scale of like a, a Jared blog post describing what's in a release where he's, he's just like, let me give you a five page summary and then let's get into the 80 pages of releases. It's not really that long, but he's very thorough. Put on your slippers, get some hot cocoa, dig in. Yeah. I was, I was, uh, they recycled plastic here, uh, which I don't know why that's notable. Oddly enough, it's hard to recycle metal here in Amsterdam, but I was walking to recycle the, uh, the plastic and I passed by this guy. He was, he was clearly a Dutch guy and he had, uh, he had a Carhartt jacket on, you know, with the, um, what would you call that Carhartt color? The tan, the like North Carolina dirt tan. I don't know what that is. And, uh, but he was, he was totally smoking like a Sherlock Holmes pipe. It was, it was quite picturesque and, uh, he was still there when I came

back. So I got to see him coming from the front as well, but it made me, it made me think just briefly like, boy, I bet it's fun to smoke a pipe. Yeah. Have you smoked a pipe before? Uh, gosh, I don't think I have. Laurel, are you a pipe smoker? I would. I'm like almost 30 years old and I think my parents would have a heart attack if I told them I was smoking pipes. All right. So that's not a new habit you'll be picking up. Good to know. Yeah. Yeah. I mean, I feel like it would be a whole lifestyle you'd have to take on. Of course. Like you'd have to get new clothes. You need new friends. Like it's a whole life shift. New friends. Exactly. And you got, you got, somehow you have these new containers that you got to put your loose tobacco in and there's, there's that move where you're like tapping your pipe all the time. Kind of like it's one of those, uh, spent espresso things that you're always jamming on. Yeah. I'm not ready for it. Too bad. There's not like a tobacco alternative that isn't like gross. Maybe bubbles. That would be fun for kids. Uh, well also, uh, there was a, man, there's all been all sorts of platforming releases, but first, you know, I haven't had a chance to look over the, the Stack Overflow dev survey. How, how are 90,000 developers doing? Have you, have you looked at it? Yeah, they seem mostly happy. So Stack Overflow runs this annual survey. They sure they had amazingly 90,000 developers chiming in on stuff and it's the usual, like, Hey, where are you based? How much do you make? How much education you've had? Those are really interesting. Then it's a sort of, what are your favorite programming languages? JavaScript kind of wins every year for most, uh, most folks and which web frameworks are most popular and kind of other frameworks you like using spring. Luckily people like using spring, which is nice for us. And which databases do you prefer? And, you know, kind of how much open source do you contribute and how often, and how often of course, do you use Stack Overflow? So tons of stuff. It's really worth digging through this. If you're in developer relations, if you're in the enterprise and thinking about what it's going to take to attract people and what kind of skills are out there. And if you're a software vendor, it's a nice insight into what a lot of developers care about and

what motivates them. So absolutely worth digging through for almost everybody. Yeah. I'll have to take a look at it. I've, I've been, I've been sort of like, uh, slightly wondering why mainframe programmers are not liked anymore and programming in general, maybe not the programmers. I'll see, have to see how the great languages of RPG and COBOL rank. No one ever mentions for Fortran. Fortran. I don't even know how to pronounce it. It's Fortran, right? Yeah. And it's gotta be like Fortran 78 or something. I forget that. I love, I love a language that's so, uh, uh, glacial is the wrong word. It's not monolithic. It's so like, uh, austere or something that it's, it's version numbers are in years and often decades. That's, that's a good look. Kind of like a pipe. Well, also there was a, there was a new version of Kubernetes out and, uh, I have to admit I'm not up to speed on it. I know, I know there was, uh, some more windows node support in there. I mean, that one actually wasn't in there until now, right? Not officially. No, we're, we're coming out with some things soon from a pivotal perspective to support that as well as a lot of people are now going to quick rally around that to pull in those windows workloads into, into Kubernetes. So yeah, exciting stuff, you know, the usual sort of patches and updates and that constant reminder of this regular rhythm of updates and hopefully who are listeners are using products that make it easy to update. Yeah. Because you don't, you don't want to, uh, do your slow rolling upgrades. I guess you would call that a stumbling upgrade. That's right. No stumbling. Now also there was, there was a, uh, this might've been since last time we recorded, but Confluent had, uh, their conference, which I know cause, uh, James Water was up there presenting. So I've been trying to find his presentation. He's got that, that great old, the new slide that's been everywhere now. Now I'm sure they announced some things, but I want to ask you. So is, is like, is like Kafka, like, is everyone into that and very popular or is it just because I follow James Watters and Twitter? I think it's everywhere. Uh, from non-just Twitter, uh, it seems to be extremely popular, Confluent. The company's doing extremely well, it seems. And a lot

of our customers at Pivotal are talking about Kafka, putting it in. So no, I mean, it's objectively successful and it's just a new way of thinking though, for a lot of folks, it does not replace your ESB. It does not replace your messaging bus. You have to think differently about how you process data and what the role of your clients are. So it's exciting stuff. It's a new way of thinking about it and offers some new opportunities, but it's not a drop-in replacement. It really shouldn't be. You should be rethinking your data integration. Yeah. Yeah. Yeah. One of the most popular questions at the, the SpringOne tours. So, so is, is kind of around that basically a lot of the presentations that people like, uh, uh, you know, Mark, uh, there and, uh, and Josh Long and, and other people do is all around event-based architectures. And then, uh, inevitably during the, we have this thing at the events at the end of the first day, the ask me anything. Uh, I always feel weird saying that, like, I don't know why, but anyways, it's a, it's a Q and a with whoever pan, whatever speakers are available. And, uh, you can almost set your watch to about five to eight minutes. Someone will ask about transactions. And then, uh, the, the speakers still haven't trained themselves not to give a snarky answer. So their answer is equally predictable. They'll, they'll look at each other and pass the mic around and someone will, you know, that thing where like, you're like cool person and you're holding the mic, like really loose, kind of like a limp, loose limp way of holding it. And then you're like, don't do them is pretty much what they say. And then of course someone gives a more serious answer, but it's, it's evident of like, you know, there's an interest in doing event-based things, but as you say, it's not like it's just, uh, instantly replaceable. And, uh, I think, I think they, uh, they were using some funny term, the speakers for it. You have, um, what is it? You have eventual consistency is what the no SQL kids started off with. And I think, I think what they start to use now to be jokey is, uh, instant inconsistency, uh, which I guess is technically true, but anyhow, yeah. Event-based architecture is very popular. Well, I think that's, uh, that's all

the major news, uh, that we have for now, I guess just one small announcement, uh, and, and, and our, uh, our conference stuff as usual. So my, uh, my little booklet, Monolithic Transformation, uh, it showed up in Spring Safari. So if you didn't want to lead Jen yourself to Pivotal to get a copy, you can go, uh, you can go in there and read it. And I've, I, there's one five-star review for it now, and I'll let, I'll let the listeners guess who left it, but I'm pretty sure what it says is this is the best book ever. Uh, I think exactly. That's right. My, my, my mom totally has a Safari account. She uses it to keep up with, uh, advancements in corporate accounting into her retirement, just a little hobby thing, you know, no, no big deal. Uh, and then also, uh, I've mentioned several times, we still have many spring tours going on. I think in two weeks, uh, we'll be in Istanbul. And then, uh, I think there's some back in the U S and, um, there's one in Paris at some point. No, I think that's already happened. So unless you have a time machine, you can't go to that one. Uh, and the, uh, the call for papers closed on SpringOne platform, right on Friday. It did. Unless you know people. Yes. Yes. That's, that's, that's what I tell everyone. Yeah. But anyways, uh, you, you should come to that. That's an Austin, October 7th and 10th. It was hard to convince the South Africans to come to that. They told me it was quite a haul, but they should come anyways. It'll be fun. That's right. So with that, uh, guest, why don't you more formally introduce yourself? What do you do around here? Gosh, I think I'm, um, so again, I'm Laurel Gray. I'm a product manager. I've been working with Pivotal, um, for the last almost four years. And right now I'm working in, uh, open source cloud foundry as the product manager for the cloud foundry services, API team. Awesome. So I bumped into you at a CF summit. You were doing this great presentation on the independent services marketplace. I think the PM of that work, what is that? So what problem

are we trying to solve there? Yeah, that's a really great question. I'm actually working really closely with the product manager who is working on the independent services marketplace or ISM. Uh, his name is Matt and he's brilliant. Uh, he actually used to be the product manager for the team that I'm currently working on. We did a little bit of a switcheroo so that he could focus more on ISM. Um, basically I'll talk a little bit about how the team breaks up, uh, but, um, before doing that, I think the more important question is like, what problem is it trying to solve? So what I think, uh, we've learned over the last year, uh, and I think we've done it for like a bit longer as well, is that most of the people who are using cloud foundry are not just using one foundation. A lot of times they have multiple foundations and, uh, it's very difficult for them when they have multiple foundations to be managing and operating many different services across those foundations. So the ISM team basically spun out of a discovery effort that the cloud foundry services API team started, um, to uncover what, you know, like what problems were people encountering when managing multiple foundations. And so, um, ISM, the independent services marketplace aims to be, uh, one place for you to, you being a platform engineer who is operating a platform for, um, many different teams or tenants at your company to be able to curate and manage a marketplace of services for people so that you don't have to be, um, updating and writing a ton of scripts that are all touching the APIs for different cloud foundry foundations, um, in order to do that. Interesting. What's your team? So what's your team as a whole do if you're kind of working together on this services marketplace, what's the services API team do? Yeah. So the services API team, we're really focused on making the developer and platform engineer experience using cloud foundry, um, like specifically services on cloud foundry.

Awesome. And the, we'll do various things, including, um, work with the open service broker API also called OSBAPI, which is, I think my favorite acronym, uh, to make changes to that spec so that platforms and brokers are sharing, uh, the right information with each other in order to solve user problems. So, um, um, a good example is like, uh, for a change that we made recently was people have dashboards that they have with their service providers. Like, let's say you have some kind of, um, database service instance that you have from an external service provider and you would like to have the platform, uh, pass information to that service provider, uh, so that you can actually identify which, um, foundation or which, um, service or which application it's bound to. Um, so we'll, we'll work with OSBAPI to get changes into OSBAPI so that there is, um, a contract for cloud foundry to pass that information to the broker. And then we also then make the changes to the platform to actually, uh, introduce the change that the platform being cloud foundry is passing that information that way, like as a developer or as a platform operator, when you're looking at this external dashboard, you're seeing the names of instances or the names of, um, the space where those instances are located instead of having to look at GUIDs all of the time. That's neat. That's cool. So have you been on that particular team a while? No. Is your journey at Pivotal, like what's your journey at Pivotal been like? That's a great question. I actually started off as a product manager for Pivotal Labs in New York, and then I was in Washington DC for, uh, a year and change, I think. And then I moved to the London office where I was also in Pivotal Labs. And then after about three years in labs, um, I started to feel like I wasn't learning as much as I really wanted to be learning. And so what I decided to do is move into Pivotal R&D so that I could actually see what XP and Agile look like at scale and get,

uh, you know, back into some kind of industry and not just be a consultant. Hmm. So what, what, uh, as, as far as like product managing all of that, who are the, how do you think about who like the users or customers or whatever are? Cause you know, usually you hear about, uh, you have plenty about product managers where someone's like, you know, I want to get some groceries delivered to my house in two hours. But, uh, but in your case, it's sort of like, I don't know, developers or not even only developers, like also people who are writing services or something. So like, what, what's that like? That must be slightly exotic. Yeah, I think it's really interesting. Uh, I actually think I worked on a product that was very similar to the, let me deliver the groceries to you in two hours. Um, and like you said, it's so much easier to find people just like literally on the street or you like go into a Starbucks and you give people Amazon gift cards if they'll answer questions to you. Um, it's much easier to find those types of users who are using grocery apps rather than finding users who are using like, um, you know, like cloud boundary, for example, like there aren't, there, there are lots of people using cloud boundary, but like compared to the number of people buying groceries, it's not nearly as high. And you probably have to give them like laptops instead of Starbucks cards to motivate them. New Google Chrome. Exactly. Yeah. I wish, uh, we actually do. Um, so as a, as a product manager, we actually don't have a designer on the team. So, um, I do think a lot about like how might we engage with users and for open source consumers of cloud foundry who are not selling their own proprietary version of cloud foundry. We offer 50 pound Amazon vouchers for a 45 minute interview with us, uh, which has been really awesome and helpful for us getting people to, you know, like, um, jump onto a zoom call and have a chat with us. And, um, we've been doing a lot of like remote, um, prototype interviews where they're, we're having them drive our screen, um, and use the terminal that we have that has a prototype binary already

installed into it, uh, which has been really cool. Um, but yeah, I think what I found finding users for cloud foundry is a lot of it is based on relationships and like getting to know people, for example, at CF summit, um, and just forming relationships with folks within companies who are excited and willing to introduce you to their teams of platform engineers or their teams of CF developers who exist within the company. Hmm. That makes sense. How do you tackle that? So, I mean, when you go into these, so help me teach us a little bit about that experimentation with users. Are you going in with a set of hypotheses or you just want to see what they're doing and how they do it? And then you kind of pull some feedback from that. How do you, how do you plot this out? And when do you go in and get user research? Like talk, talk us through that, especially if they're an enterprise customer who's listening, who says we're trying to get better at actually doing more user centered design. How do you even start? What's the process there? That is a great question. I think the first step is to identify who, well, there's a couple of different steps, but my favorite thing to do is to put pressure on myself and also on the rest of the team to identify what we want to test by having some interviews already set up. So, um, for example, we have an interview already set up this Wednesday with a platform engineer from, um, actually a pivotal customer. And, um, we had that set up before we knew what we even wanted to test. And then we kind of like backwards calculate from that, how much time we have. And then what we'll do as a team is we, um, determined our top priority thing that we have, that is either a question that we need to have answered or, you know, reworded differently, an assumption that we have, or reworded slightly differently, like a hypothesis that we'd like to test. Um, and we'll have a prioritized list of those, choose the top one we'd like to move forward with, and then design some kind of experiments, um, that would then tell us, uh, basically like, um, how to proceed, like how to move forward, uh, given some threshold or indicator that we're really looking for coming out of those interviews.

So, so what's like, what, uh, do you have an example of like a hypothesis you would run through? Yeah. Um, we, uh, we actually have one that we're running through this week, which is as, uh, the CF, um, services API team, something that we're really interested about in this, um, world that is not one foundation, but like the world everyone exists in today where you're not even thinking about foundations, you're thinking about regions or whatever. Um, we're really interested in like how people think about their cloud topology and we think kind of putting it back into like the language that our team uses, which is really about foundations. We believe that the majority of the services that people want to offer are going to be multi-foundational and not just like one-offs. I want to offer one, my SQL, uh, service offering here and another one over there, but we think that it'll be more like, okay, I want all of my, my SQL, uh, I would like all of my, um, foundations or platforms within, uh, us East to all be hooked up to this, my SQL broker over here. Um, how might I do that? So what we're doing this week is we, we actually kind of did it kind of backwards. Uh, we decided what decision we want to make and what the indicator is for that decision to be made. So for example, um, we, we said that like if shared service offerings is greater than 60% for out of for four out of the six platform engineers that we're going to be testing with, um, we'd like to consider, um, moving forward by removing the cloud foundry marketplace and making external services the norm. This is, I mean, that might sound crazy, but, um, that that's something that we'd like to consider. And then if it's actually less than 40%, then we'd like to view going forward, external services as more of an enhancement, um, on top of cloud founder, where we'd still really want to make sure that we're truly supporting the CF marketplace experience. Um, and then based off of that decision and that indicator, we then came up with some kind of like, um, interview script and also almost like

a game where we're having people move things around, um, visually within a, like a Google drawing doc. Hmm. And, and so is it like you were saying, you kind of take on the role of, uh, of a, of a designer since you don't have one on your team. Is that, is that like on purpose or are you just like, uh, haven't, haven't found one yet? Uh, well, I think something that is very hard to hire for is people who have excellent design chops, who are like a full stack, like super into user research, also really good visual and also pretty good at, um, uh, like, uh, products, more interact, interaction design, um, hiring people who have those skills for a world where a lot of the design work is more on the research side and more on the systems thinking side. I think it can be really difficult. So we've, if there are any designers listening, uh, who are interested in amazing design jobs at pivotal working with me and with other amazing product managers, um, in London, just apply because we're always looking for designers. I think finding those skills, um, with also the desire to be working on that kind of stuff can be really difficult to find. Um, and so, because our biggest need on the team right now is really to make sure that we have, um, that we're making like, um, data founded decisions. And especially as we're trying to, as we're thinking about these really complex things, like moving the services outside of the cloud controller, maybe, or, um, how might we integrate with ISM or how might we integrate with other, uh, solutions that are out there in the future. A lot of those decisions, although they might seem technical at first should be really driven by user need. Um, and so that's just where my focus has been recently. Um, and that means that, you know, like other product manager-y things tend to get put aside. Um, since this is the primary need for the team right now. Yeah. Yeah. I mean, you know,

cause I was thinking I, to put it in a totally jokey way, whenever I go over the, uh, the sort of, uh, balance team idea of the three primary roles, you know, I like to remind people or tell people that the designer surely tells you when you should stop using Serif this year. Cause that's out. And when there's no more drop shadow on, on your button, but you know, they actually do real design as it were, as, as you were covering. And so I was thinking like, what would, uh, you know, in the world of APIs and services, like maybe a designer comes up with really cool camel casing for an API name. Like, it's just such a weird, I mean, that would be the jerky thing, but like, it is, that's such a very specific role to be a designer for services stuff as, as, as you were saying. Right. So it seems like what you would fall back, not fall back on, but it's, again, it's that core role that you would have of really, um, I'm never quite sure if user research is the right term nowadays. Cause I don't follow this stuff very much, but like basically knowing how to research what a user base is doing and who they are and what their actual needs are and distilling that down to, uh, here's, here's what the user needs, uh, so to speak, which seems a lot more plausible than like, you know, being like a really cool API designer. Yeah. Yeah. I'm sure there's like some slick, like you said, interesting things to do with, um, API design or with like CLI design. And I find myself, um, reaching out to a lot of the designers that we do have that are in other offices to ask them for feedback on certain commands before we test with users. Cause I, uh, I'm definitely not an API designer or a CLI designer. And I'm also, uh, I have, I wasn't a developer by trade before I joined pivotal. And so a lot of that is not as second nature as it is for other people. Man. Well, you know, my experience using command lines is they could use a lot of designers and, and, and I'm sure, I'm sure you see this, uh, I'm sure both of you see this, like, um, you know, when, when, when you see a really well-designed command line interface, you, you can tell cause mostly they're terrible. Like, and they have very, very obscure

things and like, it's very confusing, but sometimes they, uh, they make a lot of sense. So there is a good, there's a way to design them. Well, describe my management style right there. That's good. Obscure flags on an equally obscure command. Yeah. Uh, Laura, when you were talking about the user research, you were making me wonder, can you think of a case where after doing user research, you actually did like a one 80 and I was like, wow, aren't we were completely off on that? Is there anything with that? That's a really good question. I've been thinking about that a lot within as, especially working with other product managers and pivotal right now, who've been talking about solving for these needs for quite some time too, where, um, I haven't found it so much with, in R and D, but certainly on labs engagements before there were many products that, um, when we started, uh, engaging with the clients and doing user research with them, it became really apparent that the users didn't actually need that they were, uh, like didn't have a need for the thing that was already being built. Um, that's a bummer. Yeah. But it's also kind of exciting. So like, um, I'm trying to think of a really good example was I was working with a team that had been building a data lake for six months and they only had it in, um, it wasn't in production and they'd been building it for a while. And we were, I just joined the team and I was like, Oh, why are you building this? And they had a whole bunch of reasons why. And then, um, they were, they hadn't been doing user research, but they, when I brought it up with them, they were all really interested in talking with users for the data lake that they were building, um, and learning what they could do to make it better, which was really cool. Um, so we set up interviews and the users that they had were actually developers literally in the same room as them, uh, who they just hadn't been having conversations with before. Um, so we set up some interviews and then we synthesized the research altogether. And what really came out was like

all of these developers actually really needed a lot of help, uh, setting up their, um, like figuring out how, out, how to use the platform, like the, the cloud boundary platform that this team had also set up and didn't necessarily need access to a data lake because they just weren't in a place where they needed that at all. And so the team I was working with was, um, I think a little deflated about the data lake, but then they got really excited and like built out a wiki and started doing a bit more more education with the, um, development teams in the office around like how to use the platform. So I think like it, it can be, it can be kind of disappointing, but at the same time you end up learning things that you don't expect. That's great. When you're doing, you know, in your product management experience and this sort of design thing, and you make me even go back to the ISM and thinking about that is what do you do when you're dealing with something that has a fairly established either set of expectations or user base and you're trying to evolve that. So whether you're doing that with the open service broker API, or we're doing this with a service marketplace or any of your labs engagements, when it's not just like novel, new greenfield, let's build some crazy new thing, but like, Hey, a lot of people know and love, or even hate this thing, but they know it, but we have to have to evolve it. How does that change? Maybe how you research or how you introduce changes? What's been your approach to that? Oh, that's a really good question. I think, I think a lot of the first principles remain the same, which is making sure that you have users who have needs and that you are building solutions that, and testing that those solutions are meeting those needs iteratively as those solutions become like higher fidelity from like maybe some kind of mock prototype out to actual working software. Um, I think when it comes to things that already exist, something I found interesting is challenging assumptions based on research that people have done in the past. So like some people might, um, hold strongly like, Oh, we tried to do this,

you know, like you like bring up something that came up in like user research and they'll be like, Oh, wait, this came up, um, five years ago and we decided not to move forward with it because blah, blah, blah. And I think that that can be a really interesting place. Uh, you know, it's not like a greenfield product. And so, um, the people who've been working on this product for some time have a bit more, uh, understanding of the users and also an understanding of the history. And then also sometimes need to be like a little bit shaken up. And that, um, in my mind means like you just continue, continue doing like the same thing you would do otherwise, which is user research and gathering data and gathering evidence and using that to like, um, have conversations with people instead of just having opinions or talking about old, uh, data or old assumptions. Yeah. That reminds me, uh, when, when I was at Dell, I was helping out with a, uh, a Linux desktop for developers and coincidentally enough, it was, it was, uh, at the time, like a pivotal labs talk that I'd seen where, uh, I think they use chef and, and, you know, in labs, you like want to get the, uh, the same setup in your environment, uh, every day if you're working on a certain, uh, what do you call it? Client. And so there was this, there was this like, here's the image for our developer, uh, in environment. It wasn't an image, but they would automate doing that. And I thought that was really cool. So I was like, we should put that on our developer laptop. And then, and then after about five minutes of user research, it turned out no one cared and, and, and more. And, but the reason they didn't care is because it wasn't, uh, I mean, it is cool, but they had this more immediate need of like, I want to be able to get a Linux desktop, like, and just solving that problem was enough of a, uh, an issue that, you know, anything else that happened in the future would be, uh, would be nice. But that was, that was the provenance of, you know, flying cars and things like that. Uh, but it was, it was a good lesson in just like, yeah, maybe I shouldn't be attached to these ideas. And, uh, and now there's a nice Linux desktop, which is good. People love that. So, uh, you know,

now that we've gone this long, uh, and just to ask, uh, uh, a very basic question, which I, I still, uh, babble around. So what does a product manager do? That's a great question. I think you will get a different answer depending upon which product manager you talk with. In my opinion, a product manager, uh, the role of the product manager is to help the team make decisions with the right amount of information and not only just make the decisions, but also make the right decisions being like you're prioritizing what decisions have to be made and how much time you need to dedicate to making that decision. I find that product managers who don't necessarily view that as their role, there's a lot of, um, almost like time that the team spends spinning and waiting for decisions to be made where it's almost better just to make a decision, uh, rather than try and find all of the perfect and 100% of the information that you need to have in order to feel 100% confident that you're making the decision the right way. Uh, yeah. Yeah. That's interesting because the, the, the briefest way, uh, I know of to summarize it is like you prioritize the backlog, which almost sounds dismissive, but on the other hand, it's a lot of what you just said, right. Which, and, and I think, I think, I think what's hard to explain is like, um, how much, how much work goes into that, like knowing, knowing what it is you're going to do this week and why you're going to do it. And then, and then I, I mean, I, maybe I'm interpolating if that's the right word too much, but it seems like, like you were talking about earlier, if, if you succeed or fail, then you've got to know how to interpret that for next week, uh, as it were, or the next release cycle. Yes. You can't just like go out and try to learn stuff. You have to know why you're trying to learn that stuff and know what kind of decision you think you might have to make based off of it, on it so that it's actually actionable.

Right. So there's basically setting the priorities essentially. Uh, I don't know. It's an even simpler way of putting it. Yeah. It's also funny. Cause like at pivotal, we think so much about, um, like balanced team and servant leadership. So like a lot of times it's not the product manager setting the priorities for the team as the product manager, helping facilitate the prioritization of things and bringing in all of the right voices to help make that decision. And like just getting people to a point where the team can move forward with one thing. Right. Right. Yeah. I mean, with our, our culture is very, uh, what do they say? Consensus based. It's almost like passive voice by design to more have, more have, uh, people, uh, agree to things. We, before we were recording, we were talking about this book, the culture map. It'd be fun to find, uh, where that maps into things, but yeah, and that makes it. And then, and then another aspect of like product management I hear about every now and then I'm always curious about is like, uh, sometimes product managers are the, uh, to you, to use a nonjudgmental word or the, they're the interface to the rest of the business. And then the, the funny way of putting it is sort of like they hold back everyone else from bothering the team. But does that, does that kind of fit into the, uh, the product manager role as you know it? That's a really good question. I think, uh, the way I've been framing it for myself is that it should really be a balanced leadership team of like a PM in theory, a designer and, uh, uh, the anchor or the tech lead for the team that interface to the business and have conversations with stakeholders as a group. Um, but it's really the role of the product manager to make sure that the business's goals are being prioritized against the user's needs. So, so on, on, uh, now that you've worked on, you know, with the, uh, the two hour grocery stuff and then you got, you got, you got the, uh, the, the lower level, the plumbing going on, like between those two and other experience, like what's, what's your role on, on the team that

sort of like you wish existed or is everything perfect? I mean, Hmm. That's a really good question. I think, um, I know we have exploratory testers at Pivotal who work on Pivotal tracker, I think on some more complicated products, uh, I was working on a non green field product for a grocery company in the UK. And, um, there were times where I was like, Oh man, I really wish we had like exploratory testers who could really dig in and like, just make things sure that what we're going to be delivering doesn't have any bugs rather than just the PM doing acceptance and us trusting the tests. Like I feel like more exploratory testing could be valuable there. I also feel that way with, um, cloud foundry too, cause it, it can be like a really complex product. Um, I also have a desire to have someone come in and just help us, um, make sure that we're like scheduling, uh, like help out with more of the administration of like scheduling the user interviews and like really handholding the users, um, through the process when we're interviewing them. I find that, um, something small, like even just like thanking people after they've participated or sharing, um, uh, tidbit about how their feedback was really helpful is something that means a lot, but takes extra time away from other things. And sometimes I'll deprioritize it and then remember later to do it. I just wish someone was there to like really focus in on that. Maybe that's a designer, but I also feel like it's unfair to just put that on designers. It really should be on the team to make sure that that's happening. Um, I think I need that role in my life. That would be great. Like a thank you note writer. Yeah. Yeah. Or just the entirety of it. Like, like, as you were going over it, I was thinking, you know, it's sort of like a, uh, like a master of ceremonies, like an MC or I never, I think this is French. What is it? I always want to say major domo, but the major domo, I, what I need to look up what that, that is. That might be like from my computer background process thinking, wasn't that an email list manager? Do either of

you remember that? I'm gonna have to look that up. Uh, but yeah, or the, the air traffic controller people say, or, uh, I remember, uh, the Kroger people, I was talking with Kroger about how they manage their, their warehouses to ship the groceries around. And they were saying that, um, uh, there's one role that they call, I think they call it the bus driver or something. And all that role does is make sure trucks don't run into each other. Like as they're coming and going, they have to schedule all the trucks moving around. But yeah, there, I imagine there's a tremendous amount of, uh, just coordination and then, and then, yeah, no, I like, I like your, your, I don't know what a literal metaphor is other than an oxymoron, but your, uh, your sort of symbolic example of, uh, thank you notes. Like there's all this stuff that just gets left out. That would be nice to have the thank you note writer. Yeah. Yeah. It's like the really important thing long-term that in the short term, when there's other fires that you have to put out, um, falls to the wayside. Oh yeah. It's, it's the, uh, the much forgotten of part of the Eisenhower matrix, right? The urgent, but no important, but not urgent. I forget what you're supposed to do with that. I think, I think basically as with all, uh, how to get things done, prioritization things, it all amounts to what do we need to get done tomorrow. That's pretty much what happens. I guess, I think you're supposed to delegate the important, but not urgent if I remember, but, uh, I think so too. That's the whole point you're saying is who would I delegate it to? I honestly think we probably have all of the right people already within pivotal or within like the open source group of, you know, like people who are working on open source cloud boundary for all of these things. It's just a matter of, um, some higher level coordination of moving people around and finding places for them that are interesting and valuable. I think it's sometimes we all get stuck in our own little teams and forget about the people who are glue between the teams or people who are a little, um, auxiliary to the team who could come in and out with those things.

Then you got the major domo and you got the glue major domo, just glue everywhere. Well, I've entertained myself. Well, uh, thanks for being on. It's always fun to, uh, to talk, go all the way from, uh, from an API thing up to, uh, glue. So, so that's, that's great. It's, it's been informative. So if people, uh, well, one, if people wanted to, were eager to volunteer to do some, uh, user testing with you, like what, uh, how, how could they get ahold of that? Like how can they tell you? That would be amazing. So if they're open source cloud foundry users, they can find me on the open source cloud foundry slack at Laurel, or they could come into the hashtag SAP I channel for SAPI services API, and just let us know that they're interested in participating. And then if they're keen on the independent services marketplace, they can email ISM at pivotal.io. And you have any other, uh, engaged with my brand type of things you want to give out? You got a blog, Twitter, whatever. I do not have a blog and I tweet very rarely, but people can find me on Twitter if they'd like at L A U R Z C A. There you go. Yeah. I recently, I think, I think I cut all my, the people I follow on Twitter down to maybe like 120. I don't know if I'm that low yet, but man, it's like so much nicer. Like everyone's always complaining about how much of a downer it is, but all you got to do is just, uh, not follow depressing people. And then I'm checking right now to see if you still follow me. You're still in there. Okay. I'm looking right now just to be safe. You're, you're like one of the most cheery people in there. You never know. There could be a story about like a cat fell into like a, a box of rusty nails and you would find some positive thing like, Oh, Hey, we found a box of nails. That's right. We found a box of nails and this cat is now adding to its experiences.

I interrupted you though. Uh, Laura, what were you saying? I was just going to say, um, unfollowing people. I love unfollowing people. I also get a sense of social anxiety because I know people out there have apps that tell them when they're unfollowed. Yeah, that's true. I, I, I feel like, you know, cause there's that mute option and I feel like I could do that. And so I, yeah, I'll, I'll, uh, I'll dither. And then I just think like, ah, I should, I should be brave and just insult them. Be brave. That's right. Yeah, cut ties. That's right. Be brave. No less people. That's right. That's, that's how I'm going to, that's how I'm going to, uh, I'm going to add this rotor spin on introversion. I'm being brave by not talking with people. That's, there you go. Cat in a box of rusty nails. All right. Well, uh, as always, this has been Pivotal Conversations. Thanks for listening. Uh, if you want to get this, uh, this episode and all the other old ones, you can kind of comb through them at your, uh, your leisure. We're coming up, uh, might be spring break, depending on where you live. You're traveling around, you're driving. If you're like me, all your family falls asleep and you're like, ah, I can finally listen to something they would never want to listen to. You could listen to our back catalog. You could go to soundcloud.com slash Pivotal Conversations. And, uh, you know, there's lots of stuff in there, I suppose. Uh, and then I'll put the show notes, uh, every Thursday or so they get posted formally and they'll be at pivotal.io slash podcast. And, uh, with that, we'll see everyone next time. Bye-bye.

Tanzu Talk · 🍕 Get more pizza.