Nicole Bryan

[00:00:02] Good afternoon-ish. Almost ready for lunch. [00:00:08] So last year, I stood up here, I actually think in this exact same [00:00:12] room, but I could be wrong on that. [00:00:14] And my title was VP of Product Management, [00:00:18] which you may not think is relevant, but actually the whole reason I'm [00:00:22] here today is to tell the story essentially of [00:00:26] why now my title is VP of Product [00:00:30] Development. [00:00:31] It's really why I'm here today. And as we all know, Gene and [00:00:35] this whole community is very [00:00:39] into and very much appreciates these experience reports. [00:00:42] So [00:00:44] my formal title of this story is "An Experience Report: [00:00:48] Transitioning from Project to Product." [00:00:52] That's the official title. [00:00:54] The actual title that I submitted was [00:00:57] "Oh My! [00:01:00] Does Moving to Product Value Streams Really Involve All of That?" [00:01:05] But I guess that wasn't formal enough, so we went with the formal title. [00:01:09] I'm going to attempt to go through some things, and hopefully y'all will take away [00:01:12] some tips and tricks and things to take back to your organizations. [00:01:16] But I think from my perspective, one of the most important things that I've [00:01:20] used in the last year is simply the phrase, oh my. [00:01:25] Oh my. Oh my. Oh [00:01:28] my. Oh my, oh my. Oh my. [00:01:32] I think it evokes empathy and thoughtfulness without judgment, [00:01:36] which is an important part of going through this journey. [00:01:39] I did, in fact, actually, at one point, this deck had every time [00:01:43] I had an oh my moment, I'd put a slide in that said oh my, but then the whole deck [00:01:47] was just oh my, so I removed that. So if you take away [00:01:51] nothing else, go back to your organization with some oh my's in your back pocket. [00:01:56] I do have to give one more disclaimer, [00:01:59] because Tasktop, many of y'all work at massively huge [00:02:03] organizations. Tasktop is not massively huge, [00:02:06] but I really do believe that much of the experience that [00:02:10] we've gone through is relevant. And in fact, because we are [00:02:14] small enough whereby someone like myself can see into [00:02:18] finance and HR and all the departments easier, I think there's some takeaways [00:02:22] and some things that can [00:02:24] absolutely be applied to large-scale organizations. [00:02:27] Also, all of our customers are very large-scale organizations, so [00:02:30] don't discount what I'm going to be going through just because we're smaller than [00:02:34] most of the companies y'all [00:02:36] work for. [00:02:38] So I think nobody really would question there's a movement afoot, [00:02:42] right? How many of you are working in organizations that are trying to move from [00:02:45] project to product? [00:02:47] Right. And even last year, that number was, what, much lower. [00:02:50] So [00:02:51] there's clearly a movement afoot. Here's one of many, many, many statistics. [00:02:55] 55% are trying to move from project to product. [00:02:59] So is that why Tasktop went on our journey [00:03:03] to be part of this movement? Well, the truth of the matter is that the answer to [00:03:07] that question is actually no. [00:03:10] The real reason we went on this journey is simply because [00:03:14] we were flummoxed. We were absolutely flummoxed. [00:03:18] And I can actually walk off the stage now and go off into my life [00:03:22] because I've always wanted to use the word flummoxed in a talk. [00:03:26] I now have used that word, so I guess I'm done. [00:03:30] I love that word, flummoxed. It's a great word. But we were honestly flummoxed. [00:03:34] Why? We're a product company. [00:03:37] Not a bank, not retail. We're a product company. [00:03:40] So [00:03:41] aren't I operating in a product-centric way? [00:03:44] Well, we had issues. [00:03:47] And interestingly, you've heard Mick and Carmen and others talk about [00:03:51] the core areas you need to look at in order [00:03:54] to ensure that you're moving more to product thinking. [00:03:57] You look at all of these [00:03:59] areas. [00:04:02] And if you looked surface level, [00:04:05] we were doing great. We'd ticked all the boxes. [00:04:09] It was fine. [00:04:10] But as I said before, we had issues. [00:04:13] So let's talk a little bit about what these symptoms were. [00:04:17] First, we had a bit of an us versus them [00:04:21] issue between product and engineering. [00:04:23] I'm sure that's never happened in any of your organizations, an us versus them. [00:04:27] But we had a bit of that, too much of that. [00:04:29] Problems had to go too high up to get resolved. [00:04:33] They often had to go all the way to the CEO to get resolved. [00:04:37] This one is probably the most important one. [00:04:40] There was a lack of knowledge about and empathy for our [00:04:44] customers, something we pride ourselves in. [00:04:47] And all of a sudden, we were not feeling that we had that empathy and knowledge [00:04:50] about customers. We were feeling more inward-focused [00:04:54] than outward focused. As soon as you feel more inward [00:04:58] focused, pack it up and go home. You've got to make [00:05:02] some significant changes, and we were beginning to feel more inward focused [00:05:06] rather than outward focused. And then we were really questioning, [00:05:10] were we truly product-focused throughout our entire organization? [00:05:14] Finance, HR, biz dev, throughout the entire organization. [00:05:19] And last, but definitely not least, [00:05:22] investment decisions [00:05:25] were twice-baked. [00:05:27] How many of y'all are from the South in the United States? [00:05:29] Probably not many, but twice-baked potatoes are like the best thing in the [00:05:32] world. Get your mom to cook you some. [00:05:35] You want to eat twice-baked potatoes. [00:05:37] You do not want your investment decisions to be twice-baked. [00:05:40] Essentially, we [00:05:42] would make an investment decision, and then would have to resell the investment [00:05:46] decision to the engineering organization. [00:05:50] And that didn't feel good. So these were kind of the symptoms that we were [00:05:54] feeling. [00:05:55] But again, surface level, we ticked all the [00:05:59] boxes. And we were in this very significant time of [00:06:03] reflection. Mick's book was about to be coming out, [00:06:07] all about moving from project to product. So it was kind of a good time. [00:06:10] We were self-reflecting. We were really focusing on these [00:06:14] issues. And what we realized is that mindset is [00:06:18] everything. So we ticked all the boxes. [00:06:20] But context and structure, the [00:06:24] context within [00:06:26] which you work [00:06:28] makes an absolute difference. And the further you feel [00:06:33] from your customer, be it an internal customer... [00:06:37] How many of you all work on projects and products that are for [00:06:41] internal customer usage? [00:06:44] Right. But you have customers, [00:06:47] and they matter, and you should be as close to them as you possibly [00:06:51] can. [00:06:52] Oftentimes people think when I talk about this, we're only talking about [00:06:56] companies like mine that sell external software. [00:07:00] Not the case. It is absolutely the same for internal customers. [00:07:04] So this mindset is everything, and we really began to see [00:07:08] that product thinking is really only there for the purpose of [00:07:11] customer first. [00:07:13] So what did we do? [00:07:17] What we did is we went back, [00:07:19] and we looked at those same core areas through the [00:07:23] lens of a customer, of our customers. [00:07:28] And when we did that, we discovered something very interesting. [00:07:32] Very interesting. And that effectively was that the way [00:07:36] we were thinking of teams, which by the way, the way [00:07:39] we were structured is very common in software companies, the way we were [00:07:43] structured. We weren't doing anything crazy. [00:07:46] It was very common, but [00:07:48] it wasn't customer first. [00:07:51] It wasn't customer first. So [00:07:53] it's scaled down, but this is the structure that we [00:07:57] had originally. You had a VP of product, that's [00:08:01] what I talked about last year, and we had a VP of engineering. [00:08:04] But what does that do? [00:08:06] And by the way, [00:08:08] Mick, our CEO, is sitting in this room. [00:08:10] Mick, I didn't blur you out because you aren't important. [00:08:15] That's kind of not good for your career path. [00:08:17] But [00:08:19] the view of team was this. If you asked anyone in our [00:08:23] organization what team are you on, they would have either said product or [00:08:26] engineering, and that then permeated all the way through. [00:08:30] So what [00:08:31] are some of the issues with that? It creates this product versus engineering [00:08:35] attitude. [00:08:36] All difficult decisions, even though he's blurred out, kind of have to go [00:08:40] quite high up for resolution. [00:08:44] And probably most importantly, [00:08:46] this was an internal view of team. We were organized from an [00:08:50] internal perspective, not the customer view of team. [00:08:55] So the customer view of team [00:08:59] is this. [00:09:00] This is how a customer sees the work that we do. [00:09:05] So [00:09:08] the values of product thinking, as I said before, embody [00:09:11] this notion of customer first. Why weren't we thinking and organizing from [00:09:15] that perspective? [00:09:18] And so what we did is in fact move from this [00:09:21] structure to this structure, and [00:09:24] that's why now I have a different title, and now we are structured [00:09:29] all around the concept of product value streams, [00:09:33] and all the teams are [00:09:35] smushed into one. That's a super technical [00:09:38] phrase. Smush your teams into one. [00:09:43] And so now what that has resulted in is the [00:09:46] we, the concept of team and the we, [00:09:49] matches how our customers see us. [00:09:54] Decisions are pushed down. In fact, almost all our decisions are made [00:09:58] directly within a product value stream, [00:10:00] or between product value streams. [00:10:05] This is not to say that dependencies don't still matter, and I'm going to talk more [00:10:09] about that in a bit as well. [00:10:13] So as with all things [00:10:17] in life, things are always more complicated than you think. [00:10:19] So I'm going to go through two things. [00:10:21] What happened, [00:10:24] and then [00:10:25] what happened because of what happened. [00:10:28] And probably the because of what happened part is the [00:10:32] more compelling [00:10:34] part. [00:10:35] So what happened? Fact-based, there was a [00:10:38] new role introduced called product value stream lead. [00:10:42] Brand new role introduced. And we moved from a product team and an engineering [00:10:45] team to a single product development team with four product value [00:10:49] streams. Two internal-facing product value streams and two [00:10:53] external-facing product value streams. [00:10:57] Each one of these teams, each one of these product value streams, had a [00:11:01] top-level default structure where there's a product value stream lead, an [00:11:05] engineering manager, and a product manager. [00:11:09] Now, [00:11:11] if you go onto Google and you google product value stream lead, [00:11:16] you get nothing. zilcho. Absolutely nothing. [00:11:21] And so we knew we were kind of on our own to figure out what this [00:11:24] really meant. And then the other thing is you notice that I said there was also a [00:11:28] product manager. So you have a product value stream [00:11:31] lead and a product manager. [00:11:35] And yes, you do need both. [00:11:38] And no, [00:11:40] neither of them are project managers. [00:11:43] Super important takeaway. And so the first thing we did is actually spend quite [00:11:47] a bit of time making sure it was extremely clear what the distinction [00:11:51] was between a product value stream lead and a product manager. [00:11:55] So this truly is our definition of a [00:11:59] product value stream lead. Don't worry, I'm not going to read this entire thing [00:12:03] for you all. I just want to highlight a couple points. [00:12:06] Note that in the core definition of a product value stream lead, it says [00:12:10] responsible for all aspects of their product value stream, both [00:12:14] business vision, design, customer happiness, cost pricing, market [00:12:17] changes, operational, and technical. [00:12:20] Agile teams, estimation, and architecture. [00:12:22] So you have a very holistic view of your product value stream. [00:12:26] And one of the most important things that that person does is actually [00:12:30] determines the flow item distribution [00:12:34] because they are the only ones that have the true, biggest, largest [00:12:38] context of what's going on in their product value stream. [00:12:42] And they're responsible to set objectives, results, and measure success. [00:12:45] You've heard a lot of people talk about the importance of measuring. [00:12:48] I cannot say enough times that if you're not measuring as part of [00:12:52] doing this, you're not going to succeed. [00:12:54] So measuring is [00:12:56] absolutely extremely important. [00:13:00] So now the product manager. What is the product manager? [00:13:04] His [00:13:05] or her main goal is responsibility for prioritization of all the flow [00:13:09] items by deeply understanding all stakeholder needs, [00:13:13] customer, field, analysts, and technical [00:13:17] trade-offs to ensure efficient delivery of these prioritized [00:13:21] items. So, they're responsible for prioritization. [00:13:25] They're responsible for the feature design of an entire product. [00:13:29] And they oftentimes will take on the additional role of product owner, but [00:13:33] depending on size and scope, that's not always the case. [00:13:38] So just to summarize, because I know there were a lot of words up there, summarize [00:13:41] the difference between a product value stream lead and a product manager. [00:13:44] Product value stream lead, whole picture, business, operational, [00:13:48] technical. Product manager, prioritization. [00:13:52] And anybody that thinks that you can have a product [00:13:56] manager that also does the role of PVS lead, you're mistaken. [00:13:59] It is too much. [00:14:01] The act of really knowing how to prioritize and knowing your customer is a [00:14:05] full-time gig. [00:14:09] Product value stream lead, significant people management [00:14:12] duties. Product manager, generally no people management duties. [00:14:16] Now, people skills, [00:14:19] off the charts, but in terms of people management skills, much less. [00:14:23] The leads generally don't do any of the feature design, but the product managers [00:14:27] spend a tremendous amount of their time doing feature design. [00:14:31] And then in terms of... Oh, people always like it when the metrics go up, I guess. [00:14:36] That was kind of intimidating. [00:14:39] The primary metrics [00:14:42] that are used for the lead, it's more about flow distribution, [00:14:46] as I mentioned earlier. It's actually in the definition of their job, and flow [00:14:49] efficiency. For the product manager, it's about flow [00:14:53] time, flow load, and flow velocity. [00:14:56] Now, in no way do I want y'all to leave saying, "Okay, I'm a product manager. [00:15:00] I only pay attention to these three things." [00:15:02] They get used by both, but just in terms of where your [00:15:06] focus area is, [00:15:08] these are the differences between them. [00:15:11] It's always [00:15:13] nice when there's real stories from real people. [00:15:16] So we've got two of our product value stream leads, and one thing that's [00:15:18] interesting is one of them up there is actually a former engineering manager. [00:15:22] The other one is actually a former product manager. [00:15:25] So just to show, doesn't matter which backgrounds you come from, you can mix and [00:15:29] match. However, I'm going to be going through in a moment what makes a [00:15:33] good product value stream lead, and so you have to be looking for these qualities. [00:15:37] But [00:15:40] Lucas on the left, the product value stream lead role creates team [00:15:43] agency, [00:15:45] combining PM design and technical execution. [00:15:47] It has very little to do with being a PM, he means in that case, product [00:15:51] manager. Jeff, over on the right, [00:15:54] I think his take is very interesting. [00:15:56] It requires him to speak in terms of business results. [00:15:59] Notice that he has something interesting in here about he's unenamored with [00:16:03] technology, [00:16:05] which in many ways is quite good to be unenamored with technology. [00:16:08] And the second point that he makes, I think is extremely important. [00:16:11] "It forces me to delegate the role of technical lead to someone on the team. [00:16:15] This should serve to empower the team to do what they think [00:16:19] is best." [00:16:20] I think it's just interesting to get different viewpoints from people in the same [00:16:24] role. [00:16:26] So what makes a good product value stream lead? [00:16:30] First and foremost, they have to be business-minded. [00:16:33] They don't have to be technically on the business side, but they do [00:16:37] need to be business-minded. They also absolutely [00:16:41] critical to have vision. You heard Gene talking earlier about the importance of [00:16:44] vision. This role really requires significant [00:16:48] vision. They have to be empathetic. [00:16:51] So actually, you're managing a lot of different personality types because you're [00:16:54] dealing with the fact that you're dealing with your customers and analysts, et [00:16:58] cetera, [00:16:59] as well as your engineers. [00:17:02] The personality traits in common between an analyst and an engineer, generally [00:17:05] speaking, are pretty much zero. I [00:17:10] love them both. You have to be able to show empathy, and have empathy [00:17:14] for all the parts involved. I already talked about this, being a good [00:17:18] people manager is critical. It's absolutely critical in this role. [00:17:21] Again, not so much for the product manager role. [00:17:24] And you have to be multilingual, and by multilingual, what I mean is that you have [00:17:28] to be able to speak. My husband always says that after 20 years of [00:17:31] marriage, he knows how to speak wife. That's what he calls it. [00:17:34] "I speak wife." [00:17:37] I don't think I've learned to speak husband. [00:17:39] I'm not sure I even want to, to be frank. [00:17:41] But you have to be able to speak [00:17:44] analyst, speak customer, speak executive. [00:17:48] Talk earlier about how to speak to the board. [00:17:51] You have to be able to speak like that, speak to engineers who are going to come [00:17:54] and talk to you about all kinds of technical details. So multilingual. [00:17:58] And this last one I put up specifically because I think [00:18:02] our COO is also in the room, and he always tells me that he doesn't care about how [00:18:05] the sausage is made. But this role, you need to care about how the [00:18:09] sausage is made. Now, you might think to yourself, "Hold on a second. [00:18:14] Business-minded and caring about how the sausage is made? [00:18:17] Is that possible?"It is, but it's tricky to find, and you [00:18:21] really need to make sure that you're communicating to your leads that you [00:18:24] absolutely need to care about both. [00:18:26] Because if you don't care about both, you're not going to succeed in actually [00:18:29] paying attention to the whole. [00:18:33] So a couple other considerations. [00:18:36] Don't be blind. Specific individuals matter. [00:18:39] And this is much harder, I will say this is much harder in a large scale [00:18:41] organization. [00:18:43] You need to actually say, "Is John going to be good [00:18:47] as a product value stream lead?" John, [00:18:50] not just a generic person. [00:18:54] Context and background matters. So for us, of our four product [00:18:58] value streams, two of them are run by people with engineering backgrounds, [00:19:02] two with product backgrounds, and that actually makes a difference. [00:19:06] Another consideration, where do you put cross-cutting or [00:19:10] adjacent roles? That could be a whole talk in and of itself. [00:19:13] I don't have time to go through that. [00:19:15] And then you need to make sure that you allow teams to have flexibility within [00:19:18] their product value streams. As an example, one of our product value streams [00:19:22] has determined they want the title and role of team lead. [00:19:27] Others have decided they don't want that in a different product value stream. [00:19:29] So don't dictate too much to say, "You're the product value stream lead. [00:19:33] Figure out what's going to work within your product value stream." [00:19:37] Now, a couple things that I think are very important. [00:19:41] It's more important to be intentional than it is to be perfect. [00:19:45] So I can guarantee you that in organizations, especially of y'all's size, [00:19:50] the first thing you're going to walk out is like, "Okay, well, how would I [00:19:52] structure? Which parts would go where? Where does this framework go? [00:19:56] How does this work?" Be intentional, but don't [00:19:59] be perfect about it, because it's basically impossible, and you can slice and dice [00:20:03] things in a number of ways, [00:20:05] usually with some decent success. [00:20:07] So intentionality versus perfection. [00:20:10] So interesting enough, y'all know the game Simon Says, [00:20:14] but our CFO is also named Simon. So I was going to say that Simon [00:20:18] says, but actually the more important, [00:20:22] don't tell Simon I said this, but the more important person in our organization [00:20:25] around this is actually Carmen. For those of you that know Carmen. [00:20:28] Carmen says that you need to treat your delivery [00:20:31] pipeline as a product. So one of our product value [00:20:36] streams is in fact our delivery pipeline, and that's super important, super [00:20:40] important to do. The other thing, and this gets into the whole [00:20:44] notion of [00:20:46] intentional versus perfect. [00:20:49] If you look at this picture long enough, it does kind of freak you out. [00:20:52] But what you need to do is the best way to be [00:20:55] intentional is look at your entire organization through the [00:20:59] lens of how your customer sees you, not how [00:21:03] you're seeing them. [00:21:04] That's the most important thing. If you take nothing else away besides [00:21:08] Oh my, take away the fact that think about your structure from [00:21:12] how your customer would see you, internal or external. [00:21:16] There's always the hot potato of what do I do with my internal [00:21:22] or shared services frameworks components? Super hard to deal with. [00:21:26] Treat them as products too. That could be also a whole another [00:21:30] talk about how to do that. But fundamentally, what we do is we actually have [00:21:34] our internal shared services as a product value stream that then [00:21:38] for some measurement and things gets lumped in with one of the other product value [00:21:42] streams. [00:21:45] Dependencies will exist. Relish them rather than shirk [00:21:49] them. Please, it's impossible to think of any [00:21:53] organization of any size that you can do things with no dependencies between [00:21:56] things. Yes, you should try and reduce them. [00:21:58] Of course, you should try and do that, but relish them and figure out how to work [00:22:01] within them rather than shirking them. [00:22:03] Okay, so that's the what happened. Now, what happened because of what happened? [00:22:08] So there's a famous quote, I have no idea who said it, [00:22:12] but I think it's famous. "People don't resist change, they resist [00:22:16] loss." If there's the one thing that I regret having not done as part of this, I [00:22:19] learned about this later, this concept of loss maps. [00:22:22] Has anyone ever heard of these loss maps? [00:22:25] When you're going to do a big change like this, you go in. [00:22:27] I feel better that y'all didn't know about them either. [00:22:29] You go in and you sit down, and you go through each constituency, and you [00:22:33] write down what you perceive, and it's best to ask [00:22:37] them, what they think they're going to lose. [00:22:40] Because they're not resisting the change, they're resisting loss. [00:22:43] So what was our loss map? [00:22:45] So for engineers, because again, think about combining two teams [00:22:49] into one. There was a concern of losing culture, a lost [00:22:53] culture. Where would my engineering culture go? What would happen? [00:22:57] I wouldn't be managed by an engineer anymore. [00:23:00] What would that even look like? [00:23:02] And this one I find somewhat interesting. [00:23:07] They were quite worried that they would no longer be insulated, and we were [00:23:11] saying, "We don't really want you to be insulated." [00:23:17] So that was quite interesting. On the product side, what was interesting is that [00:23:21] they had this fear of being swallowed up because of course, there's far more [00:23:24] engineers than there are product people, and they thought they would just kind of [00:23:27] get lost in the shuffle. And they were worried about all of a sudden being [00:23:31] responsible for all kinds of technical details, and they just felt [00:23:35] that they didn't have a sense of... Wait, there's one more. Don't click it. [00:23:42] They [00:23:44] were worried that there was not going to be any clarity around the role of product [00:23:48] and product managers. Which gets to the last point, which is [00:23:52] fundamentally, there was career path confusion. [00:23:56] To be a PVS lead, what does it mean to have an engineering track? [00:24:00] So we spent a tremendous amount of time going through [00:24:03] and essentially reworking, redoing our career paths, our career ladders, [00:24:08] and this is not a joke, this really is what it is, to make sure that [00:24:12] every single part of the organization around this felt that they had a [00:24:16] path. And that their discipline [00:24:20] was recognized. [00:24:22] So I highly encourage paying attention to that as part of [00:24:26] this. So Gene wanted to make sure that I spoke about one topic in [00:24:30] particular, which is who leads this. [00:24:33] I came from the product side, and absolutely it [00:24:37] makes a difference if the person that leads this combined [00:24:41] product development group comes from a product side or an engineering [00:24:45] side. [00:24:47] First off, I don't know what it would be like if it was the engineering side, [00:24:50] because I came from the product side. [00:24:51] But I have a feeling it can work either way, but there will be [00:24:55] differences. And so I just put here that the resulting optics and tone will [00:24:59] be different. [00:25:00] As a product person, [00:25:02] I more naturally focus on customer [00:25:06] first, and not as much on some of the technical details. [00:25:10] But what you have to do, what I've been learning to do, and I would argue I'm not [00:25:13] that great at it yet, is to overcompensate by paying more [00:25:17] attention. I find myself Slacking our QA people quite frequently, because [00:25:21] I want them to know that I really care about their act of [00:25:25] the work that they're doing. So [00:25:27] overcompensate then on the [00:25:31] aspects that really you would think of a more traditional engineering background. [00:25:35] As I said before, ensure that you've got career tracks. [00:25:39] And the last thing is whoever leads [00:25:42] needs to be able to communicate really effectively with the executives. [00:25:47] You can ask McNealan if I do that yet or not, but that's [00:25:50] a really important part of the job is being able to [00:25:55] take all of the information that you've got coming from the technical side and the [00:25:58] non-technical side and summarize it for the executives. [00:26:01] So [00:26:02] does the story end here? [00:26:06] I wish the story ended here. And I did have to put in one "Oh [00:26:10] my," because I couldn't go through the whole thing. [00:26:12] But oh my, it does not in fact end [00:26:16] here. [00:26:18] Again, this could be a whole other talk, so I'm going to race through this pretty [00:26:20] quickly. But just to give you an example in terms of other parts of the [00:26:24] organization and how they felt, finance said, "You want me to give you budget and [00:26:28] revenue numbers based on what?" [00:26:30] Sales, "Why are you talking to me about these technical debt thingies?" [00:26:36] The execs, "Am I going to get consistent reporting and visibility across all my [00:26:40] products?" Just to give you a sense, and I actually did spend time when preparing [00:26:43] this talk, and I went and interviewed people and asked them questions. [00:26:46] So all of the stuff that I'm going through is coming from the real people that were [00:26:50] involved. This one I find most fascinating, the world of finance. [00:26:54] So do you like this? I'm going to explain to you the world of finance from someone [00:26:57] who has no clue about the world of finance. [00:27:00] But best I could understand from Paul's summary, his world is [00:27:03] dictated by investors and laws. [00:27:06] He wrote a beautifully written paragraph about this. [00:27:10] But fundamentally, he needs to have consistent comparison because [00:27:14] investors want to be able to compare, not just within your organization, but across [00:27:18] organizations. [00:27:19] Tricky, because product value streams are inherently unique for each [00:27:23] organization. [00:27:25] So that's issue number one. [00:27:28] Paul's world is driven by traditional reporting [00:27:32] and systems. Obviously, accounting and financial management has been around a [00:27:36] lot longer than software development, but product value streams require reporting [00:27:39] in a completely different way. [00:27:42] And he reiterated to me about 15,000 times, laws are laws. [00:27:46] Laws are laws, laws are laws, and they are not flexible. [00:27:50] They are in fact laws. [00:27:53] But on the product value stream side, it's all about [00:27:56] flexibility. We wanted to be able to move people around between product value [00:27:59] streams as necessary, et cetera. So you can see there's quite a [00:28:03] dichotomy between these. And what is the end result? [00:28:06] I asked him specifically. He has to do proxy [00:28:10] reporting now that takes double the time and double the work at the moment, because [00:28:14] he has to keep reporting the way we need to be reporting to our investors and for [00:28:17] the laws. And then he has to create separate reporting for us to be able to report [00:28:21] across all the product value streams. [00:28:25] So [00:28:26] the last piece of this, do I have enough time for the last piece? [00:28:28] Conversation changers. This is super important. [00:28:30] I'm from Texas, so I can talk really quickly. Conversation changers. [00:28:33] What you want to do is you want to be able to talk differently. [00:28:36] And what you do, we changed the way we do all of our release planning, and we speak [00:28:40] only in terms of flow items [00:28:42] and flow metrics. So this is an example of how we [00:28:46] changed how we present each quarter to our executives. [00:28:50] Notice it says benefits for customers and benefits for Tasktop on each one, and [00:28:54] does in fact include features, debt, defects, and risks. [00:28:56] You always need to be talking about all four of them, always. [00:29:00] This is an example also from the same release planning that we talk [00:29:04] at the executive level about flow distribution, super important. [00:29:09] And then getting to the executive perspective on being able to report [00:29:14] and have consistent visibility. This is the dashboard that we [00:29:17] use that consistently allows us to talk about the metrics that we use to [00:29:21] measure across the board. Flow velocity, flow distribution, flow load, flow time, [00:29:25] and flow efficiency. [00:29:27] Pitfalls. [00:29:28] Change management is always the hardest part. [00:29:30] I guarantee that's not going to be a surprise. [00:29:32] Tricky balance if something is imposed upon versus driven [00:29:36] by. [00:29:37] We recognize that the entire organization won't operate this way instantly. [00:29:41] As noted, finance, we have a long ways to go. [00:29:44] And last but not least, PVS is a terrible acronym. People hate it. [00:29:49] It's awful. PVSL, yeah it's terrible. It's hard to make it plural, et cetera. [00:29:54] What were our victories? Absolutely overall, we have much more of a [00:29:58] customer focus, and that at the core is what product thinking is all about. [00:30:01] Much less of an us versus them, more of a we. [00:30:05] Investment decisions are easier to implement and there is consistency of [00:30:09] reporting. I have one second left, and this is where I [00:30:13] was supposed to talk about what's next and questions, things we haven't succeeded [00:30:16] in. [00:30:18] Lots of things. Our journey, by the way, is about a year in, so we have a long ways [00:30:22] to go. So I think I have to go. But I appreciate your [00:30:26] time, and I'm happy to stay after and answer any questions. [00:30:29] So thanks y'all.