Unfortunately your competitors don't need your skills to copy you; once you make your thing public, everybody will see how to do it and copying your product becomes trivial. But the good part is that only successful projects are copied, so you really shouldn't worry about it -- when people start copying you, it means you are on the right track.
People copy when they know it's worth the risk. That's why successful projects are copied. I agree with you that it is a very good indicator that you are on the right track. :)
All this design work isn't necessary when you copy something. Someone else has already done the design work for you. You can lean back and say: "The solution is obvious." Then you only need to implement it. In my experience, the implementation always seems trivial in comparison to the design process.
But you are right, people who copy stuff often make poor copies. I think the problem is that they probably don't fully understand your design. They see how you solved something, but they don't understand why you solved it that way.
Finally, I don't think a rebuild is the same as a copy, because you generally only rebuild when something doesn't work. And then you actually need to put a lot of design work into the rebuild process -- that's why it's hard.
Most developers I know find that the most difficult part of product development is sales. Design is also difficult but I'd recommend treating it as a process rather than a project when it comes to new products in new businesses. Design will never be done and it can always be improved, copycats will always be two steps behind or they'll fork into a different direction.
I know of financially successful products where the teams behind them don't know why the design they have works. They've even had situations where they've improved the design in their view and it's been well received in user testing. But when they release it, it has a negative impact on sales, retention or some other core metric. Imagine trying to copy a counter intuitive system like that?
If you have something where the core value is obvious and can be copied with ease you've probably released too late. Even in that case it would be pretty impressive if your marketing was so good that it found someone who could copy it. After removing the design part there are still very few people in the world with the time and resources to focus on building a copy right now. I'd guess that most people who think about copying will more likely become very good customers of yours, they can then have more time to work on their own ideas.
You'd think that Twitter with all their resources could have copied Instagram in a snap. Instead, when he saw the product and the traction, the founder of Twitter invested in it. He then got upset when Facebook brought them and is only now copying them.
Of course, now that Twitter is established, you cannot repeat their mistakes if you want to succeed.
There's more to a business than the code of its products.
Or products that are so brilliant that it's immediately apparent they'll be successful
Well, being a businessman sometimes makes sense.
But usually I deliberately pick being an engineer and not a businessman. Doing business takes a different mindset and a lot of time; it's not easy to do both, and often not fun.
If the title of the post was longer it would have been "10 Things You Should Shout at Brilliant Web Developers Who Are Building a Product for Financial Independence"
Once you have financial independence or don't want a product of your own you don't need to be a business person.
The great thing is, once you successfully get past this ugly bit of doing business you can start ignoring this advice and making products that are better in your eyes.
Shouting "how dare you" at people who disagree on this judgement call is just stupid.
I felt an extreme position was needed to respond to brilliant but highly principled people (who I wished were joking) but I felt were saying things like:
"How dare you suggest that I would charge for something that doesn't even have feature X."
"How dare you suggest that I would ever let a design loose that I hadn't spent 6 months refining."
"How dare you suggest that we shouldn't spend the last of our savings before we launch finishing the product."
"How dare you suggest that I would ever ship a product that wasn't web standards compliant and passing every accessibility standard."
Maybe I should write a joke post that uses some of these?
As long as some web developers feel that accessibility is optional, even for a minimum viable product, they will continue to discriminate (howver inadvertently) against some users. In some cases, these users will then be barred from completing some task that is required, because they can't use a particular application, e.g. an application that's required by a particular job or course. Please don't contribute to this problem by suggesting that accessibility is an optional nice-to-have. For users with disabilities who need to use a particular application, it isn't.
We need more people like you running profitable businesses and ensuring that it is never optional in the (misguided) name of lower costs and more profits.
Unfortunately when you build an MVP for the 100% you build it for no one. If accessibility is the most important thing for you then make your product and therefore your MVP for with people with disabilities as your primary audience. I would suggest a much narrower focus than that as its sadly far too big a market to start with.
I'll try to be less confrontational in this reply.
It seems to me that you're setting up this false dichotomy: either developers working on MVPs can ignore accessibility because 90% of people have no significant disability, or they can try in vain to make an MVP for 100% of people. Of course it makes sense that one can't do the latter; when developing software in general, but an MVP in particular, one has to pick and choose which categories of users to target. One has to choose which features to implement and which to leave out or save for later. But it still seems wrong to suggest that one can ignore a set of potential users who might be a good fit for the application in every way, but happen to have a disability through no choice of their own. To get an idea of the consequences when accessibility is ignored, check out this blog post:
Maybe I'm just too close to this particular issue. after all, I'm visually impaired myself, and my boss and most of my coworkers are totally blind. Nonetheless, I believe that accessibility shouldn't be a nice-to-have feature, but something one just expects to be there, like security. A commenter on another sub-thread pointed out the absurdity of suggesting that a developer can ignore security even for a prototype. I think the same holds for accessibility. Browsers, toolkits, and frameworks can do a lot to make it more likely that an application will be accessible by default, but I think that as with security, some level of consideration from the application developer will always be necessary.
Agreed about "people with disabilities" being too broad a market to focus on. Too many different disabilities. Where I work, we focus on making our software maximally usable for blind people.
Let me clarify: I'm not saying MVP (or pre-profit product) developers should ignore accessibility. I'm saying they shouldn't spend too high a portion of their time worrying about it. If a product fails some measure of accessibility it has a bug which will need to be fixed at some point. Just because it's a bug that you are aware of and it's easier to detect than other bugs doesn't mean that it should stop you from trying to sell the product. A buggy product with some income is more likely to succeed than an apparently bug-free product and no income.
I've worked with blind coworkers in the past and have tried using screen readers myself so I have some appreciation of the challenges. Thank you for the link, it's always good to have a reminder. It sounds like the employer in question and Siebel should have had legal action taken against them. They're both clearly of a size where they can and should be doing better. This is another example of why we need brilliant web developers building businesses that can destroy backwards companies like those.
How do you get on with Hacker News? I just put it through a checker and it appears to be pretty appalling. Would it be better if pg shut down Hacker News completely until the issues it found are resolved?
There's also a far more difficult one to become aware of, which is building an overly complex solution when a simpler one exists for the problem.
Some of us are serious about delivering quality. You are trivializing 2/3 of the web application right there. If it looks like shit and confuses people, no one is going to use it, unless it meets a serious pain point and has absolutely no competition yet, which, is not the case for most of us.
When your product is not profitable you need to let your customers decide if it looks shit and confuses them. You'll know it's ready when they pay for it and keep paying. I want people to stop leaving it too long before measuring that by giving people the opportunity to buy. Too often developers leave it too long and don't have the time, money and energy to invest in all the things you also need to get right.
Also quality is something which is difficult to define and pin down, and will also vary depending on the product.
For example , a backup solution which blows away everything else in terms of innovation and usability but corrupts my data 1% of the time isn't going to get bought.
And even if they fix the 1% corruption bug I'm going to remain skeptical for a very long time.
The negative impact of releasing an unfinished project is almost always enough to make a developer wait until their product is finalized.
Most intelligent people realize that they are most likely not the MOST intelligent person in the world; therefore releasing an incomplete product, when they unsure of a final release date, only opens them up to the risk of being copied and outdone.
If you do a big PR launch too early at the very least you'll close down a channel (e.g. TechCrunch readers) at worst everyone in the web startup industry will have heard about you.
The most successful products have people that both love them and hate them, you can't make everyone happy and you will loose some customers to unfortunate experiences. Fortunately the if you've chosen a good market there are probably more customers than you can ever hope to find out about you.
> Isn't there a risk that releasing a product too early
> could cause a negative first impression and by the time
> you have gotten around to improving it, everyone has
> lost interest?
* you have a large market, and there are plenty of new
* the cost of your sales cycle is really cheap, i.e.
low-touch, online sales.
If the first, second or third developer of mobile phones made them out of aluminium and glass rather than plastic do you think they would have been more successful? How about if they gave them away for nothing, or with a total return less than cost price?
If you want quality to be your differentiator, you need to already have easy access to a proven market for your core product.
These products are very rare compared to those which are an evolution of an existing concept. Even with other differentiating factors you are going to struggle to sell a product which has a perception of being below par in terms of quality.
If you speak to customers it's surprising how groundbreaking they feel very simple things are.
Competing on quality isn't yet as important on the web as many people in our industry seem to think. Just look at all the crapy project management, time tracking and build your own website tools out there. Many of the ones you think look bad and are poorly built have customers that love them and profitable businesses built on them them.
I want quality to be a more important factor in web products but the only way that's going to happen is for more brilliant web developers to be running them. Once they have profitable businesses they can switch to putting quality first.
Web products is not really a homogeneous category either and spans everything from social networks to specialized applications for industry.
Many of the competitors that have launched and have fallen into obscurity from your point of view are actually generating healthy profits from a few thousand customers in an industry you don't know.
There are huge opportunities for brilliant web developers to release a first product, or version of a product, in an obscure market and use the profits to build something amazing with wider appeal.