I thought they were advocating for creating and testing marketing material before the product itself.
But then I read they noticed traction because people started submitting pull requests and trying out the code. At that point, they already had some product.
So what are they advocating for? Is it just a different way to look at an MVP? Where you focus on creating something that can test traction instead of creating something that can deliver value?
Author here: Sorry about the confusion there :)
We started with a single landing page and readme. Already with this people started starring it and a few even joined the Slack community. We also got strong interest in calls and a few “oh wow that sounds like exactly what I need!”.
At this point we started building a working product and the pull requests came a few days after we published a first version of that.
In the article says: "It only had a simple landing page and a Readme on our GitHub repo". So they started getting pull requests without any product (is what I gather). So they are advocating for the classic MVP experiments before building the actual product (No idea why they renamed it to "MV Positioning", when MV Product is exactly the same thing).
This is what I thought too but it doesn’t make much sense.
My understanding is they fumbled around in the dark until they found something people might want and later, once they started building it out, they started getting pull requests.
This disappointingly reminds me of that post a while ago from the guy who finally got into YC after 8 tries or something, not because he found a great problem to solve with a great solution but because he really wanted to get into YC and found a formula that would at least open that door (small business CRM).
If you want to find traction without a product, I strongly recommend reading "The Mom Test" and following the advice in there - it's going to get you much farther than what this team did. If you don't want to do that, at least follow the often-repeated advice of YC itself for startups:
- Scratch your own itch
- Be in love with the problem
- Talk to potential customers to find what they need, not what they want
Then you can iterate on an MVP like this team did, but hopefully with less wandering and head scratching in the beginning. If your starting goal is "I want to start a startup" and you then go looking for a product to shoehorn into a market, I think you're doing it wrong and you should probably stick with working a day job.
3. Talk to potential customers to find what they need, not what they want
What if {{1} ∩ {3}} ∪ {{2} ∩ {3}} = ∅?
That is, what if everything you love to do is not marketable and the solutions to the problems you care about are not marketable either?
> If your starting goal is "I want to start a startup"
My starting goal is "retire by 50 without taking a hit to my six-figure lifestyle".
Achieving it via my technical chops is the only way I know how.
I'm a bad investor and my wife is a spendthrift. It's highly doubtful that we'll get there "the slow way" (e.g. collecting on several corporate real estate investments) by starting at 34.
I work as a Software Engineer. I'm not passionate about the projects I work on at my job, but doing so pays the bills.
Why can I not make use of the same discipline that brings me into work everyday to bring my own product to market?
__My issue is in identifying what other people want.__
The CS & programming topics that excite me (i.e. compilers & PL design) haven't had marketable products since F/OSS won in the '80s/90s. The backscratcher I'd design to scratch my own itch(es) can't compete with thousands of free ones worked on by an order of magnitude more people.
I highly doubt every successful payroll/billing/HR startup founder was intrinsically-motivated to build their product.
I'd be satisfied building boring CRUD like https://bonus.ly if I could turn it into a small, successful "Lifestyle Startup" and coast.
It's like API indexing, I like it. I started M3O (https://m3o.com) with this idea of API aggregation for absolutely everything but not specifically indexing, more so providing a uniform access layer to all things with one API token. The programmability of Nango will definitely a be a selling point. For the founders, focus on that, double down on that. The ability to program the APIs and the data retrieved is really key.
Kinda random question, but is there a name for the theme/style used in your website? I like it and I know it's pretty common (dark, minimal, pink, gradient, etc.) but not sure if it has a name. It looks like you used tailwind css. Just looking for more specifications on this type of style.
Huh. It feels like their overall goal was "to start a start-up".
I'll admit, I'm used to stories of "I saw problem X, so I founded Y".
But I like their approach of iterating on problems to offer a solution for.
Especially, as the author of WinRAR is no doubt very aware of, people do prefer their problems solved for free, so if you're getting paid, you've found that gap, nice :)
"...Strangers would star our GitHub repo. One Saturday, whilst I was hiking, my phone started vibrating: Pull requests and issue comments from people trying Nango started flowing in.."
The writing and appearance apart from that would suggest they want to build a startup not just an open source project so i would be hesitant to write a headline like that without even a pricing page.
We have some more details on (future) pricing in the docs but will look into making this more visible on the website.
Pricing info: https://docs.nango.dev/license-faq#pricing
But then I read they noticed traction because people started submitting pull requests and trying out the code. At that point, they already had some product.
So what are they advocating for? Is it just a different way to look at an MVP? Where you focus on creating something that can test traction instead of creating something that can deliver value?