Lean Startup with Aaron Eden

Drew LeSueur: Hi and welcome to another episode of Agile Weekly Podcast. I’m Drew LeSueur.

Roy vandeWater: I’m Roy vandeWater.

Derek Neighbors: I’m Derek Neighbors and with us today is Aaron Eden. How you doing, Aaron?

Aaron: Hi, I’m doing great. How are you?

Using Agile And Lean Startup Together in Customer Development

Derek: Doing good. Today, we want to talk to you about how Agile works inside of a lean startup and customer development methodologies. Aaron, first of all, tell us a little bit about yourself and then maybe talk about about these topics.

Aaron: Sure. I’m a product manager for Intuit during the day and also, director for Gangplank Tucson. My background is actually in software development. That’s a part of the reason that I’ve been drawn to lean startup so much, is that a lot of big things that people talk about are like, “Oh, my God. I built this huge thing and found out customers didn’t need it.”

As a developer I think back on all the times where that happened to me, and my goal with all of this is really to try and hopefully save some time with developers out there and actually build things that customers want.

Drew: Lean startup is something we’ve heard a lot, like the phrase “customer development.” Can you explain a little bit more about that and how that ties into lean startup in Agile?

Aaron: Customer development came earlier. Customer development was something termed by Steve Blank out at Stanford, and lean startup is basically the combination of customer development and Agile development methodologies and then sprinkled in a little bit of continuous deployment. Lean startup is those three pillars, so customer development is a piece of Lean startup.

Drew: The basic idea is ‑ am I understanding right ‑ to hand‑in‑hand with lean startup, making sure what you’re releasing is something that people actually want. Actually using customers as part of the development process.

Aaron: Yeah, either using customers as part of the development process or using rapid experimentation to try and understand the behaviors of your customers so that some of your biggest assumptions built in your product you can test out before actually even writing a line of code. You can test things with sketches and storyboards and cardboard and whatever else.

It’s all about getting scrappy and trying to prove that the customers are really going to have the behaviors you think they are before you go and build things that they may or may not need.

Derek: When it comes to that Agile methodology side, you’ve got Scrum or KanBan or typical lean type of things, how are you seeing people apply Agile methodologies to something that, a lot of times, when I look at lean startup, a lot of the work is actually not software development.

It’s exactly what you’re talking about, where you’re putting out a hypothesis, almost the design thinking. What’s the problem we’re trying to solve? How do we solve it? How do we put it out there? How do we let people give us feedback? There may not be a single line of code involved, and the feedback loop can be fairly tight to fairly big.

What are you seeing people use from Agile methodologies and apply to that part of the process, where they’re not really doing development, code?

Different Teams For Testing vs Building Ideas

Aaron: Yeah, I’ve seen teams using Agile‑esque techniques in those early phases where they’re using a lot of the design thinking techniques and small prototypes and things like that. What they tend to do in those situations is they’re very clearly putting together what the team is going to execute and building their user stories out for that, and then going and executing on that.

When they get beyond those early phases where maybe your minimum viable product goes from a storyboard that you went and put in front of customers to a landing page or something like that. Those types of experiments.

Usually what teams will do is they’ll split their “lean startup” team into two sub‑teams, one being the Agile development team that’s effectively working on building out whatever the next experiment is, while the other team is off testing the last experiment with customers and basically bringing all the things they learned from those customers back to the development team.

Then they go and do their sprint planning and basically go run their next sprint. So you’ve got half the team going and using a tweaked version to go and execute experiments and the other half of the team using very typical Agile to build.

Drew: Interesting. Also on the subject. One thing that I’ve run into is management’s fear of releasing something. You know, there’s like, something, I don’t know what it is. But a fear of change or fear of messing something up is.

Roy: Or fear of looking bad or something.

Aaron: Exactly.

Drew: They won’t release anything until it’s all done.

Roy: Ask QA and…

Overcoming Fear Of Releasing Something Not “Finished”

Drew: Right. Now that’s kind of the opposite of the lean startup idea. How do you overcome that when you’re trying to do these things?

Aaron: I run many lean startup events inside Intuit. I know about that all too well. There’s kind of a couple different angles that I tend to attack it from. Especially inside a big company, what you tend to find is that when leadership sees how quickly teams can move when they’re applying these methodologies, they realize that this way of operating is much more effective, and some of that fear goes away because they realize that they’re going to accomplish so much more. That it’s not going to be three months to go and fix that bug and that the were worried about not releasing. They see the speed as a way to mitigate some of that risk.

The other thing that I see… that by having the teams break things down into small experiments, a lot of times people, when they hear about lean startup and they hear about minimum‑viable product. What they hear in that is some crappy version of the final solution. Or some not completely polished version of the final solution that might have some bugs or issues or those kinds of things. You really have to take to heart the word viable in that acronym. Many teams end up…

If the behavior you’re trying to test is that a customer needs a certain thing, or that they really do have a certain problem. In a lot of cases you can test that without going through the final solution. The ways that you can mitigate leadership getting antsy about a half‑baked product going out, or whatever, is that those small experiments, you can leave your corporate branding off of them.

In our case, at Intuit, the legal team has actually been doing really great things. They’ve sort of given us rough guidelines that say hey, if you’re playing within this space, as long as you’re testing on less than a thousand customers or whatever it is. I don’t remember the exact number. They basically say as long as you’re within these guidelines go ahead and test away.

When you get beyond a certain scale, then that’s the point where you need to start getting legal approvals and that kind of stuff. I think there’s definitely some really positive ways to put some solid boundaries in place and support the teams in moving quickly while still keeping the corporate polish on things.

Turning An Experiment Into A Real Product

Derek: I think you bring up a great point that I’ve seen a number of really large companies do when they bring in lean startup. One of the things they tend to do is they start to create “innovation laps.” These laps are really targeted at a thousand pers… Exactly what you said right there, they’re very boxed to be experiments, not necessarily be shippable product with the brand flagship name on it, everything else.

What I see is a problem with a lot of these teams when the experiments actually go right. That the really struggle with how do they transition to turning them into real products. Meaning they kind of use this lean startup piece to get rolling, get moving, but then they get a thousand people and everybody overwhelmingly says, “Yeah, we want to see this.”

Then it becomes, “How do I turn this over to a development team that’s never seen it and they have to pick up the code base, and the support staff has to support it, and legal has to get involved, and marketing has to approve all of these things.” It just gets pulled right back into that quagmire of… it never hits the market because the corporate monster stops it in it’s tracks.

Drew: Sounds like in that case, like you were talking about passing it off to a new development team and getting whole new people involved. It sounds like that might be the wrong approach to take, from the stand point that the guys who built it and are passionate about it and have seen what success it can bring, they understand the vision. It kind of sounds like those people are the ones that need to see it through.

Now I realize that this may add a disincentive or a reason to try to sabotage your own projects so that you can continue being on the fun innovation labs rather than being the old legacy guys, but I guess I don’t really know the right answer for it. But it sounds like passing it off to completely new people doesn’t sound like it.

Then it also sounds like you don’t have to go from thousand to everyone. It could be one thousand to two thousand and slowly scope over time.

Lean Startup Teams vs Lean Startup Organizations

Derek: Yeah. I think one of the questions that I can have about that is are we taking the wrong approach, and are we creating lean startup teams instead of lean startup organizations? Meaning if we really get organizations to think more like lean startups and that they’ve got lots of groups of people all that are innovative and that are all…

Drew: Instead of they’ve all got their own marketing guy and their own financial guy.

Derek: Yeah. Can they really start to cut through the crap and really push forward? Instead, I think that what happens in these big companies is they extend a special title to a small number of people who are really excited that they get to work on something fun and new and iterate. But then they’re not actually able to bring the product to market, and it creates all sorts of problems.

I don’t know if you’re seeing that in any of the places where you’re at, Aaron. I know you’ve run a lot of lean startup machine stuff and if you’re seeing transition problems even from maybe lean startup small companies that start to grow into bigger companies. Do they start to lose that magic when they hit a certain number of employees or their product has a certain number of users?

Aaron: Right. I think there’s a couple of nuggets underneath what you guys were just talking about. Have you heard the term “Horizon Planning”…

Derek: Yeah.

Aaron: …that a lot of businesses do?

Drew: I haven’t.

Aaron: Basically your Horizon I products are your core products that make most of your money, and they’re where you focus a lot of your resources in a big company. Then Horizon II is like your teenagers. It’s those businesses that are beyond a certain point. They’re actually at the point where those businesses need to scale.

You’ve proven that you’ve got a real customer need that you’re solving and that your solution solves that problem. You’ve got people spending money on it. Now those founders and those people that were passionate about the vision and those kind of things, their skills aren’t as valuable because now you’ve got a repeatable business model that you now need to scale. You need different skills for that.

Then Horizon III would be like a startup. It’s something that’s just an idea, and you spend a small amount of resources on those until they get to Horizon II. Then you can increase that. Using that Horizon Planning methodology you can have the right people involved at the right times.

I think you guys are on the right track, which is that for those business ideas that are in that Horizon III, you’ve got to have those people that are passionate about the vision, continuing to work on it, and those kinds of things. The other nugget in what you guys were talking about is that in the events that I’ve run I actually have teams that are coming to the events with new business ideas as well as existing business projects.

As an example, I had an IT team. Their business idea was that they wanted to create this new monitoring platform. Most call centers monitor the usage of their platforms, their telephony, and their IVRs and that stuff. Monitor it from the inside. Look at how many customers are waiting in the queue and how many agents you’ve got on and all those kinds of things.

What this team had a hunch on is that if they’ve monitored from the customer side of things that they’d probably see things going on in the environment that they couldn’t see from the inside. They couldn’t convince leadership to invest the money in it. That was their idea, that’s the business that they brought to this challenge.

Applying the lean startup methodologies, if you imagine that they’re a company that’s trying to sell this monitoring platform back to the place they work and treat it like a business, what ended up happening was they executed a bunch of experiments, found exactly what was important to the leadership, and convinced an external vendor to come in and stand up this monitoring platform for a four‑day experiment.

Basically found that they could shift net promoter scores in the customer service area by one point in this small four‑day experiment, which in a big multi‑billion dollar company that one shift in that promoter has a huge impact to the business.

Derek: Absolutely.

Aaron: It’s like you said about that you need to create innovators all over the place that are applying things this way. I think that’s a perfect example of where people can take something internal, apply these same methodologies, treat it like a business, and have some really great success with it.

Drew: Great. A lot of good stuff, Aaron. Thanks a lot. Before we close do you have anything to promote? Anything you want to say?

Aaron: I’d love it if folks would check out my blog, which is AaronEden.com. Definitely come check out all the great things that are happening down here at Gangplank, Tucson.

Drew: All right. Thanks a lot. For the listeners, if you’d like to join in on the conversation, go to Facebook.com/AgileWeekly.