At RJMetrics, we pride ourselves on being a lean start-up focused on ecommerce analytics.  As a result, we’re always bringing new team members up to speed on what it means to be lean. My favorite way to educate them is through real-world examples.

Here are four of my favorite examples (from our team and others) of lean startups in action.

1. Faking A Move

To me, being lean is all about minimizing the ratio of resources consumed to insights gained. At RJMetrics, we did this to great effect when we were hiring our first employees. At that time, our company was based in Camden, NJ, and new applicants were few and far between. We suspected that our location was the reason for the talent shortage, but we had no way to prove that without making a really expensive bet and moving the business to nearby Philadelphia.

Just then, my co-founder Jake had a great idea: let’s just say we moved. We published an identical job posting but changed our address to a location in Downtown Philadelphia. The applicants started pouring in. We simultaneously started interviewing candidates and looking for new office space. We made our move literally one day before our first new employee started work.

Our Awesome Philly Office

I love this story for two reasons. First, had job applicants not increased we would have saved ourselves the trouble of moving with effectively zero downside. We then could have searched for more fundamental reasons that we weren’t getting applicants. Second, it saved us tons of time. By getting the answer to our question up-front, we were able to move and recruit in parallel rather than in sequence. I have no doubt that this accelerated our growth trajectory by months.

 

2. Actually Talking to Users

In the age of cookies, cheap storage, and abundant APIs, many companies have developed a strong bias against actually talking to their users.  Instead, they attempt to infer intent and sentiment from user actions.

While data can do a great job of telling us what is happening, it can often fall short on why it is happening.  Relying solely on data can also mask client frustrations.  Instead, from time to time companies should rely on a more time-honored tactic: asking what customers think.

Customer interviews are inexpensive, fast, and remove a lot of the interpretation risk associated with data-only strategies.  No matter how many numbers we crunch, we always learn something new when we ask our customers about their most and least favorite parts of our product.

 

3. Naming a Book

Tim Ferriss has a huge bag of tricks, but there is one that always sticks with me. When Ferriss was writing his book “The Four Hour Work Week,” he and his publishers were considering a number of potential titles. Rather than go with his gut, Ferriss devised a simple and brilliant strategy: buy Google Ads for each of the different potential titles, have them display when people were searching for content related to the book, and see what got people to click the most.

Users who clicked the ads would land on a blank page or “under construction” page.  All Tim needed to know was what moved people to click.

This inexpensive experiment allowed Ferriss to create an ad-hoc focus group consisting of thousands of ad viewers and learn which titles piqued their interest the most. Based on sales of The Four Hour Work Week, it’s quite clear that he made the right choice.   Ferriss shares this story in the video below.

4. Interactive Mock-Ups

Philadelphia entrepreneur Chris Cera recently turned me onto a really neat tool he uses called Axure. With Axure, you can to mock up interactive user interfaces without any backend coding. In other words, as long as testers follow pre-determined steps, they can get the impression that they’re interacting with a fully-built product.

Anyone who has done user experience work can appreciate why this is a brilliant and valuable tactic. An interactive mock UI/UX can answer huge up-front questions about how and when potential users would derive value from a product (or experience frustrations). With these questions answered, the development of the backend can be much more focused and deliberate, and there is far less risk associated with the final product’s release.