Do “Shitty” Work
ryanhoover.me
ryanhoover.me
1) You still have to do the things that you're bad at
You're a developer/designer/architect/[insert profession] so that's what you do. You build great apps or you design beautiful pixels. That's probably what people have paid you to do and that's also what you're good at. It's also highly likely that you enjoy it. The problem is that you focus too hard on what you can do and not on things you can't do. This means that you launch products that are half-baked. Most people launch without focus on customers or marketing but sometimes it's a lack of focus on design or user interaction. The point here is that you need to start looking at things that you don't enjoy because that's probably the area that needs the most attention. Now, this doesn't mean you have to learn how to be something you're not. You can outsource it, hire someone, partner with someone... but you do need to do it if you want to be successful.
2) Do the unscalable things
This is of course copied from pg's essay [1] but it is so relevant to startups. Early in the life of a startup, you need to make sure you have excellent customer service and a thirst for growth. 'Moving the needle' is what counts - you need to do it quickly. When you're bootstrapping this can often mean cold calling or 'shoe leather'. Many first-timers brush this aside as 'old marketing' and 'it'll never work'. It does work. However, it's hard work. Focus on the things that move the needle early on, however troublesome and manual, because you then you will learn what's important enough to build. You can then automate much of what you already know and move on to the next challenge.
Getting early adopters is usually a very "manual" process, even more so in B2B startups.
My business' sales will be entirely online once (if) it gets into cruise speed. Then, the CAC will lower and the LTV will rise.
But until then, I have to spend a lot of) time cold calling, getting intros and doing the first B2B sales myself.
If I don't do this, I won't have any customers from where to compute a CAC or a LTV.
Well put.
At the end of the day, if your startup is going to succeed then you are going to have to do something amazing. If you are spending all your time stifling your own instincts to follow somebody else's playbook, you probably are in trouble anyways.
The ugly fact is, when you're creating a startup, only about 5% of your time is spent on the fun coding stuff, the main implementation of your whole idea.
The other 95% is spent on "plumbing" -- refactoring, credit-card integration, e-mail newsletters, browser bugs, server administration, and so on. And that's even before you get to things like hiring, fund-raising, and such.
Of course, it depends on your definition of quality, but for the sake of argument I'm assuming that we're including things like test coverage, code complexity, code cleanliness/readability, structural soundness (cohesion over coupling, the single reponsibility principle etc) and so on.
The point with all of these things is that as much as they might seem to be a waste of time when people can be hacking on something else, they (imho) save orders of magnitude more time than that in terms of maintenance of a codebase: being able to quickly fix issues as they occur; how quickly new developers can grok the codebase; how easy it is to add new features that were not part of the original design.
Unfortunately I have no hard data to back that opinion up, but it is what I intuitively believe to be true based on experiences.
For example, do you really need 100% unit test coverage of all corner cases?
As always, these memes are useful to guide/test our thinking, but not very useful if used without reflection.
I'm just arguing against the case I've heard from many programmers that better code is always better. At a certain point, you hit diminishing returns and lose sight of the goal.
Waiting for quality for release is always a mistake.
Release, refine and re-release. And A/B test, run the funnels and measure change as it happens.
Productivity on day #1 with bad code is a technical debt you take up - it will catch up to you if you ignore it for too long.
The day your app goes viral is not the day you want to learn about db sharding and data-architectures.
You'll want to grab all the users and keep them instead of 503'ing.
But if you do get past that phase, you can hire people like me to redo things and replace the bubblegum/fishing-line architecture with something more robust :)
The far more likely case is that your code quality is too low, which means you're sacrificing untold amounts of productivity later on. Well-written, self-explanatory code is a piece of cake for later developers to modify. Code repetition and counterintuitive naming has a good chance of wasting other people's time for no reason (if it doesn't bite you personally). In larger enterprises and startups alike, I suspect more productivity is lost revisiting badly-documented hacks than doing gold-plated "elegant" work for the first time.
In the initial stages of a product lifetime, you shouldn't focus on code quality. Releasing a crappy product beats waiting until it is well polished before releasing it, every single time.
But you should absolutely work on replacing, refining or polishing the crappy parts that turn out to be actually successful, or you'll end up in a dead end where you can't make your product evolve anymore without breaking everything. Or you'll get hit by the 'unlikely to be exploitable and difficult to fix' security flaws.
Crappy alpha code is good. Crappy legacy code, not so much.