Years ago, it was just another day at the Plancast office, when Mark approached me about implementing a new feature for a project we were working on, before he could finish fully describing it, I interrupted him with, "Absolutely not, that would never work and here's why..."

I then proceeded to rattle off a long list of all the reasons why it would never work. Mark patiently listened to my mini-rant and then, with a heavy sigh, responded with something I've never forgotten, "Jay, you never say yes to anything and I'm getting to the point where I don't even want to approach you with new ideas anymore."

Some programmers might wear a response like that as a badge of honor, they might even relish in it, as this commenter on Hacker News shows:

A designer I worked with had lots of interesting stuff taped to his door

My favorite was probably the following:

“Can you just...”

no.

But I had no desire to be perceived like that, and so Mark's response that day completely transformed my attitude about how I approach new feature requests. Now, my default response to most new feature discussions is that of course the engineering team can implement it, it's just a matter of priority.

Some developers will consider this a dangerous answer, but I think if expectations are agreed to ahead of time, most problems can be avoided. The entire team, or company, needs to understand the tradeoffs of the new feature, its ongoing maintenance, and how it affects the overall product.

These tradeoffs are wonderfully summed up in two points of rfc1925:

(2a) No matter how hard you try, you can't make a baby in much less than 9 months. Trying to speed this up might make it slower, but it won't make it happen any quicker.

(7a) Good, Fast, Cheap: Pick any two (you can't have all three).

If everyone understands that anything can be done, as longs as acceptable compromises and sacrifices are made, the conversation can then change from, can we do something? To, should we do something?

I think should we do something is the more important question. If we accept we have the ability to build anything we can imagine, we need to decide if that's how we want to spend our time, because:

Among the most dangerously unconsidered costs is what I've been calling complexity cost. Complexity cost is the debt you accrue by complicating features or technology in order to solve problems. An application that does twenty things is more difficult to refactor than an application that does one thing, so changes to its code will take longer. Sometimes complexity is a necessary cost, but only organizations that fully internalize the concept can hope to prevent runaway spending in this area.

While the author is specifically talking about codebase complexity, I think this also applies to the overall product as a whole, marketing a product that does twenty things is much harder than marketing a product that only does one thing really well, especially if those twenty things span across multiple target markets.

I like to think about product complexity like a magazine subscription. I have packrat-like tendencies that require constant vigilance on my part to keep in check. A few years back I talked my wife into letting me get a magazine subscription, she reluctantly agreed after I told her I would throw the magazines away after I read them.

However, each month I would find one or two things in the magazine that I wanted to remember, so I would mark the pages and put the magazine in the corner so I could reference it later. My three year subscription ended last year, but to this day, there are 36 issues of that magazine sitting in a box in my office.

I can't bring myself to throw them away because I've marked something to remember in each and every one of them, but I also think about how annoying that box of magazines is, and how much space it takes up. That box has even survived a dwelling relocation or two. That's product complexity.

There's a reason why we have platitudes like, KISS, keep it simple stupid! and Good is the enemy of great because we really do need to keep reminding ourselves of what's really important and where we should be spending our time. Complexity in your codebase, and in your product, grows exponentially and can quickly spiral out of control--and paralyze your company--before you even knew there was a problem.

This last week I missed solutions to two different types of problems, and how I reacted to each type was so radically different that I thought I would take a moment to reflect.

The first type involved new feature discussions in the office. Usually, when the team starts discussing a new feature, one of the first questions asked is how much needs to change in order to support that new feature. My preliminary thoughts on a certain feature was that it was going to involve a lot of infrastructure changes, which caused us to rethink adding the feature at all because of the complexity involved. However, on further discussion, James proposed a solution that only needed a small tweak to the codebase.

After reflecting on James's proposed solution, he was completely right. I had completely overthought the problem and we really could fully support the new feature with just a few minor tweaks to our existing codebase.

My initial response to this first type of miss was all out pride. This is why I work with smart people, because they see things I don't, and their input makes me a better programmer, working with them makes me a better CTO, and their hard work makes First Opinion a better company.

The second type of problem I missed involved failures in our backend systems. We had two significant downtime issues this week. The first happened early in the week, one of our long running cron jobs had been failing for at least a day due to an input change.

The second happened early Saturday morning (or late Friday night if you prefer) and in my sleepy state I failed to fix the problem on my first stab, and so it stayed unresolved until I was awoken a second time a few hours later.

Both of these issues were caused by monitoring failures in our systems, and my initial response to both of them was disappointment in myself for how bad I had screwed up because neither issue should have ever existed for more than a few minutes, at most.

Programmers screw up, code is brittle and it breaks, a lot. But, because epic level screw-ups are so common in programming, you have to be careful in how you handle discussing the error after the fact, I don't know anyone who enjoys their failures being pointed out again, and again, and again. Likewise, I've never known a programmer who didn't feel just awful after an epic screw up.

My focus instead turns to solving the issue that caused the epic failure, and to do that, I like to use the 5 Whys to figure out what went wrong, and to make sure the problem is never repeated again in the future. I also drop every other project on my plate until the solution is fully implemented. My team and I are going to fail spectacularly¹ again, it's just the nature of software development, but the goal is to never fail in the same way twice.

Supplementary Material

I liked these two quotes from David Sokol, quote one:

We are very tolerant of mistakes resulting from a judgmental error at the planning stage, when despite our team's best efforts, the market zigged and we zagged. It happens. We recognize the error, adjust from it and learn from it. We are not tolerant, however, of mistakes made from a lack of planning or diligence or from plain laziness. Tolerating such situations ultimately makes the organization very good at them.

And two:

Making a decision that delivers a less than desired outcome is part of business life. Failing to take the time to understand your mistakes and learn from them is totally unacceptable.

And this is a great pep talk from the Duke Women's Basketball Coach about how mistakes are part of the game:

During the game some things are going to go wrong it's what happens. If you really like watch the game of basketball, every possession something goes wrong for somebody.

That's how someone scores or that's how someone doesn't score because something goes wrong with every possession.

So there's 150 possessions in a game, 150 times someone's making a mistake. It's part of it so just don't don't let that throw you off. You make a mistake, it happens, but just get back into the play as quickly as you can and then try to make the next right play.

That's really the most important thing about being being a basketball player is when you make a mistake try to make the next right play as many times as you can.

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.

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 Moore’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 though 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 to do it, and what shortcuts I could take.

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. I also had some thoughts I wanted to share on company culture, but 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, even as that culture is a culture I think I would hate.

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 the earlier inputs altogether because it's a pain, or you make a change in some other part 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 to 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 start 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, other times 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 quickly 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. The one exception to this for awhile was building the exact same business in a new country that was previously successful in a different country.

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.

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.

These are the slides/notes to a talk I gave at Startup Grind 2013

Introduction

My advice is for venture capital backed social companies, this advice is not for lifestyle businesses.

This is a very "lessons learned" type talk, it definitely walks a fine line between jaded and RA-RA-RA you can do it.

I want everyone in this room to understand that once you’ve taken VC money, you’ve basically started a clock counting down and subscribed to a certain lifestyle, and you've also agreed to become a certain type of company.

With all that said, I want to talk about money, there are two types of money...

Traditional Money

This is a typical business, you have customers and they pay you for your product.

Social Money

I’ve been involved in two social companies from the ground up (Plancast and Undrip, and since this talk I've also worked at Path)

In a social, or audience first, company your users are your money; they might as well be a line item on your income statement.

There is no such thing as a lifestyle social network business, if you choose the social company path you need to be a runaway success.

What do I mean by runaway success?

Pinterest (amazing success, exponential growth)

Ben Silbermann has talked about how Pinterest had 50% growth month after month in the early days of the company. Starting from a small base, this seems like awful engagement and growth for the first little while, but you'll eventually reach a tipping point when you are growing by that big a percentage each and every month.

The tech press who wrote stories about how Pinterest was nothing for years, but the founders stuck it out and didn’t pivot, really don’t understand how magical 50% growth month over month is--even from a small base. To point out how ridiculous those stories were, Pinterest was able to raise multiple rounds of funding while they were “sticking it out.”

Our intuition about the future is linear. But the reality of information technology is exponential, and that makes a profound difference. If I take 30 steps linearly, I get to 30. If I take 30 steps exponentially, I get to a billion.

-Ray Kurzweil

Plancast (linear growth, X users/month like clockwork)

You’ll run out of money long before you get to the scale of users you need to keep the lights on.

I’ll just get press and my site/app will explode with users

I want you to think back to that Simpson's episode where Rainier Wolfcastle was shooting a movie in Springfield. The acid is coming towards him and so he takes out some goggles and puts them on, then the acid hits him and he says, “The goggles, they do nothing!”

Press is a lot like that, it will not significantly move the needle for your company.

Just as a side note, an easy way to tell if a founder inflates all his metrics is to ask him how many hits he got from a TechCrunch article about his company, if it is really high, my guess is he is lying about almost all his other metrics also.

Power users are overrated

Your best bet to grow is to have users love you, and for them to tell their friends.

Pinterest and Snapchat had huge user bases before that influencer you follow signed up.

Personally, I think people that follow power users are jaded, I’m much more likely to download an app on my mom's recommendation than some random influencer on social media.

Advertising is not a business model

Why would companies use your brand-spanking-new super geo-targeted social networking app with a small user base when they could just carpet bomb Facebook ads for everyone in your city for less money and reach 200x more people (answer: they won’t).

You have to have huge scale before advertising becomes a viable business model for your company, and even then it's not guaranteed to succeed long term and build a huge company (see Snapchat and Pinterest).

Agree? Disagree? tell me why, set me straight...