May 9, 2013

8 things I learned at RailsConf 2013

Posted by Arin under User Group Reports | Tags: , , , |
Comments Off 

Portland OregonLast week I was in Portland Oregon for RailsConf 2013.  Portland is a great city with beautiful views of mountains that us East Coasters dream of, unusually good weather (last week anyways), and a very entertaining soccer team.  But none of that is why I spent a week and some long flights going there.  Here are eight takeaways I had from RailsConf…

1. Real Time Rails takes a step forward

Brian Cardarella demo’d how Rails 4 makes it easier to write real time apps in Rails that were previously better done in something like nodejs.  Brian’s slides are here, but most of his talk was a demo so the slides don’t do it justice.  For a hint of how this is done in Rails 4 you could also check out this blog post from Tender Loving.  To see how you can do similar things now before Rails 4, try out this blog post by Liam Kaufman.

2. Hiring Volatiles and Stables – So Happy Together?

On Monday night, Michael Lopp gave the evening keynote.  My takeaway from his entertaining (if rambling) talk was about how to build a successful but still innovative company, you need to balance the conflicting desires of very innovative-but-difficult-to-manage developers (the Volatiles) and those very reliable-but-not-very-creative developers that drift to more established companies RailsConf Exhibit Hall(the Stables).  As AgilityFeat grows, I can start to see this tension coming into play.  While this was not a technical talk or specific to Rails, there were some very good nuggets for where I am at right now.

3. Snappy Apps take advantage of asynchronous workers

David Kapp from coshx labs gave a very good overview of how to use asynchronous workers in rails, and it reminded me to remind myself to use them more often.  He listed these candidates for aynch calls:

  • call external apis, especially slow ones
  • number crunching
  • document generation
  • image or video manipulation
  • sending email
  • payment processing
  • geolocation

David was using Resque in his example, but other frameworks would work well too.  He suggested starting with 2 or 3 worker threads initially and then monitoring the workload, make sure things are not being queued faster than they can be processed.

4. Split Testing in Rails

RailsConf sessions were packed!Bryan Woods talked about how to do split testing using Rails, and introduced an open source frame called Experimental that has come out of his teams’ work.  They built this framework after realizing that doing simple splitting techniques like odd/even user id’s was not working well for users.  For example, they realized they typically gave all the changes to even numbered users, and so those user saw lots of changes all the time, making them look bad as a company.  The odd numbered users always saw stability and never a change.

Experimental allows them to bucket users and put them in specific experiments easier to ensure a better experience for everyone.

5. WTF is the deal with PRY?

Conrad Irwin gave a great tour of PRY, which is an alternative to the ruby console tool IRB.  It allows you to do all sorts of cool things like “ls” commands to see the methods on a class, code documentation, and the very entertaining “wtf?” command that shows part of the trace resulting from the most recent command.  Very useful stuff for debugging.

6. Datomic and “newSQL”

If you are tired of noSQL vs SQL debates, then you can take comfort in a third option:  what Yoko Harada called “newSQL.”  Yoko showed how the diametric gem will give ActiveRecord-like model functionality in Ruby on top of a Datomic data store.  Datomic’s “fact based” database is supposed to be very good for large-read database needs and also has a sense of time built into it that makes it easy to roll back data and look at what it was previously.

7. BDD for iOS? Yes you can with RubyMotion!

2013-05-02_07-02-15_34Brian Sam-Bodden showed us how to use MacBacon to do behavior driven development of an iOS app using Ruby Motion.  BDD is not something you normally see on iOS apps, and while RubyMotion is not appropriate for all mobile development it can be a very useful way to bridge the gap to mobile development for Rails developers.  Especially if you don’t want to give up your RSpec ways.

8. Running with Rails coders

The best things at conferences usually happen outside the sessions.  RailsConf is no exception.  Going to the Portland Timbers soccer game was great, but perhaps even better was taking the initiative to go running with some Rails coders.  Darin Swanson kindly organized two runs during the week.  One was a riverside run in downtown Portland and the second was a mountain top trail run near the Portland Zoo.  I ran a little farther on those runs than I typically do, because I was inspired by the scenery as well as the example set by those marathon coders I was running with.  It as a very friendly group and a real highlight of the trip –thank you to everyone I met along the way at RailsConf!

 

January 16, 2013

Lean Entrepreneurs, Surfing, and Costa Rica

Posted by Arin under Lean Startup, Startups | Tags: , , , , , , |
Comments Off 

“Wave coming, wave coming … paddle! paddle! paddle! Now stand up! Stand up! GET UP!”

I can still hear the voice of my surf instructor, and those lessons provide a great parallel to the growth of my company and yours.

Surfing and Startups in Costa Rica

photos 058Last week I spent an amazing week with the AgilityFeat development team in Costa Rica. We had almost our whole team of designers, developers, and company leadership together in Tamarindo for a few days at the Tamarindo Diria resort on the Pacific Coast. We called this company event DareToBeLean.

While there, we had three goals:

1. To learn about lean startups and how to be a better entrepreneur from Patrick Vlaskovits, co-author of “The Lean Entrepreneur”.
2. To learn from each other on our team about how to be a better agile software development company, and the lessons we have learned from our clients over the last year and a half of doing nearshore development in Costa Rica for US clients.
3. To celebrate our successes over the last year, and have some fun surfing and snorkeling.

Learning from the Lean Entrepreneur

tlecoverWe learned a lot from each other, and had some epiphanies as a team during these few days together in the sun. I’ll blog about many of them over the coming months, but for now I want to focus on the first day of our workshop, which was led by guest speaker Patrick Vlaskovits.

We brought Patrick down from California to work with our team, and for him to share what he has learned from his own experiences as a successful entrepreneur, as well as from the many great entrepreneurs he and co-author Brant Cooper interviewed for their upcoming book the Lean Entrepreneur. It’s a great book coming out in February, and I highly recommend you get it. In fact, if you are one of the first 10 people who read this blog post, and email me at Arin@AgilityFeat.com, then I will give you a digital copy of the book for free.

Customer Segmentation and Passionate Customers

Patrick shared many great things with us, but the one that struck a chord the most was his discussions and exercises around customer segmentation.

That phrase customer segmentation may sound like traditional business plan terminology, but Patrick teaches it in a way that is incredibly powerful, iterative, and lean.

Who are your customers? Traditional segmentation tells consumer companies to think about their customers’ age brackets, gender, and other easily identifiable characteristics. But Patrick taught us to walk through a cycle of how our customer uses our product, and how we can make them truly passionate.

The lifecycle of a passionate customer

IMG_3393Brant and Patrick have a lifecycle that I’ll quickly summarize here:

1. Aware – Customers become aware of your business from an ad or from a friend
2. Intrigued – Something about your pitch catches their interest, and they are intrigued to learn more.
3. Convinced – They are convinced that you can do what you say
4. Trusting – They trust you enough to give you some information about them, sign up for an email list or free trial
5. Hopeful – They begin to use your product and are hopeful that it will solve their problem
6. Satisfied – Your product works as expected, and they are satisfied because you have solved their problem.
7. Passionate – You go the extra mile, or your product causes some unexpectedly great result when solving their problem. Now they become an advocate for you and actively tell others about your product.

Building customer segments

photos 176Patrick and Brant go into more depth about this in the book and in their workshops, but basically what we did was brainstorm some customer segments, give them a simple persona, and then walk through how each segment became aware of our product, intrigued, converted to becoming a hopeful customer, a satisfied customer, and then eventually so passionate about what we do that they help bring us additional customers.

Walking through this flow can help a startup consider the overall design of their product, as well as the most important parts of the web site or mobile app to build first. It also helps you consider how that flow might be different for your different customer segments.


Anti-segments: You were not made for each other

In the process of this, you should also remember to spend time focusing on anti-segments. These are groups of potential customers that look like your regular customers, and share many of the same characteristics. But as Patrick explained, “in reality, they don’t want you and you don’t want them.“

For example, Patrick told the story about an entrepreneur building a mobile app that helps fresh seafood restaurants price their menu for daily catch items. It turned out there was a whole segment of family run restaurants where the owner was doing this as their semi-retirement job, and they weren’t concerned enough about profits to want this entrepreneur’s app. Sure, there was big potential in the size of that market segment, but it wasn’t worth trying to sell to them. Those restaurants want to turn a profit of course, but they are not so focused on maximizing that profit that they saw value in this extra technology. This is a good example of an anti-segment, which you need to plan to ignore in the development of your product.


Learning to Fall

photos 138When I was learning to surf last week, the instructors taught me more than just how to get up on the board. They also taught me how to fall down. Because the wind or a wave might catch your board, when you fall off the board, you need to stay underwater for a few seconds, let the board fall, and then come out of the water with your hands covering your head. This is important, because one time I fell and then sprang right back out of the water without covering my head, and there was a loud klunk as the board hit me on the head. It hurt.

I’m a big guy, and I don’t think my first instructor Miguel was convinced I could learn to surf. At one point, I was laying on the board as he picked out a wave for me. Miguel said “You’re going to come back and try again, right? You’re not going to give up?”

I was a little surprised by the question, because I didn’t realize I was doing that bad. I had not stood up on the board yet, but I felt I was close, and I had no intention of giving up. I said “of course!” to Miguel, and sure enough, I stood up for the first time on one of the next waves. Miguel was pumping his fist in the air and celebrating even more than I was.

When I was learning to surf, I was prepared to fall more than I stood up. With each fall, my instructors would offer a tip, and I would try to improve my technique and find something that worked for me. Eventually I got it and I caught quite a few waves.


Iterating on your Customer Segments

Your market segmentation should be approached in the same way. What looks good on paper may not work out in the real world. Like any lean startup technique, Patrick was teaching us to iterate. Determine your customer segments and anti-segments. Imagine how those customers approach your product lifecycle, and design experiments to test your assumptions and iterate on your understanding of your customer segments.

I’ve still got a lot to learn about surfing, and I need to iterate on my technique more before I can stand up on the board every time, learn to turn gracefully, and look good for the camera. The same is true for customer segmentation and building a lean startup, but Patrick gave all of us at AgilityFeat another set of great tools last week.

 

January 4, 2013

How Change.org fit Agile Engineering in with Lean Startups

Posted by Arin under Lean Startup, Startups | Tags: , , , , , , , , , , , , |
Comments Off 

How do you convince engineers that it’s okay to build quick experiments, and deploy code that you will probably throw away? How do you convince rigorous engineers that it’s actually more efficient to work in a lean startup style?

That is a topic that Sam McAfee from Change.org addressed during a panel at the LeanStartupConference last December in San Francisco.

A little bit about Change.org

Screen Shot 2013-01-04 at 3.31.27 PMChange.org is “the world’s petition platform”, and a very cool social activism site where you can start petitions about issues you care about. These aren’t just petitions about your neighbor’s annoying cats, many of these petitions are about real life changing events on a global scale.

For instance, right now there are petitions highlighted on change.org to fight corrective rape in South Africa, to end driving license corruption in India, to allow women to drive in Saudi Arabia, and many more issues. Many of these petitions actually effect the change they are asking for, and Change.org marks those as “won.”

Sam McAfee’s journey to Lean

Screen Shot 2013-01-04 at 3.48.50 PMSam is director of Web Engineering at Change.org, and I appreciate how generous he was with his time. Sam and I talked more about the issues that he discussed on the engineering panel at the Lean Startup Conference, and we started with talking about his journey to the world or agile and lean startups.

Sam got into software development at the tail end of the dot com boom. He was first exposed to agile around 2002 or 2003. At the time he was building a consulting company and stumbled on Kent Beck and Martin Fowler, and was inspired to incorporate their eXtreme Programming (XP) techniques into his consulting company.

The methods of XP are great, and things like Test Driven Development and Pair Programming are a great way to become more agile. But in Sam’s experience, it’s easy to get lost in the mechanics of those practices but still lose sight of your core goals. The practices by themselves don’t automatically make you “agile”, and it took Sam a while to really grasp that. So far Sam’s story is very similar to my own, and so this was really ringing true to me.

The lean movement got it’s start more in overall business process design and some higher level concepts, and Sam started reading Mary and Tom Poppendieck and getting more exposed to the lean movement. The intersection of agile and lean was originally presented to him as “agile for the project and lean for the enterprise”. So Sam read all he could, going all the way back to reading about Deming’s process improvement work in the post WWII era. Reading Deming really helped him solidify his understanding of the goals that agile has.

As you can imagine by now, Sam is really jazzed about the increasing overlap of the lean and agile worlds.

Combining Lean Startup and Agile Engineering at Change.org

Screen Shot 2013-01-04 at 3.31.52 PMPrior to joining Change.org, Sam had already read Eric Ries’ book on Lean Startups. The team at Change.org was already embracing the “Build Measure Learn” loop, but getting a little lost in the practices. They were also using scrum, but it was only marginally successful. Estimation was all over the place, and stories were not always finished. They were starting to deploy regularly manually, but it wasn’t automated yet. Ultimately they decided that Scrum was holding them back.

Sam reached out to Eric Ries, and asked him to get on the phone and chit chat about how Change.org was applying lean startup ideas. They decided to start separating the work at Change.org into two broad areas: 1) work on well known domains, and 2) more unknown areas where Minimum Viable Products (MVPs) would be helpful.

Coding to learn

How do you get rigorous agile TDD engineers to think like Lean Startupers? For Sam, it required convincing engineers that sometimes code has the sole purpose of learning a thing rather than doing a thing. Crossing this mental block means it’s okay to throw that code away and not be too strict about how you code it.

Here are a few challenges that Sam and Change.org ran into initially:

  • The team had code quality very high in mind, which is great for a known problem. But when building a new business, it gets in the way of testing ideas.
  • You might not keep experiments or A/B tests – there’s at least a 50% chance that you won’t keep the code.
  • Engineers were aghast at the waste of a lean startup process initially.
  • They were afraid that quick & dirty code would get integrated with the rest of the app and left there as technical debt.
  • The team initially struggled to modularize the experiments, and send user segments to the experiments
  • Business stakeholders had to understand that even successful tests still need to be re-engineered

It took patience and some architectural changes, but now the team is pretty accomplished at running frequent lean experiments before they invest a lot of time in new ideas for Change.org.

Most of the experiments are a couple days to a week in length. They are integrated into the scrum sprints but not in a real formal way, and the experiments are not bound by the time box of the sprint. Product Owners have to indicate if a user story is related to an experiment or a permanent change on the site.

From the customers’ perspective, the features on the site just gradually change for users. There are no “big bang” releases or big announcements.

On the tech side, Change.org runs a Rails stack. Their Continuous Integration (CI) system is custom designed for their needs. The team can spin up AWS server instances to run tests on production type environments.

Code deploys happen multiple times a day with small clusters of features in them. These deployments are not fully automated yet, but the team continues to iterate towards that.

Automated testing is important for an environment that changes this frequently, and so the team writes RSpec and Cucumber tests at various levels of the system. Tests have to run parallelized now because the test suite is pretty large.

Closing thoughts

Lean Startups help tie together business and engineering concerns. This is a key point to Sam, and one of the big benefits. It makes it easier to show that every decision you make is ultimately an economic decision. Will this change help us achieve some goal with our customers or not? No tool should be purchased or software developed until you have proven it’s benefit in advance with lean experiments.

Engineers understandably want to wait to delay all code deployments until everything is perfect. And while it may feel dirty to deploy code that you know is not perfect, and doesn’t have fully automated tests around it, you need to make a distinction between code that is intended to be permanent, and code that is a temporary experiment.

As Sam pointed out, even Kent Beck says it’s ok to write some code without TDD. The agile engineering practices are good, but you have to understand the intent.

The lesson I am drawing from Change.org is that if you can draw a clear line between experiments and permanent code, build an architecture that allows you to run experiments easily, and attend to the cultural concerns of engineers and the business, then you too can balance rigorous agile engineering with highly efficient and dynamic lean startup software development.

 

January 3, 2013

Video of “Just Deploy It!” from #LeanStartup Conference

Posted by Arin under Lean Startup, Startups, User Group Reports | Tags: , , , , , , , , |
Comments Off 

The Ignite talks at the Lean Startup Conference in San Francisco in December were a lot of fun, both as an attendee and as a speaker.  Below is the video of my talk on “Just Deploy It!”.

http://www.youtube.com/watch?v=SEsk8Nfwfck

In my talk, I focused on 5 anti-patterns that I see regularly in companies who are not deploying software quickly enough.  Here’s a quick summary of the points.

1) Avoid Release Plans

If you are planning your releases for the next two quarters, you are wasting your time.  Don’t do that. Release plans are for big inefficient companies, but startups have way too much volatility for this to be useful.

2) Don’t do Big Bang deployments

If you are deploying a bunch of new features, bug fixes, pricing changes, marketing changes, or more, all together, how do you know what caused the problem if customer conversion rates go down?  You need to do lots of specific and small releases so you can correlate them to user behavior and know exactly what they like and don’t like.

3) Logins and Admins are low priority

Too many teams first focus on the user administration parts of a project, but this is the least valuable thing you could start a project with.  Find some more valuable feature that you can run an experiment on first with your customers.

4) Delay Load Testing

Don’t spend a lot of time load testing features that you don’t even know yet if customers will like.  You are unlikely to have a big rush of new customers on day one.

5) Kill the Betas

Stop using the term beta, and thinking in terms of betas.  Treat every day like it’s a beta of some small feature you are working on.  Betas just encourage risky big bang releases.

So stop trying to do so much at once, release more often, and just deploy it!

 

December 28, 2012

A #leanstartup and #agile tour of @Twilio

Posted by Arin under Agile, Lean Startup, Startups | Tags: , , , , , , , , , , |
Comments Off 

Who’s ever heard of a telecom lean startup? That’s sort of what Twilio is, and it’s a pretty cool company and interesting case study.

When I attended the LeanStartup.co conference in San Francisco recently, one of the parts I was most excited about was the tour of area companies. The first tour that I did was at Twilio, and it was very interesting from a lean startup and an agile engineering perspective.

What exactly is Twilio?

Screen Shot 2012-12-26 at 1.17.26 PMTwilio.com tells you that they “bring voice and messaging to your mobile applications.” They have built a great API that developers can use to quickly and easily provision new phone numbers, and build in voice and text messaging automation to your applications. That’s even cooler than it may sound, and if you setup a trial account with them then Twilio will quickly give you a new phone number and guide you through a short tutorial. In less than 15 minutes, I had setup a customer voice mail message on my new phone number, send myself text messages from that number, and setup auto return text messages from that phone number. All of this was done using extremely simple code that they gave me.

Twilio’s guided tour of their features is probably the best I’ve ever seen. I got a quick sense of their capabilities in a very short tour, and I was impressed with how simple they made it look. They have taken an intimidating topic, broken through the learning curve barrier, and got me hooked. Within ten minutes later I was asking their sales team if they have any phone numbers available in Central America since that is where I do a lot of business. I’ve got ideas brewing for how to use Twilio!

Cool office? Check.

2012-12-04_09-09-41_359Talk about Twilio has been trending in the development community for a while now, so I was excited to see their office and meet some folks. Their office feels like a startup. They have the obligatory indoor bike racks, big monitors, and open room feel.

The desks are all handmade by the team members out of doors and cheap lumber. They started out with a lean budget for office furniture and see no reason to change it. It actually looks good, and beats the used-door desk I had in college. The conference rooms are all named after famous technical people who have inspired them, like Steve Wozniak or Hedy Lamarr (an Austrian actress and scientist who invented frequency hopping).

We sat down at large tables (hand made of course) in the kitchen area. Joel Franusic (@jf) is a developer evangelist and gave us a great demo.  Then Kyle Conroy (@kyle_conroy) talked about engineering at Twilio.  Kyle is a former intern at Twilio who is now a developer there.

2012-12-04_09-57-30_437They gave us a great tour of the API, similar to what you’ll see on the website. Joel was getting our phone numbers from people on the tour, and sending us text messages from his console in seconds. It was an impressive taunting of the demo-gods, but it went flawlessly and Twilio has a lot of confidence in their API. It’s the keystone of their business.

Agile Engineering? Check.

How do you develop that much confidence in your software? I asked about agile engineering techniques like test automation, and how they use QA teams. Kyle’s answers were very interesting. Twilio has no QA department, and no testers. They preach code ownership and so the developers are responsible for all testing before it goes to production.

They do lots of automated testing, and those tests run regularly under Continuous Integration servers so that they know how stable the main branch of the code is. They have tried Cucumber, which is one of my favorite tools for automated acceptance testing. For them though, Cucumber was too verbose. They are mainly testing an API, and they felt that the “Given/When/Then” syntax was simply too cumbersome.

I can see where that would be the case. One of the big benefits I think of Cucumber is how it gives you “plain English” executable tests that you can show to your customers. However, in Twilio’s case, everyone understands the technical talk, because serving developers is everything to them. So the extra verbosity of Cucumber is not worth it.

The development process is automated at Twilio so that they can do frequent deployments whenever the developers have small changes ready.

Applying Lean Startup stuff? Yeah, pretty much.

Those of us on the tour also asked Kyle and Joel about their application of lean startup methodologies to their business model. Twilio didn’t start out applying those concepts, but they have done more of it over time.

They pointed out that they suffered some in the past because they had not applied lean startup methodologies or customer development. They spent a long time building a new product called Twilio Connect because they were sure they knew what developers wanted. After investing a lot of time, it was not received well when they launched it.

How long should your betas be? Although I’m not fond of the term beta, Twilio has found that they have to be careful about making too frequent changes to an API. Developers expect you to maintain reverse compatibility, and you can’t change the API all the time or you will break companies’ production code and alienate customers. It’s not as simple as a UI driven company where you have much more freedom to change the look and feel of your website, or make constant small tweaks to the user interface.

2012-12-04_09-04-52_718So Twilio has found that long beta cycles work well for them. This gives developers a long lead time to start testing with the new features. Twilio tries to communicate clearly that the code is not ready for prime time yet, and so they have the freedom to change the new API calls significantly during the beta period based on feedback from early adopters. This allows them to get very valuable feedback early on from developers, without jeopardizing the stability of the official API.

Once they have a solid understanding of what the development community wants in the new features, then they can publish them into the official production version of the API.

Metrics? Check and Double-check!

One final conversation that came up is very important to those of us interested in the application of metrics to lean startups. Twilio originally did a lot of funnel analysis to get more people signed up for the service. But they realized that they were over-optimizing the sign up process, and the use of their API and customer retention was bad. In other words, they were getting more people to sign up, but they were the wrong kind of people. Some people thought they were signing up for a consumer focused VOIP solution, not a development API.

Twilio had to tweak their metrics to focus on what really matters to them: use of their API. Lower sign up conversion rates are acceptable if it means that the people who do sign up are actually using the API more. Metrics matter a lot in lean startups, but make sure you are focused on the metrics that actually matter to your core business model.

Go check ‘em out…

Screen Shot 2012-12-26 at 1.24.27 PM

By the time I finished this blog post, their sales team had already got back in touch with me. That’s pretty great for the day after Christmas as I was writing this. While it turns out they don’t have phone coverage in Costa Rica yet like I hoped, there is still so much cool stuff to play with that I will have to make some more time for fun holiday hacking with Twilio. You should too!

 

December 17, 2012

A few links from the #LeanStartup Conference

Posted by Arin under Lean Startup | Tags: , |
1 Comment 

2012-12-03_11-28-15_593The LeanStartup.co conference was great, and internally at AgilityFeat we are still incorporating some of the lessons that our team learned by participating in the conference. As a bookmark to myself, and perhaps useful to you too, I’m listing below some of the links that I made note of during the conference. This is an incomplete list of things that I want to follow up on and go read more about.

A post by Ash Maurya on Innovation Accounting (probably the toughest topic in the Lean Startup movement and the least understood or applied):
http://spark59.com/innovation-accounting

LitMotors gave a great talk about how they have applied Lean Startup concepts in designing an electric motocycle. I’m just leaving this link here so I remember to buy one when they come out in 2014:
http://litmotors.com/

Matt Brezina’s slides on Rapid Mobile App Development (Lean Startup experiments are easy on the web, but not apparently so easy in mobile apps. Matt shows us how to do it)
http://www.slideshare.net/brezina/secrets-of-rapid-app-development-lean-startup-conf-2012

Alexander’s Value Proposition Canvas
http://tinyurl.com/vpcanvas

Justin Wilcox on how to crowdtest your idea before building it
http://bit.ly/crowdtesting

GE’s $600k of prizes for innovative uses of their data
http://GEQuest.com

Of course, I would be remiss if I didn’t also remind you of a few posts that our AgilityFeat team wrote at the conference:

6 Lessons from the Lean Startup Conference
Things I learned in the morning at the Lean Startup Conference
Slides for “Just Deploy It!”
2 Pivots and 3 Lessons at Lean Startup Machine San Francisco
3 Things I learned at #WarmGun about #UX

 

December 5, 2012

6 Lessons from #LeanStartup Conference

Posted by Arin under Startups, User Group Reports | Tags: , , , , , |
[2] Comments 

What’s the best conference that you’ve ever been to? For me, the 2012 Lean Startup Conference in San Francisco is definitely the best one that I’ve been to so far. It was my favorite as a speaker, where I did a short Ignite talk on deploying software more frequently. But it was also my favorite as an attendee.

The Sunday night Ignite talks and the Monday talks were all great. Despite the fact that I’ve read all the major Lean Startup related books, I gained a lot of depth in my knowledge, I gained inspiration, and I came away with practical advice from the speakers.

I feel like I could write a full blog post on each speaker, but instead I’m going to give you the six biggest take aways I had from the Lean Startup Conference.

1. Lean Startup is for more than software

I come to the Lean Startup world from Agile software development methodologies like Scrum and Kanban. So I inherently get how this can apply to web and mobile businesses like we work with at AgilityFeat. But there were speakers talking about how they applied the same concepts in federal government, architecture and hospital design, vehicle design, helping farmers in India, porta potties in Africa, and even growing mushrooms.

By the time we got to the speakers who started growing mushrooms, and now are also building hyrdoponic fish tanks, my mind was just blown.

2. Be prepared for future stupidity

Dan Milstein described a lean startup process as planning for a future in which we are all as stupid as we are today. He made a great point that we are fooling ourselves if we think that because we learned some lessons from our last failure, that means we won’t make more mistakes in the future.

We will make mistakes in the future, and so our process should be based on calling out and validating our assumptions. Dan had many other great points, including that no every problem is a “there’s an ax murderer in our office” type of problem, and small failures on the way to success are a good thing.

3. Cut the Crap

Steph Hay gave a great talk about how important it is to talk to your customers in simple terms that they understand and which appeal to them. Cut out the crap (ie, all the marketing jargon).

I would say more … but I think Steph would recommend I should say less.

4. Good enough software

There were several sessions, including my own ignite talk, that emphasized the importance of delivering code quickly. There is a common problem with certain types of developers that they never want to say something is “done”. They want it to be fully featured, and to be absolutely bug-free. They are overly afraid of releasing something with a minor bug. An efficient business will need to strike a balance and still make a profit.

Once again, Dan Mil probably said it best: “There are two types of startups … Those successful and a little ashamed of their code, and those who are out of business.”

5. You can iterate on mobile applications

I don’t know about you, but on my android phone I’m always getting updates to my apps. It’s almost annoying. So I know you can deploy bug fixes to mobile devices a lot. That’s a form of iterative development, but lean startup methodologies is about more than that. It’s about iterating on your business model.

Matt Brezina showed me that it is possible to iterate the business model for apps. He deploys lower quality versions of apps to test ideas and concepts. Only if it appears to have traction will his teams then build a better version of the app. The better version gets a better name and completely different branding, so that the uglier developer-driven design of the first version doesn’t hurt the brand of the new and improved app. The key thing here is at a certain point you have to be willing to kill off (and stop supporting) those first iteration “off brand” apps that were really just a test.

6. Are you starting a hobby or a business?

This talk really hit home. At what point do you decide that a business is just a hobby? When do you decide that it’s been fun (or not), but you’re never going to make money on this and you need to just shut it down. I know from past projects that is a very hard decision to make. Your pride gets in the way. Wouldn’t it be great to avoid that at the very beginning of your project?

That’s what Crowdtesting may do for you. Justin Wilcox talked about doing a combination of crowdfunding and a/b testing to see if someone will prepay for your product at a discount. The data you gather from that will help you determine if you have a viable product or not. The idea is fascinating to me and you should go read more on this topic.

Go lean in small chunks

To wrap up, I’ll throw in one more bonus piece of advice that multiple speakers said. Don’t read Eric’s book and then go into the office on Monday with a list of all the things that you are going to change right away. All process changes require iteration, but it is well worth your time to keep trying more and more bits of the lean startup methodology.

 

December 4, 2012

Things I learned in the morning at The Lean Startup Conference (part 1)

Posted by Ford under Agile, Events, Lean Startup, Startups | Tags: , , , , , , |
Comments Off 

Yesterday, I went to The Lean Startup Conference in San Francisco. It was a full day of incredible presentations, fireside chats (without the fires), sharing of lessons learned and of course networking. This was my first Lean Startup conference and I was blown away by the diversity of ways Lean thinking is impacting the world around us. Here are some of the highlights, cliff notes style;

The US Government is doing big things with Lean thinking. Did you know the government operates 24,000 websites? The United States Chief Technology Officer, Todd Park discussed many efforts, benefiting form Lean methodology like a a proposed visa  path for entrepreneurs and shortened FDA approval cycles. He discussed RFP EZ, a platform that makes it easier for businesses to sell to the government and Blue Button which enables veteran’s to securely download their medical records. Further, he discussed some of the incredible resources made avialable by the Data Initiative Project (looking for a data play, check the Open Data Initiatives out). He talked about some of the great things that Code for America is doing with local governments across the country.

Conference Organizer and Lean Startup author, Eric Ries talked about the importance of Innovation Accounting as a guide for startups in the development phase of their business.

Beth Comstock described how GE created a protected class of ideas as an innovation pipeline to insulate them from the day to day pressures of the market and how they carefully integrate these ideas into the the main revenue streams of the company.

Danny Kim had an amazing presentation on his team’s process with Lit Motors including a fake dealership they set up to do customer development.

Matt Brezina of Sincerly wrapped up the early session with a great set of tips for Rapid Mobile Ap development;

  • Build an MVP
  • Test off-brand- they have a separate company for testing apps in the wild (or in Canada)
  • De-emphasize Visual Design early (but not integration design)
  • Re-use common components (payment processing, registrations)
  • Buy cheap, disposable user to test
  • Be willing to kill aps (even if they are generating a little money)
  • Used Android for quick testing
  • APIs are everything, use them!
  • Pair developers and designers
  • Minimize interdepence, empower your teammates

 

 

December 3, 2012

Slides for “Just Deploy It!” from Lean Startup Conference

Posted by Arin under Startups, User Group Reports | Tags: , , , , , , , , , , , |
1 Comment 

Here are the slides that I used last night at the Lean Startup Conference‘s Ignite talks.  I am indebted to Eric Ries and Sarah Milstein of The Lean Startup Conference for giving me the opportunity to present.  I have spoken at a good number of conferences before and given a lot of talks, most of them much longer than 5 minutes.  This was my first time doing the Ignite format, and I really loved it.

Here are the slides on Slideshare, I hope you find them useful.

If you would like to hang out with our team on the beach in Costa Rica and learn more about software development for startups, please check out DareToBeLean. This workshop in Costa Rica will cover Customer Development (led by Patrick Vlaskovits, co-author of The Lean Entrepreneur) as well as agile engineering and process methods like I talked about at the Ignite talks.

Now if you don’t mind, I’ve got something else I want to deploy before I go back to enjoy the conference…

 

December 2, 2012

2 Pivots and 3 Lessons at Lean Startup Machine San Francisco

Posted by Arin under Startups | Tags: , , , , , , |
Comments Off 

A little background on LSM events

David Alfaro and I have had a great weekend here at Lean Startup Machine San Francisco, as part of our LeanStartupConf tour of the area. For those not aware, LSM events start on Friday night, teams form around business ideas, and over the course of the weekend you use the Validation Board model to explore assumptions behind your business idea and actually build experiments to test those assumptions with real customers.

It’s a great event, with a competition at the end to see which team made the most impressive pivots in their idea and most effectively used the process.

Our team’s original idea

Our team worked on a cool idea brought by Stephen Benjamin. On Friday night Stephen pitched the idea that businesses could send their documents to Nativize.me where it would be translated by a native speaker from the appropriate country. So we started with that idea, but because of the constraints of a weekend event, we decided to focus on non-native English speaking students at US Universities.

Invalidating our assumptions

I’m holding a sign in Chinese asking students to speak with me about our project. It worked!

So we “got out of the building” and interviewed foreign students we met at the City College of San Francisco. All of them cared about their English and actively were trying to improve. That was partly validating our concept, but we realized something crucial. Almost all of them were more concerned about their spoken English than written English. The fact is they already had a support network of people who could help them for free with written English.

Next we tested if people were willing to meet Native English speakers in their area. They were, and we showed this by setting up a landing page to capture people interested in having coffee with native english speakers in their area. We ran that Google Ad for only a short time but we had a 40% conversion rate on those who hit the landing page.

Invalidating the payment assumption

Our next assumption was that people would pay for this. So we added price information to the landing page, and we set a minimum success criteria that we wanted a 15% conversion rate. We ran the ads overnight but only had a 12% conversion rate. That’s close, but it didn’t meet our criteria. So we invalidated the idea that enough people were willing to pay for the service.

Validating the match-making assumption

Next we decided to pivot to a free service that matches up people with others in their area, interested in learning the opposite language. For example, I am a native English speaker who is learning more Spanish. If I meet with a native Spanish speaker who is learning more English, we can have a good conversation and help each other out.

To test this assumption that people would be willing to do that, we built a simple form on Wufoo that looked like you could sign up to meet one of the specific individuals, as well as sign up to offer language tutoring to others.

We ran a short google ad group around this, and we got 2 signups on our form. We set a goal of getting at least one person to do that, and so we validated the assumption!

 

Our team learned a lot doing this, and I highly recommend the Lean Startup Machine events. Here’s a summary of a few things we learned.

Lesson 1: Embrace Failure

The first way we tried to see if people would pay for this was to stand on street corners in San Francisco with signs offering to have people pay us to practice English with us. This failed, and no one offered to pay us. While disappointing, it led to some great discussions among our team. We decided to run some additional tests that worked better, but still didn’t meet our success criteria.

Even though we came close to the success criteria in the second test, we embraced the failure and still invalidated the assumption, and pivoted anyways.

Lesson 2: Be Bold

Going outside and talking to people you’ve never met takes some guts. But it’s really important to take a risk of embarrassing yourself and try it anyways. You will learn so much that you don’t expect to – we certainly did.

Lesson 3: In person Customer Dev trumps online

In our first exploration phases of customer discovery, we talked to people in person and the conversation was very rich. We got to hear their passion, really understand their problems, and make an emotional connection with what interested them.

In our pitch phases of customer discovery, we were focused on setting up a few types of simple landing pages and looking at online click-throughs and conversion rates. This was very valuable and provided some interesting validations and invalidations. But it wasn’t as rich an experience, and we weren’t having the same conversations with people.

It’s worth the time

Lean Startup Machines are an investment in time and money. You’ll need to pay a little, or maybe travel somewhere as I did, but the real investment is your weekend. If you’re on the fence, let me push you over. It’s worth it.

 

Next Page »