Very helpful. In our case, our company exists to solve a problem. The problem is a combination of a medical and design problem. (I don't want to give away anything). Before I found a hacker, I did a lot of the design work, and have been accruing medical information on my project for months.
Our strategy is for the hackers to create a demo and backend to achieve my design objectives while I flesh out the rest of the medical research.
Armed with a demo and medical research, I will be able to prove to potential partners and angels that there is a big medical problem, that design can solve it, that much research, when considered together, provides a picture of haw to solve the problem, and that I solved it. Then I will find a partner for business aspects and look for funding.
One thing I'm definitely not doing is trying to get fat on the work of others. I don't want to say that I don't care about money, but my motivation is entirely solving this problem. I need hackers who want to be partners and are excited to grow a company they have a good stake in.
Thanks for typing so much, it's very helpful and constructive.
At the risk of sounding too critical (which isn't the point), allow me to help you hear yourself:
Our strategy is for the hackers to create a demo and
backend to achieve my design objectives while I flesh out
the rest of the medical research.
This is exactly the kind of thing I want to warn you against. If the hackers are your partners (as they should be), then "my" design has to become "our" design. Invite your hackers to make suggestions and tweak your design. Have a whiteboard fight (what's better than a whiteboard fight?). Take their suggestions seriously, and if you disagree, don't be dismissive: try to convince them why they're wrong; get buy-in. If you can't get buy-in, then either your design is broken, or these aren't the hackers you're looking for. Then once you're all on the same page, turn them loose on the implementation while you get busy with your medical research. To my mind, that is a better way to divide labor without losing the sense of partnership.
Armed with a demo and medical research, I will be able to
prove to potential partners and angels that there is a
big medical problem, that design can solve it, that much
research, when considered together, provides a picture of
haw to solve the problem, and that I solved it. Then I
will find a partner for business aspects and look for
funding.
This sounds great!...except, make ...that I solved it... into ...that our team solved it... - because once you take on partners, you're partners. Founders really have to be able to swallow some pride and share ownership to keep everyone on board. You may be the leader, but especially at this stage, being the leader shouldn't mean a whole lot other than a job description.
Even in your language you have to be careful about the messages you're sending to your partners to make sure that they are, indeed, partners. When you take on partners, your vision has to become their vision, and you have to be willing to let your vision evolve with new blood and new ideas (obviously, you don't want to loose the essence of the business...)
Consider the result of a subtle change in language:
Armed with a demo and medical research, I will be able to
prove to potential partners and angels that there is a
big medical problem, that design can solve it, that much
research, when considered together, provides a picture of
haw to solve the problem, and that our team solved it.
Then I will find a partner for business aspects and look
for funding.
This is much better, because it's evident that your hackers are your partners, and that the things you're doing for the venture are valuable (performing a demo, persuade partners and angels, find funding, find the additional talent you need, and medical research skills).
Again, I hope you find this helpful. This is all stuff I've been reflecting on a lot lately, so it just comes pouring out of my head through my fingertips.
I made the mistake of joining a small company where the founder did the exact opposite of everything you have described: the product was his, the plan was his, and the design meetings inevitably degenerated into lectures on why we (his employees) didn't understand the market we were in, and therefore weren't qualified to do anything but follow his guidance. There were certainly no whiteboard sessions (after all, why would you need a whiteboard, when you can just describe what's going to happen using a powerpoint presentation?)
The result was terrible morale, and a bad product. Where we should have been reacting to the demands of the market that we were in, we were plodding along a pre-determined path to failure, without the ability to change strategy or tactic.
As a result, I now have a well-developed filter for people who have this tendency, and I avoid them like the plague. Comments like "I'll flesh out the design" immediately send me running.
Please don't worry about sounding too critical. Just be honest. This is much more helpful with the true critical parts not obscured by worry about hurt feelings.
That "I solved it" is painful. That is very obvious. Gotta get rid of that mindset.
I used the term "Design objectives" from a medical protocol standpoint. We're working together closely to translate the protocol design (which I have objectives for, in the form of information flowing between components of the system, and providing certain outputs and inputs to patients and doctors) into technical designs (which the tech guys make). We are tracking areas where we disagree as open questions on a wiki, and we revisit them once we've done more research and thinking. I'm not giving them pages of screenshots and saying make it work, I'm saying the medical system must move information like this, and that creates a technical puzzle as part of a medical puzzle. I don't override them and I encourage them to be as critical and creative as possible.
Thanks again for your comments. That "I" thing is something I will watch carefully for and is good to hear.
We should talk more. I'm not going to be at start-up school though. I live in Washington and can't make it. I'm thinking about shooting for the next one (if it wouldn't be a distraction from the booming business development and R&D of my prosperous company by then ;P ).
EDIT: I guess to talk more you probably need this. lifepod technology systems (as one word) at the gmail.com one.
Our strategy is for the hackers to create a demo and backend to achieve my design objectives while I flesh out the rest of the medical research.
Armed with a demo and medical research, I will be able to prove to potential partners and angels that there is a big medical problem, that design can solve it, that much research, when considered together, provides a picture of haw to solve the problem, and that I solved it. Then I will find a partner for business aspects and look for funding.
One thing I'm definitely not doing is trying to get fat on the work of others. I don't want to say that I don't care about money, but my motivation is entirely solving this problem. I need hackers who want to be partners and are excited to grow a company they have a good stake in.
Thanks for typing so much, it's very helpful and constructive.