[00:00:00] Chris: Okay then, we just had one more. Why don’t we start, Shane? So hello everyone. My name is Chris Berg. I’m CEO and head chef of a company here in Boston in the United States called Data Kitchen. And I am very happy to welcome a guest to this webinar, Shane Gibson. Would you give an introduction to yourself, Shane?
[00:00:19] Shane: Yep, Shane Gibson. So I’m from a little place called Kapiti in New Zealand. So at the end of the world and yeah, I’m glad to be here. It’s going to be an exciting conversation between the two of us, I think.
[00:00:30] Chris: 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 hand button looks like a dialogue box on Google and we’ll try to answer those either during or partially during it. And so I think let me start with the background. 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 at 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 waste? 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. And with data and analytic teams, like we all have a lot of calculus, and we talk to business people, and maybe we think that calculus helps us, but 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 have that dialogue with your customer? Because learning doesn’t come 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 so that I think is really the topic. And it’s about data products or information products, but it’s really set in that background. I don’t know, Shane, what would you think the background of this is?
[00:02:17] Shane: Yeah, so let me just bring up some slides and I’ll I’ll use them as prompts. So rather than go through a formal presentation, what I’m thinking we’ll do is we’ll just use them as prompts.
My background is I’ve been in data for 30 years. I think of it as three generations or three decades. My first 10 years was in software and vendor land. So working for large data companies and that was back in the. N tier pre cloud days, right? And the problems we were trying to solve back then were hardware constraints, right?
It took us too long to get the hardware, too long to get the software. After that, I started my own consulting company and I was lucky that we moved to more of the cloud platforms. So our constraint there was our people, right? It 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 lucked onto this thing called Agile. And so I’ve spent just about a decade working with customers applying Agile and data patterns together. And I’ll use the term 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. The kind of three patterns I want to What 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? But going back to your question what problem are we trying to solve? These two, right? The number of times in my career over 30 years, I’ve done this. Talked to a stakeholder, thought I understood what they wanted, built something. And they didn’t come.
And when I go back to them and go, what was wrong? It was like, that’s not what I wanted. And you regress yourself to, but that’s what you asked for. Now that’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. 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 one we got to sort out. So what about you? What do you see?
[00:04:49] Chris: I got myself on mute. Shane, I think it’s about the word product instead of project. And so I think the idea of an information product or a data product means you give it to someone and you don’t go away. You’re not done with your project. Your project is just starting. You’re improving upon that product.
It has a life cycle to it. You build it, you improve upon it, and maybe you subset it. You sunset 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 the IT team. They think they’re utterly useless.
And then the 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’s just, that seemed 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 the IT team is, are 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:06:14] Shane: Yeah, and so there’s a couple of problems or anti patterns that we have as data people. So when we’re treated as IT teams, when we actually sit in IT, 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 said, is we treat everything as a project. We treat it as a beginning and an end, a one and a done not as a product. So one of the things I’ve been thinking about a lot is 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 design, we build, we deploy, we may deliver some value.
We may enhance our data products, we may not. We may just build them, push them, and forget about them. We typically don’t decommission them. In the cloud data world, in 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 I’m the co founder of a data startup, we’ve got a SaaS platform and a product, which forced me to take my head out of the right hand circle and move it left, right? I 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 left hand side of that circle, actually where we start is understanding the business problem. Not the data they want. We got to understand what’s going to 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 do we tend to do? 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 there’s multiple ways we could solve it.
We could build them a dashboard, we could dump them an Excel file, but we could actually interface that data back into the systems of record and prompt the next best action. So there’s a 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 where they need to discover, right?
We need to discover which is the easiest, the most feasible, the most valuable. Way of solving that problem and this is where data people prototype, right? That’s where I see a prototyping phase if that’s how you work. But what you’re saying is I have a theory 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 it out to see whether i’m right What can we do to reduce the uncertainty and reduce the risk?
So in the Agile world, we talk about research spikes. In the product world, we talk about minimum viable or prototypes. In data worlds, we talk about, prototypes before we move to production. And then the trick for us as data people is that 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, I’m building one thing. Yes, it’s got a bunch of features, but I am spending five to 10 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 to become very domain specific and pushing back into the product side of the business 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 going to build this one. I’m going to deploy it. Yeah. I may go back and enhance it and maintain it. I probably won’t. I probably won’t decommission it. So now I’ve got that technical debt of maintaining it.
And now we’re going to go back into that queue. And what we do is we focus on moving the left hand circle as fast as we can and just racking and stacking this backlog and then handing over to the right hand side and then trying to get through. Whereas what we want to do is go from problem. All the way through an 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 product thinking into the data world in my view. What do you think?
[00:10:54] Chris: You
know, I think data is hard because I spent half my career like you building software products. And when agile came along in software and these infinity diagrams were there, they were like, they were great. And the other challenge with data is. 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 almost iterating on the things acting upon data. Here’s the structures, here’s a way 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? Or do I have to munch 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 iterating on the representation and the type 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 some of those little circles in there like problem or idea definition they in themselves have their own iteration cycles.
And , in some ways being able to quickly get something in front of your customer. that 70 percent right and learn from that and then improve it is the best way to, is the best goal. And so even getting something 70 percent 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 I don’t know, I’ve been married now like 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 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 hearings, what someone says, Reiterating back to them, learning a bit more what they want. And I think that is it’s a very hard thing to do, especially, maybe men are from Mars and women are from Venus and IT people are from one planet and business people are 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 this is a, and in some ways, everything is communication, right? The product you deliver is communication. The definition of the product is communication.
And and I think that’s really, I think from my perspective, that’s what’s really exciting and about what Shane has done.
[00:14:17] Shane: So before we jump into the idea of a shared language and the canvas that I’ve co authored or co designed over the last decade, which solves some of the language problems, I just want to come back to that idea of is the data right?
Because that’s the thing we mentioned. And if I pick up a framework from Marty Kagan. So when we look in the product domain, when we step out of the data domain and we start looking at other domains in the world, one of them is the product domain. And this is the way Marty Kagan talks about how to decide whether to build a product or not.
Is it valuable? Will somebody buy it if I build 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 in the product world, is it viable, right? Will 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 a need, we go straight to feasibility. We go to can I build this? Is the data right? Do 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, we had a conversation at the beginning, this is a New Zealand box of thing called honey pasta, which was the treat when I was a kid.
And for
[00:15:27] Chris: the American translation is super sugar crisp.
[00:15:31] Shane: 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 built this information product, Is it valuable to the person funding it?
And typically that is somebody internal, right? That’s a stakeholder that’s saying maybe here’s some project money, maybe this is the priority that everybody’s going to 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, right?
The stakeholder typically is the buyer, but we’re serving a user, a consumer that is slightly different in data world. How can we build it, right? The thing we love to do. And actually, most important one, is it desirable? And my test for that is, do people use the information product instead of Excel?
Because that’s their alternative, right? Their alternative is the hard graft of getting that data and mashing 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, we’ve missed the whole step. And part of the reason we missed that step is this idea of a shared language.
So if I can only speak one language, right? I can only speak English. If I went and had a conversation with somebody who was fluent in French and only French, there is no way we’re going to get alignment. We’ll probably start using 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, right? And everybody else that we talk to who wants some data to answer a business question, to take an action. So if I just go over to it, there is this idea of canvases.
It came from a couple of gentlemen who wrote a book, an open source to canvas called the Business Model Canvas. And then you would have seen a whole lot of variations, Lean Canvas, 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 it an open source.
So you’re allowed to pick up 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 Is the product valuable? Is it feasible?
Is it usable? What are we gonna build and try and bring some of the conversation, 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:18:09] Chris: Shane, before we jump into the canvas, which I think is the meat of this I do wanna 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, it was a chief data officer conference. So it was like 20, 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 the what, and to me, I think a data product is a how. And if you look at certainly the information product is a 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 Oh, 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 is 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, forgetting 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.
[00:20:03] Shane: I agree. We need to deliver value. Otherwise when downturns happen like it has, we, our teams don’t survive because they have to make trade off decisions on who’s making value for the organization. One of, one of my, one of my rans. As data people, we can’t do that middle word, that middle line.
I sat on a one hour call with some very talented people arguing what a semantic layer is. We argue data mesh versus data product, right? We argue what a data product is. When I’m teaching people product thinking for data, oh, what do you mean? A data product? Data as a product management for data.
Product thinking I feel the product, back to the Agile, you only know it 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 product.
Not data product. 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 going, I’m not changing the term to a data product.
I’m just not using that language. But the key thing is, in your organisation, you need to have a term, and you need to have that term agreed amongst your team and the rest of the organisation, and you need to stick to it. Just like we do in data, we talk about active marketing customer, active risk customer, active finance customer, because we know we don’t actually have a single definition of active customer, or customer, right?
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 there’ll be three different numbers. But in our world, we’re incredibly bad at do as we say, not as we do. And so yeah, I think it’s important that it doesn’t matter which word you use, just use them consistently, right?
Create that business glossary of those terms. And so yeah, for me, I have a definition of an information product. To me it is a combination of data, code, analytics, and visualization. It’s the whole box. There’s, yeah, everything’s in the box. It’s gonna deliver information. Now that may be just data.
It may be 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 that data box off the shelf. I have to know what action they’re going to use it for, what the outcome if they take that action is, and the business value.
Because by understanding that business value, I can justify how we’re helping the organisation be more successful. How we’re helping them make more money, save cost, or reduce risk. Because that’s all they care about is a healthy business, and that’s what we’re there for. Actually the way I really like to think about it,
If I’m using email in 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 doing something internal.
If I compare that to Candy Crush, yeah the boundary is me. I don’t play that with anybody else. The data, it’s gaming data. And the action outcome Potentially it’s relaxation. Sometimes I get that sense of anger when I’m not covering a level. So maybe it’s a sense of success, but you can stay on it.
You’re
[00:23:48] Chris: really
[00:23:48] Shane: frustrated. So each one of those products has 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. That gives us a really good sense. Now, then it becomes hard, because what’s the boundary?
Lifetime value, right? That could be an information product, but it’s massive. Churn is 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, because two and a half years later, they’ve already gone with the alternative, right?
So we want to break it down into 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.
[00:24:39] Chris: Yeah, and I go back to the psychological blockers from it, right?
The fact of 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 it doesn’t answer the question.
You just, you’re basically giving them a database query tool to 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 and analytic team as consultants, and we’re trying to, we were the high priest and priestesses of data and people who don’t have enough time and don’t have enough skill are consulting with us to see if this magic Oracle that we have can give them some insight on what they do.
And honestly, if they don’t get the insight, they’re going to just use their intuition. Or, use it with the last person to pull them.
[00:25:49] Shane: And the other thing is, we treat everybody in the organization as if they’re us. We treat their persona as the same as a data persona. We talk about self service, and your example is a great one, right?
We think that our stakeholders want a dashboard with 12 drilldowns. But if we go and actually ask what’s desirable, sometimes it’s just the answer. They want silver service 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 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 if I go back to the scenario, I want to go and buy a box of cereal and eat it. I don’t want a bit of wheat, a milling station, a deep fryer and a bunch of these. I don’t want to sell service from that point of view.
I just want to pull the box, right? 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 jobs do they need 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 Data Kitchen, exactly the way you think about it is, who’s going to 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 nobody comes?
[00:27:12] Chris: Yeah, yes and no. I don’t know. Sometimes I wonder if, 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 argument, right? People, do people want cars or faster horses or the Steven Jobs argument?
And the reality is it’s a mix, but whether you know 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 going to work rather than wasting time. Because that, at the end of the day, I think we’re just wasting 50 to 70 percent of our time.
And that’s, it’s emotionally tough because you hear people, like it’s tough when the the markets go down and your job’s threatened and it’s also just, why do you want to do a job where 70 percent of your time is not valuable? We’re all talented people. Let’s do something where let’s get a good ratio on that.
[00:27:58] Shane: Yeah. The trick is, is that saying that 50 percent of my marketing spend is wasted. I just don’t know which 50%. And so that’s, yeah, for me, that’s a great segue into 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? It’s just about, okay, if we know that 70 the right now is not valuable, what can we do to make it 60 percent that’s not valuable and 50%? 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 as a data team and we look at it as a cycle and we say, how much effort is there in each step and how much time do we spend between the steps, how much delay in the handoffs 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 handoff.
So actually we’re going to be a better data team regardless, right? So again, I always encourage people to work in their team, their way of working, 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 teams doing that. Yeah.
They
[00:29:22] Chris: don’t do it and they don’t, and they don’t measure it either. No one I’ve almost, I’ve never met. I’ve talked to a couple of thousand companies. No one measures their cycle time, their deployment, their back, they might measure their backlog. And, but everyone will say, it’s just really big.
[00:29:38] Shane: And we measure from picking it up from the prioritized backlog to delivery of value to the stakeholder, right? We sometimes measure that, but we’ve got to remember that stakeholders put that problem in that queue six months before that, before it even got to prioritization. So if we put, if we go back and measure, The time the customer or the stakeholder 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’ve got to do is just focus on finding things that make it shorter, Faster, safer, better. Again, data has to be accurate, right?
That’s one of the challenges we get given compared to a product team actually. So So let’s think about this idea of one template, one cat that I’ve used successfully over the last decade which is information product canvas, and it does go in multiple of those circles and that continuum, but primarily I use it on the left hand side at the discovery phase.
If somebody’s come with a problem, a business problem, they said I need some data or information. Ideally, it’s not a JIRA ticket yet, right? We don’t want to go into ticket hell. We’ve got people having a conversation with us saying I’ve got this problem. And we want to ideate and discover what that problem is and see if we can reduce the uncertainty of how we do it.
So the canvas is open source. So I think somebody asked the question. Yes, you’ll get the slides and I’ll 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’ve got we won’t go through all of them so I’ll just start with the ones that I think are 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 to that. So the first thing about the canvas is you can fill it out in any order you want. It doesn’t matter, but I have a specific way that I fill it out that has been valuable for me, right?
And I’m going to start with business questions, and then I’m going to go into actions and outcomes and move on from there. The other most important thing is, I do the, I complete the canvas with the stakeholder. 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.
That is probably the most valuable piece of the canvas. What we do is, as we’re typing 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 said with your wife, what I think I hear you saying is this, 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 that conversation was.
And typically when they do this, go, yeah, that’s good. You build it. I’ll then have a look what you built. And then I’ll tell you, It’s not what I wanted.
[00:32:53] Chris: Yeah. So it’s not worth their time. And I also think what’s good about a canvas is it’s small, like this, it’s not meant to be a canvas that you put on the wall or you 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 I think that Limitation on what you can write and putting it on one page and putting in reasonable font actually is a huge benefit because you don’t, um, you don’t spend all your time describing exactly what it is.
[00:33:25] Shane: Yeah, and we constrain, right? So again, MVP is about constraints, right? The canvas is about constraining what we’re 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 LinkedIn side of the continuum. One of the anti patterns that I see.
Lots for data people is 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 stakeholder. And there’s something weird about humans. When a human stakeholder sees the canvas in this format, somehow they find it more easier to understand, right?
Less cognition. As soon as I put a table in a Word document or JIRA they channel. 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. The first thing I ask and I’ve learnt to do this over the years, is I don’t ask them what action or outcome or the value is yet. 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 engagement. Now, often the business questions you’ll get back are quite fluffy. It might be how are we going with customers? Or, is 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, is I go back and I ask them for very specific ones. I say, I’d like questions that begin with, How many? How long, how much, what, why what Lawrence core calls the seven W’s. And once you give them that framework how many orders do we have? What customers are churning?
How many customers did we lose last month? You’ll find that your stakeholder will then rattle off three to five questions in a heartbeat. They’ll just, they’ll get that pattern and they’ll just go bing. And then they’ll stop. And what happens is as a stakeholder. You know that you’ve spent all this time getting to the priority queue, you know that you’re going to move to the right hand side to that build cycle, you know you get a one and done with the team, whether it’s a project or not, and so you’re going to rack and stack every business question you want answered, because this is your one shot at getting the data back.
And we don’t want that, we want small products that we can iterate. So as soon as they take a breath, I stop them. I say good, that’s good for now. We’re going to 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.
[00:36:26] Chris: Does that make sense? Yeah, because I guess you’re saying the temptation is they’re just going to rattle off everything they’ve ever wanted. And, yeah, and is it, is the scoping by the size of the box? Is the scoping conceptually, like, how do you draw the line? Is that
[00:36:41] Shane: We haven’t scoped yet, right?
If I see questions that are lifetime value model in my head, I know that is a massive product, right? And Agile will call it an epic, right? That’s probably a year or two to build that out. I don’t care yet, right? Because I’m trying to discover what they need. And then we’ll come back and manage scope later, right?
We may say that’s five products, and we’ll break the canvas out into five canvases. But what we’re doing there is we’re scoping and doing trade off for feasibility, right? Not for value, not for desirability, not for usability. So we want us to focus on the left hand side, right? Let’s make it easier to tell us the problem they want us to solve.
If you’re a data person and you’re doing data design, as you should, we actually start getting some really interesting hints already about a conceptual model. Ah, I’ve got this thing called an order. Yeah, I’ve done that before. I’ve already done that for another product. There’s a reusable data asset.
Ah abandon orders. Ah, actually, you know what? I know that’s in another system and we haven’t brought that in yet. I’m going to make some notes, right? So 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 in the organization as well.
So we’ve got these 3 5, 6 10, 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 did we lose last month?
And I tell you that answer. What are you going to do? What action are you going to take? And if you take that action and it’s successful, what outcome will be achieved? And so they will naturally roll on to that. They will go, oh actually, if I’ve got a bunch of customers that churned, and I can understand the churn reason, then what I’m going to go do is a save campaign.
Okay. So you’re going to go and do a safe campaign. How do you do that? And they go, Oh, I’m going to go into Salesforce and I’m going to segment the customers that are likely to churn. And I’m going to go send that out. Okay. And if that campaign was successful, what happens? Ah we retain our customers.
Okay. Do we know how many customers we’re 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 stakeholder 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 going to say 5 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. If I’ve got 10 products I could build, then this is the box that a steering committee, prioritization 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? So it
[00:39:51] Chris: makes sense. And Are these outcomes personal or organization based? It’s hey, I want to, I want to get my bonus. That’s an outcome. Or I want to or is it like my team’s trying to optimize investment in new channels?
[00:40:04] Shane: So again I as a data person that’s working in product, we should help our stakeholders be successful.
And if I see an outcome which is, I want to get my bonus, and, and it won’t be worded that way, that’s the words in there, and then I know I’ve got another product which is reducing churn for a million dollar revenue increase, I’m going to say to the stakeholder, 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 remedy.
Yeah.
[00:40:37] Shane: The other thing is sometimes you’ll just get fluffy outcomes. And at that stage, you can realize that the stakeholder hasn’t actually thought about their problem.
They’re just asking for data or they’re not articulating their problem. They’re just doing a data request, not telling them 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 that helps the organization.
So we should coach them going, okay let’s have a chat about that, right? Because I don’t see that as a strong outcome statement. Yeah. The other thing is, as data people, we love to be deterministic. So we’ll want an action and an outcome, an action and an outcome, an action and an outcome. But in reality, we’ll get a bunch of actions and a bunch of outcomes, and they are a many to many relationship, almost a graph, 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’re discovering early, we’re reducing uncertainty, we’re starting the conversation, we’re trying to figure out what’s the next most viable thing to build is.
That’s the purpose of the canvas at this stage.
[00:41:48] Chris: Okay. Yeah, that makes sense. And I think a lot of data people I find are, and I’m surprised that this are disconnected from their customers. They’re disconnected from the kind of questions, if they’re a business, should I, am I going to increase sales or cut costs?
And all the subsequent, and at some perspective, a lot of businesses are the same. They’re about, investment return growth versus risk. And, I think trying to get one of trying to get the theory of the business in your head. What is my business doing? Are we trying to expand to 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 A framework to attach what’s happening is helpful for me, and maybe that’s just the way my mind works, but I like to think from big picture in and I, I think the sort of understanding where your overall outcomes fit in the overall outcome that the organization is also, it’s helpful.
[00:42:57] Shane: Yeah. And it’s more fun, right? We’re more engaged and we’re more valuable. We’re more valued. I’m going to bag Jira and DBT here 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 that says, give 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 takers, we’re order takers, and we don’t see the value we deliver.
We’re just constantly smashed with more and more orders. We want to be on the left hand side because being in that product space is more fun. Amen. And so just imagine that you’re, we’re back in the days where we were actually in a building together and we’re in the lift and we’re with the chief executive of our organization and, he rocks in and he goes, Oh, Shane, met you before and I go yep.
And they go, what was the last valuable thing you delivered? Ah, Jira ticket 12345, I delivered a list of customers to Jane. That’s not a fun conversation, right? That’s not a valuable conversation. That’s not a product conversation. But if I go and said, ah, actually, I was working with marketing. Jane had this problem to really understand abandoned carts.
So what we did is provided some information around our abandoned cart numbers. And then what we did was Together was, we actually went out and did a notification through the e commerce store to say that we’ll give you a 10 percent discount if you finish that car. And that was automated from a data point of view, and that resulted, in a 10 percent reduction of abandoned carts and a 5 percent increase in dollar.
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, that’s why I’m so passionate about bringing these different patterns together, because it’s actually more fun.
I remember the days where we used to have BAs that used to do this on a regular basis. And then somehow we lost it. I do blame Agile ways of working a little bit, right? As we lost these ways of actually understanding the business processes, the ways of understanding the organizational outcomes, part of that.
Again, my opinion, right? Not every organization is like that, but I see it a lot. What do you see?
[00:45:33] Chris: Oh, I see an Agile product management, product owners having a huge role. In every software company I’ve been, 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 more It’s a rare engineer who can do that on their own. And 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 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?
Because 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 we’ve got 10 more minutes and there’s one question. From Carl, he said, Shane, you said the canvas isn’t for requirements.
How do you take the canvas to a requirements document?
[00:46:34] Shane: So it’s just about iteration. So what I would do is I’d use, 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. I then size it, 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 designer requirements document. 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 design, 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 there for data sync or freshness. That is, how often does the data need to be refreshed from where we found it? How up to date does it be? That becomes the requirements for our SLA or our data contract.
The delivery types, we talk about how would you like it delivered to you? Is it a file to Excel? Is it an integration with Salesforce? That becomes the box we expand out, which is the requirements of, our output board or our delivery mechanism. So each one of these boxes then gets expanded out.
Into a requirements document. If you create requirements documents, we then 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 it, I’ve forgotten what it was about.
So I can bring that canvas up and go, Oh yeah I understand the business context, the questions, the actions, the personas, what we delivered, what was in, what was out of scope. So that’s the last part is the bottom of the canvas feature stories and will won’ts. That’s where we scope our requirements.
We will deliver it from the source system. We won’t deliver it from the source system in this iteration. So that’s where we start minimum viabling or breaking that product down into smaller chunks. Hopefully that makes sense.
[00:48:34] Chris: Yeah, I don’t know. I guess I’m not a fan of requirements documents. To me, I think this is enough, and then you start working and building something.
And so if you’re skilled enough, you can, you say, okay here’s a, um, here’s a crappy schema. And it’s done. It’s here’s what I think this is. And then you put a crappy report on it and you’re like, I read this. This is what I think. And we need orders. We need this.
We need some facts, dimensions here’s. And I think of working software or working analytics over requirements. And so my feeling is, I just don’t, 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 percent right and say take a look at it.
Did I get it? And they’re like, oh no Yeah, that’s right. But like 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 yeah
[00:49:24] Shane: So i’ll just i’ll just counter that a little bit, right? So i’m unlike you my focus is around from problem statements How quickly can I get around that iteration to value?
And then how can I look through the 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. 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 you have to, 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 makes you slow. It’s stuff you have to maintain. So if you’re forced to do requirements documents, because that’s your way of working. Then just make them as light as possible, right? Just remove stuff until people start complaining or 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 be, because that’s what we should do as a data team. I think there was another question in there I saw flash up around external use of this versus internal. Is
[00:50:42] Chris: it more of this for internal teams, or could a consultancy use it as well?
[00:50:46] Shane: So I run a consultancy. Our company is a product is a service as well.
I won’t deliver anything for a customer unless 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 of what you’re going to deliver. Now, the customer you’re working with has to be comfortable that it’s an agile scope, right?
It’s fluffy, it’s not 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, I delivered a dashboard. Versus I help that organization deliver 5 percent more revenue. As an external consultant, one of those is 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.
[00:51:48] Chris: Yeah. They don’t. And they, by proxy, they don’t trust you yet, so you’ve got to work with them to gain their trust. And partly, it’s the rapid delivery of value. It’s partly listening, and it’s just, it’s what makes a good relationship. Feeding back, making sure you get it right, admitting 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 where we’ve gone from terrible relationships to great relationships by following those principles.
And I think now that we’ve got 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. Any more questions from anyone?
We have one more. Dominic, raised a hand here. So we seem to not, people seem not to be able to write in Q& A. They 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 there’s a question from Michael around. Does this work for Kimball like results or a three tier data warehouse?
Is there a tech, maybe intuiting a little bit of Michael, is this implied a technical design or not?
[00:53:17] Shane: No. So I’m a more data vault guy than I am a Kimball guy. I’m definitely a three tier data warehouse architecture guy. I’m like I said, I’ve been doing it for 30 years, so I’m old school.
So this, I can infer a conceptual or physical design from this but it’s not hard coded in there. So where I see what I call a core concept, where I see customer places order I, I talk about this patent called concepts. I see a concept of a customer, a concept of an order, a concept in a relationship or an event.
For me, customer becomes a hub and dimensional customers are dim, order becomes a 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, right? So it works on any architecture. I’ve done it with Google Analytics data for a customer, which is all horrible and nested event streaming JSON, 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 DIM, fact, data model, physical model, hub, link, set, activity schema. They don’t care, right? They want to share language, which is here’s your business problem, here’s how we’re going to 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.
[00:54:45] Chris: And Shane, how should people contact you if they want to learn more?
[00:54:49] Shane: So the easiest way is you can find me on LinkedIn if you search for Shane Gibson or Shugility.
We’ll send this link out, but the open source template is available from we’ve got a companion website to our product, which is the WoW website way of working. So if you go to that link, you’ll find the write up. On how to fill the canvas out, you’ll find the templates themselves. I run a course if you want to run a course for your teams, or I can go through and we’ll do it together and you get hands on building out a canvas as a team, so that’s there as well.
But yeah. All the canvas information is effectively open source. It’s giving it back to the community and I’m so passionate about it because it just helps teams, data teams work in a better way that I’m happy to share it without trying to make money out of it.
[00:55:31] Chris: Yeah, Shane, I think this is just excellent.
So I really thank you for taking the time to talk with us today. In, my career in data, I’ve seen a lot of ideas come from software and hit rocky shores. But I think this has got a lot of legs on it because it’s simple. It’s easy to use. You can start using it right away. There’s no tech or cost confusion, and it’s just it helps.
It’s a tool to help communication. And and I think that’s any tool that can help people. Who naturally would rather look at a screen to communicate with their customers is a good thing. So 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 you shortly.
So maybe tomorrow, maybe the next day. And thank you so much. Thanks everyone. Thank you.