Also, you can take risks that they may be unwilling to take. You don't have group-think to worry about. You can use tools & languages that it's too hard to hire for. As this is a PG site, consider functional systems. I'm a huge haskell fan myself, and holy crap is it faster to develop in, especially early on. In terms of productivity, it can be 10-15x. It's proven as such in my own work. How many devs do they have?
Look at who's funding them, perhaps try to infer some of their movements by the likely advisors they have. Ask around. Check out the founders' resumes. It's easier to get intel about a larger group than the plans of a single man. Check out what technology toolchain they're using, and find someone who's used it before, and/or other public systems that use it now. It may provide a useful source of likely avenues they'll take later (some APIs make some approaches easier), you may be able to predict them before they've even decided. With that in mind, choose your own toolchain and market focus accordingly. Are they going to have any nasty chokepoints later, in terms of necessary features that aren't supported by their toolchain, or performance bottlenecks that'll squash their scalability/skyrocket their costs for a while?
Also, if all else fails, you've got your brain just churning away at the problem domain all day. If you want to play dirty, take out some patents on some inevitabilities in that space. Hobble them early, force them into more expensive routes (some stupid bastards will even think it's an advantage that they can afford to!). In software, it's easy & tempting to go the safer O(N) route when a riskier O(1) will do (in effort -- say writing all your entity types by hand versus an automatic derivation mechanism). A patent threat can certainly push people in different directions early. In terms of productivity, that can be a 30+ scale factor. How many devs do they have?
Put out a blog & control the narrative. The more people they have, the more mistakes they can make at a time, the more datapoints you can pick from to form the narrative your way. The right narrative can help compensate for a lack of a marketing team. Consider reading up on Guerrilla warfare.
Also, you don't have to win the market. You can just stay alive & appear useful long enough to get bought by someone else who wants to compete against your opponent.
Yeah, a good part of this is way over the top, but maybe something will be useful to you :-)
I'm curions about this too. Haskell is my hobby language right now, I'm still an uber-noob, but my impression is Haskell code is easily 10-15x more robust, but not necessarily more productive than cool-kid languages (Ruby, Python, Javascript).
Depends on what you are doing of course. But having an impedance mismatch between the language and the problem domain can make simple problems extraordinarily complex.
This is great advice for me to hear, as I'm in a similar position right now. I've been considering obliquely slamming our competitor in a blog post, but I've held off because I don't want us to come off like dicks. Wouldn't I be better off focusing the messaging on how we're doing it right, rather than how they're doing it wrong?
You can define yourself and, through the remaining empty space, end up defining them. If you define yourself as "The simple, no-frills, easy way to Foo," for example, then you're defining your opponents as one or more of: complex, extra frilly, less easy.
Publicly slagging off competitors by name seems to backfire more often than not, unless you're Steve Jobs.
However you can talk about all the ways that X is done wrong without actually mentioning by name the competitors who are doing X wrong. Clearly explain the problems you see in 'the industry' and your solutions to them, but not the other people/companies involved.
Look at who's funding them, perhaps try to infer some of their movements by the likely advisors they have. Ask around. Check out the founders' resumes. It's easier to get intel about a larger group than the plans of a single man. Check out what technology toolchain they're using, and find someone who's used it before, and/or other public systems that use it now. It may provide a useful source of likely avenues they'll take later (some APIs make some approaches easier), you may be able to predict them before they've even decided. With that in mind, choose your own toolchain and market focus accordingly. Are they going to have any nasty chokepoints later, in terms of necessary features that aren't supported by their toolchain, or performance bottlenecks that'll squash their scalability/skyrocket their costs for a while?
Also, if all else fails, you've got your brain just churning away at the problem domain all day. If you want to play dirty, take out some patents on some inevitabilities in that space. Hobble them early, force them into more expensive routes (some stupid bastards will even think it's an advantage that they can afford to!). In software, it's easy & tempting to go the safer O(N) route when a riskier O(1) will do (in effort -- say writing all your entity types by hand versus an automatic derivation mechanism). A patent threat can certainly push people in different directions early. In terms of productivity, that can be a 30+ scale factor. How many devs do they have?
Put out a blog & control the narrative. The more people they have, the more mistakes they can make at a time, the more datapoints you can pick from to form the narrative your way. The right narrative can help compensate for a lack of a marketing team. Consider reading up on Guerrilla warfare.
Also, you don't have to win the market. You can just stay alive & appear useful long enough to get bought by someone else who wants to compete against your opponent.
Yeah, a good part of this is way over the top, but maybe something will be useful to you :-)