1. Money
2. Dedication
3. Time
4. Patience
5. A co-founder you can depend on.

These all come back to one key point: Provide value and you will win.

Money

If you listen to Hacker News, it’s easy to get these days. I don’t think that’s true. I haven’t done any fund raising, but I’m about to start, and it appears to be way harder than people make it out to be. I had the privilege of seeing a founder just off the road from raising a huge series B give a talk about his experience and jesus I wouldn’t wish that on anyone!

If you provide value to people, though, money should be easy to come by. You prove you provide value by showing traction. Traction begets money, assuming you have a reasonable way to monetize that traction (or sometimes not so reasonable, even).

Dedication

Can you see yourself working on your project–whatever it is–for the next five years? Seriously, think about that for a moment. Five years is a long time, especially if you have only been working on your weird idea for three weeks.

Not to toot my own horn, but I’ve turned down six-figure jobs in recent months to work on Revisu (ironically I get these six-figure offers because I’ve started Revisu). If you’re dedicated to your project, you’ll be constantly searching for ways to provide value to people, because providing value breeds traction which begets money.

Time

Another unfortunate facet of the modern startup world is the notion that startups start and succeed (or start and fail) on such an accelerated time frame. To a certain degree, you can “validate” (for some definition of the word) a start up idea or market quickly, and you can make some cash pretty quickly with a prototype.

The reality is that most startups don’t get anywhere any time fast. Even at PIE, a lot of the startups are just barely off the ground. But, we have wobbles of hope. We have a plan to get off the ground. That plan takes engagement, validation, and hustle. It takes time. Time to prove value, which will breed traction, which will beget money.

Patience

Patience is the effective use of time. Patience is especially necessary when you read about everyone around you making it while you’re still struggling. If you’re diligent, smart (read: providing value to your customers), and patient, you’ll get there eventually.

A well known entrepreneur told me the other day that be believes that any reasonably smart person can find money in any market if they push hard enough, and I really trust his opinion. So, be patient, stay hungry, and with time you’ll find a way to provide value, which will breed traction, and beget you money.

A co-founder you can depend on

Everyone is searching for a co-founder. Good entrepreneurs are searching for co-founders even when they have co-founders. Business folks are searching for technical co-founders, and technical folks are searching for business co-founders. It’s a difficult proposition, but the only thing more difficult is progressing without one.

Without a co-founder you can depend on, you have nothing. Starting a startup is literally the most difficult thing a participant in the tech industry can do, and most people just can’t go it alone.

At some point, after you find a co-founder, you’re going to hate them. You’ll feel like you can do it alone and you don’t need them. You’ll feel like they’re not pulling their weight. You’ll feel like you can do the things they do. Maybe that’s true, but it’s probably not. The most important thing: Keep your collective eye on providing value to your users. Providing value will breed traction, and beget money.

I started making a mental list–a pretty short one, actually. We need to have revenues enough to support hiring, which means we need to have more paying customers, which means we need to get more general traction, which means…which means we need to keep pushing.

Startups are about pushing. Constantly.

When I first got interested in startups, it seemed easy enough to get started. Just make something people are interested in, they’ll start using it, and suddenly a million dollars! At a high level (a really high level) I’d still contend this is correct. But, as I’ve learned, there is a ton of stuff that happens between the “make something interesting” and the “people will start using it” bits.

At Revisu, I’m happy to say that we’re finally starting to see that traction! People are seeing value in Revisu and actually using it with their teams like we envisioned they would. Whew, that only took…how long again? Well, I can’t remember exactly–longer than we thought it would–but I do remember that it took constant pushing to get there.

Pushing is also about velocity.

In terms of work, it’s a tough proposition to keep your queue full when you’re filling your own queue. However, if you’re working on your startup and you find that you don’t know what to do next, that’s a really bad sign. I means you aren’t working hard enough–you aren’t learning fast enough.

To really push hard you need to be able to move from task to task quickly and efficiently. After I finished polishing a feature I went immediately to working on the deck. In a startup, there are hundreds of things that need to get done and the pool of people to work on them is really small–you and your partner(s).

Seriously sweat the small stuff.

Pushing means not just getting stuff right, but getting stuff right right. Small things that are broken in small ways break experiences in really big ways–ways that keep people from using your software. Especially when you consider that something that might not be a big deal to you is indeed a deal breaker to anyone else. One of the most common problems an MVP is that it’s missing the V for small (or perhaps more often big) reasons!

As I’ve said before, at Revisu we’re known for iterating quickly. Our primary motivation for quick iteration is that we want to get things right. Thus, we get stuff out the door quickly, we figure out how it’s wrong, and we iterate. While this is a really great way to get things right it can be extremely painful, too. After re-designing our login page for the 15th time because it still doesn’t look just right, it can be just…exhausting.

Lean + Pushing = Cognitive Dissonance?

After I wrote this whole post, I thought that I should go back and address this as I love lean development, Eric Reis’ strategies, and the benefits there of. Often enough, though, I have a really hard time reconciling the concept of MVP with sweating the small stuff.

The trick that we’ve been using lately is to evaluate what the #1 blocker to progress is (from a customer on-boarding perspective, obviously). Perhaps it is in direct competition with what we would call an MVP but I’d contend that that just means that your MVP is not an MVP!

Pushing hard on product is a lot like social media marketing to me: It just works! Somehow, you put energy in to it and the results will surprise you. I don’t think it will be a direct ticket to success, and I have no idea how long we as a team can keep it up, but we’re getting extremely positive results and making really great progress. Hopefully you will, too, as it’s the only way I’ve found to bridge the traction gap.

The only thing crazier than the two parties duking this out in public is the sentiment on Hacker News shifting wildly depending on which story is #1 at the time. Perhaps there are just two deeply divided sides two the argument, because I can’t immediately find an instance of a person directly contradicting themselves between the posts.

At any rate, the the buzz generated by each is certainly palpable. And pretty silly for a bunch of startupers, when you get down to it.

Do you even remember why we’re here?

Look, people, lets take a seat and talk about this for a bit. Start ups are really hard. Like really, really hard. Even when they’re going exceedingly well, they’re still really fucking hard. At PIE I sit next to a start up that’s fucking killing it right now, and it looks really scary to be in their shoes.

But, it also looks like a lot of fun. And it looks like they’re pumped to be doing what they’re doing. And I’d really love for my company to start hockeysticking like theirs has.

It’s not easy to get to that point, though. They’re often the first in to the office and the last to leave office, and their hard work is paying off. They are going to make something awesome–hell, they already have made something awesome. That is why they worked hard, and that is also why I am working hard.

40-hour work weeks don’t change the world.

We work exceedingly hard on our stupid start up ideas because we want to make a difference, and you just can’t fucking do that in a 40-hour work week. If you are sitting there thinking you can, then either your goals are too modest or you just haven’t figured out that you can’t yet.

I just finished a 15-hour work day. I’ll probably work about the same number of hours tomorrow, and the day after for that matter. My start up, Revisu, gets a lot of praise for iterating and moving quickly and that doesn’t happen on its own. Here’s a hint to our secret on iterating quickly: A 40-hour work week is not involved.

I’m OK with it. I’m happy to put in the extra hours in order to build something I think will be great. And if it turns out to be a failure then, well, I fucking tried–I learned something–and that’s more than the 40-hours-a-week workers can say.

If you run a start up or work at a start up and you get anxious at 5pm, then you’re in the wrong vertical in the tech industry. You should probably go get a “real” job. Oh, and let me know if you need help in that area by the way as I know a few companies in Portland that are hiring .

The experience I can speak from dictates that when Revisu got accepted to Portland Incubator Experiment I had assumed that someone else would be looking out for me, I wouldn’t have to work too hard on the shit I didn’t want to do, and it was only a matter of time  before I got my million dollar check.

Turns out this is really really not true and, since I think this is a pretty common belief, the sooner we collectively understand this the better off we’ll be. Indeed, even raising money–another major “milestone” in most startup peoples’ minds–does not symbolize the end, but just another beginning. Perhaps startups are really just a sequence of beginnings.

What is a startup’s ending anyway?

That’s pretty subjective, I guess. Perhaps it’s a significant liquidity event, or some kind of merger, or perhaps you wind it down because someone (probably you) fucked up. My opinion is that if you can go on a vacation and both afford it and not spend the whole time worrying too much, your job is close to over probably. But again I’m pretty new to this weird game.

Y Combinator does not a millionaire make.

I used to be of the opinion that if you made it in to Y Combinator, you were set for life. After all, your Pokemon daily deals text message startup obviously passed the YC interview test, so it was only a matter of time before you got the call from Google about your exit, right?

When I saw a YC company fail, I was always left scratching my head. If these people were the best of the best per the Paul Graham test, how could they possibly fail? Turns out, if you somehow make it in to an incubator, you aren’t magically blessed as an entrepreneur.

Here’s where it gets awesome.

Incubators succeed in giving you the support you need to take your company to the next level, and in making you ultimately responsible for getting it there. This is where your journey to becoming an entrepreneur gets really exciting.

This weekend, I spent 26 hours working on Revisu. I absolutely loved every second of it. Not only did I get to work on some really interesting problems–both technical and non-technical–but they were problems that we (my partner and I) identified in our quest to build my our company.

Half of loving the crazy hours is having the support of a community behind you. As a for instance, a thread was started yesterday on the PIE mailing list, and within 15 minutes there were 10 replies to it. On a Saturday afternoon. Do you know of any group of individuals of which more than a third of them would reply to an email thread because they were working on a Saturday afternoon?

So just getting in to an incubator won’t make you a millionaire. Hell, it really doesn’t give you a huge leg up over someone that decides to go it alone. But, it does give you access to a community of like-minded people, a lot of ins to your local tech scene, and maybe a little cash to get you started. And that’s a really great way to get started starting up.

Parsing and acting on advice is a skill that you have to learn, and it’s a skill that I didn’t understand before I entered PIE–hell, I still might not understand it. So, here are a few things I keep in mind when I’m talking to mentors and advisors.

1. Don’t waste your mentors’ time.

When I first started talking with people, I assumed that I needed to savor every damn second I could get with them. Thus, I figure that if I end a chat early, or run out of things to talk about, or can’t start a decent conversation that I would look amateur and ungrateful for their time.

While it’s true that these conversations are probably the most valuable you’re going to have at this stage, don’t waste people’s time because you feel like you need to be talking.

2. Make a list goals of your conversations.

For chats that you’re trying to schedule ahead of time make sure you have a list of questions or goals. You should probably come up with this list way before hand (in fact, you should have been prompted to call them up based on that list in the first place) as this will help you figure out whether or not you actually need to talk to this person or whether you’re just wasting their time.

3. Understand where they’re coming from.

Everyone has an angle–and not in a shady way! It has more to do with the way humans work. Marketing people think about things as approaches to marketing. PR people think about things in terms of PR. Product guys and founders…well, they have to think about everything. Your job is to find the overlap and pick out the bits that make the most sense for you and your company.

4. There are many ways to do any one thing.

Take launching for example. The aforementioned PR guy would be pushing us to build up to a big launch. But the product guy probably wants us to eschew launching and just open up for business right now–after all, how else are you going to  validate your market?

Both have very valid, well measured, and compelling reasons for their respective approaches. But neither is (likely) better than the other! Note that I think this is particularly poignant given the modern startup ecosystem and our belief that there is one really hard way forward.

5. You are ultimately responsible for everything

If your metrics tank (you are tracking your core metrics, right?) because you followed someone’s bad advice, your investors are going to blame you. At the proverbial end of the day, you have to make your calls based on some confluence of  advice, experience, data, and gut.

It’s important to remember what a mentor’s motivation is. People who have been there want to give back, so don’t forget to say thanks! Often that feeling of gratitude is what they’re getting out of helping you. For others, they feel like they’re getting the inside track on something awesome, which is hopefully true.

The most important thing to keep in mind when talking with your mentors is to just treat them as people first and teachers second. You’ll learn a lot from them, and they’ll help you build an awesome company!

We tried searching Google and crawling through Hacker News to figure out what to expect, but real actionable data was lacking. Here are a few tips on getting started at an incubator.

1. Don’t worry, no one else knows what they’re doing either.

At PIE there was a real mixed bag of startups in terms of progress. Going in to PIE some were really far along, some (most) were just very basic prototypes with unproven marketability, and some were just ideas and two cool guys.

All of them, though, didn’t know what to expect from an incubator. And you really can’t find out, either, until you go through it as each incubator is different.

2. Figure out what your startup is about — quickly.

By “what you are about” I mean write down — on paper — the answers to some very basic questions. What are your goals? What is your (hopefully market driven) problem hypothesis? Why are you in an incubator? What do you hope to have done by the end? What do you hope to learn from it? The sooner you do this, the more successful you will be as all of your decisions should hinge on those answers. Any decisions you make without this data are just shots in the dark.

As of now, we’re about half way through the program and we just now figured out the answers to these questions. We’ve got a lot of work ahead of us to make up for that lost time. Oh yeah, and these can change at any time, too.

3. You’re probably wrong and that’s OK.

This point gets harped on a lot but it’s one of those things that people still fail at realizing when they’re actually put in the position, when they’re actually wrong about something. And you could be wrong about anything and everything — technological viability, marketability, your ability to reach customers, anything!

The best entrepreneurs are the ones that realize they’re wrong the earliest because they can figure out how to fix the problem. Again, this is something we’re just now learning!

4. You’re about to learn a lot.

You’re going to meet people that have expertise in fields that you didn’t even know existed  and are very important to building a company.

PR was a field that I didn’t consider to be important. “it’s just something big companies use for damage control,” I thought. It wasn’t until someone explained to me what PR was that I understood how important it is because I (obviously) didn’t understand it.

5. The most valuable advice you’re going to get will come from…

Previously successful founders. The real bitch of an incubator is that there is too much data being thrown at you.

You’re going to hear from experts in all fields — marketing, PR, sales, product management, technology, design, UX, and a bunch I’m sure I’m forgetting. Each person you talk to will tell you how important their respective field is and how if you concentrate on this one thing you’ll be successful.

The only people that really know what is important to starting a company are the people who have done it. Even then, realize that it’s different for everyone to a certain degree and highly subjective to how far along you are.

Consider the following bit of code with spec:

class User
  attr_accessor :username
end

class Project
  attr_accessor :users

  def add_user(user)
    raise "User is already on project" if user.users.include? user
  end
end

it 'should not allow you to add multiple users to a project' do
  user = User.new
  project = Project.new

  lambda {
    project.add_user(user)
    project.add_user(user)
  }.should raise_error
end

In this obviously contrived example an error will be raised…but it won’t be the error you expect. You’ll get a NoMethodError! rspec lets you check the type of error raised, so here is a better alternative — notice the differences on linew 1, 11, and 21.

class DuplicateUsersError < StandardError; end

class User
  attr_accessor :username
end

class Project
  attr_accessor :users

  def add_user(user)
    raise DuplicateUsersError, "User is already on project" if user.users.include? user
  end
end

it 'should not allow you to add multiple users to a project' do
  user = User.new
  project = Project.new

  lambda {
    project.add_user(user)
    project.add_user(user)
  }.should raise_error DuplicateUsersError
end

Now the spec will properly fail as the wrong type of error was raised!
]]> http://bradhe.wordpress.com/2011/08/09/always-check-error-type-when-using-raise_error-matcher/feed/ 0 bradhe http://bradhe.wordpress.com/2011/06/26/a-sneaky-rails-3-bug-in-logging/ http://bradhe.wordpress.com/2011/06/26/a-sneaky-rails-3-bug-in-logging/#comments Sun, 26 Jun 2011 20:26:59 +0000 bradhe http://bradhe.wordpress.com/?p=215 ]]> When locally debugging a production issue today I kept getting this message when starting the server:
Rails Error: Unable to access log file. Please ensure that /path/to/rails/app/log/production.log exists and is chmod 0666. The log level has been raised to WARN and the output directed to STDERR until the problem is fixed.

Despite the fact that the file was indeed present and accounted for (permissions-wise — not exactly 0666 but perms matched other log files):
-rw-r--r--   1 brad  admin        0 Jun 26 13:07 production.log

As it turns out, there is a “bug” in Rail’s logger configuration code such that if an exception is thrown during configuring the logger it just tells you it couldn’t get to the file. This isn’t so much a bug as just a poorly-worded error message.

The Fix

The root cause of my issue was that in configs/environments/production.rb I was configuring logging like so (legacy Rails way, apparently):
config.log_level = Logger::WARN


When I should be configuring it thusly:
config.log_level = :warn


After changing configuration, everything worked just dandy.

How was this bug originally manifested?

Interestingly, I originally started looking in to this because (surprise surprise) logging wasn’t working in production! This fixed the issue.

Add the Resque tasks to your Rakefile

Herp derp. I have no idea how I missed this twice. Make sure you include the rake tasks in your rake file by adding

require 'resque/tasks'

to the top of your Rakefile. If you don’t rake won’t know how to start the Resque worker.

/www/integrand [ master* ] $ QUEUE=* rake resque:work
(in /www/integrand)
rake aborted!
Don't know how to build task 'resque:work'

(See full trace by running task with --trace)

Add a script to start your Resque worker

The syntax to start Resque workers is (marginally) verbose. Make your life easier by adding a script to your script folder. All you really need is the following:

QUEUE=* VVERBOSE=1 rake environment resque:work

The VVERBOSE argument, not suprisingly, tells Resque to use very verbose logging to the console. The “environment” argument has Resque load the full Rails environment (read: Your models!) for it’s jobs.

An example would be a hand off process I’ve been helping refine. One team writes features/modifies functionality for an automation process and the other is responsible for the management/operations of said automation. For whatever reason, the ancients dictated that the maintenance team must write the configuration files for the automation.

Hind sight is more probably like 20/120 when dealing with process

Obviously, it’s been a bumpy road any time there is a hand off between the maintenance team and the operations team. The short-sighted process that dictated the maintenance team must maintain configs resulted in a healthy dose of environment-related problems — files in different locations than anticipated, missing metadata in various places, etc.

After the two teams got fed up with bickering about who broke what the proposed solution was a “handoff checklist.” For whatever reason people default to adding documents when something goes all wonky. While it seems like an “easy” fix, man, that’s such a pain in the ass. To get a new document in place the teams must agree upon a strategy for where they should be stored, what format to use, how they will be maintained, who will maintain them, how to backfill for existing artifacts, and a whole bunch of other scenarios.

Avoid process-overload by modifying existing processes

That’s a lot of man hours and added frustration to fix the core issue: Operations should maintain the configuration. It’s their environment, it’s their automation process. By modifying the existing process (in this example, forcing poor ops to maintain the config) you can save a lot of energy.