Category: Technology

The hottest Christmas book around our house this year has been The Thing Explainer by Randall Munroe. It explains complicated stuff using only the thousand most common words in the English language. A helicopter becomes a “Sky Boat with Turning Wings” and a dishwasher is a “Box that Cleans Food Holders.” This has had the kids cracking up every time they open the book. If that’s not a good enough recommendation, maybe Bill Gates can convince you that it’s worth checking out. If you want to try your hand at writing with only the 1000 most common words, Munroe has created a tool to help you do it.

And, if you haven’t encountered Munroe before, you’re in for a treat. His comic XKCD is a gem. Here’s a good place to start.

It is very easy for software product owners to be lured into the trap of designing software to solve a broad problem for many people right from the start. This is a mistake. Most ideas start to scratch an itch or build something that is unique to a particular company or group. Then as you think more about solving it, the natural tendency is to go bigger and think “hey, this could also solve these similar problems!” You increase the scope of your project to encompass those problems as well. After all, it’s software, there’s no cost to make your product just a bit more generalized, right?

No. Again, this is a mistake.

Build to solve the smaller problem. Learn the domain by focusing on solving the problem you started off with from A to Z. Once you have done that, expand to similar problems or refactor your software to a higher level of abstraction.

For example, say you rent a house and find it tough to communicate with your landlord. You decide you want to build software to help landlords communicate with their tenants. Great. As you start thinking about it you realize that you could also solve the problem for people who rent out their houses to vacationers for the summer or for commercial apartment building landlords to communicate with many tenants in a building. After all, they’re basically the same problem, right?

No.

They require different models, different abstractions and different user interfaces. Solving everyone’s problem means solving no one’s problem. Instead it means getting bogged down in creating software generic enough to not exclude any potential customers. It may seem like you’re making big fancy plans and building elegant software models when in reality you are severely lengthening your time to market and setting yourself up to build a product that doesn’t fully solve any one of your potential customer’s problems.

Here’s what not to do:

• Don’t try to solve a problem that can be described in two words like “Project Management” or “Travel Guides” or “Technical Training” or “Note Taking.” Your first product should be much more specific. “Note taking for software developers,” for example.
• Don’t start trying to sell something that has even the smallest geographic considerations to customers globally. Instead, pick a country or state and go from beginning to end with just that segment of the market.

An example in the software world is Ruby on Rails. It didn’t start as a broad framework. It started as a product–Basecamp. It wasn’t until after Basecamp was successfully built to completion (depth) that 37 Signals extracted Rails as a general framework that could be used to build other web applications (breadth). Contrast that with Meteor or Famo.us. These are frameworks built to solve huge problems for many people. They are promising but have been extremely expensive to build and growth has been quite slow, in fact for Famo.us, it seems to have stopped completely.

Resist the temptation to start by building for a broad market. Focus. Build a product that completely solves a small problem, then expand it.

I’ve started a newsletter!

Join me, a natural, habitual collector of information on a random journey through languages, spoken and coded, literature, culture, science, learning and many other topics. This is a casual, infrequent email conversation that will point you off in fun & interesting directions.

rien ne tient en place. A few of my favorite things: literature, French, JavaScript and Ruby beautifully joined together in this essay about language and meaning.

A couple weeks ago I posted about “Radical Creation”–stopping reading, watching TV, listening to podcasts etc. to re-focus on creating content and move away from constant consumption. It was a successful experiment. I came away from it refreshed and with a more conscious approach to media. I’m no longer cold-turkey, and have moved back toward the middle; toward what feels like a better place. This has resulted in me setting a few informal rules:

• Give time to think, write and process anything you consume. If you haven’t done that for the last thing you read, listened to or watched, don’t start something new.
• Write about it. Even if it’s just jotting down a quick note, write something about everything you take in. This is to help remember it later, but more importantly, to remember it now. 
• Triage. Consume all types of information, but be aware of the relative value. It’s not always easy to put something down midway through, but do a gut check. If it’s not working out, move on.
• Avoid “The Shallows“. It’s easy to spend all available time reading Twitter or Hacker News, but there is more out there. The best fish aren’t found in shallow water.

Since taking that approach, I’ve been writing significantly more, have re-started some side coding projects and have generally felt more in touch with the present and more conscious of how what I consume affects me. It’s been a good reset.

Telling stories is hard. Getting people to tell them can be hard too, but once you do, there is nothing as captivating. Recently Tim Ferriss interviewed Alex Blumberg of Gimlet Media on how to tell and elicit engaging stories. The interview is specifically geared toward giving advice to podcasters on how to get people to tell good stories, but can also be used to help you relate information in a way that people will identify with.

Blumberg’s goal when editing a podcast is to draw in his audience with memorable stories. We’re “hard-wired” to want to hear a story and if you can do that with your content, people will listen. He suggests learning to “listen to your own boredom.” In personal interactions we try to meet people halfway to understand their perspective and maintain interest, but the Internet isn’t a personal interaction. If you’re feeling a twinge of boredom or drifting while editing your content or speaking, chances are, you have already lost your audience.

In the same vein, when you are reviewing your content, be aware of any feelings of confusion. The axiom applies here as well: don’t assume people will meet you halfway. Even a subtle feeling that what you are working on might be confusing is an indication that it will be very hard for your audience to follow. Stop and clarify.

Blumberg also has a couple specific techniques and questions to use when interviewing to help get you to that moment where someone tells a story with real emotional appeal. A question he finds useful is “what do you make of that?” It is a little awkward to ask, but it is open-ended and tends to draw out people’s feelings on a subject. He also asks “why is this story meaningful to you?” After using these questions he suggests you “sit back and shut up.” Let your interviewee talk, give them time and you will the story you are looking for.

Part of the interview comes from a Creative Live class that I haven’t seen ($99), but looks interesting.