Product design, with Alex Tran

Episode 133 · 52:42 · SRT · archive.org · all Tanzu Talk

Did I tell you about this? And they said, I've been listening to the Pivotal Conversations podcast. And if you bulk listen to them, that's not what the kids say. They say binge. If you binge listen to them, you can start to pick up a lot of background about what's going on with you two in your lives. Now, one, as I'm saying this, it occurs to me that you are, aside from your sartorial choices and how you survive the rain, you're very mercurial about not revealing very much about you. I mean, no one really even knows you could live in Kansas City, Antarctica. I don't think people even know where you live. Wow. No, that's true. I maintain tight control over my personal life. That's right. Now, that said, I wanted to give an update. Everyone knows I'm here in Amsterdam. Today in Amsterdam, very hot. And I don't know how Celsius works, but it's 91 degrees, according to my Apple Watch. Fahrenheit, which is hot. And the problem is there's no air conditioning here. I mean, it's not standard. It's not normal. So you kind of, like I was biking home from picking up the kids and, you know, it was hot, but not okay. And then it dawned on me that I'm not going to go home like I would in Texas to an ice cold house to cool off. I mean, you're wearing those wooden shoes. Those really air it out, though, don't they? They do. They do. They actually smell a lot better than you would think they would, being wood. You just use a coarse-grain sandpaper after a couple hours, just clean out all the gook. I completely buy that. I was talking to one of my neighbors, and he said, I asked, speaking of being slightly, is the right word, obsequious? I said, so do people swim in the canals around here? And he was like, oh, yes, everyone swims in the canals, lots of people. And so I said, yeah, like, is it, I mean, is it, like, is it, like, clean?

And he's like, hmm, not really. And then I said, so do you swim in the canals? And he said, no. If you do, I would take a shower afterwards. So I think, you know, he gave a good review. But I think there's, I'm learning this pattern of when you ask for recommendations is you ask specifically, this is like a net promoter score, I guess. You ask specifically, like, would you do this, right? Never mind what you think is the situation. So I guess what I'm trying to say is, is if we don't, if we don't publish or record next week, it's because I, uh, I dove into the canal and might've punctured my head with a bike that, uh, had fallen on there. Oh my goodness. Yeah. You've got lock jar tetanus or something. That's good. Uh, yeah. I mean, I love that he wouldn't have volunteered that if you didn't ask, like, I'll go swim in the canals. There's bodies and whatever else in there. It's fine. Exactly. That's, that's, that's a, uh, uh, I guess it might be a slightly relevant to, uh, our guest here, which you heard a little bit before, you know, like you find, you've got to find out how to interview people appropriately to like pull the information out of them. Otherwise, otherwise they, uh, they don't tell you things that are helpful. Right. You swim in canals full of barnyard animals or whatever else the problem is. There are, there is a swan family that lives in the canals with the mother swan. And well, you know, I don't want to be presumptuous, but let's just, let's be figure out, you know, swans. Probably you got the, the mother and the father swan and, uh, they've got about maybe six or seven swan babies. And I feel like if I encountered the swan family in the canal, I would be toast. They would do away with me. Yeah. That's their natural habitat. Yeah, exactly. Well, why don't you introduce yourself guest? Awesome. Uh, thanks for that, uh, awesome anecdote. Uh, I'm Alex, I'm a staff product designer, uh, pivotal labs and up here in beautiful Seattle. And, uh, yeah, I'm excited to be here with both of you. Now, I, uh, I assume you and Richard ran into each other.

You were chatting maybe around the coffee and, uh, yeah, yeah. I see him around. I don't know, you know, always learning new things about Richard, especially on this podcast. But, uh, uh, it's always been a pleasure. That's good. That's good. Tell us one new thing. Is he, uh, how much coffee does he drink a day? Do you, uh, do you see him surfing over there? Uh, we have really good coffee up here in, in Seattle. And so I'm sure he imbibes, uh, a good amount, but, uh, I don't know if he's the top, uh, consumer. I mean, there are folks who are really... I mean, Coté, we've, Coté, we've done a podcast for two years and you don't know I don't drink coffee. Oh, no, no. I was just about to chime in with that. If, uh, if, uh, well, at first I wasn't testing, but then my memory, uh, I've tried to explain to my family that my memory is like five minutes behind reality and, uh, it comes in. But yes, I, I do remember, I guess if you were to go look at the, uh, the fan Wikia for Pivotal Conversations, you could look up episode, I don't know, 98, where, uh, we discovered that Richard does not drink coffee. Yeah, Richard doesn't do hot drinks. Yeah, but I mean, I'm, I'm really owning the, uh, the Coke Zeros in the Seattle office. Oh, I see, I see. Okay, okay. Your little, uh, your little, who's the, uh, who's the, uh, man, I'm going to have to wrap up this inanity at the beginning, but who is the, um, who's the, Carl Lagerfeld there? Carl, he, he, uh, recently passed away. Oh, Lagerfeld? But he infamously drank Coke all the time, diet Coke all the time. So, uh, now it's not Coke Zero, but I think you're in good company. You've made some of those decisions. That's right. All right, well, uh, let's go over some news first in the tech world to remind ourself of, uh, why we're here. And then, uh, we'll, we'll talk a little bit with, uh, with Alex and see what's going on with that. And as always, if you have anything to contribute to the news items, Alex, feel free to, uh, to chime in or not.

Awesome. Uh, well, uh, there's, there's a new, uh, Pivotal Cloud Foundry release out, I believe 2.6. You wanted to tell us what's in that, Richard? Yeah, depending on when you publish this, you'll actually be breaking the news since I don't think we've published a blog post, but it is, uh, going live today here this, uh, Tuesday. So there's a lot of good stuff in there for Spinnaker and Concourse. First time, if you're doing CI, CD stuff with Spinnaker, really sophisticated deployments, that all works great with PCF. Now, uh, we've had things like sidecar processes so that you can deploy an app and have a little process sit next to it and do things like, you know, access the file system or do I have the transformation or things like that. Uh, there's also app revision. So once you deploy something, the PCF and PAS, you can actually roll back to a previous version very easily. That's the first time you could do that. Uh, we've generally available the AWS service broker. So connecting to all the sort of data services and machine learning stuff, all that's readily available now as well. So lots of good stuff in there, some KS updates and more stuff for Bosch aficionados and things like that. So a lot of good stuff in two six that's out today. And, and then, uh, somewhat related, you know, in the world of developers, just, just, uh, just briefly to kind of as a pointer to it. So I think it was a jet brains came out with their developer survey and I forget how many years they've done this, but I think it's one of those, uh, reliable, uh, yearly sort of things that you can start to look at. And, uh, we talked about it a little bit on my other podcast software defined talk. Last, uh, I was going to say last year, last week, excuse me, but, um, I think, I think one, as always, you see that, uh, Java and the spring framework is, is very widely used there. Uh, you know, those are perennial favorites. And I think, I think, I think the other, the other angle, which I talked about on, on that other podcast a little while ago that, that I think is, it's always interesting to look at this is, um, how ubiquitous, but sort of unchanging the adoption of things like unit test and, uh, continuous integration and things are so like with unit testing, it's at about

like, I don't know, 70, 75%. And, um, I think, I think as, as any sort of like NBA spreadsheet jockey will tell you, like your, your market share is never really going to get above that except maybe for breathing oxygen that has very good market share in the triple digits. Uh, but like, I, I think, you know, so maybe unit testing is like the, the height that we can achieve around 70. But then if you look at like build pipelines and stuff, it seems to be hovering around like 30 or 40% or maybe even lower, which going back to, uh, around 2014 or so when I was doing a roundup of this time and, and different, I think it was info queue surveys back then I would look at, but, uh, it was kind of at a similar level. And so, you know, without getting all nerdy about how surveys work and stuff, like it seems like, uh, you know, speaking of like Spinnaker and concourse and stuff, there's, there's plenty of room for people to automate their builds more. Hmm. No, it's a good point. I noticed that too, on that survey, some of the, the main points there on how many folks were doing CICD, how many were doing not unit was popular, as you mentioned, but integration test was fairly low. So that was interesting. Some other stuff. I mean, you mentioned boot and even Apache Tomcat, which was a leading contributor of 66% of the app server usage. 21% was number two and spring boot was also 60 something percent, just 12% for the next framework that most popular. So cool to see some of these, these pivotal technologies take over. The other thing that jumped out to me, I don't know if you noticed it was 70% are happy with their database and not planning to migrate. Boy, if you're selling databases, that's a tough space. Cause everyone seems locked into whatever they have. Yeah. So I thought that was interesting. That is, I like that. See, speaking of questions, that's good. Are you happy with solution X that the, the, the way that's phrased is good, but yeah, no, you're right. It is, uh, yeah, it's hard to move off a database, especially if it just works, which I think is key to happiness. Uh, that's right. And it's good enough. So, I mean, there's so many cool databases out there, but you'd think it's gotta be so

tough. It's brand new apps to get people on there. Yeah. Yeah. That would be interesting to look at. Like if that was one database or all the databases you were using, what are you going to do? Just sort of open up the info pane and preview for the PDF and drill down into it more. See, see what's in there. Have you ever noticed, do you ever do this where there's a published PDF? I like to go look at like a white paper, go look at the info page. And like most everyone uses InDesign to pump it out, which I guess makes sense. But InDesign, huge market share in the white paper PDF market doing very well there. True facts, true facts. Uh, well, related to that, uh, we also, uh, to, to PDF market share, not really, but, uh, we, we have a lot of coverage of the, uh, the spring runtime that offering that we've released, which bundles up, uh, an open JDK, uh, basically runtime for you and, uh, has support behind it, but also bundles Tomcat into it, uh, which, which I think, uh, covers most of the scenarios people would have. I think, I think, as we were just saying, tons of people run Java, lots of people run Tomcat and, uh, many of them have spring. So you've got kind of like the three main things, if you're doing Java development that, uh, you would be interested in. Yeah. Specifically everywhere. Cause I think people associate us with spring and things like cloud foundry versus run this on bare metal, run this on VMs, run it on windows or Linux, run it on Kubernetes in the cloud on-prem, all of that's now supported. So if you're looking for that full stack Java support, Pivotal actually has a pretty good story now. Specifically everywhere is a phrase I'm going to start using. I think that, uh, that points out the totality of something. It does. So if you, there's a, there's a lot of other exciting things, but if you were to pick out one more, Richard, what do you think is worth highlighting? One more news item. Yeah, there's a, uh, I put in here, there's a Kubernetes release that just came out one 15 and that was actually led by a pivotal person, Claire, which was pretty cool to see

that have the other thing I tweeted yesterday. Cause I did a quick look and saw like how, how well is everyone keeping up? Cause a year ago, it seemed like everyone was running like their cloud service or their private Kubernetes thing on the latest version, but has everyone caught up? And I thought it was interesting that, uh, Amazon's elastic, uh, Kubernetes service, uh, there's AKS and Google's GKE are all defaulting to still one 12 Pivotal is doing one 13. We'll actually ship one 14 in our PKS update coming up. Red hat's also one third. So just pointing out, and you know, you always trail a little bit, but it seems like potentially that lag between the full release and this being available in some of the commercial and cloud prices is a little thinning a bit. And just to me, China drives home, it's hard to keep up to date, even on quarterly releases for the cloud providers. So hopefully a normal, a normal customer is Kubernetes has a strategy for keeping up to date because it is hard and thinking you're going to manually do that in all your clusters seems pretty optimistic. Now, I don't, I don't know if you're working on a new, like maybe your 10th plural site course, Richard, but maybe, maybe to align with one of your professional hobbies, you could use an example application that basically automatically every day checks which version of Kubernetes is running where. That would be just a fun little splash page people could refer to. Like this is probably, this is still the case, but you remember in the, the heyday of the OpenStack world, I think Mirantis ran this site, but there was a site that would do like lines of code by contributors. And then you could see who all the top contributors were for things. People love that. And I think, yeah, you can see those for, you can see those now for all the cloud native computing fund. There you go. And I think, I think that, you know, the, uh, which version of Kubernetes are you running? That's, uh, people would love that similar sort of thing. Just a dashboard information radiator, uh, as they used to call it. So, so I like these ideas. Thank you. Thank you. If you note that in your, uh, your ice box, that's great. When you're having a Coke zero staring out the window and in Kansas city or wherever it

is, you may reside. Uh, well, uh, with that, why, why don't you tell us what you do around here? Guest. Uh, Hey, uh, it's great to be here. Uh, I'm Alex, a staff product designer at Pivot Labs in Seattle. Uh, yeah, it's great to be here. What's, uh, so what does a product designer do at Pivotal? Yeah. Thanks for asking. So we, uh, work with clients, uh, large and small to both help, uh, build products, but also help build, uh, that client's user-centered design practice. And so, uh, we typically, uh, have engagements, you know, a few months long, uh, bringing clients to the office, uh, and help them really grow their sense of how, um, they should validate or invalidate, uh, their assumptions, their experiments into building a product. I, you know, this is actually, uh, I've been right in the middle of this week of, of trying to find and write up these kinds of things where basically, uh, well, you use the keyword there where you're, you're validating and invalidating things, uh, and walking through it. And, and, and I mean, I think just, uh, you know, you can anonymize it or whatever, but like, can you give a couple of examples of like what that looks like, like to give you the template, like, Hey, I'm working on some software and I think I should have this feature and implement it this way. Is that a good idea or not? Now when I find out like, like what, uh, what are some instances of what that looks like to give people a sense for what that, that process looks like? Totally. And, uh, yes, I'll definitely be very anonymous. Uh, so sometimes it's extremely ambiguous. And I think that that's where, uh, design, uh, in a well-balanced team with product and engineering, uh, really gives our clients, uh, the most value when they come and actually they oftentimes

don't know what their priorities are and they actually have not clearly articulated their assumptions. And so for example, I landed in an engagement, I think, uh, two engagements ago, uh, my second day, uh, I was speaking with the chief architect and, uh, we were going through, uh, the different projects that the team was having. And, uh, the second priority, uh, we were going into and, and they said, Oh, you know, uh, a VP has told us that, you know, we have to do this project because it's going to unlock $9 billion worth of value. And I kind of paused there and I, and I just asked, how do you know that? Right. And, and they all kind of just stop. Right. And they're like, thank you. How come no, no one has asked this question, uh, before. And I was like, really? Uh, and so, you know, breaking that down a little bit, that phenomenon, it, it, it, it happens at a few different levels. One is, I think that sometimes people, uh, just at a consulting level, uh, you know, they in their organization may be faced with some inertia or they, you know, are just in a rhythm and they, uh, need to break out of it to ask those fundamental questions. And I think that sometimes people, uh, get caught up in when they think about design and just the visual aspects. Uh, but really when design is, in my opinion, uh, properly deployed as part of the whole team, they're taking everyone's, uh, abilities and disciplines and really helping, especially in

the early days, uh, of the product development process, help, help the team confront those assumptions really head on and, and break them down even at the organizational level. So the team in that instance had, uh, not only kind of, you know, taken this mandate from a VP, but after actually conducting user research with the people who were intended to unlock this $9 billion of value, uh, we actually also learned eventually that, that VP had no strong stake in unlocking that value. It was just kind of a casual thing, a casual hypothesis that this VP had thrown out and the team themselves had interpreted it as a mandate. And so not only did we, uh, eventually actually by doing user research and validate, uh, that this was something that was going to deliver any value at all, we also help them gain confidence in interpreting and understanding information that was coming from powerful people and helping them digest that and say, wow, like we had an assumption that someone more powerful than us would be telling us something and that regardless of their tone or messaging, we had to do it. And that wasn't the truth in this case. And so I think that it's really valuable for people to really step back and, uh, just have real conversations about what they think is true and to help everyone to have those authentic conversations and, uh, try to find the truth in the heart of the matter. Interesting. So one thing is you're, you know, I know we have people come to us and our office

here in Seattle, all our other couple of dozen pivotal labs offices that, to kind of learn how we work and start to maybe even get that mindset in place. What are those agile rituals that you think matter the most? Like what are those ones that people come in and we have to kind of show them or just kind of get them in the habit of? And, and then secondarily to that, I want you to answer, how do we make that doesn't just become ceremony when it's like, all right, stupid standup time. So what are the ones that matter? And then how do you keep them fresh? Totally. Um, so Richard, I appreciate you saying the word habit. Uh, I feel like, um, that's something that we do a great job of is instilling those rituals, uh, into the teams that we work with and creating those habits, right? Those, that muscle memory, uh, because I think that, uh, rituals really are built on that foundation, built on that, that habit forming, uh, abilities of humans, uh, to enable those types of practices to have momentum. Um, but to your kind of second point of your question, uh, any type of habit or ritual or practice that does not then, uh, connect to the principle or outcome that it's trying to drive can, can, can just become like, uh, a ceremony, right? Almost like, uh, just ceremony for ceremony's sake. And I think that, um, what I try to do, and I think, uh, what other folks in labs really try to do is really pair, um, those rituals, uh, with those principles and reinforce them over time. Uh, because if those become decoupled, then it doesn't work. And so I'll give you an example, um, with retro, for example.

So, you know, uh, in a typical labs practice, uh, we have retro, we have iteration planning meetings, we have company and team standup, um, just an example of, uh, uh, team retrospectives at the end of the week, uh, I've seen them be extremely impactful and also, uh, be kind of, uh, uh, uh, not, uh, substantive. And I think in the not substantive camp, I think where people lose sight of, uh, coming to those with humility, um, coming to those with an openness to receive feedback coming to those, um, you know, without having an objective perspective, uh, you may not have, you may not harness the full value of retrospective, which is a time set aside for teams to really catch those things in the week that may have been festering in terms of team dynamics, or if it's something that people want to use as time to give feedback on a code base or a design change, uh, making sure that that's based for that. And then also just for kind of team gathering and team cohesion, uh, and I've seen, uh, what I've seen really great is I think that in the beginning of a labs team interfacing with a client team, sometimes when clients are breaking out of their shell in that beginning, a retro may look more surface, uh, and not be as deep, but as that trust is formed, uh, the team seeing labs, folks model that behavior, that openness, eventually it becomes that more substantive ritual. And I think that's how rituals are so valuable and important to instilling those principles

of, you know, making a team able to have that open communication, that human connection. And I think that's something that people, you know, when they hear a ritual that supports agile or XP practices, they think it's highly technocratic or, um, technically focused. And of course we have discourse over technical topics, but for me, the real like, uh, value that sometimes like implemented subliminally is that human connection. Yeah. I mean, that, that end of week retro is interesting as, as, as you say, for things that we're going to learn, whether, whether some of the beginning of week things, for most people who don't know, the pivotal practices that we've kind of run these weekly cycles, what does the week look like? Totally, totally. So, uh, uh, as I was, uh, sharing a little bit earlier, right? We have a whole host of, uh, rituals that we normally run, uh, company and team standup. So we will have breakfast in the morning together, come together for company standup, uh, and then break out into our team standup where we talk about helps that we need blockers that we have things that we worked on previously, uh, and things that we intend to work on today. Um, and then also we'll have iteration planning meetings. Sometimes those are earlier in the week, uh, but sometimes, uh, those happen later in the week as well. Uh, those are really to help us run through stories, uh, to go through, uh, design and design changes and to really bring the team around, uh, things that inform the cadence of the week. Uh, of course there's always a ping pong break somewhere in there. Um, something that I've also been seeing as we engage with kind of large portfolio work or large enterprise work is, uh, connection to multi-teams.

And so having, uh, drumbeat type of communication where we also connect, uh, information across, uh, different, uh, small, well-balanced teams, as well as connecting to like larger, uh, leadership through things like a growth board, uh, where we talk about, uh, metrics that, um, connect down to the project team. Well, you know, this, as, as you've been going over this, I've, I've been thinking about the, uh, I don't know, maybe it's just cause, cause I'm hot, but the kind of like negative, uh, mirror image of this, um, which is, you know, we used to have that. We had this podcast series a couple of years ago now, I think called, uh, that moment, which was all about like, when was that moment when you decided to, uh, do awesome stuff or like to innovate something or do a good development. And it has some nice stories around that. And, you know, to use the kind of negative version of that, just to hear you theorize it, like, like, let's say an organization is going around and things are successful, right? Like most all large enterprises at some point were very successful. Uh, otherwise they wouldn't be large enterprises that still exist. So they figured something out. Uh, but you know, sometimes, uh, they have, you know, that moment where things start to go poorly. Like they forget the bad habits or they become too bureaucratic or, or something. Right. Um, and, and I wonder like, like whether it's only in your head or you sit around with people, like one of the things, and you're kind of just like maybe having some Coke zero or too much coffee. And, you know, I used to talk about this with, with my developer friends, which is basically like, why are these people not doing the thing that obviously is better? And instead they're kind of like sticking to this other thing. Like you, you know, as an example, what made me think of this is like, you know, any time someone uses the phrase unlock followed by billions of dollars, it's probably good to question that, that phrase and yet no one would.

So anyways, I'm curious, like what you think in a large organization, like how do they get to this point where they sort of need to be retrained about how to do things in more of a, uh, I don't know the way you're talking about? Totally. Uh, I feel like I've been very impressed with our clients. And I say this like completely authentically that, uh, many times they have the, uh, foresight and the talent, um, to think about problems in the way that you're saying to go, because to go back to that anecdote, um, the architect that I was talking with was like, absolutely, you're exactly correct. Like we should not just take this as gospel, right? That we're going to unlock this $9 billion of value. Uh, but I think that, uh, to your point, uh, sometimes people need some empowerment and they need, um, also a container for having those conversations. And I think that sometimes the macro environments, like they're slammed with seven hours of meetings a day, right, which is very against kind of our just enough process, uh, practices in labs. Uh, they have no psychological space or psychological safety sometimes to have those real authentic conversations that help drive, uh, the types of decision-making, uh, nimble decision-making to move forward. And, you know, sometimes I think that, uh, you know, we then come in and we help them establish these rituals where they can have those conversations. Uh, but something that I also like to think about is where each context that we go in, in, in labs

is, is totally, uh, totally different, um, engagement and engagement. And so it, as we like think about principles and first principles, we're also flexing how, um, rituals and how our practices, uh, need to land engagement to engagement. Uh, and so just to give a concrete example, you know, this, that client in that anecdote, uh, they had been with labs for a few engagements now. So things were really, you know, established and running in terms of standup, in terms of IPM, uh, and, you know, they really understood, you know, from a designer perspective, uh, the, the discovery and framing process, like going out and doing user research with users and validating and validating assumptions. So they have the tools, but still there was, uh, an emotional gun shyness, maybe I'll say around questioning or being able to bring up how data, uh, brought out from research could validate or invalidate someone really powerful, uh, this is assumptions. And so, um, um, I actually started a new ritual with them that I, uh, going back to our coffee discussion earlier this morning, um, called design coffee. And I made it a 10 minute time box ritual every Wednesday to discuss any type of, um, product or design conversation that may be something that had kind of fallen by the wayside, but maybe was a little bit emotionally charged, but just needed a space to be talked about. Um, and, and more, more space than maybe a standup provided, um, and something that I didn't want

to wait for in a weekly retro. Um, and the outcome of that was, um, we finally had a space to discuss things that weren't specifically, um, you know, what was going to be refactored this week or, you know, what, um, was going to be specifically worked on in terms of a database perspective or in the code base, but rather like, hey, you know, we have these priorities, like, how are we going to understand if this is our real priority? Um, and how are we going to prototype or figure out something that we can put up in front of users to validate or invalidate this assumption? And so I think that for me, um, having that flexible mindset in terms of, hey, uh, just have just enough process, but also like if, if there's feels like a need that's not being filled, how can we be entrepreneurial and instituting any rituals or, or deleting any rituals that are not serving our, our principles or the outcomes we want to drive? Yeah. And, you know, it seems like that last part pulls together, uh, a lot of things, which is, well, I guess to kind of reformulate like my, my original questions, just as, as reference for myself, like, like, uh, uh, so you have an organization that's successful and sometimes, oftentimes what happens is they, they, they start new bad habits, like maybe, you know, because they're new, they never really had these habits, but they kind of like fall back on doing these habits. Now, maybe this habit is that they don't evolve their process to match new ways of doing things. So they're stuck in the past, so to speak, but you have, you have some bad habit, like, like to use our example, you don't, you don't question what the boss says as far as like what, um, what macro and micro strategy is, uh, essentially like, like we were, we did a podcast with, um,

Jonathan Sterlin. Is that how you say his name? Mm-hmm. Remember, remember that one, Richard, about the food service company? And, uh, yeah, that was great. And the bosses were basically like, you know, what we need to do is, uh, you should put recipes on iPads in the kitchen. And, uh, so normally, you know, you would put recipes on iPads in the kitchen, but instead the team went there and they were like, you know, what actually is a problem is they're always, they're spending all this time measuring the mayonnaise and that really like clogs up the system. So we should fix that problem first, which is, you know, it's a good example. I think of, um, questioning authority is like, you know, some nineties black bandana breaking a McDonald's window way of putting it, but like, it's sort of like a process of truly discovering what you should be doing by not assuming things. So anyways, I mean, that's a good habit to, uh, you kind of build that up. Uh, but you know, then there's also just regressing to habits you fixed, uh, that happens as well. But it seems like a lot of what, how you prevent that. And you were saying this at the end is, and it's always kind of frustrating to have this as the answer. Cause it's, you're assigning yourself more homework, but it's like, you need to really like write down what the principles are that you're following. And like, you're, you know, like kind of to, to kind of like come up with a principle with our example, like you shouldn't just take on face value, like some assumption that you have, unless it's kind of like proven out. Like if there's no footnote, then you should find out what the footnote should have been. And if there isn't one, then figure that out. And so like, I don't know exactly how you express that in some like, you know, really nice principle, but it probably, it probably is like worth the time of an organization to think like, here are the, and I'm just making this up, like five or 10 operating principles that every now and then we need to check in and make sure we're doing. Um, and, and the first principle is like checking on the principles, right? Like, like, like if you're not doing that, then something is probably going wrong, uh, which should be indicative of, of sliding back on, on, uh, bad habits.

Totally. And, uh, I, I like how you talk about also, you know, regressing to bad habits and like how that's something you don't want to, uh, like not look out for. Um, and that's where I think that, uh, you know, when you're going into a client engagement and you're wanting to be really sensitive to people's, uh, emotional states and supporting them and their growth, you know, I don't go out of my way to, um, point that out and, and, in a way where they feel shamed or, um, not supported. Um, but I think that, uh, instead like helping them, um, have a conversation with themselves and acknowledging that they do have those bad habits and figuring out a way to then also, uh, like I was, I was sharing with the design coffee example, replacing those bad habits with a safe way in their mind, a psychologically safe way to question, um, something that was said, right. And, and knowing that that doesn't, doesn't mean that they're not, they can't be collaborators with a VP. They can't be, um, you know, uh, have good relations with that leadership. Uh, but they also don't have to mindlessly follow, um, what those people are saying, right. And changing that dynamic so that, um, you know, cause it was, it was fascinating. They were like, I was like, oh, are you all afraid of getting fired? And they're like, no. And I, so I was like, okay, so if, if you have that safety or that feeling of safety, um, then let's, you know, let's have those, those conversations. Um, and, and it happened and then I was actually, I had to leave for, um, uh, a week for health

related issues, which are all fine. Um, but they actually had that entire conversation with the VP while I was gone and they actually sustained, uh, that kind of casual design coffee ritual. We started together while I was out. Um, and they had the conversation with the VP, they were nervous, but they, they walked that VP through that research and, and this person was like, oh, great. Thank you. You all are the experts. Uh, you all have this on the ground information. Thank you. You all are free from having to do this, this work. And, you know, went about, you know, the 80,000 other things this person had to deal with. And so that was, uh, a really, I mean, proud moment for me, honestly, because I was, I was really happy that the team felt like they had the confidence, um, and the space to, to do that. Yeah, that's great. One to pull back to Alex is something you'd mentioned earlier. And I was introduced to DNF, uh, I mean, I knew of it and I knew Pivotal does discovery and framing, but I heard David, our office director explain it in the meeting and he did such a great job. What's the role of design in that effect, if I steer you in that direction? So what is discovery and framing and how does design help make that effective? Totally. Totally. So, uh, not a ritual that we do every week, but certainly, uh, a large, uh, kind of thinking framework and also a process that we do, uh, up front in a lot of engagements is, is exactly what Richard said, a DNF. And what a DNF, uh, stands for is a discovery, uh, and framing, uh, process. And, uh, this process is really, uh, about getting our clients thinking in, uh, you know, going

back to our conversation about principles in an evidence-based mindset, um, at its simplest level, right? Like not taking our assumptions at face value, especially from, uh, folks who have a lot of power in the room. Uh, and so what we do is we run through all the way from a kickoff process with our clients, we run our clients through, um, all of the kind of initial steps of a user-centered design process and we do a lot of exploratory research to, uh, understand the problem space around the initial brief. So a client might come to us and say, uh, to Michael's point, uh, hey, we need, uh, recipes on iPads in the kitchen and we'll say, okay, great. Uh, thanks for bringing this problem to us. Uh, let's understand all the people and the technology and, uh, the environments that surround this problem and we'll generate a lot of understanding in that space and then we'll synthesize that information. We'll hone down, um, and then come back to the client with a kind of, uh, boiled down understanding of, of a key framework and a key problem statement, uh, that backed by data helps us communicate back to them. I'm like, hey, you said you have this problem. Uh, we kind of got down to root causes and, uh, uh, also did technical discovery and, uh, uh, interviews with folks in, in, uh, that space who may use your product. And we actually understood that this was your real problem. Uh, and from there we'll expand again, diverging into many different types of solutions, uh, do again, uh, more technical discovery, but also a lot of rapid prototyping, even on paper,

uh, and bring those to clients, validate or invalidate, uh, those different solutions and then produce that, um, kind of, uh, final idea and solution to the client again, um, at the end of the framing part of the DNF. Um, and that really helps us inform the client, like, hey, you had this mountain of ambiguity, uh, with all these assumptions about your user and the problem space and the solution space. And here's how we, the well-balanced team of developers, designers, and product managers, and sometimes data scientists, sometimes other folks, uh, brought together all of these users and key parties to really understand where we should start development. Or, um, if the solution is not a development solution, here's our recommendation about how to approach this problem. Um, and that leads us to inception and starting to, you know, add stories to the backlog, um, and start development. And so, oh, I really think that it's a great, um, also from an enablement perspective, it's a great way to introduce clients to, uh, the user-centered design process and also to technical discovery. Uh, but I think that it's, it's something that we try, like the spirit of the DNF is what I like to call it, that evidence, uh, based mindset. It's something as a designer, um, I really try to carry through all the way through an engagement so that people don't lose that spirit. I mean, just so if somebody doesn't hear all that, go, that sounds like a lot of work. Like, what is that a two-year process? Like, how long does DNF usually take before we get into inception and start putting hands on keyboards, building things? Totally. So, uh, I've done DNFs that are like four weeks. Um, but sometimes it can be shorter or longer. Um, it really depends on the problem space and also honestly, uh, how, like the velocity,

of, um, how, how, how we are as a team. So, you know, if I have an experienced, uh, designer pair, uh, and, and the client has like helped us, uh, set up, um, those research participants really well from the beginning, like we can, you know, really blast through a lot of work fast to help the client, um, really get to, to building things as you said, Michael. Um, but I also think like, and this is what I really love to work with, uh, the developers on both the pivotal and client side with is, um, I'm very agnostic in terms of how we prototype and how we invalidate or validate assumptions. So if engineering paired with design and product, uh, think about like, oh, like what if we, you know, push some small production app to like validate or invalidate this assumption and it's, it's cheap and fast to, uh, do that, to de-risk that assumption. Um, you know, if it's a really, uh, API driven or backend type of thing that we're developing, like sometimes the best thing to prototype will be, um, something that's, that's, that we can push a production really fast. Um, if it's something, you know, very ambiguous, like they have no idea, um, where they're going with it, then, uh, sometimes we do want to hang out in a more kind of design or research space longer. Makes sense. Yeah. You got to add the, uh, add some of that deliberate expertise to the, to the, to the guide there to, to, uh, that always does seem helpful to have some outsider who sort of knows how the story goes to give you some notes on it.

But, but speaking of, uh, you know, I, well, I mean a couple of things, one, so, uh, before we wrap up, like, is there like, where would you recommend people like go read up about all this stuff? Like, do we, we don't really have like, uh, the labs way of life book, but there is, there is, there is like, like over on built to adapt and other places here, like, you know, there's, there's a, there's a fair amount of writing up of a lot of this thinking, but outside of the confines of pivotal or that as well, like, is there like, like what's, what's a good, like, I don't know, one to three item reading list or something that people would go look at for, for all this kind of, let's call it product thinking. Like what, what do you refer people to? Absolutely. So, uh, we have, as you just mentioned, great, um, blogs about our DNF process, uh, and our other processes on built to adapt, uh, watch this space, uh, labs is going to have a lot of content coming up on, on the, uh, normal pivotal.io, uh, website very soon. Um, and I'll actually be writing a little bit about design rituals on there. Oh, that's exciting. Yeah. Yeah. So some exciting content is coming. Uh, uh, our wonderful, uh, design team in Seattle is, is hard at work working with designers all over the world at pivotal, um, to build out, uh, a lot more content around, uh, describing our process, uh, describing, uh, ways that we engage with our clients, large and small. Uh, so definitely, uh, watch the space, uh, but also, uh, in terms of, uh, some of the things that we discussed here, uh, uh, we have, uh, great content, um, just in terms of like the

DNF, actually, it kind of grew out of, um, work done by the London design council. So if you, if you go to their page, uh, and just Google them, uh, they have a lot of, uh, some of the thinking that was, uh, the foundation for, uh, what eventually became our DNF process. Um, and then, uh, my work around and my focus around design rituals, um, is inspired, uh, a little bit by just, you know, my work on the ground as a pivot. Uh, but also there's some really cool things coming out from, uh, the design ritual lab at the D school in Stanford. So, um, those are just some great things to just pertinent to what we talked about in this conversation, um, that I think that's a great thing. I think would be great. Uh, otherwise, uh, lean startup and the startup way are just in terms of, uh, overall product thinking are good resources as well. Yeah, no, that's true. It often comes back to the, uh, the, well, in the context of the enterprise space, the tragically named, uh, startup part of lean startup, but it always comes back to that, uh, that like loop of validation, which, which I think, uh, people are often missing. Well, well, that sounds great. Well, thanks for going over all of that, uh, that stuff with us. But, you know, that's, that is the second thing I was going to say is, uh, you know, uh, we might be saturated here around Pivotal, but y'all labs people, you should have a podcast just every week. Ooh. You don't, you don't have to do the whole thing where you, where you lay down some, uh, some spooky, you know, ducking of music tracks and things like that. That's a lot of work, but just, uh, just have some podcasts going over things like right before this, I was, um, I was reading up on a bunch of internal case studies of, uh, lab stuff in Europe. And there's just like no end of like, they're just one slider things, but you can kind of read in between the lines of like the fun, enjoyable processes that, that went behind

them to actually, uh, you know, it's like mortgage stuff and connected car, which ostensibly is really boring, but I'm sure, you know, when you're doing the actual work, it's interesting. And then it, uh, actually has like, you know, people can get mortgages better, which is nice. But anyways, there, there's a, there's a lot of good stories just as you're illustrating running around there. I'm going to have to pick your, I'm going to have to pick your brain. Uh, yeah, well, uh, well, uh, and also do you have, uh, you have a Twitter account or anything you want to point people towards? Totally. Yeah. Uh, folks can follow me at, uh, Alex S Tran, um, on Twitter. Uh, yeah. I tweet, uh, a lot about design things and then just full disclosure, a lot about, uh, the design of our, uh, government and political systems. So the design, that's a good way of putting it. Yeah. I just like to put that full disclaimer out there, uh, so that, you know, people know what type of content they're getting into. Exactly. That's right. Uh, but yes, welcome, welcome folks to connect with me there or any other places, um, online. All right. Well, great. Well, thanks again. And, and as always, uh, just in case you don't know what's been happening to you, you've been listening to pivotal conversation, you can get this episode and, uh, like the, the one with Jonathan that we referenced referenced and other ones over at soundcloud.com slash Pivotal Conversations. And about every Thursday or so, uh, we post the show notes for this. We'll have some of the links mentioned, uh, at pivotal.io slash podcast. And with that, I think, uh, I think I'm going to go jump in the canal. Yeah.

Tanzu Talk · 🍕 Get more pizza.