5 ms·

"Not surprisingly, most of the women were domain experts solving a problem they themselves had. That's something that tends to be true of successful founders r

"Not surprisingly, most of the women were domain experts solving a problem they themselves had. That's something that tends to be true of successful founders regardless of gender." How much domain experience is necessary to solve the problems you have. isn't that something you learn/pick up once you start solving em?

dragonwriter 12y ago
> How much domain experience is necessary to solve the problems you have. isn't that something you learn/pick up once you start solving em? If you are a domain expert when you start, then the problems you have are more likely to be real, significant problems in the domain, and your attempted solutions are more likely to be both novel and well-considered in terms of the problem than is the case for someone with less domain expertise at the outset.
- pskittle 12y ago
  edited you make fair points. However the most common advice you get is , "focus on user experience". Most domain experts focus more on the tech as opposed to users. Also some of the great/successful startups have been started and run buy people who've never done it before.
  - dragonwriter 12y ago
    > However the most common advice you get is , "focus on user experience". Most domain experts fail to do that. A domain expert scratching their own itch often is unwittingly focussing on UX of the target audience, which is one of the reasons that open source tools by and for developers that don't have a lot of deliberate focus on UX beyond what works for the people building it often are fairly good, while the same kind of things built by developers in more consumer-oriented markets often have very bad UX. Ultimately, its the same principle as dogfooding -- the most effective way to really understand UX deeply is for the developer to be the target user.
    - pskittle 12y ago
      are you talking out of experience of being in a founders shoes? asking just to get some context
kasey_junk 12y ago
I think that people assume the job of startup founders is solving domain problems, when in reality it is about selling solutions to domain problems (and the various infrastructure that goes around that and starting a business). If you are not a domain expert when you start this process, it is just one more, very big thing you will have to learn.
- dragonwriter 12y ago
  > I think that people assume the job of startup founders is solving domain problems, when in reality it is about selling solutions to domain problems Well, really, the job of startup founders is to sell an entity that itself sells solution to domain problems, but there are three parts of that that the company needs to do: 1) being able to build a solution to a domain problem, 2) being able to build a company that can sell it, 3) being able to sell people on the ability of the company to sell the solution to the domain problem. Ultimately, #3 is what startup founders are about, but the people they are selling to really want proof of #2, and the market that will determine whether #2 succeeds wants #1 to work. Sure, you can build either #2 or #3 (or both) on smoke and mirrors without having the basis that they ideally rest upon, but then you are hoping that no one catches on before you've cashed out. All other things (including sales skills) being equal, you'll sell better with a real product -- whether that product is the domain solution or the company that sells the solution.

dragonwriter 12y ago

> How much domain experience is necessary to solve the problems you have. isn't that something you learn/pick up once you start solving em? If you are a domain expert when you start, then the problems you have are more likely to be real, significant problems in the domain, and your attempted solutions are more likely to be both novel and well-considered in terms of the problem than is the case for someone with less domain expertise at the outset.

pskittle 12y ago
edited you make fair points. However the most common advice you get is , "focus on user experience". Most domain experts focus more on the tech as opposed to users. Also some of the great/successful startups have been started and run buy people who've never done it before.
- dragonwriter 12y ago
  > However the most common advice you get is , "focus on user experience". Most domain experts fail to do that. A domain expert scratching their own itch often is unwittingly focussing on UX of the target audience, which is one of the reasons that open source tools by and for developers that don't have a lot of deliberate focus on UX beyond what works for the people building it often are fairly good, while the same kind of things built by developers in more consumer-oriented markets often have very bad UX. Ultimately, its the same principle as dogfooding -- the most effective way to really understand UX deeply is for the developer to be the target user.
  - pskittle 12y ago
    are you talking out of experience of being in a founders shoes? asking just to get some context

kasey_junk 12y ago

I think that people assume the job of startup founders is solving domain problems, when in reality it is about selling solutions to domain problems (and the various infrastructure that goes around that and starting a business). If you are not a domain expert when you start this process, it is just one more, very big thing you will have to learn.

dragonwriter 12y ago
> I think that people assume the job of startup founders is solving domain problems, when in reality it is about selling solutions to domain problems Well, really, the job of startup founders is to sell an entity that itself sells solution to domain problems, but there are three parts of that that the company needs to do: 1) being able to build a solution to a domain problem, 2) being able to build a company that can sell it, 3) being able to sell people on the ability of the company to sell the solution to the domain problem. Ultimately, #3 is what startup founders are about, but the people they are selling to really want proof of #2, and the market that will determine whether #2 succeeds wants #1 to work. Sure, you can build either #2 or #3 (or both) on smoke and mirrors without having the basis that they ideally rest upon, but then you are hoping that no one catches on before you've cashed out. All other things (including sales skills) being equal, you'll sell better with a real product -- whether that product is the domain solution or the company that sells the solution.