Starting Up #19 - Map Your Customer's Process and the Product Builds Itself

Speaker A: Starting a business is hard. Betting on yourself is hard. Do you know what else is hard? Working for someone else and jobs that you hate for incremental wages while hanging on to the hope that by age 65 you're going to be able to retire and do all the things that you wanted to do while you spend the best years of your life making someone else rich. That's hard. Welcome to Starting up the podcast where we're choosing the hard that gets us where we want to go faster so we can live life on our terms. I'm your host Jay Sensei. I am a non technical founder who bootstrapped the software company from idea to multi million dollar ARR, sold it to private equity in an eight figure exit and retired at 40. All without a coding background, without outside capital, and without leaving my day job. Each episode I'm going to be sharing the real story behind how I did it. The wins, the mistakes and the playbook that you can use to start, grow and sell a company of your own. This is starting up. Let's get into it. One of the most important meetings you might ever have as a founder is the one where you don't talk, where you put away your pitch deck, you stop selling your vision and instead you hand the marker over to your customers and say, show me how you do this today. Show me every step and tell me what frustrates you. That meeting, and if you run it the right way, will give you a near complete roadmap of exactly what to build, not based on your assumptions, but based on their reality. Last episode I introduced the voice of the customer concept. Today we're getting tactical. I'm going to show you exactly how to assemble the right team, how to set up the room, and how to run the first stage of the process that told me exactly what Campus Kaizen needed to be. Bring a notebook. You're going to want to write this down. Welcome back to Starting Up. Last episode we talked about what the voice of the customer means and why ego is probably the biggest obstacle to building products that people actually want and will pay for. So today we're going to go hands on. I'm going to walk you through the first two stages of a framework called dmaic. DMAIC M which stands for Define, Measure, analyze, Improve and Control. It's the backbone of Lean Process Improvement methodology and it's what I use to design every single product that we ever built. By the end of this episode, hopefully you will know exactly who should be in the room, how to facilitate the conversation and how to map out your customers current state processes in such a way that reveals every problem that your product needs to solve. Let's get into it. Step one, let's get the right people at the table. You know, Lean doesn't have a lot of hard rules about how big or how small your team should be. Now I've run these sessions with three or four people and I've run them with uh, maybe a dozen. The size isn't what matters here, it's the composition. And so I put together a couple guidelines that I follow and I developed over the course of time when selecting participants for our Kaizen event here. The first thing that you want is some variety. Your team that you bring to the table for this exercise really should represent as many different types of customers as possible. So you know, in my case I was selling to universities. So I wanted people from large universities, I wanted people from small universities or medium sized universities, from state funded schools, from private schools, somebody from liberal arts colleges, and maybe even somebody from community colleges. I wanted different flavors, different sizes, different structures, different budget ranges, different process variations. The reason for this is because somebody working at a UH school that has 40,000 students has very different challenges than the one that works at a school that has 2,000 students. And if you only listen to one type, basically you end up building a product that works perfectly for one type and maybe not so great for everybody else. So you want to try to capture as much variation in the customer type as you possibly can. If you're selling a product for uh, B2B, maybe you want small, medium and large size businesses. Maybe you want uh, businesses in manufacturing, businesses in sales. You want businesses that are service based. Depending on what you're trying to sell, try to figure out what are the different flavors or colors of these businesses and try to capture as many of them as you possibly can. The second thing I think is you want people who are actually willing to share the details of their work, not just highlights like the nitty gritty details. They're going to be the people that are going to be using whatever you're going to build. They're going to use those systems, they're going to interact uh, with it. And so you want people who can tell you the tools that they're using today, the systems that they're interacting with day in and day out, and the minute detailed steps of their important processes. We're also going to want to hear from them what they feel is working well and what they feel is not working well because those are going to be opportunities as well. And I think this is an important topic because not everybody is comfortable sharing. Right? Not everybody is comfortable sitting in a room, if you're lucky, and you could do this in person, or virtually sitting in a virtual room and just kind of spilling their guts about their work. Right? So it's a. You might have to dig to be able to find the right people to get to the table here. Right. Some people are kind of protective of their processes. Some people are maybe worried about looking inefficient or disorganized. Uh, so you want to try to find people who are open enough to show you how things really work and kind of tell you what they want. You also want to try to find some people who are passionate about the work that they do and are kind of excited about the opportunity to have a seat at this table. Right. Enthusiasm matters. You know, the people that care the most are going to be the ones that are going to be most vested in this particular process and want it to succeed. You know, you're. You're asking people to volunteer their time and their expertise. And so the quality of the output is directly proportional to the energy in the room. So here's a recommendation that maybe might sound a little counterintuitive. I highly, highly recommend including at least one person in the team who knows almost nothing about the work that's being done. You know, that maybe is completely, uh, new, has no idea what this process does, has no idea what these people do. Someone from outside the field, even. I call this the fresh set of eyes. Now, uh, this person needs to be outgoing enough to actually participate in the discussion, not just sit there quietly in the corner. Because the fresh set of eyes is a very, very specific skill set and is something that you want in the room. Their value is not in their expertise. It's kind of in their ignorance. And I'm going to explain what I mean here. When somebody does a job or a process or they're in their role for a long time, it's very easy for them to take things for granted. Steps that seem obvious and necessary, because that's m how we've always done it. They can't see the forest through the trees. They never often pause and question, why is something done in a particular way, or whether that step is even required at all. Because they've done it for so long. It's just kind of ingrained in them. But here's where the fresh set of eyes comes into play. The fresh set of eyes is going to ask the stupid questions. They're going to ask the questions that seem silly. They're going to ask the questions that seem obvious to the professionals in the room. They're going to be the ones that sit there after a seasoned veteran spends 15 minutes explaining their process where they are an expert and they've done it for 20 years. The fresh set of eyes is going to sit there and go, why do you do it that way? What happens if you skip that step? Has anybody tried doing it differently? Those silly questions are not going to be the questions that the experts bring up. Uh, the experts know their process. They're experts, they're proud of what they do. They're not going to stop and say, well, why do we do it this way? That's the fresh set of eyes. The fresh set of eyes that has no idea. They have no foundation. They don't do the work. They know very little about the process. They're going to be the ones asking those silly questions. And those silly questions are sometimes the most important questions that, that are asked in the entire process because they uncover assumptions, they challenge the status quo, they reveal inefficiencies that the experts have been blind to for years because it was just the way that we did things. Yeah, I've seen entire product features born from a question asked by the person in the room who knew absolutely jack shit about the work. So do not, under any circumstances, underestimate the power of just naive curiosity. Another thing about getting people to the table, the ease of assembling your team depends a lot, I think, on your relationships and your experience within the industry that you're going to be trying to sell to. It also kind of depends on how severe the need is for your product. If you're solving a problem that keeps people up at night, they're more likely to show up. They'll give you your time, they'll give you their insights, they'll give you some war stories because they kind of feel like they got a personal stake in seeing that problem get solved. So the challenge is to try to look for participants who, I guess, knowingly recognize the pain they feel, the frustration. They understand that there's inefficiency in their current processes, and they care enough to have a vested interest in trying to make those processes better. Those are going to be the people who will give you the richest, probably the most actionable feedback. Before we start actually mapping the exercise, I'm going to give you a, uh, little bit of an overview of how the full framework works so you have an idea where we're headed. You know, Lean, as I mentioned earlier, follows a process called dmaic. It's an acronym that stands for Define, Measure, Analyze, Improve and Control. Think of this as a logical five step flow for taking any process from usually a pretty inefficient current state and really transforming it into an ideal or more ideal future state that is a lot more efficient. The define stage. Define is where we map out how things work today. We call this the current reality. We call this the current state. Measure is where we're going to take data on specific process steps, sometimes how long they take or how many errors occur, uh, or how many outputs are produced. This stage is, it could be optional depending on your goals. You know, if you were doing this in a manufacturing facility, you'd want to know how long does a step take? How many widgets does this produce? Right. You may not measure everything in every, every process step, but, but it's an important part of the process to understand. Analyze is the third phase. This is personally my favorite step. And the analyze phase is where we actually identify the waste and the problems within the current process. This is where things can get, get awfully interesting. The improve phase is great because we can wave our magic wands and we can design the ideal future state. Kind of the process of your dreams. This is where your product features come in. Control is where we also build in safeguards. Improving a process is great, but what tends to happen is if you don't have controls in place, people will fall back to the old way because it's comfortable. So the control phase is where we actually build in safeguards to make sure that the process stays on track and doesn't go back and revert to the old way. Each stage really builds on the one before it. You can't really analyze waste until you've defined the current state. You can't design improvements until you've identified the problems. It is intentionally designed to be sequential and a very disciplined process. And it works tremendously. But there are a few ground rules that I set at the beginning of every session. I call this a Kaizen session. Well, I don't call it that. Lean calls it that. There are no ranks. All right? One person equals one vote. It doesn't matter if you have the president in the room and the janitor. The president's opinion does, uh, not outweigh the janitor or quite frankly anybody else in the meeting. So it's important to set the framework that one voice, one vote, everyone's output is equal, all questions are good questions. Nobody, uh, should feel embarrassed about Asking something that maybe seems obvious. And ideally, if you have a, your fresh set of eyes, person is a bit outgoing and doesn't take things personally, that's even better because they're going to ask the dumb questions or what some people think are the dumb questions and they're not going to feel bad about it. The process is just, it is what it is. That's kind of the mantra for the current state process. You know, when we're mapping the current state, we're not judging it, we're not trying to fix it at that juncture, we're not identifying waste, we are just documenting it exactly as it is today. It is what it is, no right or wrong. And finally, it's important to uh, avoid assumptions. If you're not sure about something, say it. Don't fill in the gaps with uh, guesses. The defined stage is where most of the initial magic happens. And it starts with one simple exercise. Just getting your team to describe step by step how their current process works. Going to take you through an example and how I run this. My preference is always to do this in person, right? It's not always possible if you've got a team that's spread around the country. It's not always economically, uh, or logistically feasible to get people together in the same room and do this. You know, sometimes you can do it online. It's not as easy in my opinion, but my preference is to do it in person. And when I do it in person, I tape a sometimes 8 to 10 foot long brown sheet of paper on the wall. We call it a brown paper because it's brown paper 6 to 10ft long, sometimes longer depending on the process complexity. You can always add more. The paper stays up for the entire session and it serves as kind of our, our uh, working canvas. Then I start to put up post it notes in various colors. Each color generally represents something different process steps. In one color, maybe yellow decision points in another like blue, deliverables in another like green. And I write every single step down on its own sticky note and I place it on the brown paper in the order of the process flow. Why not just write on the brown paper? Have you ever tried moving Sharpie? Processes are never described perfectly the first time. Somebody is always going to be eight steps in and say, ah, I forgot a step. Oh, what about this? Oh, uh, well we have a decision point there. Somebody's going to realize that step three actually comes after step five. Somebody's going to remember a sub process that branches off at step seven, sticky notes you pull them off and you move them Sharpie on paper, you can't. It's often sometimes beneficial to use a concept called a swim lane. All right? When a process involves multiple people or multiple departments that each do different steps, it's often beneficial to break things up in what's called a swim lane. These are basically like horizontal lines drawn across the paper, like kind of like lanes in a swimming pool. If you've ever watched an Olympic swimming race, they all have their own lane. Each lane represents a different person, or sometimes it's by, uh, department, it represents a different department. And so when a process step happens in someone's lane, the sticky note goes into that lane. I want to know what the marketing department does. I want to know what the um, HR department does. I want to know what this department does. You know, if you've got a process that crosses different departments or different people, it helps things stay organized if you understand which department is responsible for which particular task. So you know, when the work passes to somebody else, the sticky note moves to the other lane. This helps you kind of immediately visualize something that's kind of hard to see. Handoffs. Every time the work passes from one person to another, there's an opportunity for delay or miscommunication or error or maybe a missed handoff altogether. Swim lanes make those handoffs visible. You know, for virtual sessions, it's not always easy to get everybody in the same room. You can use things like Microsoft, uh, Visio, you can use Canva. There's other process map designer tools online. Some are free, some you got to pay for. But the point is the concept is always the same. It's really the medium that you use that might change depending on your in person or um, virtual. During this exercise though, my role is clear. You know, I am the facilitator and the observer. My job is to listen, to take notes, to document the process and also to ask clarifying questions. My role is also to keep the team on task when conversations start to deviate or wander. You know, if you get people in, ah, in a room at some point in time, people are going to go off on a tangent. You got to reel them back in. You only have a certain amount of time. You got to get through a lot of content here. You got to get through a lot of information. It's important to have a strong willed person to be able to keep people on task. The role of the team members is also pretty clear. Their job is to explain their work processes in as much detail as possible, step by Step from the very beginning of the process to the very end, and any decision points here in and here out. So here's the critical rule for this stage. You know, we are not talking about problems or improvements yet, right? If your team members start to get into trying to think about solutions or talking about their problems, you got to stop them. You got to save that stuff for the next phases, right? We're only talking about the define, which is it is what it is. The process could be terrible, it could be great. It is what it is. Our job in the define phase is just to map it exactly as it is, good, bad or indifferent. We're not going to map what it looks like in the future, what we want it to look like, what we wished it looked like, just what it is. The process is what it is. This, uh, having discipline to do this is important because if you start critiquing the process before you've even fully mapped it, you're going to end up with an incomplete picture. People are going to skip steps they're embarrassed about, they're going to gloss over things that maybe they think are wrong, and they're going to miss information that's critical for the analysis stage. So you just got to keep them on tack. You got to document without judgment, every single step, every handoff, every decision, every document that gets passed, every system that gets used so that by the end of the exercise, you have a very, very detailed base bird's eye view of the entire process from start to finish. Decision trees, process roles all laid out. This is your current state map. And it's going to be the foundation that everything else gets built on. I've got to emphasize the value here. It isn't just the map itself, it's the conversations that happen while you're creating it. Uh, as the team members are describing their processes, they are naturally going to start revealing different insights. Like, we do this step because five years ago there was a problem with abc or this handoff always takes longer than it should because, or, you know, I've always wondered why we do this manually when we could probably have a system for that. You know, these insights aren't formally part of the defined stage, but they're gold. You're going to hang on to them, you're going to write them down, you're going to put them in what we call the parking lot, and they're going to feed directly into the next stages, which we're going to cover in the next episode, which will be the analyze phase, the second stage of dmaic. Is measurement or measure. This is where usually you take data on the process steps that you just mapped. So if you're analyzing a process where speed or efficiency matters, this is where you're going to measure how long every step takes, how many outputs are produced from every step, how many errors happen and whatever else is important metric for you to use to, you know, whatever metric you're trying to improve, this is where you start to measure it. And we'll. I like to use a simple analogy. Let's say you're trying to improve the process of making toast. If you go on YouTube and uh, search uh, Kaizen Toast, you're going to find this super old video. Um, but I've shown it in every lean training that I've ever held and you know, shown to me in my own lean training where it really goes through the process of making toast. Something so simple right in the measurement stage, you would time how long it takes to open the bread bag, how long it takes to put the bread in the toaster, how long the toaster takes to toast the bread, how many steps are between the fridge and the toaster and wherever you keep the bread, how much butter is used, how many steps do you physically walk from every point in your kitchen to, to achieve the goal of making toast? It's a good video. It illustrates waste so simply. And so I'll put a link to uh, to Kaizen Toast in the uh, in the, the comments section here. You can check it out, tell me what you think. The point is though, that each data point gives you a baseline and you cannot improve what you cannot measure. But uh, and I think this is important, the measurement stage, it can be skipped if speed or efficiency really isn't your primary focus. In my experience building platforms and software products for Campus Kaizen, my clients needed tools that made their jobs easier, that kept their jobs in one place. They needed better workflows, they needed more intuitive interfaces and they needed more comprehensive data. They weren't so laser focused on doing things faster. They just wanted to do things better. And so measurements wasn't always a step. That was included in my DMAIC processes for a lot of my products. And that was fine, didn't really need it. But the key is knowing what your customers care about, what they value. Uh, is it speed? Is it usability, is it compliance, is it features, is it accuracy? Um, and this is where your voice of the customer conversations, they're going to reveal the answer for you and that answer is really going to determine for you whether or not you even need the measurement stage or whether you can move right from define to analysis. So you know, you don't need to necessarily spend the time measuring things that your customers don't care about. Just measure what matters to them. Next episode, we're getting into the good stuff, the analyze stage. We're going to take our current state map. We're going to cover it with red sticky notes. Red is for problems, by the way. Every problem, every frustration, every form of waste is going to get identified and documented. I'm going to also teach you the eight forms of waste from Lean Methodology. And I'm going to show you how to train your eyes to see inefficiency everywhere. This is where your product features are going to start to emerge. You won't want to miss it. If you're getting value from starting up, uh, please subscribe. New episodes will air every Monday. The complete playbook will be in my book. Starting up subscribers are going to get early access. That's it for today. As always, I'm, um, Jay Scentsy. Keep starting up.