To pile onto my post last week about selling Plancast, I decided to pull out an email exchange I had with a fellow entrepreneur about a year ago. The entrepreneur is in the events space and was curious about some of the things we tried at Plancast and what worked and what didn't.

Which of the "social" tools on Plancast worked? And which didn't?

The number one absolute driver of engagement for us was email, it trumped everything else by a huge margin and was the only thing that would get users to come back on a regular basis. If I remember correctly, we had two types: a daily digest that would go out everyday of all the activity your friends had planned, and then a weekly summary of upcoming events of your friends and general popular upcoming events in your area.

Which ideas would you jettison and which would you keep?

We spent a tremendous amount of time integrating with Facebook and Twitter. Facebook was good for getting events into the system, though a lot of them were either really low quality, or semi-private, and so we spent a fair amount of time fixing titles, removing private and useless events, etc.. We built this elaborate system for Twitter so you could direct message your friend's events and invitations, this turned out to be a huge waste of time and almost no one used it.

If I had to do it all over again, I would focus entirely on email, and focus all my attention on getting access to their email or phone contact lists and not really bother at all with Twitter or Facebook until they wanted to send a tweet or share to their wall. We went the other direction, focusing on the social networks and neglecting their email account and I think that was a mistake. Sure, some people signed up because a friend posted on their Facebook wall, or tweeted at them (this was before Facebook graph, but that ship has sailed already too), but I think the time we spent implementing those features and working with their apis would have been better spent on email.

With mobile phones, their contact list is all that matters. In March or April, Facebook turned off api reading for both Path and MessageMe. That in and of itself is not all that interesting, Facebook turns off their read api for any growing social site, what is interesting is that Facebook thought it mattered. Almost all the growth at Path, and MessageMe, was coming from the phone contact list. Very, very, very, little of it was coming from Facebook or Twitter.

I really do like the idea of creating a mobile site where there's a big database of all events that are searchable. and then you can send any of those events to your friends. but you tell me--did this just suck?

I think this sounds awesome! I enjoyed seeing all the plans in my area at Plancast, there were tons of things we could've done to have a better mobile presence, and a better site. The problem is with relevancy, there are a lot of events out there, and on a page of 25 upcoming events, chances are you don't care about 20+ of them (maybe you have a scheduling conflict, or 20 miles is too far away, or you hate that band). This is an incredibly hard problem to solve, Eventbrite has entire groups of people trying to solve it, at Plancast we had me¹ :)

Or should i go for email newsletters?

You most definitely should do email newsletters, get as many email addresses as you possibly can, email them around once a week (Although we sent emails out every day, very few people got an email every day since our daily digests only included activity generated from your Plancast friends, since the average user visited Plancast once a week, most people would get an email 2-4 times a week).

Or some kind of auto event notification, where people sign up for pushed content from their favorite venues/performers?

We started a pilot program in Austin that was similar to this, the idea was the bar would have a Plancast page that had all their upcoming events, and you could follow your favorite bars and find out what was going on. I still think this is an incredibly powerful idea and I still think it would be insanely useful, but it requires a tremendous amount of upfront effort. You have to basically sell the bar on it, and then most likely have someone you pay manually add the upcoming events for the bar, so it takes a large upfront investment of time and money.

The reason why we did the pilot in Austin is we had an awesome girl that volunteered to go to bars and do all that work for us. Sadly, Plancast didn't last for much longer after that so we never got to see the results of all her effort :( I still think it is a great idea though, but it will require a lot of "man on the ground" type work.

Or should we do "click on this event if you're going to this event" and/or "click on this event to see others going to this event?" thoughts here?

Meh, it was cool to see the 1000+ faces on certain events at Plancast, but almost no one ever clicked through to learn more about the people, they only cared about which of their friends were going to the event, it did help make Plancast feel more alive though, which was an overall win.

A lot of time people were afraid to click the "count me in" button on Plancast because they weren't sure they could make it. Mark wanted to add an "interested" button but I didn't like the idea of having two buttons, because then they had to make a choice on which button to click, I wanted to solve the problem by softening the language of "count me in" to "follow", but in the end we didn't do either.

You said earlier that you actually got decent enough traction to be a lifestyle business. if you had to identify 2 or 3 features on the site that got you to that level, what were they?

Not sure there was any one thing (or 2 to 3 in this case), we had a lot of initial press from sites like TechCrunch that seeded the site with a good amount of users in the beginning (each TC article in those early days was worth about 5000 signups), and then we got a good amount of core users that were bigwigs in the tech space who shared their calendars.

We originally envisioned the site as a lightweight way to plan events with your friends, but much like no one at Foursquare checks into Walmart or McDonald's, no one at Plancast created coffee events, instead focusing on events that made them seem like a special little snowflake (mainly things like concerts and conferences). Read into that what you will.

I wanted to take a moment and expand on a tweet I made hinting about our experience selling Plancast. Even though it's now been a few years, I think it's still relevant because not much seems to change in the land of acqui-hires.

I also just wanted any fellow entrepreneurs, who find themselves in a similar situation, to know how wrong this quote from New York Magazine is:

Making offers to four-fifths of a company as part of an acqui-hire, while legal, is nearly unheard of in Silicon Valley, where mergers and acquisitions are still generally governed by a certain type of decorum.

For me, the Carrie Underwood song, You won't find this, nicely sums up the difference between your startup being bought and your startup being sold.

There's once in a lifetime
And there's once in a while
And the difference between the two is about a million miles

When your startup is being bought, The acquiring company wants something you have, so you have leverage. When your startup is being sold, you’re trying to convince the acquiring company that they need you, which completely changes the power dynamic in the favor of the acquirer.

But in an acqui-hire situation, you usually have no leverage and no power because your startup has pretty much already failed, so there isn’t anything the acquiring company wants from you except your talent. And since they only want the people, it’s in the acquirer’s best interest to cut out the investors as much as possible, in order to give more money to the employees they are buying. We had multiple acquirers refer to any money paid to the investors as dead money.

The acquirer usually accomplishes cutting out the investors by trying to basically hire away all the employees of the startup and giving each employee a bonus and retention package, thus making the startup worth nothing, but effectively performing an "acquisition" of the startup. The negotiations of an acqui-hire usually revolve around what the acquirer is willing to do to make the investors and shareholders whole¹, with the acquirer wanting to do nothing, and the founders wanting something for them so no bridges get burned.

I remember sitting next to a Google M&A guy at a small dinner, he mentioned it is usually the founders, hoping to start another startup some day and not burn their connections, who would push back to get something for the investors (Coincidently, this is exactly what we did at Plancast). I also know another entrepreneur who gave all the money he received from his acqui-hiring to his investors when the acquirer wouldn't budge on giving the investors anything².

How we started the process

When we made the decision to shop Plancast around, Mark, me, and some of our investors, gathered around a conference room table and worked out a list of companies we would approach, and the order in which we would approach them. Once we had the list made, we worked through who we knew at each potential acquirer and which one of us would make the initial approach.

One of our biggest regrets is we worked through that list serially, contacting each potential acquirer one at a time, instead of working with multiple acquirers simultaneously. This not only took a long time, making Mark’s life hell for about six months, but also meant we had no leverage to get the acquirers to hurry up and make a decision. We did it this way because we were much more bullish on the attractiveness of Plancast at the beginning of the process than at the end, I mean, who wouldn’t want to buy us?

The process

Below, in no particular order, are some thoughts about the overall selling process.

• Acqui-hires are incredibly hard to pull off and they fall apart all the time, you really, really, really can't count on your acqui-hire going through until you are either at your new desk or the money is in the bank.

• The less ambitious acquirers basically told us that they would wait for us to fold and then extend employment offers. Their M&A department had drunk so much company kool aid that they believed we would actually choose to work there after hearing something like that.

• The more ambitious acquirers tried to pick apart the team, extending offers or making overtures to just part of the team. In one of the cases, we shared a common investor with the acquirer, so Mark called him up and he basically said, “That’s the way these things work, what did you expect?”

• While Mark took the brunt of the extra work of talking to each company, we all had to go through multiple all-day interviews and divvy up the massive amounts of due diligence that caused the whole team to lose days at a time of our actual work. This was incredibly tiring and high stress, with lots of traveling for Mark, Peter, and me. On more than one occasion there were heated arguments in our conference room about how to proceed.

• It was well known among our investors and advisors that a certain large tech company was incredible picky in acquisitions. One founder told me that this particular company interviewed every single engineer in his startup, and then ultimately passed on the deal. We all went through thorough interviews there also, and they likewise passed.

• After a while, you just had to shake off the rejections, if we took personally every company that passed on us, we would still be curled on the floor sucking our thumbs and crying out for our moms. You cannot take these things personally, you just can’t. Even knowing this though, it did hurt a little when our 8th choice turned us down, even if we didn’t really want to work for them anyway³.

• We had multiple acquiring companies hint that they would’ve been much more apt to acquire us if we had more engineers. One even told us we were just flat out too small for the money it would cost to structure the deal. The magic number seems to be around 4-5 engineers with the whole team being under 10⁴.

• We ended up with multiple offers for Plancast, but passed on all of them, because the numbers just didn't make sense for us or our investors. Mark then published the best startup post mortem I’ve ever read as we were beginning the wind down process. His post prompted a whole new round of acquisition interest and we found Plancast a great home with Active Network a few weeks later.

• The post mortem also prompted a lot of approaches by other similar startups with a pitch like: "We are in the same space and we would love to merge with you guys and raise a new round of funding from your current investors." Of course they would’ve loved to raise from our investors, our investors were awesome. In regards to all those offers, Jeff Clavier gave one of the best compliments I’ve received in my career, “If Mark and Jay can’t make this work, then I don't think anyone else can either.”⁵

I'm really grateful to Mark, Peter, Jeff, and McKay for reading drafts of this and making it better.

I naturally take a moderate stance on pretty much everything, unless of course, you want to argue about something. What this means is I become more extreme when I’m challenged because I tend to defend the side I identify with most even though my true belief usually sits somewhere near the middle.

I remember walking along the boardwalk in Ocean City, MD a number of years back when I was approached by a PETA representative who wanted to talk about the abhorrent conditions of chickens kept in captivity before they are slaughtered and sold in restaurants and stores.

His proposed solution to the chicken captivity problem, which seemed entirely reasonable to him, was for society as a whole to completely stop eating chickens and he got defensive when I chuckled at that suggestion. I told him that I agreed with him the conditions, which I was able to observe from the large pictures on the signs they had everywhere, did look horrible, and I felt chickens should probably be taken care of better before, you know, they’re slaughtered and eaten.

Where we diverged was I felt it might be unreasonable to expect everyone in the world to stop eating chickens entirely since they are a delicious bird that people love to eat. I also suggested his time would be better spent trying to find ways to improve the living conditions of the chickens rather than trying to set all the chickens free. Soon after we parted ways, ultimately agreeing to disagree on how to solve the chicken problem.

While I think, traditionally, there were lots of inhabitants in the land of moderation at the middle of the line, it seems that people just don’t want to compromise on anything anymore, and it seems to be getting worse and worse with each and every year, people are clustering to their respective side and refusing to venture towards the middle for any reason.

Something Awful, talking about groups like Furries, blamed the internet for this trend:

In the endless expanse of communications the Internet is, probably the greatest and most terrible gift it offers to furries, pedophiles, and others, is the ability to shut themselves off from the mainstream. They huddle in cloisters that are virtually unassailable by the outside world and whisper encouraging things to one another that would be nearly impossible to say in real life. Free from the pressures of society to conform to a boring standard they go in the exact opposite direction, externalizing things that are roughly as far from "normal" as can be expected. Then, within their protected virtual enclaves, they declare these things to be the norm. By declaring their perversions, mores, and general imbecility to be their own status quo they have simultaneously validated their own existence and demonstrated the inferiority of outsiders.

When you can surround yourself with a community that only shares your beliefs, you have a recipe for killing any and all compromise, why should I ever try and see your point of view when all my peeps over here are yelling and screaming that you suck? Add on top of that the ease at which you can hurl insults with relative anonymity and little repercussions means it’s much easier for any discourse to fall victim to Godwin’s law than for anyone to ever change their mind.

No one has ever truly changed their position under force. Publicly shaming someone might get them to quiet down, but I guarantee it won’t get them to change their mind, as observed by this comment on Hacker news by Joel Runyon:

It's ironic that people are intolerant of intolerance.

I get the 'tit for tat' argument, but if you're trying to get rid of an oppressive opinion by being oppressive, you're not really getting anywhere.

You can't really "force" anyone to believe anything. If you have to "make" someone believe something by force, then it doesn't seem like your argument is strong enough to stand on your own (a statement that's applicable to both sides of this debate).

While I don’t have any concrete suggestions for how to persuade someone to your side, I do offer this thought experiment that I’ve noodled on every now and again since the tragic events of September 11th, 2001. What if George Bush, instead of declaring war with these words:

And we will pursue nations that provide aid or safe haven to terrorism. Every nation in every region now has a decision to make: Either you are with us or you are with the terrorists.

From this day forward, any nation that continues to harbor or support terrorism will be regarded by the United States as a hostile regime.

Had instead said something like this:

We don’t condone what you have done, but we forgive you!

Do you think the last 13 years would’ve been any different?

Supplementary Material

From reliable sources October 26, 2017, George Clooney, in an interview with CNN's Megan Thomas, reflecting on his days growing up when there were only three major networks:

Basically you started with the same fact base. And so, if you were conservative and I was a liberal, we'd start with the same facts." But "now we're going to the place that best represents what we believe. So our facts that we're starting with, from the beginning, are much further apart. And that's a problem, I think for all of us, because we're talking at one another as opposed to talking with one another.

The other day I showed a fellow programmer an old blogging engine I had built quite a few years ago. He was shocked by how much work I had put into the code and as we went through one feature after another, he kept asking me why I had added it since it didn’t look like I had ever actually used the feature.

He’s right, of course, it turns out I wasn’t much for using pingbacks or trackbacks, and my infrequent posting¹ meant no one ever commented on my blog, so they couldn’t appreciate the time I spent getting the interaction just right. But I learned a ton about how all those things worked during the nights and weekends I spent crafting that code. I also learned how to read and implement specifications during that time. I became a better programmer through reinventing the blogging wheel.

I love reinventing the wheel, I also love iterating on my previous solutions to make them even better. Luckily, I seem to be in good company with this compulsion, here’s Charles Moore, the creator of Forth, on reinvention:

Before you can write your own subroutines, you have to know how. This means, to be practical, that you have written it before; which makes it difficult to get started. But give it a try. After writing the same subroutine a dozen times on as many computers and languages, you'll be pretty good at it .

and here’s a description of Forth’s relentless iteration on his own code:

Moreover, he was never satisfied with his own solutions to problems. Revisiting a computer or an application after a few years, he often re-wrote key code routines. He never re-used his own code without re-examining it for possible improvements.

One of the things I love most about programming is the deliberate practice it entails, and with wonderful things like Github and Stack Overflow I’m not even sure it’s all that difficult to get started anymore. You can look at how better programmers have solved the same or similar problem and use their code as a template to roll your own solution. Joshua Froer, in Moonwalking with Einstein, uses Benjamin Franklin to describe deliberate practice:

Benjamin Franklin was apparently an early practitioner of this technique. In his autobiography, he describes how he used to read essays by the great thinkers and try to reconstruct the author’s arguments according to Franklin’s own logic. He’d then open up the essay and compare his reconstruction to the original words to see how his own chain of thinking stacked up against the master’s.

This is also similar to how chess masters improve their skill, Joshua continues:

“The best chess players follow a similar strategy. They will often spend several hours a day replaying the games of grand masters one move at a time, trying to understand the expert’s thinking at each step. Indeed, the single best predictor of an individual’s chess skill is not the amount of chess he’s played against opponents, but rather the amount of time he’s spent sitting alone working through old games.”

Sadly, even thought this is one of the things I love most about programming, it is also one of the things most frowned upon in programming, which is strange, since tons of things rely on this type of deliberate practice for improvement, no one complains when a musician covers a popular song, or an artist paints a picture of fruit, or a poet writes a poem about love. And yet, lots of programmers seem to relish pointing out how much time you’ve wasted on reinventing the wheel.

The other day, while working on my new blogging engine that powers this very blog, I decided I wasn't going to reinvent the wheel with the RSS feed generation. I spent a few hours trying out a few available libraries, but they all proved frustrating to install and/or use, relying on a ton of complicated xml dependencies and trying to be all things to all people. Throwing my hands up in frustration, I ended up rolling my own solution in about 30 minutes, how was I able to reinvent the RSS wheel so fast? Because I had done it once or twice before, and so I knew how.

The last question from the audience during my interview with Tony was about maintaining company culture as your company scales up. Tony gave a great response about hiring a money guy earlier than expected—but truthfully, I wasn’t really listening because I was too busy forming some thoughts I wanted to share on company culture. Sadly, we ran out of time before I could throw out my two cents so what follows is how I would've answered the question had I actually answered the question.

We’re thinking a lot about culture right now at First Opinion because we’re knee deep in scaling up the team. Executives pay a lot of lip service to shaping and maintaining culture, but often that’s as far as it goes because they don't realize the most important part about culture is buy-in from every person in the company¹.

Culture cannot be top down only. Let me repeat that because I think most executives forget it: company culture cannot be top down only. Many company builders think that just because they want to work a certain way, everyone in the company wants to work that way also, and so they attempt to impose their ideal culture on their early employees through sheer force of will and epic stares of disappointment, which only causes internal strife in the company².

The best way to make a healthy culture is to involve the whole company early, and often, and come to an agreement that not only everyone can commit to and follow, but one they actually want to follow. Then, when everyone knows what’s expected, you hold everyone responsible for maintaining those expectations. When there is buy-in from all the employees and everyone feels like they were heard while setting it up, there is a higher chance everyone will feel ownership in the culture and will actively work to maintain it.

What do I mean by buy-in? Let's look at an example that has never worked out well for me in real life³: suppose you want to have a 9am development team standup meeting each day. Seems reasonable, however, your developers usually don’t get into the office until around 11am. So, everyday, you’re nagging your developers to get to the office earlier because you want to have standup at 9am. Meanwhile, none of your developers want to show up until later. So, everyday, there is noticeable friction in the office between you and your dev team because you’re mad at your developers for not meeting your expectations and they’re annoyed because they had no say in setting those expectations.

How should you handle this situation to make sure your company culture returns to full health and includes a daily standup? My advice, sit down with everyone involved and work out a time that everyone can agree on. The key is everyone commits to the agreed upon time and feels that their voice was heard and their concerns acknowledged and/or answered.

If you’re setting up a company culture, I recommend picking up a copy of Delivering Happiness by Tony Hsieh. In the book, Tony talks about losing control of his first company's culture and the pains he took at Zappos to make sure it maintained its culture as it grew up. There is a reason Zappos offers you money to leave the company if you're not happy there because Tony recognized early on that buy-in was one of the most important parts of maintaining a culture as you scale the company from 1 to 100+ employees and, consequently, Zappos has done amazingly well maintaining its culture.

I'm saying it one more time for emphasis: I think a healthy culture is created when employees have buy-in to your company's culture and that your company’s culture was mutually agreed to, not just dictated from the top down.

There was quite a discussion about software testing on Hacker News this week and I was shocked by how many of the commenters leaned anti-testing. On the one hand, I breathed a sigh of relief, firm in the knowledge my job is safe since I build large well-tested systems; but on the other hand, I weep for anyone who has to work with someone who doesn’t believe in testing because there is a high likelihood their code sucks. I’ve been building software for a while now and I've never seen a large untested codebase that people were excited to work on¹. Why? Because the fear of not knowing if a change will break everything stifles even the best of developers.

I’ve often said that every developer writes tests, whether they admit it or not, some developers just don't save them for later. Here’s an example, say you’re adding a new function named boom. You add your boom function and then run it against input foo to make sure you get the expected output:

boom('foo')

After verifying the output, you smile to yourself because your boom function works exactly as expected with input foo, so you decide to also run it against input bar:

boom('bar')

Oh no! Your boom function threw an error with input bar. So you go back into the code and change some stuff and run it again:

boom('bar')

Whew! Once again, you’re all smiles because now your boom function works with input bar, but because you're a great non-test writing developer, you also run input foo again:

boom('foo')

Dang it! It doesn’t work with input foo anymore, back to the code, and after another set of changes, you run it again:

boom('foo')

Yay! It now works with input foo again, but in order to make sure it still works with bar you need to go back and run it with input bar again also. This back and forth grows tedious after awhile. This is exactly how most non-test writing developers write code². The problem is, as the codebase grows and gets more complex, you forget some of the earlier inputs or just stop running earlier inputs altogether because it's a pain, or you make a change in some other area of the codebase not realizing that the new change completely breaks the boom function for input bar now.

Now, let’s add the same boom function, but with testing:

def test_boom():
    boom('foo')

Let's make sure it also works for input bar:

def test_boom():
    boom('foo')
    boom('bar')

That's what testing gives you, a place to keep your previous input history so you can re-check it every time you make a change. So, each change to the code is ran against all the previous inputs to make sure it is working as expected. This allows you to make changes throughout the whole system and be able to check past assumptions to make sure your change didn’t break anything. I love testing because I like being as sure as possible I’m not the one who broke stuff, with the added benefit of other developers being able to understand and work on my code also.

My testing style has developed over the course of building a few companies from scratch and also working on rather large existing codebases. The idea is to make writing and running tests to be as fast and efficient as possible, allowing changes to be made effortlessly.

The first thing you need when writing tests is to get everything into a needed state. Usually, when people think state, they think of fixtures, which are usually data files you load when starting the tests, that set up the database and stuff. I’m not a fan of fixtures because I've always found them to be too rigid and difficult to keep in sync on a fast moving codebase because they are so separate from the actual code that runs the tests, so when I tried to use fixtures I found I almost always abandoned them and stopped running tests that depended on them all together.

Since I need testing to be as easy as possible to make sure I stick with it, I don’t use fixtures. Instead, I generate my data on the fly. In Python, I use a module called Testdata for this, It makes it easy to quickly generate a wide variety of data. I usually start with my generic library but wrap it in a codebase specific module. For example, at First Opinion we have users, and we often need a valid user on lots of our tests, so this is how we've set that up:

from testdata import *

def create_user(**kwargs):
    first_name, last_name = get_name(as_str=False)
    kwargs.setdefault('first_name', first_name)
    kwargs.setdefault('last_name', last_name)
    kwargs.setdefault('email', get_email())

    u = User.create(**kwargs)
    return u

Then, at the first of a new test function that needs a user, we just call:

u = testdata.create_user()

Now, in our test, we have our new user and even if the user object gets modified, we just have to update the testdata.create_user() function and we are good to go, instead of having to change large monolithic fixture files³. Anytime we need to add a new object or whatnot, we just add a new testdata function that creates it and then any of our tests that need it will be able to get it. Testdata has been a lifesaver for me, allowing database populating to be relatively low friction and easy.

The next problem I had was actually running the tests. I need my tests to be easy to run, otherwise I won’t run them nearly as often as I should. For Python, I solved this with another module named Pyt. One of the most annoying things about python’s unittest module is it was harder than it needed to be to run a single test, a normal test would be named something like:

footest.FooTestCase.test_bar

And to run that using the command line, I would need to type:

Python –m unittest footest.FooTestCase.test_bar

Which was hard for me to remember. Sometimes I use the Test postfix, othertimes I would use TestCase and I almost always switched them when typing out the command. Pyt lets me shorten that to:

pyt Foo.bar

And it handles the rest, this means I spend less time trying to remember how to run the test and more time actually writing the test.

When I worked on small codebases where I was the only programmer, I didn't care about writing tests, but as the codebases got bigger, and the developers more numerous, I became a convert to the testing lifestyle. I don’t really distinguish between unit, system, regression, and functional tests, I just want code in my applications to be tested in some way because I need it to work, and I need other developers to be able to work on it. The most important thing when testing is finding something that works for you and sticking with it. The next most important thing is being able to answer in the affirmative the question: am I confident I can push this code to production?

This post was originally published in 2012 on the Startup Grind blog, I'm republishing and expanding it here.

Lots of startups just don't seem to get it. They focus on things that don't matter instead of on the most important piece of the startup puzzle: the core mechanic. But what's a core mechanic? Well, I'm glad you asked. The core mechanic is what makes your product novel and exciting to your users. It's checkins for Foursquare, search for Google, and photo filters for Instagram (2014 observation, it's also talking to doctors on First Opinion). Basically, the core mechanic is the main reason someone who isn't your mom will bother to use your product.

Most Startup founders go wrong because they think a novel core mechanic is just an additional feature on top of an existing mechanic, it's not. If your pitch includes the phrase, "product x with a twist" then stop right now and go back to the drawing board. Just because an existing product doesn't have a feature you want doesn't mean you can build a successful business by cloning the product and adding that feature, and even if you did gain some traction, you'll almost certainly play second fiddle to the product you copied because they pioneered the original mechanic to begin with.

Why is a core mechanic so important? Because it will be your most powerful sales tool. That's exactly what happened to me the first time I saw an iPod touch in the Apple store. 30 seconds with it and I knew I had to have one, the core mechanic (in this case, the user experience) was so good I disregarded any limitations I knew it had, in fact, I didn't care about its limitations at all because everything else about it was so good. That's the kind of product every entrepreneur should want to make, but few actually do. You'll know you're on to something when people start nodding in agreement as you describe your product because it offers them something they want.

Once you've got the right core mechanic then your users will be hooked. Twitter was forgiven during the fail-whale years because Twitter was so addictive that people couldn't stay away; Finally, instead of only whispering your awesomely funny and insanely witty comment to the person sitting next to you during a boring presentation, you could broadcast your genius to the whole world. Likewise, if you've got a great core mechanic, your users will forgive missing features and product missteps because of the value they do receive when they use your product.

The tricky thing about a core mechanic is it's only novel and revolutionary once. Those who follow your trailblazing footsteps will have diminishing returns. Groupon owns the daily deals space because they found a core mechanic that resonated with people (2014 observation: too bad Groupon's hook doesn't make actual money, zing!). However, all those Groupon clones that quickly popped up and tried to capitalize on Groupon's success are dropping like flies because what Groupon offered was no longer enough. Personally, I think daily deals sites are like auction sites. Can you name an eBay competitor? Exactly! Yet, I remember in the late nineties you couldn't mistype a url without stumbling on a brand new auction site.

So what should your startup focus on? Most definitely the core mechanic. Nothing else really matters. You can have the slickest designed product in the world but it doesn't matter if you don't have the right core mechanic. A great example of this is Path, their first version was widely regarded as one of the most beautiful iOS apps anyone had ever seen, yet no one used it. It wasn't until Path fixed their core mechanic problems that people began to care (2014 disclaimer: I have since worked at Path, and it was awesome).

Your core mechanic is your app, site, or product's total value proposition. If you don't have a good core mechanic, you don't have anything. When you do finally have a great core mechanic, every time you think of adding a feature, ask yourself, does this feature accentuate my core mechanic? If it doesn't, resist adding it.

But don't just take my word for it, take Alan Cooper's word from The Inmates are Running the Asylum:

Programmers will naturally emphasize edge cases, but they can largely be ignored during the product's design. This doesn't mean that the function can be omitted from the program, but it does mean that the interaction needed for them can be designed roughly and pushed way into the background of the interface ... the product will succeed or fail in its ability to handle daily use and necessary cases. ...

If a user performs a task frequently, its interaction must be well crafted. Likewise, if a task is necessary but performed infrequently, its interaction, although designed with different objectives, must still be well designed. Tasks that are neither necessary nor frequent simply don't require careful design. Time and money are never available in unlimited quantities, so this is the place to conserve our resources safely and concentrate them where they do the most good. ... we need to design only for those that are important or that will occur frequently.

Core mechanics also have different sized markets, some products are novel and great, to a small subset of people, that's exactly what we found out at Plancast (last 2014 observation: sigh).

Supplementary Material

Skype is a perfect example of nailing the core mechanic, via Ars Technica:

Talking to a computer felt silly at the time—as silly as talking to your hand did when mobile phones first appeared. Feedback on the initial version of Skype was not exactly enthusiastic. The sound was glitchy, for instance. But when testers realized that they could now speak via computer to people on the other side of the world for free, attitudes changes

A friend emailed me a few months back asking me my thoughts about entrepreneurship and the valley, my quick brain dumped response included this paragraph:

Expectations! If Instagram hadn't sold for $1b, would Snapchat be worth $3b? I don’t think so. Microsoft's investment in Facebook many years ago set the big valuation stage and raised prices for everyone around the valley. Instagram's sale to Facebook raised prices yet again (even Instagram's own investors had valued it at $500m the week before). Current valuations are a reflection of all the valuations that have come before, which is why you should never get angry when a company is sold for a staggering amount of money because it means your company most likely just got a little more valuable, no matter what company it is.

With Facebook buying WhatsApp for the incredibly awesomely staggering amount of $19 billion this week, I thought I would take a moment to expand on the above thoughts a bit, focusing on Instagram’s sale in particular, since I think it is the single most important event in the last few years affecting company valuations.

I think the general consensus of almost everyone over the last few months is that Instagram sold for way too little. The problem with that reasoning is it exists in a world where Instagram did sell for what was, at the time, a staggering sum of money. Before Instagram sold, people weren’t talking about unicorns, baby unicorns, or Thunderlizards at the same frequency they are now, neither were so many companies reaching billion dollar valuations or making billion dollar acquisitions; Instagram’s sale changed all that. It’s been a few years now, but I remember the coverage being just as dramatic, and people being just as shocked, for Instagram as it has been for WhatsApp this week¹.

A rising tide raises all ships, and both Instagram and WhatsApp have definitely raised the tide. If you were a decently successful company in the process of raising later stage growth money in 2012, Facebook basically gave you a gift. It was only after that sale that you started regularly hearing about billion and multi-billion dollar valuations. And my bet is you wouldn’t have if Instagram hadn’t sold.

If you’re a founder, or employee, at a startup right now, congratulations, because chances are Facebook just gave you another gift and your company just got a bit more valuable. Every Venture Capitalist in the world just had their expectations on valuation pushed upwards, and that’s good for all of us venture backed startup people.

Since discovering this GoPro point-of-view video of a luge run on Business Insider a few days ago, I've watched it over and over again (protip, it's awesome on a big screen TV).

So today I broke out Gifgrabber and turned part of it into an animated gif as my special gift to all of you on Valentine's day. You're welcome, Internet!

I’ve been thinking a bit about networking this week since I had the opportunity to interview Tony Conrad at Startup Grind 2014. It was a great experience and a lot of fun. However, I was shocked at the number of people who approached me after the interview to ask for an introduction to Tony. While I admire the bravery it takes to walk up to a complete stranger and ask for something, I’m also boggled that people think this approach would ever actually work.

A few years back, while Plancast was still going strong, the entire team attended SXSW. I don’t drink but I spent a lot of time that week in bars yelling at other people over too loud music. I was networking in the classic sense, and it was completely useless to me, I haven’t seen or thought about most of those people since.

Sure, a lot of people gave me business cards; I’m sure some of them even connected with me on LinkedIn. But most of them never contacted me again and I didn't contact most of them either. Just like me, they were getting out there and networking, and also just like me, they were mainly just spinning their wheels, without making any forward progress on gaining a valuable relationship.

However, I didn't completely blow my SXSW networking experience, and looking back, I can tell you the people I met at SXSW that I still have a relationship with were the ones I met up with multiple times over the course of the conference. I went to parties with them; I ate breakfast, lunch, and dinner with them. Basically, we became friends over the entire length of SXSW, and after the conference, I stayed in contact with them (we traded emails; we followed each other on Twitter). That was relationship building, not just networking. And it took more work than just having one awkward conversation for 5-10 minutes in a bar.

You want an introduction to an investor? Follow this blueprint from an experience my cofounder, McKay, had with an entrepreneur. This entrepreneur reached out to McKay to meet up. Then, afterwards, he kept in contact, sending McKay updates on the progress of his startup. He also occasionally sent relevant industry news (the great, “Thought you’d be interested in this” email). Their relationship kept progressing over a longer period of time, what Mark Suster refers to as lines, not dots. Then, only after the friendship had been established, did the entrepreneur mention he was looking for funding and asked if McKay knew anyone he should meet. McKay made an intro to a prominent VC in the valley. That, ladies and gentlemen, is how you build a valuable relationship and ask for an intro to an investor.

Networking events like Startup Grind are great as a starting dot to a relationship, but they should never be the whole relationship. It takes a tremendous amount of guts to walk up to someone at a conference and start talking to them, don’t waste it! Rally your bravery after the conference also, and reach out again. If you get a response, continue to build up a friendship. But whatever you do, don’t ask a complete stranger to introduce you to one of their investors the first time you meet them, because that’s never going to work.