Lean Startup with Aaron Eden

Episode 74

August 15, 2012




The Agile Weekly Crew and Aaron Eden discuss lean startup, customer development, innovation labs and horizon planning.

Episode Notes

Drew LeSueur, Derek Neighbors, and Roy van de Water, and Aaron Eden discuss:

Lean Startup

Customer Development

Fear of releasing

Innovation labs

Lean Startup Teams vs Lean Startup Organizations

Horizon Planning


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

Roy van de Water:  I’m Roy van de Water.

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?

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 ConBon 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?

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…

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.

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.

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 inste