4 ms·

Ask HN: Curing Founder ADD

• smt88 12y ago
  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 12y ago
  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.
• anigbrowl 12y ago
  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.