undefined method `node_name' for nil:NilClass

Check that the button is inside a form. As in, the following code will cause this error:

HTML:

<form></form>
<input type="submit" value="save" />

Capybara:

click_button "save"

Moving the button to the inside of the form will fix the issue.

Why Most Features Aren’t About Differentiating

You’ve got 5 seconds. Tell me how you’re better than the incumbent I am currently using. If your pitch to me — as a customer, partner, or investor — is that your site has the most features: you’re screwed. Here’s why, from the perspective of each:

• Customers & partners: Yes, but, who are you again? I don’t put my eggs in nests that might disappear tomorrow, even if the nest has a built-in heater.
• Investor: So your company is a feature away from being destroyed?

In the Internet Era, features are cheap. Big or small, a company can bang out a feature in a week or two and start testing it. You disagree because said company would “never” build that feature? Never say never. Innovative companies always surprise people. Hoping your competition doesn’t want free money on the table is tantamount to gambling, and there is a much safer, more logical way of approaching this problem.

So many “feature” companies (i.e., they’d just be a feature in a bigger company’s product) are born everyday. The criticism isn’t that these companies are doing something “easy.” The problem is that many startups use a specific superior product experience or feature as a key differentiator, without considering whether or not it helps them corner a new or different market. Being “better” isn’t enough.

Same Thing, Different Optics

Certain feature sets, if marketed right, completely change your target market. This is key. Let me say it again:

Certain features put you in a different market.

Think about this for a moment. Most all companies are chasing a specific market. 18-24 females. College students. People who like coffee. Couples. Widows. Canadians with houses.

Not all features are created equal. Most features just add further convenience or refinement (i.e., “single signon,” “AJAX uploading,” “mobile support.”) But these same features, with the right marketing, change who your audience is. Sometimes marketing isn’t even required.

Remember that cheeky nest/egg example from above? This would be like saying, “let’s build huts and go after people because people prefer huts over nests.”

Why Incumbents Ignore Certain Features

Like I said, some features change who a company’s customers are. In worst case scenarios, some features alienate your existing customers entirely (i.e., killing your existing revenue stream).

For example, your feature might be a free, ad-supported version of an existing model. A very famous site called OKCupid did exactly this a few years ago. Even today, this is what they’re known for. Why didn’t the other players in the market copy them? Because going free would mean changing their customers from their users (who pay a monthly fee) to advertisers (who pay for data and exposure). Yes, much like Facebook, OKCupid’s product is its users, and its customers are its advertisers (mmmm sweet, sweet data).

While the main differentiating feature, being free, is an easy feature to build, even to this day, incumbent sites like eHarmony and Match remain paid services. They are ultimately after different markets. You and I can intuitively see that there is likely a well-defined difference between the two markets of people willing and not willing to pay for dating (income, what they are looking for, age, etc.). It’s clear now that there was always two markets in the dating space, and OKCupid successfully cornered it using a simple marketing message.

The key for you and I is to understand and learn from this lesson: figure out what differentiators you introduce that give you unique access to a new or different market from incumbents.

Don’t Get Distracted

In any given startup, there is probably a backlog of 100 features to choose from. And most of them are from customers. Think about it.

Customers ask for features.

These customers are asking you to pick their market. With each feature you work on, your are moving toward a given audience. If this is a market you don’t want, ignore the feature. A feature that doesn’t help you define, carve out, and keep a specific target market is a waste of time.

In some markets, usability is everything (mobile). In others, aesthetics (marketing). Yet again in others, speed (search engines). Maybe in another, depth of technical end points (APIs). And within these markets, there are niches with even finer requirements.

Identify your core desired audience and build features only they yearn for. Everything else is a distraction.

Feature != (does not equal) Technical

A feature isn’t necessarily a boat load of programming. A “feature” is a marketable unit of software development. The complexity of that development is irrelevant. It can be as simple as a change in design, pricing, copy, or even name. Here are some examples:

• Pick an XXX domain for your Pinterest clone: bam! PinPorn (NSFW). No difference in technical features from the original, but the site successfully corners its own market via community (the feature).
• Want to be a Groupon for gay people? Fab. (Another year later, they’ve exited their niche and become a mainstream fashion site.) You know how they did that? They built a sizable mailing list of the gay community from their original ideas to be a gay Facebook and/or Yelp. Fab’s differentiator? Good taste, according to them.
• Instagram’s killer feature was tight social integration (arguably pretty technical); yet Hipstamatic came first. Instagram brought easy sharing to a paid digital photo filter market that Hipstamatic defined.
• And, of course, there’s Facebook: a MySpace for college students. The killer “feature” was that you had to have a “.edu” email address. Facebook probably would have perished in its early days without those 5 lines of code (maybe less).

The Real Meaning of Market Differentiation

Recall my example about the free dating market. Rewind 10 years. Online dating was something you paid for. That was it. Maybe this is easy to recognize now, but this market dichotomy (free vs. paid) was not apparent until only recently.

When smart people ask you about your market differentiation, this is what they mean. They are asking you if you’ve found a market angle that existing players will gladly give up because they either don’t value it or can’t compete in it due to conflicting interests.

So next time you’re looking at a list of features to work on, ask yourself: “is this feature putting us in the market that we want to be in?”

Facebook just seriously injured their own app developer ecosystem, and they’re poised to finish it off. And they did it on purpose.

Recently, Facebook announced that they would remove the default landing tab for Facebook Pages. They did this while simultaneously introducing Timeline for Pages. Most people probably aren’t going to miss those “like gate” pages where users were asked to like the brand’s page. The move makes sense for Facebook as it forces brands to spend money on the new Facebook ad units that have embedded likes (see below). Brands are understandably upset: getting likes means spending money.

The effects were immediate to one audience. The real doom-and-gloom story is around app developers. Facebook made this announcement at the start of this month. Since then, some of Facebook’s biggest apps have taken a nose dive on traffic. How big? A good example of this is Band Page, which gave artists cool, interactive fan pages with embedded music/videos, rather than the boring old wall. Facebook announced these changes roughly at the start of March. As you can see below, Band Page lost roughly 1/4 of their users (6 MILLION!) in a period of 15 days (yes, the chart is a little weird to read).

And this will only continue as more pages transition to the new format (10 more days until it’s mandatory).

The “default landing tab” was how many, many apps got their traffic on Facebook. The default tab was the first thing new users saw when they visited a brand’s page. This was a way for the page to “message” themselves to new potential customers, and it was very popular for brands to spend money on these apps.

Unfortunately, that party is over.

Check out this comparison on how else the new change hurt an app like Band Page. Here’s a “before” of Taylor Swift’s page, which has yet to convert to the new format:

Notice how it lets you play the music straight from the page and links to their iTunes store (links like this are not allowed on Timelines, btw)? Notice how it “lives” in Taylor Swift’s page as part of a seamless experience? See how you can see a quick list of all the apps the page has?

Let’s compare…

Snoop Dogg recently updated his page to use Timeline.

Wait. Where’s the link to Band Page? Oh, I found it under that little “2″ to the right of his “Snoopermarket” (that’s cute) section…

Check out the installed Band Page app look and feel:

What? Where am I? Where’s his page? That white space you see is exactly as it appears. The app is sitting alone off in its own area.

It might as well live on Snoop’s own website, and I imagine this is exactly the direction many brands will take as this becomes the norm for Facebook apps.

How much does all this hurt these apps? Check out the biggest losers in the weekly app ranking charts:

It is the same story with every major app: stagnated growth in early March followed by a continuous and very steep decline as the month continued. All that jazz about the Ticker and Open Graph hasn’t been enough to stop this decline. I fear what will happen April 1.

Page apps are getting destroyed! This explains the recent shift for Wildfire (reference) and Buddymedia (reference) to becoming Facebook Ad aggregators. These two companies built an empire by being the go-to solution for Page apps and now they’re running away. At least Facebook notified these guys.

Facebook is out to kill page apps, albiet slowly and only after suffocating the ecosystem so the loudest and most deep-pocketed players move to greener pastures (see above two examples). Developers beware. Profile apps suffered a similar slow strangulation followed by a sudden death. When profile apps were killed, we got just over 60 days notice (announced as a footnote Aug 19, 2010 and officially removed Nov 3, 2010).

IPO-Facebook needs to make money, and if there’s companies eating their lunch, don’t expect them to sit back anymore.

After all, Timeline is all about hurting Twitter. Let’s see, it:

• Decreases the ability of “doing stuff” via apps (e.g., self-maintaining content)
• Makes it more embarrassing for a brand to not actively post updates since their page starts off as a wasteland. Thus, it…
• Increases the importance of providing frequent updates and engaging your fans
• Makes it easier to see who’s interacting with a page

Page apps became a casualty because they discouraged page owners from using Facebook like Twitter. Previously, brands could hide crappy walls by having cool apps and a nice splash page with a “Coupon for a like” message. Those days are gone. And Facebook did it on purpose. It’s probably for the best, but as a developer, it still hurts to think about all the blood, sweat, and tears that went into building those amazing Page Apps.

TLDR: Don’t focus on being right. Don’t rush the sale. Find believers.

I recently got my startup funded. It was an extremely, extremely challenging exercise. Today’s post is short; I’ll save the funding journey for another time. Today, I wanted to talk about pitching. I’m going to focus on three big, often overlooked issues.

1. Friend-speak: “That’s an awesome idea!” => “Good luck, bro.”

Friends tell you what’s wrong with your idea, but they often say it nicely. Listen to your friends carefully, and recognize that “That’s a cool idea, but what about blah-blah?” is a veiled criticism of your idea. Listen and understand their concerns. A good pitch patches up these holes before they’re even asked.  Often, when an idea is criticized, it’s natural to want to be defensive. It’s important to take criticism as something to solve for, not something to “be right” about. Ok here’s the analogy:

You’re a pirate. You’re practice fighting with your buddy pirates when they accidentally shoot a hole through your hull. But you’re smart so you win the argument with them that there is in fact NOT a hole there (Uhhhh). You decide to go out and challenge some Brits to a battle to the death without first addressing the damage your buddies left on your idea — er, I mean — ship. Oops!

2. You need more time to sell

I haven’t pitched that many people specifically to get money (a lot of pitches were over partnerships), but when I felt rushed there wasn’t a second meeting. When you are trying to convince somebody to give you — a nobody — enough money to buy a few cars (or a house), they need time to digest things. Here’s the analogy:

Your startup is like a restaurant. First you lure in a customer to try out your food. Once inside, you serve your customer what they are going to eat. It’s a game changing meal, so they’re naturally skeptical. They start to nibble on it. Maybe it’s good. Maybe it’s not. But you’re in a hurry so you jam the food down their throat, ask for money, and remind them to leave a good review on Yelp. They throw up and get major indigestion.

Like with any good meal, make sure you have a full hour to pitch. Your pitch should be 30 minutes max. Leave 30 minutes for questions (which will be sprinkled throughout your presentation).

3. The Crazy Idea Train needs passengers

You’re the conductor of the Crazy Idea Train. You built it, actually. It’s a little rocky, but it’s speeding along! But there’s no passengers. Your friends say they’ll get on the train later. Strangers say you need to pay them money for them to get on board (it looks really ghetto and unstable, after all). And nobody really knows where it’s headed. Maybe it’s going to Billion Dollar Land; maybe its going to Unemployment Mountain. You think it’s the former. But it looks like most people believe it’s the latter.

I’ve thought about this a lot, and I’ve decided that this is actually super duper important not just from an investor’s point of view, but from a founder’s point of view. If you can’t convince one person to join your Crazy Idea Train, then is it really a good idea? Finding a co-founder is social validation that your Crazy Idea has legs. Without this, investors are left to imagine the worst.

I’ve also heard cases of people unsuccessfully looking for co-founders. Again, this to me is a sign of a crappy idea or worse. There’s a lot of reasons why somebody would be unable to find a co-founder, and most of them are bad signs. Are you arrogant and un-friendly? Do you seem untrustworthy? Do others have no confidence in your ability? Are you a terrible leader? Are you all talk? Are you no fun to be around? Do you kill kittens for entertainment? Maybe. Maybe not.

Your number one job as a founder is to sell the company to future investors, acquirers, and employees. If you suck at this, that’s a death sentence. Start with selling to a co-founder.

Summing it up

Don’t focus on being right. Don’t rush the sale. Find believers.

Bonus pro-tip: make sure your lawyer doesn’t put your cell phone number in the SEC filings. Yeah, that happened.

Sharing Events = Global Dispatcher

Today, I came across a fairly mundane – and probably common – problem: I have two views that need to talk to each other. An example for this would be when you have a status bar in one corner that gets updated when a user completes an action in another area. It turns out that Backbone (as far as I can tell) does not support this use case very well out of the box. Well, it does: it expects you to build that yourself.

Backbone supports a model where you publish and subscribe to things happening in your views/models (commonly known as an “event dispatcher“). For example, you can make your application do stuff when a user clicks on something or if a model attribute changes. The native solution localizes these events (probably a good thing) to the model/view that you’re working with. This works for simple stuff, but when you need it in other parts of your application, things break down. The short answer is that you need to build a global event dispatcher A.K.A. global event “hub.” Everything publishes (“trigger”) and listens (“bind”) to events from this object.

This is a common pattern. In fact, I found two solid articles on this topic. The first explains in detail why you need an event dispatcher. The second shows you how to make the dispatcher natively accessible by all of your Backbone classes.

Event Dispatcher Gotcha: Native Events

However, I felt both solutions weren’t quite there. The first forces you to pass around an Event object everywhere you need it. This is nice from a decoupling standpoint, but highly error prone. The second solution is nice, but makes the caller oblivious to the global event namespace they are triggering/binding to. This is dangerous because Backbone has native generic events that are fired when certain things happen. For example, when you edit a Model, it automatically fires a “change” event into its event dispatcher (which bubbles up to its Collection too). This means if that dispatcher was global, every object would see a “change” firing every time every Model changed. Not good.

Goals

I came up with my own solution that accomplishes three main goals:

1. Retain native Backbone event triggering/binding
2. Allow the developer to trigger/bind to global events
3. Not require the developer to pass things around

Solution Code

(If you can’t read CoffeeScript, just use this converter to convert it back to JavaScript)

The following (very simple) code modifies your Backbone definition to attach the global dispatcher to all objects. The dispatcher is easily accessible from any Model, Route, View, or  Collection through the global_dispatcher parameter. I thought about having it trigger events to the local dispatcher as well, but I decided that keeping them fully separate was in everybody’s best interest (to prevent events from accidentally colliding):

Example Code

The next section is a simple class I wrote that will demonstrate how these events work. I am defining a simple Collection and a Model. Note that I named the global and local events the SAME. This was to help demonstrate that the namespaces are in fact completely separate (as in, just because they are named the same doesn’t mean a local event will ever trigger a global event with the same name).

The following snippet illustrates triggering the events attached to the Collection. Note that we add a Model into this collection (which has no impact on the output). The trigger_stuff method triggers both a local and global event (in that order). The output shows that the events were picked up in the order fired (local, then global). Note that the Collection also listens to the “model_custom_action” event, which coincides with an event the Model triggers. This is very important.

The order of operations looks like this:

1. Fire a local event
2. The Collection picks it up
3. END OF FIRST EVENT
4. Fire global event
5. The Collection’s globally attached event handler picks it up
6. END OF SECOND EVENT

The next snippet shows what happens when you fire an event on a Model inside a Collection. It is also why I decided to keep things separate. This is a little hairy, so pay special attention.

The order of operations looks like this:

1. Fire a local event
2. The Model picks it up
3. The Collection picks it up since all events in children bubble up
4. END OF FIRST EVENT
5. Fire global event
6. The Collection’s globally attached event handler picks it up
7. The Model’s globally attached event handler picks it up
8. END OF SECOND EVENT

Notice that in step #6, the Collection’s binding fires BEFORE the Model’s. This is key.

Step #3 fires because there is a LOCAL binding to the “model_custom_action” event in the Collection. The local binding is reacting to an event triggered in the child Model’s local event dispatcher. In other words, any event triggered from the local event dispatcher in a Model will bubble up to the Collection’s local event dispatcher and be otherwise indistinguishable from events triggered directly from that Collection.

Step #6, however, is different. That event did NOT originate from the child model’s local event dispatcher. Instead, it is reacting to the global bindings, which happen to share the same name as the event we saw earlier in step #3. Because it didn’t bubble up, the events are being processed in the order they were bound (via the bind() function). The Collection was defined before the Model, thus, the Collection’s global binding fires first.

In this last snippet, we demonstrate how Models behave when not inside a Collection.

1. Fire a local event
2. The Model picks it up
3. END OF FIRST EVENT
4. Fire global event
5. The Model’s globally attached event handler picks it up
6. END OF SECOND EVENT

This is very straight forward if you managed to follow the last example. To get additional clarity, you may want to try renaming the events in the above class and re-run the examples.

By having the global dispatcher separate, you can consciously decide when an event should be “public,” as well as not clobber any existing Backbone functionality. Backbone is still really young (pre 1.0!), so I wanted to avoid using any solution that might break if they changed the internals. Also, completely preserving the behavior of event bubbling for Model-Collections is important to future proof my hack.

I hope this is useful for all of your Google-visitors!

People will work just as slow or fast as before. It is not a miracle drug. Agile DOES ensure people are working on the stuff that matters at that particular moment. Which leads to the next point…

Agile Does NOT Mean You Can Change Your Mind All Day Long and Still Ship on Time

If you change your mind that the product should do X instead of Y, you may have to throw away code. This is a fact of life. Agile DOES encourage making key decisions at the last possible moment so that the cost of change is minimized. Agile (a la retrospectives) exposes why or how the deadline was missed and how costly bad decisions were.

Agile is NOT a Better Way to Manage Down

Yes, there are lots of little tasks now. And yes, they are all prioritized and bite-sized so it’s easier to micromanage, right? But you’ve missed the point. Agile let’s the engineers tell the managers what is going on. Agile IS a way to manage expectations (e.g., “managing up”).

Bonus Non-Issue: “We Need to Focus on How It Will Scale”

I’ve heard this a lot. It doesn’t matter (and if you disagree, then you probably aren’t ready for Agile). Agile is about making stuff that works – right now – so you can see if what you’ve made has any value. If it has value, then you worry about scaling. If it’s garbage, nobody will care how it was architected. Get it to work first; scale second. Getting stuff in the customers’ hands and then making decisions based on the feedback is your top priority. If you aren’t focusing on that, you’re probably on your way to creating your very own crappy product that nobody uses.

Today we learned that “agile” is a loaded word.

Instead, we ended up with an ugly smudge magnet. Don’t make the mistake we made.

See for yourself (covering our catch phrase on purpose):

But what’s the market shares today? Did you know that IE is below 50% by most measures? Did you know that Chrome ate up Firefox’s market share? And what’s Safari’s market share if all the iPhones and iPads use it?

You probably don’t know.

Because, who cares.

5-10 years ago, it mattered that IE had 70+% of the browser market because it directly influenced what was possible as an application developer. But mobile changed all that.

Mobile browsers ended up being the adoption wedge for HTML5 and alternatives to Flash thanks in large to the fact users — and developers — treated mobile as separate from regular browser apps. What a blessing in disguise: it let everybody start over. And once the mobile stuff got popular and apps broke, people blamed the bad mobile browser (“My ghetto Blackberry won’t load Facebook right!”) instead of the website. It was the perfect storm to force everybody to start adopting HTML5. Add in CSS/JavaScript standardizing tools (Modernizr,  jQuery, GWT, etc.) and developers didn’t even have to do cross-browser testing for simple stuff.

Maybe this is a bad thing to admit, but I haven’t bothered testing in all browsers for a year or two now. Stuff just breaks less often. IE7 is “good enough,” and the other browsers work 99% of the time. Thus, the only time I bother checking browser compatibility is if I’m doing something super complex or a user complains.

Good job, Internet. Ya, the evil Microsoft IE empire is still around, but we won the war and nobody even noticed.

Your friend is a victim of Failure Paralysis.

It’s clear that inaction guarantees a lack of success. No success can be achieved by doing nothing. You can’t even win the lottery unless you buy a ticket. This applies to anything: becoming president, getting a girlfriend, losing weight, seeing a movie, etc. The first step, is to start moving toward the goal.

This is the struggle every entrepreneur eventually has to overcome.

A lot of people talk about the uncertainty around taking that first step. The reality is that as soon as you take that first step, you’ll be hit with 100 new issues you never imagined. You can read all day about poker theory, but it pales in comparison to real playing experience. And yet, so many people get stuck in the theory-crafting stage of an idea. Move past this step.

To succeed, you must do. And not doing assures failure.

What are the odds that the idea in your head will become a million dollar company? Well, if you do nothing, the odds are 0%. If you start now, maybe you increase your odds to 0.1% – a literal infinity-percent better odds. The problem is that some people don’t want 0.1%. They want 99%. Thus, they wait while they do stuff to try to increase their odds. But isn’t actually doing it going to increase your odds too? When does the waiting stop and the doing start? Well, for most people: never.

Everybody has excuses to do something later. But only a few don’t let those excuses stop them. Kevin Rose famously destroyed his relationship to fund Digg. Mark Zuckerberg dropped out of Harvard for Facebook. HARVARD! Actually, so did Bill Gates for Microsoft. Michael Arrington, a now-famous tech journalist, abandoned a career as a lawyer to join the startup world. Even Jack Dorsey bailed (I use this term in jest) on Twitter to go do Square.

Did these guys fear failure? I’m sure. You can’t gamble your future and not be. But that didn’t matter — they ignored all the “sound” advice from their friends and family. I won’t get into each case, but history shows us that if each had waited an extra year or two to make the jump “safer,” they may have missed the boat entirely.

Later is the same as never. Now is the only acceptable time.

Your friends might buy your excuses, but as an Internet-Stranger, I’m going to say the truth: your excuses don’t matter. Results do.

• Too tired after work? Suck it up or change your sleeping habits.
• Credit card debt holding you back? Pay it off and quit going out.
• Not enough time? Manage your time better and quit reading Reddit.
• Can’t code? It’s OK to suck at it. Learn.

So, take a deep breath, and do something. Anything. Don’t fear failure. Fear not-succeeding.