Learning to Ride Bikes and Building Software

BikeWork has been a real challenge recently. Being a Product Manager is a fascinating job – when you actually get to do that job. I know that’s a flippant thing to say but you’re really the central hub in an ongoing tug ‘o war with Sales, Development, Customer Services and leadership in the company.

Some people lose site of the fact that the objective isn’t to build more features or the next cool Web 2.0 application, the objective is to empower people to do their job more effectively, and more efficiently. Every day I’m asked, “What features are in the next release?”

I rarely answer the question because my focus isn’t on features at all, my focus is to build a solution that enables marketers to do their job more effectively and more efficiently. Empowering your customers is what it’s all about. If you focus on things big and shiny, you’ll have big and shiny things with no customers using it.

Google built an empire starting with a single text box. I’ve read some articles where Yahoo! has actually criticized Google on their usability. What’s better usability than one text box? Don’t get me wrong, Yahoo! does build some fantastic features into their applications. I absolutely love their user interface components, I just don’t use their applications.

Google educates people how to ride a bike, and then they continue improving the bike. By building more efficient searches from a single text box, Google empowered hundreds of millions of people to do their jobs better. It worked, and that’s why everyone uses it. It wasn’t pretty, it didn’t have a glamorous home page, but it empowered their users to work efficiently and effectively.

Can you imagine putting you 4-year old on a 15-speed mountain bike with rear view mirrors, signals, water jug, etc? You wouldn’t. So why would you want to build a software application that has 15-speeds, mirrors, signals and a water jug? You shouldn’t. The objective is to get them to learn to ride the bike so that they can get from point A to point B. When Point A to Point B grows in complexity, that’s when you need a bike with new functionality that supports it. But only when the user can actually ride it!

That means training wheels are great (we see these in the form of wizards). Once a user can actually ride the bike, then you can remove the training wheels. When the user gets great at riding the bike and needs to ride it faster, then put some gears on it. When the user needs to run off-road, set them up with a Mountain Bike. When the user is going to hit traffic, throw in a mirror. And for those long rides, throw in the water jug.

Google does this with the progressive releases and continuous improvements in their software. I love the fact that they hook me with something simple and then they continue to add to it. They started with a text box, then they added other things like image search, blog search, code search, the Google Home page, Google docs, Google Spreadsheets… As I’ve grown accustomed to using their software, they’ve continued to improve it to support additional processes that make me do my job more effectively and more efficiently.

The bike is what gets the person from point A to point B. Build a great bike that’s easy to ride, first. Once they learn how to ride the bike, then worry about how to support additional processes by building out new functionality in your application.

Remember – Google started with a simple text box. I would challenge you to take a look at the fastest growing applications and successful businesses on the web and you’ll find one unique characteristic for all of them… they are easy to use.

Off to work…


  1. 1

    Fabulous post! Especially loved the analogy.

    I think what product managers have difficulty in nowadays is precisely defining when is the right time for extra the “bike” features and how to plug ’em in the already existing features that their users have grown accustomed to.

  2. 2

    Great post Doug. So many things that seem so cool really just make the job harder. Seen the book “Why Software Sucks” or “Dreaming in Code”?

    Both talk about how software is ruined by trying to be cool or super flexible vs. just getting the job done simply.

What do you think?

This site uses Akismet to reduce spam. Learn how your comment data is processed.