3 min read

Multiple products, same product

Multiple products, same product

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 idea was so easy that I’ve seen the market being flooded with new “solutions” doing just that. Some of them were just simple WordPress sites where someone would share a set of products, some other 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 not as valuable – and, for this and other reasons, I quickly moved away from it and 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 ways, or has the world “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 research online and write. It’s permission-less (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

Being fast

Let me know what you think on Twitter. I’m at @mikerubini.

Thanks for reading,
Mike.

===

##Enjoyed this article?

Join my newsletter to learn when new products are launched, as well as other stories from the trenches. People from great companies like Facebook and Hubspot read my newsletter.