Multiple products, same product

Do not index
Do not index
I previously wrote about how multiple products can end up looking like the same product.
 
In a similar fashion, even if you take two different products, with different designs, with different team sizes, etc – your target market will think that they generally do the same thing.
 
And, that has nothing to do with design.
 
Aligned with the JTBD framework, and maybe stressing the concept further, I believe that customers hire a product to solve one problem and one problem only.
 
I also believe that customers do not care how you do what you do (to a certain point, of course).
 
Lately, I’ve seen a trend where the line between software products,  “no-code” products, simple newsletters, and communities has become blurry.
 
For example, the first version of my e-commerce software product, Cart, had a section with so-called “winning products”.
 
These were lists of in-demand products with ready-to-go advertising interests, videos for your marketing creatives, vetted suppliers, and more.
 
Dropshipping was booming at the time, maybe more than ever, and everybody was selling newbies the idea that e-commerce could be plug-and-play: copy and paste this product into your Shopify store and you’ll make money.
 
Selling this concept was so simple that the market has been flooded with new "solutions" that do exactly that. Some of them were just simple WordPress sites where someone would share a set of products; others were just communities.
 
Some of them would just subscribe to the competition, then resell the same products to another audience, basically doing arbitrage.
 
At one point, I counted 2 or 3 of these “solutions” entering the market every week.
 
Eventually, of course, selling winning products became less valuable – and, for this and other reasons, I quickly moved away from it. Cart now has another unique differentiator.
 
The point here is that, in the mind of the customer, it doesn’t make a difference if you are a community, a SaaS, or a newsletter.
 
I used to believe that building code was a deep enough moat, and that customers would notice the difference. That is simply not true.
 
I’m now seeing the same movement with my other software product, Treendly.
 
If you don’t know, Treendly spots rising trends in different industries and countries, and it’s a pure-play SaaS.
 
I’ve seen Treendly being compared to Trends.vc or Trends.co, or other similar products that frankly have nothing to do with Treendly in the sense that, while they might respond to the same need, they handle things substantially differently. Basically, these are completely different products.
 
Again, though, just because each one of us deals with trends in some way, or has the word “trend” in the name – they end up in the same mental space for the customer.
 
The barrier to entry is also very low: anyone can get up tomorrow and write about trends, and not even build technology for it. He/she can just do research online and write. It’s permissionless (which, btw, I like).
 
Now, building successful products has increasingly more to do with creating a category of one.
 
I’ve been interrogating myself on how to do that, how to build a moat that can last.
 
While code is becoming more and more a commodity right now, I do think that there’s still space for me to build my moat with a combination of technology and marketing.
 
I think it comes down to these 3 things:
– Picking up hard, complex, problems
– Owning a marketing channel
 
Let me know what you think on Twitter. I’m at @mikerubini.
 
Thanks for reading,
Mike.
Mike Rubini

Written by

Mike Rubini

CEO