

Ask HN: Curing Founder ADD - 147

I saw Emmett Shear&#x27;s startup school talk a few days ago. He talked about he and Justin had &quot;founder ADD&quot; at the beginning.<p>They would start an idea and get off track with other ideas and launch&#x2F;work on them only to have them fail and go back to the original idea.<p>I was wondering, other than finding another cofounder to be your &quot;parent&quot; how do you guys focus and commit onto one idea at a time?<p>Link to talk if anybody&#x27;s interested: https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=cQ3tZ05KCtw&amp;feature=youtu.be&amp;list=PLQ-uHSnFig5OyY5JWSQrl_gESiEUJxe1m
======
anigbrowl
I have actual ADD, and I'm going to suggest something you'll hate: waterfall.
Identify your MVP and some obvious desiderata, and then break it down brutally
into small, small chunks. Build pieces each day, set cutoff points, and then
troubleshoot for a little while at the end of every day over a beer on how to
adjust for the day's successes/failures with minimal changes to your overall
schedule.

This is how it works in film production where I make my living and where a
very high percentage of people also have ADD - it's an asset in that context
because you need to be able to focus on detail issues for many hours at a
time, but also to be able to pivot rapidly in response to changing
requirements of environmental constraints or unexpected problems.

Now it's true that you can sit down with the idea to write some code and just
start doing it. And I love to work that way on things a lot of the time. But
it's also a trap because without a Big Plan then you just end up bouncing
around like a pinball between different problems. Now, the Big Plan is not
that much fun because planning is actually kind of a tedious grind.

For a film you go through the script just doing a _ton_ of data entry on every
goddam thing that gets mentioned on the page, and adding in things that
aren't, eg if there's a scene where a character is eating dinner you realize
you have to make ten records for knives, forks, plates, napkins, wine glasses,
bottles of wine, fruit juice to replace the actual wine, real food, fake food,
yadda yadda yadda. The script here is analogous to your user experience map or
functional specification or whatever you want to call it.

I have no idea what your product/service is but I assume that the more closely
you try to document it the more the entries on your task list multiply...the
header files, the libraries, the makefiles, the VCS, the blah blah blah.
You're sitting there thinking 'damn, let me just write some code already, get
something up and running here, when it gets a bit messy we'll pause and sketch
out the next stage...'. And of course you can, if you're smart and creative -
same way if you get a bunch of actors and creatives, a bunch of props, and a
camera package, you can start shooting some fun sketch comedy or
improvisational work...but you'll very rapidly hit a wall in terms of the
amount of complexity you can juggle on the fly. So to get anything done, you
and your team sit there and plan, and plan, and plan. You pick tools, do some
rough tests to see if those tools will hold up, and then design around them,
but you also plan for a back up tool and plan for who to call if your
toolchain collapses.

You sit there and plan and allocate time and argue about it, which is
_intensely frustrating_ because it's not as much fun as actually doing it, and
you work for days with no more output than an ever-expanding to-do list on an
ugly spreadsheet/project management file. But the good part of this is that
the structure of your project and your pain points gradually become clear
before you start production work, and you go into that phase knowing what your
priorities and constraints are. I can't stress the importance of this enough,
because when you run into problems, it's that intimate knowledge of priorities
and constraints that will help you to make decisions about when to press on,
change tack or abandon something.

------
smt88
It's all about discipline. You have to commit to one thing at a time, prove
that it works or doesn't, and then move on.

If you're changing ideas, it should be because your clients told you the idea
you're focusing on wasn't going to work. Whether that happens before or after
you create the prototype is just a matter of how honest you can get your
audience to be.

I've seen far more companies fail at this than succeed. In my limited
experience, it's what defines a successful founder: the ability to have laser
focus, execute, and then know when to move to the next thing. Too early and an
opportunity is lost, and too late and time is lost.

Unfortunately, no amount of advice can prepare you for knowing the right
moment. A lot of it is luck (despite what anyone tells you), and the rest of
it is just going to depend on the context. There are very few generalizations
you can make about it.

I know that wasn't very helpful, but you're basically asking us to unlock one
of the things that every entrepreneur is trying to unlock. I don't currently
know of a magic key.

------
ulisesrmzroche
A lot of people work on their products at the same time that they are
contracting/consulting on the side, so I feel running multiple businesses is
actually pretty common.

It's totally ok to tackle multiple projects at a time, though, and sometimes,
like in the case of freelancing, its also a good strategy in order to avoid
any outside investment.

The trick is to find the right product, which which develpment work, that's
always in demand, and thus a pretty safe bet, and then your own idea, which
you're kind of trying to prove at the beginning.

