Ben Halpern (@bh), the creator of Dev.To…
Ben Halpern (@bh), the creator of Dev.To, shared an interesting idea on the podcast (out next week) about how too many founders focus on originality early on. Said it's better to simply clone what works for your MVP, then innovate on top of that. He did that with Dev.To, which essentially began as a Medium clone.
This really resonates with me. The early Indie Hackers community was a Hacker News clone in many ways. This social feed is, to begin with, a Twitter clone.
I think it's a really good idea to clone first, then look at evolving the idea to add some features not in the original.
Or like dev.to and indie hackers have done, focus on a niche and build the product ./ service for that niche.
This of course is about the start. What it grows into 5 / 10 years down the road can be anything. Just don't try to invent a market that might not be there when you have an audience of 1.
Sounds like good advice but draws so many questions to mind haha. I assume then your unique selling point for your MVP needs to be something basic like better, faster, cheaper? Otherwise how do you convince a user to use your product if it’s just a clone? Guess I’ll just have to tune in to learn more! 🧐
By getting "more of the job done" if that's possible. Look at what people are complaining about with regards to existing solutions and see if you can carve out a segment of customers that you could serve with an offering that addresses their needs better.
Easier said than done though.
As @serversncode pointed out, it helps to pick a niche. IH focused on indie hackers, whereas HN and Twitter are much broader. Dev.to focused on developers, whereas Medium is much broader. Ofc we're both community sites, but I think this applies just as well to SaaS products, etc.
Makes sense. Better to have loyal users in a niche product than fickle ones in an everything product. I’d assume another key value is it helps you keep a more focused feature set.
That's one good approach; starting out with a clone is a great way to learn about building, selling, and all the details about starting a business, and it also can reduce risk. It reminds me of a story...
One of the first companies I worked at was a game studio whose origins was with contract work, their first success was creating downloadable pinball video games based on very popular IP. The designer and owner of the business was already familiar with designing pinball games, but while the design of the pinball "tables"had a unique design, it wasn't neither a new type of game nor an original IP, just an iteration of an existing concept. The success of the project and the income paid by the IP holder led them to continue on and build bigger products, get an office, and hire more people. The business is still around today, after ~15 years of business with now about 100 employees and it's been awarded one of the best companies to work for in the city they are located.
Ooh not sure I like that. Agree on the originality point, but surely that's more a symptom of the founder being
ideadriven vsproblemdriven?As you describe it (this social feed being a Twitter clone, for instance), for features cloning an existing implementation makes a lot of sense. No point reinventing the wheel. But you're working on it with a really good sense for the problem, which most founders don't have when starting out.
Good point, you do need to have a deep understanding of the problem. But I'd submit that people who set out to build a totally innovative solution just because fall prey to the same tendency to fail to understand the underlying problems. (Am I getting deja vu or have had this exact same back-and-forth before, but about a totally different theory? 🤔)
Two interesting things:
I suspect the answer is somewhere in the middle. Dev.to was innovative, because it was bringing Medium to developers. The "Medium" part of it was derivative, yes, but the part about adopting it for developers required some thought about the problem.
So maybe the advice is best stated: You don't necessarily need to innovate on the user experience at first just because you're tacking a unique problem.
Yes I think we have.
Agreed.
I feel like that's almost the exception which proves the rule. I'd submit that, in the vast majority of cases, successfully innovative products (as opposed to needlessly or detrimentally innovative products) are the result of a founder understanding the problem so well that what they build doesn't seem innovative to them - it just seems the obvious, most impactful solution to that problem.
I think so, but normally in a negative way. A potential competitor can see and copy 80% of what any software product I build does pretty easily. But not understanding the 20% they don't see (and why I do what I do) is going to cause them problems.
Also, I'm probably making a lot of mistakes myself. So by copying my product, you fall into the trap of constantly being 2-3 months behind me product-wise.
You can see exactly the same problem in swimming - many 'junior' coaches can't actually swim well themselves, and teach kids to swim by saying "well Michael Phelps moves his hands and shoulders like this, so you should too."
But because they don't understand why or how MP moves like he does (by focussing on the hips and core rotation), the coaches end up with kids who superficially look like they're swimming with a good technique, but who generate no power and damage their shoulders within a few years.
Nice.