00:00:05

Great, we're super excited to be here. Uh, my name is Nicole Bryan. I run product at Tasktop and I'm looking really forward to, um, having this, uh, time with y'all. And I can tell none of y'all must be car enthusiasts 'cause you skipped the Jaguar Land Rover to listen to, to listen to us. So I'll hand it over to you, Kevin.

00:00:24

Thank you, Nicole. So my name's Kevin Fisher. Uh, I'm an a VP within Nationwide IT group, and I'm happy to be here with Nicole. So the way we're gonna work on this presentation is I'm gonna talk for about 12 minutes, and then Nicole has really the, the meat of the, of the message. And it's about, uh, just making the switch from project to product. Uh, you heard about that this morning from CSG. You heard about it from Mark Schwartz. If you went to his talk, you're gonna hear about it later today from Mick Kirsten. And he has a new book about this. Um, at Nationwide, you know, many of you know us by our public facing advertisement campaign for our personalized insurance products, but that's actually not, uh, that's only a portion of our business, I should say. Um, we're actually a very large, uh, commercial insurer, plus very large financial services company around retirement plans, annuities, life insurance and that sort of thing.

00:01:11

Um, you know, we like to protect what you matter most to you, which is your home, auto life boat, your, your kids, your retirement, right? Uh, and we're based out of Columbus, Ohio, and we have about 10,000 people in it. So it's a pretty big ship to turn when we talk about making the change from project to product. Um, so these are like the five impediments that everybody is challenged with, and you'll hear it as a common theme today, right? Um, it is generally disconnected from the business. We heard it from the night presentation all the way through this morning about how getting it and the business to work much more closely together on common goals and objectives. Um, you know, leadership tracking is generally, uh, by activity based tracking. I know the switch at Nationwide to get our leaders talking about outcomes. What business outcome do you want to achieve?

00:01:57

And having it at the table. Uh, when you do that, Mark Schwartz has a whole book about that called Seat at the Table, which I recommend. I also recommend his other book, art of Business Value. Um, but that's a, that's a big thing for at least a large company like us. Um, project funding is fundamentally broken, right? So, uh, like I said, we're a large 35,000 employee company. We still fund projects on an annual funding cycle that usually takes 18 months, right? Um, and, um, business idea is, is usually viewed us as, you know, uh, working on our own agendas or our own items, and in a lot of ways a black box, right? Um, and that black box is generally the focus area is, well, we need to get the developers more productivity, right? We need to make the developers more productive. So when we think about that, um, there's all these elements to changing that conversation and that dialogue from budgeting timeframe, uh, how to measure success, how you allocate work to teams, how you prioritize work, how you make that visible, uh, and how you manage risks.

00:02:57

So I'm gonna go through these really quickly 'cause um, you all have seen these in many other things, right? We all want to switch from linear based projects to more secular products. Um, you know, when I think of this particular, uh, diagram here, I like to tell a story that our CIOs routinely go outside the company to visit other companies, uh, and learn. And a couple years ago, they did a trip out west. They, they, they visited what we call the unicorns, right? Google, Amazon, um, Microsoft, all the, uh, startups that are doing quite well. When they left the building, they had a sense of we need to go how, figure out how these companies do a better job of long-term planning. 'cause we don't think we do a good job of long-term planning. What they learned is they actually don't do long-term planning. And they came back and said, they coined the phrase sense and respond.

00:03:45

We need to do a better job of being able to sense what's happening in the marketplace and responding to those trends, right? We don't do a good job today. 'cause I mentioned before, we have an 18 month, uh, funding cycle, right? It's hard to sense and respond when everything takes 18 months to get new funding, which leads to how you actually, uh, manage your, your work, right? So we all know, uh, project mentality is linear. It requires an absolute perfect sense of forecasting ability that no one possesses. Um, and you're bound to be disappointed, uh, in multiple, uh, multiple avenues. However, if we dock more of a product mentality and we, we learn from things like the Lean Startup by Eric Rice, right? Where we're, we're having hypothesis, we have a hypothesis, we fund a hypothesis, we do a test, we measure that test, and then we sense and respond.

00:04:31

There we go. We know good things will happen. Um, we know that measuring success the old fashioned way, either hours burn, dollars burn, right? That sort of thing, activity measures, uh, is not successful. We've learned that through mon through, uh, what now 17 years of Scrum and xp. We know that, um, when we start with the conversation with the business, with business outcomes, and we can align technology solutions to those business outcomes, good things happen. Um, and we know that when we bring people to the work, uh, it's not as efficient if we bring work to the people, right? So we've strived over the last, uh, three years to really have a, a stable alignment of IT resources, right? So in 2016 at Nationwide, we made the decision that, uh, all of our work will be done with Scrum and xp, and we align around 200 agile teams, plus or minus a couple.

00:05:22

But essentially you, we have a nice stable plant, uh, a stable factory to do work. Um, we know right through multiple years of working with Agile, all the agile methods that, um, what your pick your favorite flavor of Agile, it's better than waterfall. We all know that. Um, and we know that project visibility through big visible charts like you saw the, the lean program structure in CSG this morning, that's fantastic, right? They have all work depicted visually they can bring the business partners in and have a trade off conversation. Visually, uh, that's all much better for everybody involved. Uh, and then we do this, well, as you heard from Nike, we can manage risk in a very, uh, iterative way. You heard it from CSG, right? Which was continuous compliance, not, uh, compliance theater at the end. Um, we know that that will be better.

00:06:11

So specifically for us, um, you know, this might look sound familiar to many of you, especially if you work in a big company, especially a big company like ours. It's a hundred years old. Um, we have a hundred years of bad habits to overcome. Prior to 2005, right? All work, uh, was done in projects. Um, teams were being constantly formed and stormed to meet those projects, right? Which meant for the first three months outta the year, nothing happened because I'm storming, forming. Uh, and then my first status report says, great, the team is now formed, and I haven't really spent any of the money, so I'm not gonna spend all the money by the end of the year. Um, and since I was managing success by how much money you spent, that was bad. Um, lots of time spent in project related meetings talking about, you know, things that either, uh, people could not affect or just, you know, not unproductive conversations.

00:06:59

Um, hard to manage application integrity. Dependency is not visible until the last moment when, uh, things go bad. And then very large batch sizes and very long, uh, cycle times. So what we've done, um, you know, our, our transformation has taken about 10 years. So we're 10 years in, and we're not perfect by any means. But ours was a development centric transformation, meaning we focused, uh, from the development process first, and we applied scrum and XP practices to all of our work. And that took us many years. Like I said, we, that took us up until 2016 to do that. Then we said we need to focus on DevOps, right? And continuous deployment. And those two things are great, but those are very IT centric a, you know, aspects to, to improving your whole value chain. And there's a missing component there, right? It's the business.

00:07:47

And to get truly fast, we need to have the business involved, and we want continuous flow. That means they have to be involved. Um, and so when we think about words like product value stream and all that kind of stuff, um, in our world, that's not the way our business IT relationship was formed. It was still a very contractual relationship. And so to get them to open their hearts and minds to a better way, we know there's a better way. We know we can, we can leverage lean, we can, we can look at other industries to figure out a better way. Um, but to get them to understand the value of doing like hypothesis driven planning, right? Where you do small ROI based funding, um, fund a hypothesis. Let us put it in the marketplace. Let us test and learn. Let us actually truly embrace that sense and respond mentality that you saw with other companies.

00:08:33

One of the main, uh, trigger points for us was being able to have some metrics on our flow. So to have a very rudimentary view into lead time and cycle time and where people are spending their time. So I have a question for you. How so, in a very simple value chain of idea to somebody, you know, work gets decomposed, uh, developer works on it, testing happens, and you deploy very simple. How much, what percent of time do you think we spend in that development phase where people actually hands on keyboard writing? 5%, 5%? Anybody else want to go higher or lower? 30. 30. I wish we were 30. How about two and a half?

00:09:19

So once we know that number, the conversation changes, right? Conversation changes from what are you doing to make your developers more productive to, ooh, all the stuff that surrounds them. What are we doing to make that more productive? What are we doing to eliminate waste there, right? Um, what we, if we wanna go from idea, a concept of cash, as Mark Schwartz said just a few minutes ago, you know, what are we doing to help that? If the, if the development piece is only two point a half percent of the time, boy, there's a lot of waste and opportunity and that rest of that time period. So anyway, that is, uh, so important to create flow. And part of it, like I said, is all about decomposing that work into small batches. And so the, now the second thing that having this measure allowed us to do is start having real conversations with our business partners.

00:10:06

And I'm talking business unit presidents in their cabinets on thinking about small batches. And the best we could do is 90 days, which is fine. That's a big, Hey, I'm, I'm, I'm taking people from three years to 90 days. This is a big improvement for us. Our, our, the bar, the bar was low. Um, but thinking about things in 90 days, and we have had in the last six months success getting them to rally around and start thinking about things in 90 day chunks. What, what value can we deliver to our distribution partners, our customers, our associates, what have you in 90 days? Doesn't have to be a firm hard, fast, 90 days. 90 days is not the new net, not the new word for project, right? But it's, it's breaking their mindset of that everything has to be a three year commitment. Um, and how can I do that? And then how, more importantly now, how can I measure that flow? And that's really the, the, the main piece of the value of this presentation, um, that Nicole's gonna come talk to us about how do we measure that flow and decompose the work so that we have a a real view into what's happening.

00:11:12

Cool. Thank you. So before I get started, I wanna ask a couple questions. Um, a year ago, how many of y'all would've thought about the notion of moving from project to product a year ago? Not today, a year ago? Okay. Um, three years ago. And today.

00:11:40

Okay. So it, it's an idea that is clearly taking hold, um, and, and has clearly with this many people believe that they see the value in it. There must be a reason why we need to be embarking on this journey. Now I'm gonna ask you a second question. How many of y'all feel like you have concrete steps, concrete things that you can go do today to start moving in a product direction? Okay, so I'm hoping that at the end of the time that we've got here today, that I'm gonna leave y'all with something concrete that you can go back to your organizations today and start working on. And it's called product modeling. How many of y'all, y'all have ever heard of this concept of product modeling? Okay, so cool. So if nothing else, you'll uh, you may think it's crappy, but you'll learn something new, um, to take back <laugh>.

00:12:33

So, um, I, well, I have to make this joke because Kevin and I have been chatting about the fact that, um, you know, our talk is very boots on the ground, it's concrete, it's applicable. Um, and then the first slide I'm gonna show uses the word abstractions, which is pretty much the furthest thing from concrete. But, um, uh, you know, Kevin described what they're going through in some of their experiences. Um, and what is really, when you start to think more about moving to product, you're gonna hear a lot more about value streams, value stream management. And you'll hear a lot of, of use of the words mapping and modeling, mapping and modeling, map mapping and modeling. And really what those words are, um, are various ways to recognize the importance actually of abstractions. So I'm gonna read this quote, the essence of abstractions is preserving information that is relevant in a given context and forgetting information that is irrelevant in that context.

00:13:35

So put it in your back pocket, 'cause we're gonna come back to that in a bit. Um, Kevin, um, made it incredibly clear what the goal is around flow, which is to be able to measure flow so that you can hopefully deliver more to your customers. Um, so I mean, I heard all of y'all's voices when he said two and a half percent, right? That's measuring your flow, measuring what's going through your product value stream. So the whole act of product modeling, what I'm gonna be talking to y'all about is done in order to be able to have the best possible, the most accurate measuring that you can. And by the way, I completely agree with what Kevin said, that it's impossible to make it a hundred percent accurate. So throw that away and go for the 80 20 rule of getting relatively good, um, relatively good metrics.

00:14:24

So, um, here's the tricky bit. So you know that you want to measure your flow, but here's the tricky bit. Um, value streams and, and product thinking intentionally require you, they're just begging you in every way possible. Please think from the business perspective, please think from business outcome perspective, well, here's the problem. The problem is that you end up with this core dilemma because you do have two different perspectives. The technology perspective, the IT perspective, um, is at the core fundamentally always going to be different than the business perspective. And until, and unless you own up to that, you're never gonna have success. And being able to measure, um, measure your value stream. So, um, it's kind of a tricky concept. So I'm gonna go through an example and hopefully the example will help, um, bring to light what we mean by um, having these two different perspectives and then thus requiring the act of product modeling.

00:15:28

So, um, I'm gonna use as the example one of TaskTop's products, um, tasktop integration hub. This is the business perspective, the business perspective on our product. This is the thing I sell, this is the thing I'm wanting to improve, the speed with which I can deliver value. So every product value stream, every product has a value stream. The set of activities that you do in order to deliver value through for that product. So this is the value stream for test desktop integration hub. You see things like investigation, um, implementation, story breakdown. And by the way, this is the end to end. We've heard a number of talks now also about making sure that you're not just focusing on the, the, the code, the two point a half percent, but on the full entire set of activities. So this is the tasktop integration hub, um, value stream.

00:16:22

Now here comes the dilemma. So in order to measure your value stream's delivery, you have to capture and abstract the right information from within the physical constraints that the IT organization is working within. Um, and I know that sounded kind of, I dunno, I dunno what we're lofty or kind of crazy, but it really does make sense when you start to break it down. So I'm gonna break it down, um, break it down, um, for y'all. So this one product value stream has at least seven different artifact types in it now actually, um, it has the four core flow units in it. Um, and, uh, Mick is gonna be talking more about this later today, the four core value units, but there's also, so features, defects, tech, debt and risk, but there's also many other artifacts. Why is this important? Because the artifacts are your digital footprint, and I'm gonna come back to that in a, in a bit as well.

00:17:21

But, so this one product value stream is, has seven different artifacts. And those seven different artifacts actually live in six different tools. And I actually took out some of the tools as well to simplify it. So now we're starting to, we're starting to see how the IT perspective is different from the business perspective. Seven artifact types, six tools. This part is super confusing, and Carmen is gonna, I I'm getting the evil eye from Carmen over there already across 10 different projects. And this is not the, the use of the word project, the way that we, we've been discussing it. This is the boots on the ground concrete. When you're in Jira, when you're in rally, when you're in version one, when you're in ServiceNow, you go in and you configure a container to contain your work. And it's often called a project. Um, so these six tools, um, those seven artifacts live in six different tools that cross 10 different projects and eight different teams.

00:18:17

And tasktop is nowhere near the size of nationwide, not even by many orders of magnitude, right? So now hopefully you see that there is this distinction, the business perspective, it was one product, and I want you to improve, measure and improve how you're delivering that one product. How in the world am I gonna do that when the reality is that it's seven artifact types, six tools, 10 projects across eight teams, and that's where product modeling comes in. So, um, let's go back a little bit and make sure to remember why we're doing this. Um, your goal is to be able to measure your product's value stream. And so as I mentioned earlier, the way in which you do that is via the artifacts. They are the digital footprint. Those artifacts are the things that know how long things have existed. So the way that, um, Kevin was able to measure and Nationwide was able to measure how long, why, how they got to that two point half percent is they're looking at status changes, uh, in their artifacts across all of their tools.

00:19:18

That's how you do it. Um, easier said than done. So what you have to do is you have to figure out the right way to, to determine which artifacts matter, which artifacts should I be measuring. So you need a way to map those seven different artifact types across 10 different projects spanning six different tools. And that is in fact what product modeling, um, what product modeling is. And it's a very concrete thing. Um, and so what I'm gonna do now is, um, I'm going to actually give another little example around how you can do do product modeling, modeling. Um, and just to bring it back to the original quote that I, that I said to put in your back pocket, um, the essence of abstraction is preserving information that matters in a given context and forgetting information that is irrelevant in that context. And we now fully understand that the context we care about is the business context.

00:20:13

So we need to make sure that we're abstracting the right information to meet the business needs. So, um, essentially, um, the act of product modeling is, um, you have to go into all of the tools that are involved and, um, it's really an exercise in, in carving swaths through those tools to know which artifacts actually matter. So here are four tools. Um, so what you do is you have to define the conditions under which an artifact matters. So one of the four flow units, feature defect, risk tech debt, you have to go through each one of your tools, um, and identify the conditions under which, um, that artifact the artifacts should matter. And I know that's a little bit, uh, a little bit abstract. No, no pun intended. So I'm gonna give a bit more of a concrete, um, a concrete example. So imagine that your products value stream has these four tools in it, jama, JIRA, A LM, and ServiceNow.

00:21:13

So you are using JAMA for requirements. You're flowing information to Jira for execution on the development teams. You're using microfocus a LM for testing and ServiceNow for, um, help desk and, and trouble tickets. Um, but all of these tools are utilized in servicing, delivering value for one product, one product. So in this case you may say, all right, with jama, I need to get requirements from sets a, c and F only from project 1 59. That's the project. And those requirements are the ones that matter for Jira, it's epics that are assigned to component A from either project D, E, and F. And those of y'all that are big into Jira will understand that a lot of times component is a very important piece to being able to do your product modeling. A LM Um, I only want, um, artifacts that are risks and tests that were created after January of 2017.

00:22:06

And in the case of, um, ServiceNow support tickets from application h and j, um, and if the status is passed, the acceptance, the the accepted state. So that is, that is a a, a real semial example of how you do product modeling. Um, if you, I know that doesn't sound trivial, um, but that is the work necessary so that you can actually answer these types of questions. Um, things like how long did it take for this feature to get through the value stream? How much wait time was there for defects? What is the distribution between defects, features, risks, and technical debt? Um, so if you do product modeling, you will be able to answer questions, questions like this. Um, and so I wanna make sure and, um, give y'all very concrete actions to take today. Um, and, but before I do that, I want to, um, tell two quick stories.

00:22:58

One, um, we've actually been working with Nationwide, um, on doing product modeling, um, for a little while. And, uh, I can tell you that and Kevin can, can attest that it, um, it's, it, it does take, it does take a little bit of, oh shoot, hmm, wait, let's try it again. And so for that reason, I encourage everyone to start just trying it and get, we've been using spreadsheets, we've been using spreadsheets and video calls to go back and forth and, and try and figure out how to model the products. My second story is that, um, BMW Renee is here and, um, he's gonna be talking a bit about this tomorrow. Uh, BMW has done an unbelievable job of doing product modeling. It's the most sophisticated one that, that I've seen so far. I'm hoping that some of y'all will come talk to us afterwards and say, no, no, we've been doing product modeling, we just know we are calling it that because I'd love to hear more stories about, about how you're, how you're doing this.

00:23:54

But, um, come talk to Renee because he, um, BMW has been doing some very interesting work around that. Um, so actions to take today, um, one of the key things, so you noticed, um, I had four, um, four tools up there. Jira, JIRA, jama, micro Focus, Salem and ServiceNow. So at the core, you are never going to be able to successfully do your product modeling if you aren't also connecting the tools together so that your artifacts are flowing so that you can get the accurate state changes across all of the different tools. So the first action you can take today is to get your tools talking, connect your tools. I'm not gonna talk about this today, but that involves a whole nother kind of, of abstraction around, um, artifact modeling. Um, but if anyone wants to talk about that, I would be happy to chat, um, chat about that as well.

00:24:45

Artifact modeling is a very powerful way to be able to flow information between, between tools. Um, and then the second thing is go in there. You model your artifacts, model your statuses. I should talk more. Modeling statuses is also very interesting and diff and, and provides great insight into, um, one of my favorite stories of that is that, I can't remember which company it was, but they were like, yeah, we've got all of our statuses and people are using it. And then come to find out that all of the developers, what they were doing was just going in, um, right before the end of the end of the iteration and moving everything quickly from one state to the next <laugh>, which like, okay, that's not really what we're going for. Um, and then the last thing, um, that I encourage everyone to do, do it the old fashioned way.

00:25:29

Don't get fancy. Um, don't just get, keep it super low tech. Get spreadsheets. Get yourself talking to the business about how they view the product. Tell me what is the, how would I carve out what piece of this goes for this product? And then sit down with spreadsheets, go through all the different tools that you've got in your organization and figure out how you would define conditions, um, define conditions to, um, to actually begin modeling your products. So with that, hopefully y'all have something concrete now that you can take away and say, not only do I know about project to product, but I have something I can start doing with everyone today. That's it. Thanks.