Mastering the Fuzzy Front End of Data Products

00:00:00 Welcome: why data and analytics teams struggle to deliver value

Chris Bergh: Okay, then we had one more. Why don't we start Shane? So hello My name is Chris Bergh. I'm CEO and head chef of a company here in Boston in the United States called DataKitchen, and I am very happy to welcome my guest to this webinar. Shane Gibson. Would you give an introduction to yourself Shane? Yeah, yeah, so just this is a webinar. So just let me go through housekeeping. So we will be sharing some slides and we will share the slides and the recording shortly after this webinar, so don't worry about that. And then if you have questions, feel free to put them in the chat. It's in the lower right end button. Looks like a dialog box on Google. And we'll try to answer those either partially during it. And so I think let me start with the background. So I think Shane and I share the same worldview in that data and analytic teams are struggling and they struggle for a lot of reasons and I think a lot of times they're just not delivering value which really means they're not getting out what customers want truly and I think that's for a lot of reasons. Why aren't they delivering value? Why is there a lot of ways why aren't we all as a team working together to give our customers business value or analytic value or insights? And I think it comes from a lot of reasons. I think from my perspective. It's really three one is a sense of humility that you don't really know what your customers want with data and analytic teams. we all have a lot of calculus and we talk to business people and maybe we think that calculus helps us. In some ways it hurts us and if you don't really know what they want. How do you get at it? And how do you set the stage to kind of have that dialogue with your customer?

Shane Gibson: Yep, Shane Gibson. So I'm from a little place called Kapiti in New Zealand. So at the end of the world and I'm kind of glad to be here. It's gonna be an exciting conversation between the two of us, I think.

00:01:57 Thirty years of technology waves, and the same failure at the end of them

Shane Gibson: Yeah, so let me just bring up some slides and I'll use them as prompts. Rather than go through a formal presentation. What I'm thinking we do is we'll just use them as well. So, my background is I've been in data for 30 years. I kind of think it is three generations or three decades. So my first 10 years was in and software and been DeLand so working for the large data companies and that was back in the interior pre-cloud days, right and the problems back then were hardware constraints, right? It took us too long to get this Hardware too long to get the software. After that, I kind of started my consulting company and I was lucky that we moved to more of the cloud platforms. So our constraint there was our people right was how do we get the people to understand what to build and build it and the people began the constraint and as part of that I kind of lucked onto this thing called Agile. And so it's been just about a decade working with customers applying Agile and data and patterns together and I'll use it to patterns a lot because what I think about is patterns as being reusable things a data team can try because it's had value for that use case for somebody else and it may fit your organization. It may not So the kind of three patterns I want to cover with you today is talking about all the patterns from product management and how could we apply them to data? And where do they have value? How can we take this idea of customer Journey mapping or information value streams and apply them to our data world. And then how can we take a specific pattern called the canvas? We're gonna make you a question. what problem we're trying to solve with these two right the number of times in my career over 30 years. I've done this. Talk to a stakeholders. And when I go back to them and go what was wrong, it was like that's not what I wanted and you kind of aggress yourself to but that's what you ask for. Now there's actually not a bad problem because sometimes you build it and they don't even come right. Sometimes you build these data products and they don't even have a conversation with you and they won't even respond to you. So what we want to do is that's the problem we want to fix right we want to take these patterns and apply them to the data world where we're building things that are valuable feasible viable and actually used by our business. and so for me that is the problem that we're trying to still solve in the data world after three decades and multiple technology wave changes and that's when got as we got to sort out. So, what about you? What do you see?

Chris Bergh: Because learning is not one shot. It takes multiple times to do it. And how do you set the stage to iterate and learn and get that dialogue going when you have a lot to do and that I think is really the topic and it's about data products or information products but it's really set on that background. I don't know Shane. What would you think the background of this is?

00:04:57 Product, not project — and why business and IT talk past each other

Shane Gibson: I mean Yeah, and so there's a couple of problems — anti-patterns that we have as data people. so when we treated as IT teams when we actually sit and we end up with a language problem we end up with this idea where we start using these words of the business. Right. So we make this barrier of them and us and then we talk in three-letter acronyms. We talk in data speak business people talk in the language of the business and we don't have the shared language where we can bridge that Gap. And the other problem like you see it is as we treat everything as approach we treated as a beginning in an end a one and a done not as a product. So one of the things I kind of been thinking about a lot this idea of taking value stream mapping from the product world and applying it to data and I've been through multiple iterations of this type of diagram to find one that actually tells the story the way I like to tell it but if you think about data teams, where do we spend the majority of our time in this diagram? We spend it on the right hand side. we may deliver some value. We may enhance our data products We may just build them push them and forget about them. We typically don't decommission them and the cloud data world and the modern data stack. I would start arguing. We're not even designing data products anymore. We're just writing Bunches of code to make us fast at this Loop. But if you look in the product world and on the co-founder of the data startup, we've got a SaaS platform and a product which force me to take my head out of the right hand Circle and move. It became the product manager for our product. And so I've spent Five Years Learning a whole lot of product patterns. And so if we look at the product world the leaf hand side of that Circle actually where we start as understanding the business problem. Not the data they want we've got to understand. what's gonna happen if you use this data what business problem are you trying to solve? Are you trying to increase your Revenue? Are you trying to decrease your costs? Are you trying to manage some kind of risk? Whereas what? we tend to go in and say what data do you want or how do you want the dashboard or potentially what business question you want to answer, but we don't worry about the action. And then once we understand the problem then actually these multiple ways we could solve it. we could build them a dashboard we could dump them in Excel file.

Chris Bergh: I I think it's about the word product instead of project. And so I think the idea of information product or a data product means you give it to someone and you don' You're not done with your project. your project is just starting your improving up on that product. It has a life cycle to it. you improve upon and maybe you sun set it and so I oppose that to a project right where the goal of it is for you to complete your task list. And then you're done and I've had customers who their business users. Hate IT team. They think they're utterly useless. And then IT team has worked with the business users and they've gotten Awards and why because they've followed their project process and completed all the tasks. And so that seemed to really absurd to me that one team is very focused on the steps to get there and the other team's very focused on the outcomes and there's such a disconnect and the business team thinks IT team is our idiots. And I think that's the idea of a product is let's not Follow a bunch of arbitrary steps to get to a result. Let's actually talk to the people who get the results and see if we've done our job and then if not, let's tweak it.

00:09:55 Ideate the options, then reduce the uncertainty before you build

Shane Gibson: But we could actually interface that data back into the systems of record and prompt the next best action. Right? So these are bunch of different ways that we can ideate how we use data to solve that business problem. And then we've got three or four options. We need to discover which is the most valuable way of solving that problem and this is kind of weird data people prototype, right? That's gonna where I see a prototyping phase if that's how you work. But what you're saying is I have an idea that I can solve the problem this way before I go and invest my entire data team for three months building that product and pumping out to see whether I'm right. What can we do to reduce the uncertainty and reducing risk? So on the Agile world, we took about research spikes and the product world. We talk about minimum viable prototypes and data worlds. We talk about, prototypes before we move to production and then the trick for us is data people is at last one on the left which is prioritize and that is incredibly difficult for us in our domain compared to a product domain and why is that because When I'm building a software product on building one thing. Yes, it's gonna bunch of features, but I am spending five to ten years building that one thing that is solving ideally one problem. As data teams, we cross every business domain. Typically, we may be if we're adopting something like data mesh where we started become very domains to specific and pushing back into the product side of the business and then it's different but typically We have a team and they get given different products to build. So we have to keep context switching. We have to say I'm gonna deploy it. Yeah. I may go back and enhance it and Main data. I probably won't be commission it. So now I've got that technical debt of maintaining it and

00:11:33 Why data work iterates twice over, and what makes the front end hard

Chris Bergh: I think data is hard because I spent half my career like you building software products and when Agile came along and software and these Infinity diagrams were there they were great and the other challenge with data does the data Express the problem. Can it actually Express what the customer wants I want to know who my top customers are do you have the data I want to be able to segment my customers this way is it statistically valid and those things I think are make it a little bit harder because you're kind of almost iterating on the things acting upon data. here is the structures. Here's I want to put it together. Then you're also iterating on the data itself. Is this the right data set to solve it or is there another data set order at the munge these two together to get the right result? And so we have these cycles of iterating on our tools and our schemas and our reports, but we're also kind of iterating on the representation and the type and of data to answer the question and that makes it hard but I think that challenge of iterating on the data itself iterating on the things acting upon the data still fits into this framework of defining a problem working on a solution getting feedback and learning every way and even though Those little circles in there like problem or idea definition and themselves have their own iterations cycle. And so in some ways being able to quickly get something in front of your customer that 70% right? And learn from that and then improve it is the best goal. And so even getting something 70% right is hard. And so sometimes it is very hard to communicate with people who aren't technical who don't think in schemas and dashboards who haven't had a bunch of math classes and they can speak in business speak, but they may not speak in the same language you do and so I think there's a real challenge at the very front end of how do you write what someone wants and how do you get that down in the very first initial case because there's a series of handshakes between you and your customer like I heard you say this and you take some and really it's sort of like I don't know, I've been married now 32 years and one of the things I've learned is I have to say back to my wife. I think this is what you just said to me and like I heard this and she'll go. No, that's not what I meant at all often more often than not and are you listening to me? But that dialogue of hearing what someone says reiterating back to them learning a bit more what they want and I think that it's a very hard thing to do, especially, maybe men are from Mars and women are from Venus and people are from one planet and business people for another but I think the same challenge goes it's really a communication Challenge and that's why I'm excited about this Information Product Canvas and someone just made a question communication is hard and I think that's totally true communication is hard and in some ways everything is communication, right the product you deliver is communication. The definition of the product is communication and

Shane Gibson: we're gonna go back into that queue. And what we do is we focus on moving the left hand circles fast as we can and just reckon and stack in this backlog and then handing over to the right hand side and trying to get through whereas what we want to do is go from problem all the way through and iteration back to Value before we pick up the next one and we want to get the whole cycle to be as fast as possible and that is hard right, but that is bringing products thinking into the data World in my view. What do you think? yummy Christopher

00:14:52 Marty Cagan's four questions, and the one data people jump straight to

Chris Bergh: and I think from my perspective. That's what's really exciting and about what Shane has done. and for the American translation is super sugar crust.

Shane Gibson: Yes. So before we jump into the idea of a shared language, right and the canvas, they're gonna co-authored or designed over the last decade which solves some of the language problems. I just want to come back to their idea of is the data. because that's the thing we mentioned and if I pick up a framework from Marty Cagan, all right, so when we look in the product, may we skip out of the data domain and we start looking at other domains in the world. One of them is the product and this is the way Marty Cagan talks about how to decide whether to build a product not right isn't valuable, somebody it is it usable if I give it to them? Can they actually do the job to be done Is it feasible can I actually build it and the product world is it viable — can I actually make money. Is it sustainable? When we think about data people, where do we go? As soon as we have a conversation with me we go straight to feasible. Right we go to can I build this is the data, So I have the data and we ignore all these steps and we've got to think about information products or data products as almost a box of cereal and this is within a conversation at the beginning. This is a New Zealand and box of I think honey pass which is kind of the treatment when I was a kid. and so we've got to try and get as close to this pattern of a box which is a product as makes sense for the data world. And so for me the way I think about it is if I build this information products, is it valuable to the person funding it and typically that is somebody internal, That's a stakeholders that saying maybe hear some project money. Maybe this is the priority that everybody's gonna work on and I've agreed that with the organization. What's the most usable way? We could give that information to the people who need to use it, The stakeholders typically is the buyer but we're kind of serving a user a consumer that is slightly different and data world. How can we build it? Right the thing that we love to do? And actually most important one is it desirable and my test for that is do people use the information products instead of Excel because that's their alternative as the hard graft of giving that data and measuring it into Excel themselves, which is not a product. Right? It makes their life hard. So if we can't build something that's desirable with just the whole step and part of the reason we missed that step. Is this idea of a shared language. So I can only speak English if I win and had a conversation with somebody who was fluent and French and only friends. There is no way we're gonna get alignment. Yeah, I'll probably studies and hand signals. That's the lowest common denominator for a language we have and so the idea of the Information Product Canvas is to try and create this shared language that is visual between us data people and everybody else that we talked to who wants some data to answer a business question to take an action. So if I just kind of go over to it there is this idea of canvases so it came from a couple gentlemen who wrote a book and open source to Canvas called the Business Model Canvas and then you would have seen a whole lot of variations Lean Startup canvas and that kind of thing one of the things that was great about the people who created the first canvas was they made an open source, so you're allowed to got that canvas and iterate it and so what I've been doing for the last decade is working with organizations and just iterating this canvas and I've ended up with a canvas that has 12 areas and each one of those areas is to try and decide as the product valuable as it feasible as it usable, right? What are we going to build and try and bring some of the conversations some of that shared language early in that cycle before we actually get into the design and build phase. and so the way I typically fill it out is

00:19:50 Information product or data product? Agreeing on one term matters more than which

Chris Bergh: But before we jump into the canvas, which I think is the meat of this. I do want to go back to the notion of an information product and a data product and the differences between the two and before you answer the differences between the two. I just want to share one experience. I had at a conference about six months ago. So I sat in is that Chief data officer conference? So it's 20 or 30 CDOs. It was a data product discussion. It's one of these conferences where there's no leader. Someone's and people are just talking at each other and they spent 20 minutes talking about a data product is it's a data catalog plus access plus shopping for data. We have data virtualization. It was very focused on the building blocks and what, And to me I think a data product is and if certainly the information product is how if you look at that, I think it was slide seven or nine that you showed it. Those are all methods to achieve a business goal. They're not really like, you use data virtualization or you use a combination of a data catalog and this is our definition and we've got data contracts and I get discouraged. Honestly. I've been in the data field for a while and the amount of sort of buzzword bingo I hear Is and it doesn't really help the core problem of you're just not getting at what the customer needs and as many Gartner buzzwords as you do use it ends up not helping your resume and it ends up not helping your customer. So relentlessly focusing on customer value for getting all the buzzwords and saying what actually do you want? I think is really the benefit of this and I found from my job all the other stuff melts away. If you just can keep this one thing in your head. I only care if I'm making my customer successful and that's all that matters. Yeah.

Shane Gibson: I agree with we even deliver value. Otherwise, we're downtown has happened like it has our teams don't survive because they have to make trade-off decisions on who's making value for the organization. yeah one of my friends, As data people we can't do that middle line. I mean I said on a one-hour call with some very talented people arguing. What are semantic layer is? we argue mesh versus data products, right we argue. What a data products. when I'm teaching people product thinking for data. Yeah, what do you mean a product management for data products thinking I feel the products, back to the edge when you feel it. Is it just data we sell right and as data people we love to argue the semantics but never agree and that's one of the problems and so one of the things that's interesting for me is I use the word information products. Not data products now, I can self justify that I can say I talk about data assets or data products and tables and information is about wisdom and knowledge, but actually it's 10 years ago. I was working with a customer and that's the term they picked for this thing that we do and I'm being stubborn and go hang on. I'm not changing the team to a data products. I'm just not using that language but the key thing is and your organization. You need to have a term and you need to have that term agreed amongst your team and the rest of the organization and you need to stick to it. just what we doing data. We talk about active marketing customer Act of risk customer Act of Finance Customer because we know we don't actually have a single definition of active customer. Here or customer, And so we're really good at saying to our stakeholders. You can't use the same name for something that's got three different definitions because they'll be three different numbers. But in our world we're incredibly bad at those we say not as we do. and so yeah, I think it's important that it doesn't matter. Which would you just use them consistently right create that business glossary, of those teams. And so yeah for me. I have a definition of an information product. What to me, it is a combination of data code and looks and visualization as the whole box is Everything's in the Box. It's gonna deliver information and that may be just data and maybe just a file but it may be something else and it's within a boundary, right? There's a certain amount of that can fit in the box and then I'm gonna have another box in that box is gonna be slightly different more importantly if somebody takes it data box off the shelf. I have to know what action they're gonna use it for what the outcome of they take their action is and the business value because by understanding that business value, I can justify helping the organization be more successful and we're helping them make more money save cost or reduce risk because that's all they care about right as a healthy business and that's what we're here for. the way I really like to think about it. Is an app on my phone?

00:24:47 An information product is like an app on your phone: boundary, data, action

Shane Gibson: If I'm using email and my organization, I have a boundary of people that use it with me. I have a certain amount of data or content that's in that boundary and I have an action. So for us email is always external. I only use it for external people not internal. It's text and a conversation and normally it's something to do with selling or supporting our customers. Whereas if I use Slack, the personas the group of people that I use that product for is different. It's our internal team only and our partners around the world. It's still text. It's still a conversation. So it's very much the same as email and it's around our way of working right doing something internal. if I compare that to Candy Crush Yeah, the boundary is me. I don't play that with anybody else It's gaming data and the action now come potentially. It's relaxation. Sometimes I get that sense of anger when I'm not covering a level. So maybe it's a Sinister success, but you can see what I'm saying, right? So each one of those products is effectively got a boundary of who uses it what data it contains and what they're using it for and if we think about information products that way it gives us a really good sense now then it becomes hard because what's the boundary? Lifetime value right they could be an information product but it's massive. Churn. There's another one maybe right or something for marketing versus something for finance. And this is where we need to focus on what the boundaries of those products are because we can't boil the ocean. We can't build products that take us three years

Chris Bergh: Or a broken phone if you're really frustrated. Yeah, and I go back to this psychological blockers from it right the fact that putting something out that's not entirely done or data that may not be entirely correct. Right or the embarrassment of getting things wrong. Right and a lot of times I see organizations build these defensively complex tools like a dashboard that's got 15 drill Downs on and

00:26:35 Self-service, personas, and the dashboard with twelve drill-downs nobody wanted

Chris Bergh: it doesn't answer the question you just You're basically giving them a data base query tool the tier query everything and so I'm trying to get the right level of insight delivery to your customer. And as you said Shane, is it a recommendation? Is it an extract? Is it a well configured dashboard a recommendation or a discussion with you? because I think we have to think of ourselves as an extended data analytic team has as consultants and we're to we were sort of the high priest and priestess as of data and people who don't have enough time and don't have enough skill or Consulting with us to see if this magic Oracle that we have can give them some insights on what they do and honestly if they don't get the insights, they're gonna just use their Intuition or use with the last person to hold them. Yeah.

Shane Gibson: because two and half years later they've already gone with the opportunity, So we want to break it down to something small and deliver it quickly and that's the point in my head of bringing product management into Data small bundles of things. We can deliver value quickly and early and we have to learn how to do that. And the other thing is we treat everybody in the organization as if usually we treat their Persona as the same as a data Persona. So we talk about self-service and in your examples a great one, right? We think that our stakeholders want a dashboard with 12 drill downs, but if we go and actually our Sports desirable, sometimes it's just the answer they want Services because they say I don't want to spend time playing with the data. That's not my job. I have an action that I need to take. I want the data or information that's going to help me drive that action and then I want to get on and do my job because my job is not to play with data. And so, if I go back to the scenario, I want to go and buy a box of cereal we need it. I don't want a bit of wheat a Milling station and

00:28:27 Do you build what they asked for? Henry Ford, Steve Jobs, and testing early

Chris Bergh: Yeah, yes, and no. I don't know, sometimes I wonder if You know. I want to do that sometimes and other times I just think I'm smarter than the people and I go ahead and say you use the Henry Ford car argument right people want cars are Faster Horses or the Steve Jobs argument. And I mean the reality it's a mix but whether the right way to do it or someone else does it it's so much better to hit the road early and find out if it's not gonna work rather than wasting time because that the end of the day I think we're just wasting 50 to 70% of our time. And it's emotionally tough

Shane Gibson: the other deep fryer and a bunch of bees and see what I don't see this from that one of you I just want to pull the box So again we need to go back and actually be very clear when we're building a product take that product thinking who is our Persona who is our audience what job thing to be done. How do we help them deliver that job which is how we think about it when we build our product and I'm assuming with DataKitchen exactly where you think about it as who's gonna use your product what job they need to be done what's valuable and desirable for them. And then if I build it, how do I test early that it actually is before I spend three years building a product and

00:29:45 Half the work is waste, and nobody measures their own cycle time

Chris Bergh: because you hear people it gets tough when the markets go down and your jobs threatened and it's also just why do you want to do a job or 70% of your time is not valuable. we're all talented people. Let's do something where let's get a good ratio on that. Yeah. Yeah they don't do it and and they don't measure it either like no one. I've never met I've talked a couple of thousand companies. No one measures their cycle time. They're deployment they're back they might measure their backlog and but everyone will say it's just really big.

Shane Gibson: nobody comes Yeah, the trick is Is that saying that 50% or my marketing spend is wasted. I just don't know which fifty percent and so That's a great segue. And so what patterns can we bring in that help us on the left hand side of that continuum? So what can we do that is light. And easy, on the left hand side to reduce the uncertainty and risk when we get it to the right hand side and it's not perfect. Right as it's just about okay if we know that 70% of the week we do on is not valuable. What can we do to make it 60% It's not Valium 150 and one of the things that I see when I'm coaching teams. As we focus on data. And we focus on tooling but we don't focus on our way of working and if we adopt some of the lean thinking and we actually just map out every step we do is a data team and we look at it as a cycle and say how much effort is you're in each step and

00:31:24 Measure from the first conversation, not from the backlog

Shane Gibson: how much time do we spend between the steps? How much delay in the handles are there and how can we iterate our way of working to reduce that cycle time to reduce that delay to reduce the cognition of the end of we're gonna be a better data team regardless, So again, I wasn't encourage people to work in your team their way of working kind of, if you think about it as a startup work in the business as well as on the business and again, I don't see data things doing that. So, and we measure from picking up from the prioritize backlog to delivery of value to the stakeholders, right? We sometimes measure there but we've got to remember that stakeholders put that problem and that queue six months before that before it even got to prioritization. So if we go back and measure the time the customer or the stakeholders asked us for something the first time they mentioned they had a job to be done or a problem that needed data to help them. So we actually delivered that value. How long is it because if it's a year, we're not a product team, and so yeah, it's a balance and it's a trade-off and all we got to do is just focus on finding things that make it shorter faster safer better again data has to be accurate, There's one of the challenges we get given, compared to a product team So let's kind of think about this idea of one hit there. I've used successfully over the last decade which is Information Product Canvas, and it does go and multiple of those circles and that Continuum, but primarily I use it on left hand side at Discovery phase.

00:33:06 The Information Product Canvas: twelve boxes, open source, filled in live

Shane Gibson: So someone just come with a business problem. They said I need some data or Ideally. It's knowledge zero ticket yet, right. We'd only go into ticket. Hell, we've got people having a conversation with us saying I've got this problem and we kind of want to idea and discover what that problem is and see if we can reduce the uncertainty of how we do it. So the canvas it's open source. So I think somebody asks the question. Yes, you'll get the slides and also give you a link to the canvas. There's a bunch of formats PowerPoint Google Slides PDF that you can use it's all free and open source. And so what happens is we've got 12 boxes to fill out and in the time we won't go through all of them. So I'll just start with the ones that I think and most important again. I'll give everybody a link to a whole article. I wrote on what goes in each of the boxes why and how you get So the first thing about the canvas is you can fill it out and any order you want. It doesn't matter but I have a specific way that I fill it out. There's been valuable for me. Right and I'm gonna start with business questions and then I'm gonna go on to actions and outcomes and move on from there. The other most important thing is I do the canvas with the stakeholders. I use a thing called pattern storming. So I will bring the canvas up and as I'm talking to them, I will start typing in the boxes so they can see what I'm typing.

00:34:42 Pattern storming: typing into the canvas while the stakeholder watches

Shane Gibson: That is probably the most valuable piece of the canvas. What we do is as we type in these words, they're seeing the words that we're writing and they're giving us immediate feedback when we've written the wrong thing. Just like you see with your wife what I think I hear he's saying is this yeah I need to do the dishes now not at the end of the game and so by visually showing people what we're writing. They give us immediate feedback when we've got it wrong. And so what we're doing is we're just bringing that to the beginning of the process versus interviewing them writing it up sending it back to them a week later when they're busy and they've forgotten what their conversation was and typically what they Let's go. Yeah, that's good. You build it all then have a look what you built and then I'll tell you it's not what I want. So yeah, and we can straight So again MVPs about constraints, The canvas is about constraining what we capturing early, right? We still need to get to the detail later when we're going into that design and build phase that's important. But we're at the latest side of the Continuum one of the anti-patterns that I see lots the data people as they'll take the canvas and they'll then just create it as a table in Jira. And then they'll try and fill that table out with the stakeholders. S the canvas and this format somehow they find it easier to understand right less cognition. As soon as I put a table in a Word document or Jira they turn off that's really weird a decade ago. We actually had a thing called the information product brief, which was a Word document and then we locked on the canvas and that actually has been the game changer. So again data people you can take the canvas and turn it into a table and data later, but with your stakeholders use the canvas. Pattern storm and interact with the canvas while you're doing it. So the first thing I ask and I've learned to do this over the years as I don't ask them what action and outcome or the value is you The first thing I ask is what business questions do you want to answer? And the reason is they've been thinking about this problem. They think they know what the answer is. This is the easiest part of the canvas for them to answer very quickly. So we want to engagement. often the business questions, you'll get back are quite fluffy. Yeah, they might be how are we going with customers or as our business healthy or are we going to be profitable next year and as data people we know that those are big questions, right and they're a little bit hard to quantify. So what I do when I get fluffy questions as I go back and I ask them for very specific ones. I say I'd like questions that begin with what Lawrence calls the seven W's and once you've given that framework, so, what customers are tuning how many customers do we lose last month? You'll find that your stakeholders will then read all three to five questions and a heartbeat Lotus. They'll get their pattern and I'll just go bing bing. And then they'll stop and

Chris Bergh: Yeah, it's not worth their time to and I also think what's good about a canvas. Is it small like this? It's not meant to be a canvas that you put on the wall or your drill into this is 10 or 12 point font that you should put in this you shouldn't write a novel. it's a few bullet points and and you and I think that limitation on what you can write on putting on one page and putting in reasonable font actually is a huge benefit because you don't spend all your time describing exactly what it is.

00:39:00 Scope later, not now — what to do when a business question is a two-year epic

Chris Bergh: Yeah. Yeah, because I guess that you're saying the Temptation is they're just gonna rattle off everything they've ever wanted and and yeah, and it Is the scoping by the size of the box as a scope and conceptually, how do you draw the line? Is that just Yeah.

Shane Gibson: what happens is as a stakeholders. I stopped them. I say that's good for now. We're gonna come back later and we'll iterate the canvas. This is not a requirements document. So we've got some good stuff here. I understand the questions you want to answer. Let's move on. Right. Does it make sense? Wait, we haven't scoped yet, I'll see if I see questions that are lifetime value model and my head. I know that that is a massive product right an Agile. We'll call it an epic. Right? That's probably a year or two to build that out. I don't care you right because I'm trying to discover what they need and then we'll come back and manoscope later. We may say that's five products and we'll break the canvas out and five canvases. but what we're doing here is we're scoping and doing trade off for a feasibility right not for Value not for the desirability not the usability. So we want to focus on the inside Let's make it easier to tell us the problem. They want to solve. if you're a data person, right and you're doing data design as you should we actually start getting some really interesting hints or really about a conceptual model. I've got this thing called an order. Yeah. I' done that I've already done that for another product is a reasonable data. I see abandon orders, actually, I know that that's in another system that we haven't bought that I'm gonna make feel free to make notes on a separate piece of paper with the things that you already know because you're a data expert and you should be an expert on the organization as well. So we've got these three to five six to ten, right? It is constrained. If you get down to 6 point, they can't see it. So then stop we want to move on to the next box and the next box is top left. And this is for me the most important box to move us from building data to building a product. And so what I say to them is okay, if I answer that business question with information, how many customers do we lose last month? And I tell you that answer.

00:41:34 From business question to action, outcome, and business value

Shane Gibson: What are you gonna do? What action are you gonna take? And if you take that action and what outcome will be achieved and so they will naturally roll onto that it will go. if I got a bunch of customers that churned and I can understand the churn reason and what I'm gonna go do is a save campaign. Okay, so you're gonna go into a save campaign. How do you do that? Right and I'm gonna go into Salesforce and I'm gonna segment the customers. I like you to churn and I'm gonna go seen that and if that campaign was successful what happens we retain our customers. do we know how many customers we are ideally trying to retain what's our Churn number? We're trying to reduce now you may or may not get an answer for that one because we're breaching from action and outcome into value. And often a stakeholders can't quantify the actual value if they can that's great. Because now we have a valuable product. We can actually articulate if I build this information product. We're gonna say five percent of our churn which equals a million dollars There's our justification for building it, but often they can't so we just stay with action and outcome. This box is actually the box that prioritizes the product. Yeah, I've got team products I could build then this is the box that a steering prior Edition committee information product manager, whoever's in charge of prioritization should look at and say I've got five of these which outcome would I like to enable next? to make sense So again, as a data person that's working and product. We should help our stakeholders be successful. And so if I see an outcome which is I want to get my bonus and it won't be weirded that way but that's the words and there and then I know I've got another product which is reducing churn for a million dollar. Review increase I'm gonna say to the stakeholders. you're competing with these other products and I don't think that is a strong outcome statement. So let's try and refine it because I can guarantee when it's in the backlog you getting your bonus is not a priority for the organization over increasing me. The other thing is sometimes you'll just get fluffy outcomes. and that stage you can realize that the stakeholders hasn't actually thought about their problem. Yeah, they just asking for data. they're not articulating the problem. They're just doing a data request not selling the problem to be solved to the job to be done. And again, that's where we bring in the product management thinking we want to help them be successful because we know it helps the organization so we should coach them going. let's have a chat about there. Right because I don't see that as a strong outcome statement. The other thing is data people. We love to be deterministic. So we want in an outcome an action and

Chris Bergh: Yeah. Yeah, that makes sense and I think A lot of data people I find are.

00:44:37 Stakeholders hand you actions and outcomes in any order, and that is fine

Chris Bergh: and I'm surprised at this I sort of disconnected from their customers they're disconnected from the kind of questions you if they're a business should I you am I going to increase sales or cut costs and all the subsequent and and at some perspective a lot of businesses are the same they're about you investment return growth versus risk and I think trying to get sort of the theory of the business in your head. What is my business doing? What are we trying to expand a new markets? Are we trying to cut costs this year? Are we having a new product and understanding that framework of what's going on with your business or your organization? If you're not in a business if you're in a government organization, what are the goals of this year and trying to get sort of a A framework to attach what's happening? It's helpful for me, and maybe that's just the way my mind works. But I like to think from sort of big picture in and I think the sort of understanding where your overall outcomes fit in the overall outcome that the organization is also it's helpful.

Shane Gibson: outcome. But in reality we'll get a bunch of actions and a bunch of outcomes and they are a mini to many relationship almost agree and that's okay because that's how our stakeholders think. So some stakeholders will give us action outcome. Some stakeholders will just give us a bunch of actions and a bunch of outcomes. It's okay because remember what are we doing? We discovering early and we're reducing uncertainty. We're starting the conversation and trying to figure out what the next most viable thing to build is that's the purpose of the canvas at the stage.

00:46:16 Bagging Jira and dbt: how data teams turned into ticket takers

Shane Gibson: Yeah, and it's more fun, We're more engaged and we're more valuable. We're more valued. So, I'm gonna bag Jira and dbt here for a second, right not because they're not great products. But because of what I see them being used for and it comes back to that conversation. You said right at the beginning when we sit in it, we become ticket takers. So we get a Jira ticket. This is giving me some data we go into dbt and we just quickly write some code which pretend it's called a model and we do that because we want to be really fast on that build cycle on that one dot on the right hand side of that and we ignore everything else and we just become ticket take as we're order takers and we don't see the value we deliver we're just constantly smash with more and more orders. We want to be on the left-hand side because being in that product spaces more fun, and so just imagine that you're back in the days where we're actually in the building together and we're on the left and we're with the chief executive of our organization and He rocks and then he goes. Shane, me before and I go. Yep, and they go I was the last valuable thing. You delivered. Oh gear a ticket. One, two, three, four five. I delivered a list of customers to Jane.

00:47:37 The product-manager role, and the abandoned-cart story

Chris Bergh: I mean I see an Agile product management product owners having a huge role in and every software company. There's someone who is trying to interface with the world and reduce it down to statements that an engineer can build right and it's a rare engineer who can do that on their own and so I've been that role in software organizations. I've run a product management team and it has different terms product ownership. It has different and companies but it's an incredibly valuable role and also it's the role that most often. People take to become a CEO or a senior leader because it sits you at the interface of everything that goes on in the company right? And that's what's exciting and I think a lot of teams are starting to make data product managers or business analysts or whatever. The term is right to help people do this. And so, we've got Shane, we've got 10 more minutes and there's one question from Attendee.

Shane Gibson: It's not a fun conversation, There's lot of valuable conversation. That's not a product conversation. But if I go and I was working with marketing Jay had this problem. They really understand abandoned parts. So what we did is provided some information around our abandoned cart numbers and then what we did together was we actually went out and did a notification through the economist store to say that we'll give you 10% discount if you finish that car and that was kind of automated from a data point of view and that resulted and 10% reduction over to being in cards and a five percent increase in and dollar, really? That's a product story. Yeah, and that's what we want to do because why can't we be involved with that conversation because we're an enabler we have the skills to provide that information to enable that problem to be solved rather than treat ourselves just as ticket takers. And so again

00:49:27 Audience question: how do you get from the canvas to a requirements document?

Chris Bergh: He said Shane you said the canvas isn't for requirements. How do you take the canvas to a requirements document? Yeah, I don't know. I guess I'm not a fan of requirements documents like to me. I think this is enough and then you start working and building something. And so if you're skilled enough you say okay? here's a You here's sort of a crappy schema. Right and it's done. It's like here's what I think this is and then you put kind of a crappy report on it. And you're like I read this this is what I think and the orders, we need some facts to mentions. Here's and I think of working software or working analytics over requirements. And so my feeling is I hate requirements documents because they take forever to write and they get in the way and I'd rather just give people something that's 50% right and say take a look at it that I get it and they're like, no. Yeah. That's right. But I don't want to have these six charts. I want to have a different chart and this data looks sketchy here. So I think there's Yep.

Shane Gibson: that's why I'm so passionate about bringing these different patterns together because that's actually more fun. I remember the days when it used to do this on a regular basis and then somehow' I do blame Agile ways and working a little bit right is we lost these ways of actually understanding the business processes the ways of understanding the organizational outcomes. I mean part of that again why opportunity Not every organization is like that but I see it a lot. What do you see? So it's just about iterations. So what I would do is I go and capture the canvas at the beginning. I then fill out all the boxes over time or in one go if I can the insights I get it through the prioritization phase depending on how the organization wants to prioritize that work. And then each one of those boxes naturally becomes part of a design or a requirements document. So we haven't talked about it, but you can read Around core business events. So who does what's that effectively gives us our data model, customer orders product, customer pays for order those become core concepts. I can do a conceptual and then a physical model of that and that becomes part of my requirements. There's a box in here for data sinful freshness. That is how often does a data need to be refreshed from where we found it. How up to date does it be there becomes a requirements throughout East LA or our data contract the delivery types we talk about how would you like it delivered to you is that a file to Excel as an integration with Salesforce that becomes the Box we expand out which is the requirements of our delivery mechanism. So each one of these boxes and gets expanded out and to a requirements document if you requirements documents Within make it a living document. So I use it about five different times over that life cycle over that value stream and I will actually end up with it as an as-built as well. And the reason I do that is if I come back six months later to an information product somebody's using and I need to enhance it or maintain it or decommission I forgotten what it was a child so I can bring that canvas up and go. yeah, right. I understand the business context the questions the actions the personas what we deliver what was and what was the other scope? So that's the last part is the bottom of the canvas feature stories and we'll work that's where we kind of scope our requirements. We will deliver it from the store system. We won't deliver it from the solar system in this iterations. That's where we start minimum viable or breaking that product down into smaller chunks. Hopefully that makes sense.

00:54:23 Trust, listening, and repairing the relationship with business customers

Chris Bergh: Yeah. Yeah Yeah, the more this for internal teams are kind of consultancy users Yeah. Yeah, they don't and as by proxy they don't trust you yet. So you've got to work with them to gain their trust and the rapid delivery of value is partly listening and it's what makes a good relationship feeding back making sure you get it right and meeting when you're wrong and It's very basic stuff that would work well in a marriage or a friendship or between countries or between data people and their business customers and I think if you can do that you end up repairing the relationship and I've seen it and I've done it myself we've gone from terrible relationships to Great Relationships by following those principles and

Shane Gibson: Yep. trust and let's go. just Yeah, so I'll just cancel that a little bit. So I'm like you right my focus is around from problem statements how quickly can I get around there iteration to value? And then how can I look through there three or four times to keep delivering small amounts of value get feedback and iterate it right and that's the way I work and that's the way we work. However, some organizations the teams are not allowed to work that way right. Yeah, they have to do a flow where they hand off each of those dots as a handoff between teams. And so what I say to them then is try and find the leanest way to do that handoff if you're creating a requirements document because what's the minimum amount of information that you have to put in that requirements document for the next step to be taken and just do that. Yeah, because anything else is waste anything else Mike's you slow at stuff you have to maintain so if you're forced to do requirements documents, right because that's your way of working. Then just make them as light as possible. Right just remove stuff until people start complaining with the next step can't get done. Yeah, because some of the teams I work with aren't lucky enough to be empowered to build their own way of working but like you they should because that's

00:56:55 Closing questions: the canvas as a consultant's scope, and whether it works with Kimball or Data Vault

Chris Bergh: I think now that we've got sort of just four minutes left Shane. I think I want to put out if there's any more questions and then I want to give you a chance to close and for people to find out how to contact you. So any more questions from anyone? Okay, we have one more Attendee. I guess raised a hand here. So people seem not to be able to write in and Q&A. I have to not be able to write in the chat. They seem to only be able to write in the Q&A questions. And so that there's a question from Attendee around does this work for Kimball results or a three-tier data warehouse is there I guess maybe intuiting a little bit of Attendee is this implied a technical design or not? And Shane, how should people contact you if they want to learn more? Yeah, yeah Shane I think this is just excellent so I really thank you for taking the time to talk with us today And my career and data I've seen a lot of ideas come from software and and sort of hit rocky shores, but I think this has got a lot of legs on it because it's easy to use you can start using it right away. There's no Tech or cost confusion, and it helps. It's a tool to help communication and I think that's any tool that can help people who naturally would rather look at a screen to communicate what with their customers is a good thing. Thank you so much for spending your time. And for everyone we will be sending the stack. We will be sending the recording of this and the transcription out to shortly so maybe the next day and thank you so much. Thanks, everyone.

Shane Gibson: what we should do is a data team. I think there's another question in there. I saw flesh up around external use of this versus and So I run a consultancy our a product is kind of a service as well. I won't deliver anything for a customer and if I have a canvas, this is my scope statement. So as an external consultant experiment with using this as the document that defines the scope what you're gonna deliver now, the customer you're working with has to be comfortable that it's an Agile scope right? It's kind of Fluffy is not like 20 words that they can sign as a contract. they're committing to building something of value with you rather than Contracting you to do a bunch of tasks. Again, that's what I think we should be doing if we're Consultants we should be adding value to the organization and think about the power. Yeah I delivered a dashboard. I help that organization deliver five percent more revenue is an external consultant one of those as a much better story for your next customer, but it's hard because a lot of customers don't trust that fluffiness of the front end, right? Okay. Okay. No, so I'm a more Data Vault guy than I am Kimball guy. I'm definitely a three-tier data warehouse architecture guy of them. Like I said, I've been doing it for 30 years. So I'm old school. so this I can inferior conceptual or physical design from this but it's not high coded in there. Where I see I call Concept where I see customer places order. I talk about this pattern called Concepts. I see a concept of a customer a concept of an order a concept and a relationship or an event for me customer becomes a hub and dimensional customers are done order becomes Hub and Vault for me and then I have a link which is customer orders places order dimensionally I would say that order is the driver of effect So it works on any architecture. I've done it with Google and analytics data for our customer, which is all horrible. Nested event streaming JSON. Yeah. Awful stuff. But again, we're trying to get that shared language, right? We're trying to get away from Anything that has the word m fact data model physical model hub, link, sat, activity schema. They don't care They want to share language, which is here's your business problem. Here's how we're gonna solve it and we'll take care of the right hand side of that Circle. Right? we'll take care of the design and build. That's our expertise. Don't worry about it. That's our job, but we need to be together on the left hand side and that's my view on that one. so this is why is you can find me on LinkedIn if you set for Shane Gibson or fugility, we'll send this link out but the open source template is available from we've got a companion website to a product which is the website way of working. So if you go to that link, you'll find the write-up on how it feels the canvas out. You'll find the templates themselves. I run a course if you want to run a course for your teams where I can kind of go through and we'll do it together and you get hands on building out of canvas as a team. So that's there as well. But yeah, all the canvas information is effectively open sources Connor giving it back to the community and I'm so passionate about it because it just helps teams work in a better way that I'm happy to share it, without try to make money out of it. process particularly Thank you.