Webinar Recap: Continuous Product Learning – The Shift From Project to Product

Presentation Recording

Presentation Transcript

Myriam
Hello to all on this Thursday and welcome to our webinar, Continuous Product Learning: The Shift from Project to Product. My name is Myriam Sanie and I’m with the marketing team here at cPrime and with me today is Anne Steiner, VP of DevJam Practice at cPrime and Coach Extraordinaire. Today she will present us with a kind of a different way of thinking about product development.

Anne
Good morning. Good afternoon everyone. Thanks for joining our Webinar. Hope you guys are stoked as I am to talk about continuous product learning and really our individual companies shift from thinking in projects. to more so thinking in terms of product. This is what we really think about and it’s how can we put product in the driver’s seat and really have that be the thing that helps us have a greater impact for our customers. Just a little bit about me. I started out as a developer and later kind of moved on into being a technical product owner, a junior product manager kind of role, and then later kind of climbed the ranks of product management.

From there I landed in coaching and one of the things that I really enjoy about coaching is the opportunity to bring both delivery or development together with the product people, that all too often had been separate and as we talk through some of the material today, you’re going to see how a lot of the shift is really about bringing those perspectives together so that we can have this common viewpoint. And that’s really a lot about what’s going to make us stronger as development teams. We’ll talk a little bit about kind of what was that project mindset, what was that product mindset and how are we shifting. I want to talk about product discovery. When we talk about product discovery, and when I use that word, what I’m really saying is this is kind of the steps that we need to go through to answer the questions:

What are we building? Why are we building? Who are we building it for, and in what order are we building it? When we think about product delivery, that’s really going to be about answering the questions, how are we going to build it and how much can we build, and then also you know, that trivial part actually building it, and then in the end we’re going to talk about bringing discovery and delivery together, blending those two things and using that cycle to get to continuous product learning. Lastly, we’ll talk about kind of what’s in it for everybody when we get to that point. So, let’s talk about project versus product for a minute. So, if we kind of go back to the traditional world or the waterfall world or maybe we’ll call this the project world. We worked a lot like this over what was typically a fairly long period of time we would seek to build something, but we did it in those old traditional stage gates of requirements design build test and you know, we were looking to reach some goal often that would be to get some value from the market or to have some impact to our customers, or we’ll just say here is to get some revenue.

So we’d work over this long period of time and we typically would be judged by finishing on time, on scope and on budget. And we’ve talked about a lot of the things that went wrong in this traditional triangle of terror. But for the sake of our conversation today, let’s just assume it all went right, let’s assume that we did deliver this thing on time, on scope, on budget. But because we were working over what was a pretty long period of time, it might have been six months, it might have been a year, this funny thing happened over that goal that was right here had suddenly shifted on us. So even when we delivered on time, on scope, on budget, we still delivered the wrong thing because the market had moved on and we weren’t able to adjust and shift with it.

So that kind of sucked. So, Voila! As an industry we said hey, there’s better ways to do this. And that really brought us to the agile movement and the idea of let’s start building this thing in iterations. But when I looked back to the early days of my experiences with agile and I still see this many, many, many places I go today, there was still this separation between, we’ll call it product and engineering or in some places we call this the business and we call this IT. And so, what happened is that requirements piece was still happening separate and a big bang. There might still be some of this design piece happening upfront. And then we started to deliver in those nice iterations or sprints, so we’re doing design, build, test design, build test, design, build, test. But we were still marching towards something that had been designed up front.

So, what happened was we were iteratively delivering, but we were delivering in that black box. We weren’t blending discovery with delivery. So again, in this scenario, the market inevitably shifts over time. And again, in this scenario we potentially missed that market. All right? So that’s kind of another drag. So how do we make that better? Let’s start to bring all of this together and instead of having that big bang requirements design, then iterate, iterate, iterate. Let’s see if we can, let’s attack this and try to shorten it up so we can start to blend this in. So, we’ll talk about something that would call early discovery in and picture that is a lightweight one to three days a type of thing. We’re, we’re going to bring the entire product team together and we’re going to start with a product idea. And often that idea, it could be massively huge, are somewhat nebulous.

It’s not understood. It’s not documented, it’s not analyzed because we don’t have all the answers and we’re going to kind of walk through a set of practices that are going to allow us to, again, as a full product team to narrow into focus and we’ll accomplish that narrowing and focusing by making some product choices in the end, we’re going to come out of that with an ordered list of things that we can do that could deliver value to our customer, to our market. So, you might call that a backlog, you might call that a roadmap. I don’t care what you call it, but that’s kind of our goal coming out of early discovery. Once we get through that and we kind of have that path and that journey we look to go on. Now again, we can begin to iterate, but this time we’re going to blend discovery with it, with delivery, and we’ll do that in that sprint cadence.

So, as we start to go, maybe we have sprint one, sprint 2, sprint 3, by iteratively discovery and delivering and learning. We’re going to start to realize is we build, hey, you know what, maybe we should shift so we’re going to start to move, you know what we built it that way, but that architectural decision made things overly complex, we put this in front of customers and they said, no, that’s not really what we want. We did some market research, our competitor released something, so on and so forth. We keep gradually moving and adjusting iteration by iteration and although, and we think back to how that market over time again is going to ultimately shift on us. When I draw here on the screen, it’s very abrupt and it seems like something that happens all at once, but in real life it’s very gradual and it isn’t something that happens all at once. It isn’t something that happens necessarily in a straight line. So, in this picture, our ability to really learn and product by building, that’s going to allow us to shift and pivot with this. And that’s really going to be what unlocks for us product agility. You can talk about agile and process all day long, but at the end of the day, to me what agility really is a product agility really is. It’s the area under this curve. It’s how much can you really move and shift over time.

One of the big issues when we talk about challenges to reaching product agility, is that we often are called to focus on too many number one priorities, as well as large releases with preset time scope and budget commitments and legacy and complex architecture. And these are real life constraints. I think everyone’s just dealing with our corporate climate and even just life in general right now is everything’s pulling us away from focusing, you know, all the way down to Facebook notifications on your cell phone and everyone’s being asked to do more with less. You know, when it comes to complex architecture, that’s a serious constraint and it’s something that isn’t going to change overnight and it’s something that we must work through and work around. It’s also so pivotal to agility and one thing that bums me out is a lot of people talking about agility in the market, really, I don’t think of the technical background to understand and respect how difficult constraints like that can be and how much we must invest to iteratively help ourselves to get out of that pickle. If you’re working in a large company, a company that’s had software infrastructure for a long time, you likely have this situation and it wouldn’t be acceptable to your business, your customers, your leaders to just say, hey, we need to shut this down or we write this thing. So that’s one of the things we do here at cPrime is really help our clients to find ways to iteratively address that problem.

All right, so as we’re talking about discovery and delivery, what are the things I want to be careful to say and make sure that we have top of mind is that discovery and delivery are two different activities. There are two different cadences, but they’re done by the same product team. We don’t want to have or get into the mindset of having a discovery team and a delivery team and having that be separate or right back into having that handoff between product and engineering or business and IT. So, think about one team that’s formed together that’s bonded around product, but there’s different folks on that team. They’re going to have different skills. You know, you might have some folks that are sitting on the left that are going to be a little more product minded. They’re closer to the customer. They’re out in the market. They are talking to your people, that might look like your product owners, maybe your user experience engineers, customer stakeholders, those types of things.

You’re going to have some folks that are super delivery minded. They’re in the weeds, technical folks that are building the thing, maybe developers, maybe QA engineers, maybe your DevOps, etc. And then you’re going to have some folks that are in the middle and they’re doing both and these people are worth their weight in gold. A lot of times it looks like an architect, the user experience engineer that still writes code. I’m a technical lead that’s helping both in discovery, writing stories, authoring journeys, and in delivery architecting the product, helping mentor younger engineers, stuff like that. So, as we talk about discovery and delivery, please think of this as two different activities or two different cadences within a single product team or a product program. So, we’re talking about early practice discovery and let’s just talk a little bit about what the end is and what we’re going to get from that.

So like I told you guys before, you know, I started out as a developer and then one day somebody came around with a magic wand and they said, hey man, you’re the product owner now, and I know this has happened to a lot of people so, one day they were just suddenly the product owner and when you’re that team level Product Owner, one of the big pieces of your job is you’re given some sort of product idea. Oftentimes this feels like just like a bullet point on the roadmap or maybe some random thing that the boss says, Hey, we want to redesign whatever. And then you somehow are supposed to magically turn that product idea that’s like super big and misunderstood and like maybe you don’t even know what it is in the stories that can be fed into a sprint.

You know, right-sized stories typically three to five day efforts. And this product idea might look like six to 12 months. So, when I first started doing this, I really struggled with how do you get from here to here, how do you get from the ideas to the stories? And because I came from development and because I started out being the product owner for the team that has a developer on, I knew the code base well. So, what I did was I just, as best I could, started with the tech and I worked my way up. But because of that, my stories really, really sucked because what they look like were more technical tasks. We’re going to have to add this table to the database. We’re going to have to create this API and that API.

We’re going to have these screens and these front end components. And at the end, although we built a bunch of stuff, it didn’t necessarily become that idea. It didn’t necessarily have that impact that we’re seeking in the market. And I always tell people one day my boss randomly called me into her office and said, hey, and you’re not going to work on that team anymore. You’re going to work on this other team, and I was like, Whoa, that’s a bad idea because I don’t know their tech, so I don’t know how I’m going to write their stories. And she kind of smiled slyly at me and said, don’t worry, you’ll figure it out. So, it goes back to having this question again because now I couldn’t do what I had done before. So, this forced me to say, all right, I need to start here, and I need to work from the idea down, forced me to understand the customer more to get into the market, to really think about what impact are we trying to have here.

When you think about practices for doing that, that’s a lot of what we’ve talked about in terms of early discovery. So how can we get from that idea to those stories and be able to make choices about those different stories. I’m going to show you an example here. And we used in this example, kind of this top stack of practices. We started with framing. We went to persona story mapping journeys and then ultimately wrote some stories. That’s one way to do it, starting with something large, getting into the stories, but it’s not the only way. There’s many ways you can do it. There’s many different practices. We’ve put some of them on the slide here and there’s many that aren’t on this slide here, but as we think of early product discovery, I want you to really think of it not in terms of a set of practices or tools, but in terms of this opportunity to answer three questions.

What are we building? Why are we building it? Who are we building it for? And answer those questions as a full product team so that everyone has a common understanding of those things. And then also think of early discovery, that opportunity to narrow and to make choices so that we can focus. So, we’re starting with this idea that’s this huge thing and we’re going to take some sort of frame out of that idea and say, okay, we’re going to focus on this now and we’re going to learn about it. And that’s what’s going to end up being those product choices. It doesn’t mean that’s all we’re ever going to do because we might come along later and take this frame or something like that, or by the act of building that first thing, we’ll realize actually the idea shifted over here and we need to take this frame, but as we talked about, we have too many number one priorities, we have too many big projects on big time frames. This narrowing and focusing is valuable for helping us to get out of that pickle. All right, so what you see here on the screen is an example of the output of one of these early discovery sessions. And this is some work that we did with the Bridge for Youth, which is an organization in the Minneapolis Metro area that helps kids, mostly teens, that find themselves on the street and in need of help. And this is a story map for second phase of their mobile app that they have, where kids can kind of reference the location of resources, availability of resources, those types of services. So what you’ll see here is, you know, they went through a framing session, you don’t see that in this artifact, but where the gap, that common understanding of what they’re trying to do, who they were doing it for, why they were doing it, they were very clear in that.

But they also brought stakeholders into this conversation that really added to that. Then what this map is, is really showing the product story of the experience that, you know, one of these kids would have other, using that mobile app. You’ll see here there’s a person in play. That person or persona has a goal, and these are the steps and activities that they’re going to complete, you look at these kind of high level activities that they would complete to accomplish that goal. And then the yellows are tasks within those activities. So, as you walk through this, the experience that the person is having as laying out from left to right, and then variations of that experience are up and down with the most common variation on top and the least common variation on the bottom. That story map, that visualization is giving them a big picture, giving everyone a big picture idea of what is this thing we’re building?

What is the experience that we wish to provide? And now you can see on here there’s some lines drawn through it that almost look like trails that are going through this map and that’s what we called journeys and journeys are a big tool for focusing and getting us to that smaller increment of value. If you look at this piece of the map, what this is was one of the features that they wanted to add was the ability to receive notifications on your phone. When for example we want to say, a bed one night opened at one of the shelters and there were two ways that they wanted to accomplish this. They wanted to accomplish this by a text notification and they wanted to accomplish this by an email notification. So, if you thought of this big activity, you might call it notification, but as we laid out those steps here in this chunk of the story map, it’s covering both email and text.

As you look at the red line or that path through a portion of that experience. This red line is just the text experience and if you guys can see the black line, that’s actually the email experience. They’ve written request text notification by region, request filtered notification by email. So those are those two journeys or you could think of them as epics if you’re working in the Scrum world. But the difference here, if we had said we want to build this whole thing notification, we would have built all these stories. But they started by saying we want to build text. And in that case, they only built this story, this story, this story, this story and this story. And at that point they released it to the market and you know, what happened when they released that to the market and they started testing out with these kids, they realized that, that, that was what the kids wanted, they actually didn’t want email because only old people like me that are in their forties actually still use email anymore.

So, email wasn’t an important thing, and, in the end, what was not built was this, this, this, and this. So, think of the money that was saved, the learning that was acquired by not building those things that their users didn’t need. The other cool thing was they were able to get this valuable feature, notification via text in the hands of the people that they were trying to help sooner because they chose to do that first versus building those other things. So anyway, in the end, you see here that we have a common understanding of what we’re building, why we’re building it, who we’re building it for. We understand that at a high level what our stories are off over here, they even have some low fidelity, but rich design artifacts, we know what the experience is going to look like and that early discovery has really helped us to gain that common understanding as a product team. This session took about a day and a half and the end. So, this isn’t something that takes weeks or months like we used to toil writing our requirements and design documents. All right, so once you’ve completed early discovery, now we’re ready to Kind of, let’s talk a little bit about delivery and then we’re going to talk about kind of bringing that together. So, as we look at agility, again, that discovery or figuring out what to build and in what order that’s going to feed delivery and delivery is actually building the thing. And we can kind of oversimplify a bit and say, we’ll call that three steps. I’m coding, building and testing. All right, so in the end, now by actually building some whole thing or some whole artifact that has value, then we’re able to release that thing. We’re able to learn in that in turn is going to help us to cycle back and to discover and build and do more, etc.

Alright. I want to zoom in a little bit on this piece right here and talk about some of the different learning cycles that are in that. This is kind of core fundamental stuff that I fear sometimes we lose a little bit in the noise and if you’re a product person, this is a lot of what your developers are trying to tell you that we need to give more time to, but sometimes they don’t always tell us in a way that’s easiest for us to understand. Alright, so I’m going to throw up the extreme programming picture here and for some this may be kind of retro. Extreme programming was one of the first agile methodologies that was introduced in the late nineties, but they do a really good job in here of talking about different learning cycles and where you can learn within the code and then ultimately blending discovery with delivery.

So that first cycle I want you to kind of zoom in on is the core cycle of test driven development. So, the idea of test driven development, test first development is, hey, before we even go to write a hunk a code or to do a thing, we’re actually going to think about how we would validate if that thing worked or not. So, it’s as simple as I’m going to write a unit test for this piece of code that I have not yet written and how I’m going to validate it. So, I write the test, I run the test, and of course that test will fail because the code that it is validated does not exist. So then at that time I’m going to go write that code. The cool thing here though is I’m just going to write the very minimum amount of code required to make that test pass.

As I go in, I may have to do a little refactoring. I’m going to write some code, I’m going to run the test. It might still fail a couple of times. I might need to tweak some things in the existing code base to simplify them so that data can be so on and so forth, but in the end will ultimately get to a place by refactoring in, we’ll run that test in and that test will pass, and it will be green. In the best of these scenarios, we’re actually doing this in pairs where we have two people working together. Maybe one person is writing the test, someone else is reading the corresponding code, maybe one person is reading the code while the other is helping to navigate those types of things, but we’re learning together through this process of writing tests, writing just enough code to make them pass, so on and so forth.

We’ll keep moving from test to test, from acceptance test to acceptance tests as we go, I’m completing our stories and our capabilities now. Once we built something, we had the opportunity to ask ourselves, okay, does it integrate with the rest of our code base? And that idea of continuous integration and then can we deliver it so that we’ll be able to validate that. Um, so back in the day before CI/CD and DevOps became a thing, XP called that small releases. They said, let’s bring all the code together. Let’s integrate it, let’s ensure that it builds and compiles. And then once we can answer that question, let’s go ahead and let’s release it. Of course, as part of the CI, typically we will be running tests, automated tests as well. So not only are we answering the question, does it build, but we’re also answering the question, does it work? So, if I can be bold enough to make a little edit, I’m going to add and to make this third cycle and here I’m going to add continuous learning. So, by integrating our code, by bringing that together, by ultimately releasing that code, then we’re able to learn and that gives us a second learning cycle within this picture. So, if we want to pull all of that together, then with discovery, by releasing, by learning from our customers, then that’s going to actually redirect what we decide to do next and how we validate future things. And that is over the XP picture how we blend discovery with delivery. Just a couple other comments on the technical agility side. You know, we always want to make sure that we’re monitoring our build health. And this gentleman in this picture, he’s looking at one of those monitors and you can see in front of them, they got a couple of places where their build break and hopefully as it has his attention, it has the whole team’s attention because if our code can’t be compiled and can’t build right now, then it can’t be released. Then if we can’t release it, we aren’t able to learn from it. The other thing is we think about DevOps and I’m kind of bringing operations, monitoring and support into that picture, we want to blend that into it because that’s going to help us to learn more. So, kind of bringing all that together. If we lay operations here on top of that delivery and all this delivery, that’s going to allow us to truly unlock this box, which is that ability to continuously measure and learn. So that’s what blended discovery and delivery is going to look like.

So, in the end when you’re really able to accomplish kind of bringing these things all together, this is what success is going to look like. And remember we want to shift from project to product and we want to kind of put product at the forefront, making that more important than simply making progress or certainly more important than process. So how do we define success in this world? Frequent delivery of whole value. Are you putting out something that can be validated, that would have some value to your customer, your user, so that they can say Yay or nay that they can try it. And we learned from watching that. Are we building the right thing in the right way? So, building the right thing. Yeah, we’re impacting the market, building it in the right way: Are we doing it in a way that our technology and our products going to be sustainable on healthy going on?

It’s hard enough to deal with aging codebases when you’ve done the right things, like you’ve written automated tests, you have a CI/CD pipeline, you have good monitoring. But when we choose not to invest in those things, it’s just like a snowball debt that you’re going to have to pay down later. So again, product people, if you’re on the line today and your developers are asking for those things, really hear them and listen because if we turn a blind eye to that, especially in the beginning, later, you will suffer by not having the technical agility to be able to maneuver in and adapt we want it as a whole product team to be collaborative with the learning and improving. We’re in this together. We want to have the same context. We want to balance evidence. And intuition is we’d make decisions, we know things about our customers, we know about our market, we know things about our product, but we also want to measure and validate, use in the impact that we’re having.

And then as we make strategic decisions, think about both of those things together. Obviously, we want to produce what people need. And then last but certainly not least, we want to do this all in a way that’s sustainable and we’re not burning out people or we’re not having peaks where we’re asking people to work, you know, 80 hours a week, or something like that, so to me, this is what success is and product development. Um, when you get to that point, what are we going to get from it? Or a. So why, right? When is all this stuff matters. And it matters because of these reasons. You’re going to get a team or a program of people that have a shared product vision. They all have the same information. They’re going to have the same love for the product, the customers, but market respect, empathy, all those things, they’re also going to care a lot more because they get to be a part of those decisions.

In those conversations, when we just handed things off and built products like it was a relay race, passing the baton, the message is lost at every stage from product agility, we’re going to get maneuverability. We talked about that in the pictures. We’re going to be able to shift to change, to adjust as we learned subsequently, we’re going to be able to be more responsive to our market. And that’s so important right now because everyone’s being asked to do more with less fast and the expectations of companies that have traditionally not been software companies is for them to act like software companies and to be able to react, like a Silicon Valley startup that does not have a code base that’s 10 years old. And then in the end, what does all this mean? And this is what we tell finance of course, is we’re going to get a better return on an investment and we’re not going to get a better return on investment because we’re more efficient or because we’re turning the crank faster, we’re going to get a better ROI because we’re building less of the wrong thing and we’re building more of the right thing.

And we’re figuring that out sooner. There’s less wasted money in development. There’s less wasted money in support of features that are unused or unwanted.

Thank you, Anne, for providing really some great insights on how to combine product learning and delivery to really optimize the value of what we bring to our stakeholders and in the marketplace. And I’d like to really thank everybody here for their participation. And thank you for taking the time to join us today on this Thursday and we hope you found this session of value and as a reminder, we will be sending out the recording as well as well as the slides, so be on the lookout for those within the next 48 hours and we really hope to see you again on one of our upcoming webinars. We appreciate your time and enjoy the rest of your day.