Doing really well, doing really well. It has been a good conference. A lot of new ideas getting kind of mashed up here and trying to get some of these Agile principles and practices out of the IT department, so I see some glimmers of hope there.
Todd: Excellent, excellent. So before we get started, maybe just tell us a little bit about yourself.
Yeah, so I am a consultant at BigVisible Solutions, but before that actually I worked in several start-ups. During college I joined a start-up instead of going to a big company. That was very influential in my career and kind of what I get excited about. And I was actually introduced to a lot of these iterative processes early, except we were a start-up and we did not necessarily have the discipline we should have and we were kind of doing things out of panic many of times. We would not call it a pivot, but we did pivot. It’s just we did them, because we had to or we were going to die as company. And, so I learned some good practices and a lot of bad practices and this was about early 2002. And than over time I just started being able to understand things a little bit more and work now essentially bringing these ideas into big companies, very large companies like Fortune 500. So I kind of take all these start-up ideas and pull them into big companies for corporate entrepreneurship programs. So we are trying to not only help them with the delivery and doing the iterative development, but also how you test their ideas, how do you validate you know these products, how do you visualize your business model. So, it’s been kind of fun to pull that stuff up into big companies and try to figure out how to make it work.
So, start-ups, for those who haven’t been at start-ups, they can be quite dysfunctional too. I think there is this myth, that you have to be a large corporation to be soloed and not collaborating. I’ve been part of ten persons start-ups, where you had a couple of people in development and a couple of people in product and some in the middle trying to play broken game telephone and disfunction started very early. And there is also this, everyone thinks they are Steve Jobs, well now it is Elon Musk, so Elon Musk is the new Steve Jobs, and several think they are Elon Musk, they have this vision and the will it into being and they are not really receptive to data, you know. It is very much they’ll challenge data in many ways, that you wouldn’t expect. So start-ups can actually be quite frustrating too in different ways.
But the only way I thought I could enjoy going into big companies, was pulling some of these great things about start-ups, like small collaborative teams, quick feedback loops, being able to experiment your way through the unknown and thinking like, I’ll give it a shot, you know. And I think it’s the only way I can make big companies enjoyable, because let’s face it, polls and a lot of studies show that most people aren’t enjoying their careers in big companies right now, especially in the United States. So if I can impact people and help them on a personal level, but also help the company and help them become more kind of agile and flexible and it’s fun. But yeah it’s often, often you go back and forth on, is changing the world through the big companies or is changing the world through the small companies about to be big. And I think it’s a little bit of both.
So, I have seen a pattern where Agile kind of gets stuck in this IT department, where you actually have pretty highly functioning teams, but everything else around it is very big batch, slow change, doesn’t necessarily jive very well with what we are trying to do. Like the business doesn’t realize the value of having these teams. You can deliver faster, but everything else is still working the old way. So trying to pull these ideas up into product teams and into business stakeholders, into VPs, into executives and say: You know, the world is getting more uncertain and how do we actually go about testing our way through this. And at a principle level it is very similar with Agile, at a practice level we might use different practices and we might not call it Agile, but it’s very much those principles and values pulled out of IT. And I think, if you go into let’s say marketing: Yeah, we are going to do Scrum. You're usually going to get adverse reactions to that of: Oh, we heard bad stories about Scrum, maybe we don’t want to do Scrum. But if you come in and say: Hey let’s visualize you work and help you kind of work through and be a better marketing team, than they are usually pretty receptive to that. And at the principle level they are visualizing the work, helping it flow. You might not work with two weeks sprints, but maybe it’s more a Kanban kind of flow. And I try to mix and match up stuff in a way, where they see the benefit out of the ideas and the principles and the values and the branding of it is less important to me.
Todd: There is one of the big kind of ideas originally from start-up management coming into the enterprise is Lean Startup, which you mentioned in your talk today was kind of bad branding.
Yeah, it’s quirkily branded I kind of said. But yes, it reminds me in a lot of ways of Extreme Programming. In the das we were very passionate about Extreme Programing, I am still very passionate about it, it became the underpinning of everything we do underneath Scrum or engeneering practices. The software craftsmanship movement, kind of really got born out of XP, yet I don’t really see many people nowadays doing XP or calling it XP. There are those select few shops, but they kind of pride themselves and they’ve stayed with it, but if I go into a large corporation and say: Let’s do Extreme Programming - usually the response I get is: Oh, wasn’t that pair programming and died off several years ago? So the lesson is, they know this little thing, that was popular and controversial and kind of forgot about all the rest. And I'm afraid that’s going to happen with Lean Startup, but it could be a good thing in a way that it’s kind of pulled into the underpinnings of how we do product development. And maybe we don’t call it Lean Startup, because at big companies we're not a startup and we really don’t understand Lean. But some of these ideas of scientifically testing your way through business, it’s pretty sound and so I think it’s going to be there. I am not convinced it’s going to be called Lean Startup long term.
So I am really careful on how I approach transformations and executives and that. So the goal is not to do Lean or to do Agile. It’s some kind of business outcome they are trying to achieve. In general, what I hear from C-level executives in Fortune 500 companies are: We need to deliver faster and not sacrifice quality and build stuff people love. And it’s that combination that scares them. They think they can go faster with what they have, but the wheels might fall off. They are still not certain they know how to actually talk to customers and solve their problems, because that is a whole heart in itself of how you do customer interviews and do customer development. And so I try to key in on: What are you trying to achieve as a company? And than how can we help co create with you a strategy and a way and do some training and coaching to go through that and actually follow through.
So I try not to use the buzzwords when I can. Sometimes I fall into that, but I try not to. I really try to focus on like what are you trying to achieve, so some of the things like even change strategies, I use like change strategy mapping and it’s very much like a visual mind map I’ll do with executives. I’ll say ok holistically, we`re trying to get this outcome. Here are the capabilities and here are the things that support the capabilities for this outcome. This is great, where do we start and you can’t do it all once and helping them navigate that and break down the work and then manage that change, it is actually kind of fun. And we use a mix and match of different principles, but it’s very much around matching stuff to them, so they can actually achieve these business outcomes.
So it trying to test your way through the unknown in a way, that we are just open and honest about experimentation. So I view it as, we are already doing experiments, we are just not calling them experiments. A lot of our projects, some of our stories, we had some really risky assumptions and a lot of uncertainty and we just do it. But we are not really owing up to the fact that all this exists. So I’m trying to clear the air and say: Look, we have a lot of uncertainty here, let’s be honest and open about it and let’s just not assume, this is going to work and iteratively going to that goal. And so, let’s experiment our way through it. And there are all kinds of different techniques you can use through experimentation. I think some of them translate from start-ups into big companies well and others don’t and some need tweaks. So it’s very much the practices, like people getting excited about building fake doors, right, that’s something they'll latch on to.
But if I go into a company, that wants to do that and say: Ok, we're going to build a fake door. Ok, and than what. And they don’t know, they don’t know what’s next. Or they don’t even know why they build a fake door. It was fun and they had people sign up for their new business offering, but they are not sure what to do next. And the intent is, those are not your Beta users, when you go off and build your product and six months later you come back and say: Hey, you signed up, here is your product. You need to actually talk to these people. You need the qualitative feed back. And you need to actually find out whether or not they wanted your product. Why did they sign up? That’s where the real learning is and so we help companies kind of navigate that, especially big companies. Because you have to reach out the legal, you have to get ok. Do you do it on-brand, do you do it off-brand? It’s a very different way for them to launch fake businesses within an enterprise corporation to test out ideas.
6. Let’s clarify for some of our readers: What is a fake door?
Yes, so a fake door is basically, it can be simple as a one page web site with analytics baked in, that has a call to action, usually some kind of email box to collect email from the user and you’re basically selling magic. This is our product which doesn’t exist yet, but you don’t say that and here’s the experience sign up and we’ll let you know, when it's live or sign up and we’ll contact you. And so you see are people even willing to sign up? Sometimes they are, sometimes they aren’t, sometimes the customers that sign up are not the costumers you thought would sign up. So I've seen teams do great learning and I’ve seen teams do it in a way for less than like 250$ within a big company and that’s quite a cheap experiment for a large company and to do that, and experiment your way through it, I’ve seen people launch ideas, test them out and kill them within three months versus I've had them come back to me and say, you know, if we use traditional methods to do that, we would have spent a year on that building it out, only to realize, it wasn’t the right product, it didn’t solve a real problem. So, it’s getting comfortable with those techniques. So the fake door it’s just one of those.
Todd: So there’s a chance that you may do something like that and it might fail. Yes.
7. How does that impact a lot of these larger enterprise organisations?
Yes, we really have a problem with failure in large organisations and it’s both at a technical and at a cultural level. I’ve been really working on the cultural level, because I feel like with sound engineering practices we get through with testing driven development and all this automated testing, that we can have safe fail experiments from a technology point. But from a cultural point of view, it’s very much more of a challenge, because you’re trying to get past the stigma of failure equals a career limiting move, or a failure means you did something wrong, right? And we don’t focus on the learning. So, I think a lot of the really big success stories over the years that have been through companies that have lots of failures but when they hit the cover of Wired or they have a movie made about them it’s like: Oh, they had a bright idea and then they just kind of made it happen. And that’s not how it works, you know?
So the really interesting learnings I’ve seen in companies are the people that try something and they fail, but at the same time something else happens that was really interesting and they say: Well, that’s interesting let’s just go explore that and when they do, then they uncover something big that they didn’t expect. So it’s starting small and so it’s you know, I’ll work with teams that will say: You’re telling us to experiment but we’re just not going to do that. So it takes time and that’s the coaching comes in, because you don’t really solve that with a workshop, you solve that through being there for them, helping identify small safe fail experiments and getting into kind of train their intuition.
Yes, so it really start with the top and that’s why I feel what I do is really unique and that I can work with C-levels execs on down. So I’m really comfortable. It’s interesting. Executives have some of the same dysfunction of a team, that maybe a Scrum team would have. And it’s just how they interact with them and really understand them and have empathy and why are they trying, why they behave the way they do. And I think sometimes we work with executives that think that they would act in a certain way in a situation, but actually in the situation they act very differently. And so as a coach, we can reflect back and help them understand that gap. And so much of the time feedback comes up and than it kind of goes horizontal and it does not actually make it to the executive. And so what we try to do is say, objectively: Hey, let’s coach you through this. And if you are saying: Experiment! But don’t fail. That’s not exactly the right message, we want to send to the teams. So it’s being able to say: Ok, this team, they are working on a product that we think we can experiment on, that can uncover vast amounts of revenue. Let’s make sure they understand that message, let’s empower them, give them some feedback, so they can actually go through that process. So, I end up working on multiple levels in the organization to create a safe environment, so that they can actually do it.
9. Can you give us an example how you might create that safe environment?
So the example would be, you know, starting with maybe the VP of product and having me understanding their context a little better. One of the products is the core product that they don’t want to touch, although I still go after those, but maybe not right away, with other products that are more the disruptive things, or like, you know: We have this idea, we think it might work. We don’t really know. Help us experiment our way through that. And so what we’ll do is, we’ll facilitate, like let’s build up the business model for that, either with like a Business Model Canvas for example, or let’s visualize this in a Lean Canvas. But get the ideas out conceptually, what’s this model look like and let's starting designing some tests and how do we go about doing those tests.
So, it’s really working at, for that example, I work with the VP of product, but I also work with the product managers and the product owner, to make sure they are all aligned, so that we can actually have a product that we see as an ideal candidate to run experiments on. And than, of course, when they fail, they need that feedback loop: It’s ok. You only spent a sprint on this or maybe a day on this, it’s not a huge failure, you are trying to learn. So it’s having that conversation about where we point our experiments and again, it’s not an experiment on everything all at once, it’s: Here is a good candidate and here is the type of user. Let’s go after that. So it’s a lot of coaching at different levels to get them there.
Right, so I’ve been doing a lot of work around the Business Model Canvas, because I think, as I said in my talk, you can have a very strong product but the wrong business model. And you still fail, in a spectacular way, not a tiny way. And I have been really working with teams on how you fold that into the process. So, in an ideal situation, I come in, we do that at the top of the organization, what is your business model for the organization. At that level it is more strategic, their customer segment is kind of general, but as you go down the levels of the organization, then you start to say: For these products, what are your models for those? And than you start seeing, these conflict with each other, do they align with the top model, and you start to having these kind of conversations, even between marketing and product you can have conflict, where marketing says: This is our customer segment, we are running campaigns for them.
And the product team saying: This is our customer segment, we are building products for these people. And you drive all this traffic into your product and nothing converts. And it does not convert, because you are not talking with each other. You are not even aligned between those two very key parts of your organization. So it’s creating that alignment, that I find is crucial. So, not only do you need to have technically sound emergent design, test driven development, all the engineering practices and delivery practices, but if you are not even aligned cross functionally outside the team, than you are still probably building things that don’t resonate as they should. So it’s really getting that out in the open and facilitating that and than getting the transparency of you know, we may actually have a product that is generating a lot of money, but that is not the vision of the company, so: Is that ok, are we ok with that? Do we want to explore that? There is some fascinating conversations that come out of facilitating it.
The most exciting thing to me at the moment is around this idea of passionate users and I really learned this from Brant Cooper and Patrick Vlaskovits who wrote the “Lean Entrepreneur”. I have been at their workshops before the book and seen them talk several times and I’ve kind of distilled it down into just four phases: aware, hopeful, satisfied and passionate. And I think it’s a conversation we rarely have inside companies. Why are users passionate, why do they keep coming back? And how do we reduce friction in this transition to generate more passionate users? And I have been toying with that idea and than toying with metrics around it and how you design experiments around that and it’s really, really interesting. And I feel it’s a conversation that we need to have more often with our teams, because there is such an untapped potential there, with just: Let’s talk to our passionate users and understand why! And how they became passionate and can we replicate that? And that is such a great engine of growth for your company if you can tap into it. And often we are too busy building and we don’t spend enough time and it’s hard and you have to talk to them. And there is a fear of talking to the customers, even the really passionate ones. So, probably out of everything right now, that’s what has me the most excited.
I feel like a lot of work that I do is like empowering the product owners. I find time and time again, they are not empowered at all. In worst case they are just some kind of backlog monkey that’s ordering stories and they don’t have any say into the vision of the product. And that’s not really a dynamics we want to create. If we are talking about pushing decisions down into the organization, like those people that are close to the product and close to the day-to-day work, their opinions really matter and if you can work with them to understand, how to guide that product, how to make it a better product? Did we do work that got a light turned on in one customer segment, do we want to explore that? Do we even want to see if that can be part of our business model, right? So, it’s a, I think the challenge of that role is, it’s so, to do it well, it’s so intense and time consuming, that it’s tough to say: Oh, be there for the team and get out of the building and do all this customer development.
So the natural break I see, and it doesn’t mean that you necessarily have to do it this way, is having product managers do more of the customer development or pairing people up with interaction designers and going outside and talking to customers. But then working really closely with the product owner, to kind of feed that into the backlog and have a more informed backlog. So I think the challenge right now is just the bandwidth. We set this up this way, specifically Scrum, where it’s so much on the product owner, that than you say: Oh, by the way, go out and do 50 or 100 interviews, whatever that number is. It is just completely overwhelming.
So it’s the adding and it’s also the dynamic that changes in the team and helping them understand what it means. So, usually when I add it people are like: Oh, but that’s a test column! We already tested before we release the production. No, no, this is your measuring the outcomes, like there is an expected outcome from doing this work. Let’s remember to measure it. And WiP limits apply there too, so if it fills up, you need to stop, right? It’s like: Do your constraints! Why aren’t we measuring this stuff? What’s taking so long? Why aren’t we following up on it? So, eventually you are able to train the team to say: Guys look! When we release stuff, it’s for reason. It’s for outcome not output. And we need to be able to measure that in a real way and feed it back into the team. And without visualizing it, I find it kind of gets forgotten.
Or they measure it and it’s not shared. So, it’s just a nice visual indication and when it works really well, it’s when the team is starts questioning the work coming in: How are we going to validate it? And I’ve seen that happen. It’s been really cool to see the team get engaged and say: Why are we doing this? Not in a disrespectful way, but more of a: How are we going to validate this work? And if we can’t validate it, why are we doing it? And you know, there is all kind of nuances, like sometimes you can validate things quickly and sometimes it takes more time and there is some specifics there, but in a general level, it’s just really get the team to buy into the why of the work, how they are going to measure it and really focus on outcomes.
For me? Well I have been doing a lot of coaching and also workshops and events, so it’s been a nice mix, because I feel like, if I am too heavy on training than I loose that perspective of coaching and what happens when you actually try to do it inside big companies. And if I am too heavy on coaching and not enough workshops and training, than I am so involved in the coaching that I don’t get time to step back, get my ideas out of my head of what I’ve seen, assemble it in a way that kind of makes sense and than help teach people. So I feel like they inform one another. And I am also working on writing more. I am writing, I am working on a book to kind of tell a story of how to do this in a modern company. It’s very much a modern day version of “The Goal” by Eliyahu Goldratt. And the reason I am choosing that is, because case studies become outdated so quickly nowadays, especially with these new ideas. So we have very, very new ideas and there are just not the case studies there yet. I personally am terrible at putting case studies together and too busy doing work to even coordinate that, so what I want to do is tell a story – a business novel, of what I see synthesized from all these different experiences and say here is some of the common pitfalls.
It’s not a: We tried this and everything went well and we made hundreds of millions of dollars of revenue, the end. It’s: We tried this, we lost 50.000 Dollars, we couldn’t turn it off, because we couldn’t think of that and than we had to facilitate a Five-Whys to do the damage control. And than rebuild that trust and try again. So it’s kind of like a Quentin Tarantino applied to business. He had a great story of real life is when the cop is chasing somebody, they come into your car, they jump in the car and it’s a stick and they drive automatic. And that’s very much how business is and how teams are. It’s all these unexpected things that get into real life. So I wanted to do it justice and I want to be able to explain these concepts in a way that’s based on my experience and based on my coaching, but also in a: You are going to have to try and fail and learn and try again and, and oh by the way, here is how you mix this stuff together. It won’t be some kind of a linear prescriptive flow, but very much a: Here is what we see, here are the pitfalls, here is how you can avoid some of them. And this is how it is going to be difficult, but hopefully I am going to land them in a good place.
Todd: Alright, well thank you very much David.
Thank you.