I don't like this new startup trend[1][2], nor do I think it actually works.
Literally all of those examples are the opposite of what the blog post is claiming. They did have a product: Hotmail had the service built out, Eventbrite had the service built out, and there was a Dropbox before you could refer your friends to it. There are examples of what the author is claiming, but most are gimmicky Kickstarter-style (and often derivative) products.
I mean, think about Dropbox or Slack or Instagram: how could you possibly sell (or even validate the idea of) those products without actually giving some sort of demo? Without people actually using that thing? It might work for something like the product in the post (people understand what "video chat" is), but I don't really see it working for any kind of particularly novel or value-generating product.
Followup: grabbed a coffee, and this post got a bit of attention. To be clear, I think that an MVP should be just that: a minimum viable product. By definition, you shouldn't be able to go leaner. I also think that sometimes people conflate "fake it 'til you make it" with PG's "do things that don't scale" -- these two are not the same.
[1] https://tommorkes.com/lean-launch-how-to-sell-an-idea-before...
[2] https://hbr.org/2013/12/sell-your-product-before-it-exists
In general though, you definitely should work on figuring out if customers want your product without building it if at all possible, and most times it is possible. I run a SaaS that's a project management tool (todo list + calendar, basically, at https://getartemis.app) and the main page is simply a video demo that I made with Figma and an animation tool called Principle. People signed up and it works great for showing users what they'd be getting in the future.
This is not true, the video used a few clever techniques (cutting/editing) to make it seem snappier and more responsive, but Dropbox was very much a real (albeit beta and buggy) product when the video was made.
I think strategies differ depending on:
- How new the market is for that particular product
- How big of a risk is it to adopt your product vs alternatives
- How polished it looks (inverse relationship to how many solutions already exist)
In some cases, you may need a much more polished MVP to get people to bring out their credit cards. If your product is the only one of its kind (and is in high demand), the UI is less important in v1.
It's important to at least have a strong growth hypothesis that you've validated to some degree.
That's all I have right now - hypotheses.
This blog post captures some of the differences: https://archive.is/wip/tnm2D (skip to conclusion). This one elaborates what an MLP is: https://medium.com/the-happy-startup-school/beyond-mvp-10-st...
I've never done this, but it makes sense. Why spend the engineering effort to go from Demo --> BVP --> MVP when you can just do the first jump and test the idea.
Everything is on a spectrum and -- given the vast graveyard of random ideas engineers build as side projects -- we should figure out a better way to drive better yield.
On the other hand, I've seen organizations using this "BVP" approach for absolutely everything they build, which I've come to view as a sort of product development antipattern, reflecting some lack of ambition/conviction/vision at the top. It's like the polar opposite of a moonshot: building things in such tiny increments that you can only ever achieve a local maxima, because the higher summit requires a bigger leap.
There are some people for whom growing a business is the exciting part. They can get excited about tax prep software if they see the opportunity.
I'm more like you (not one of those people). If I don't care about the problem, and (maybe more importantly) the users I'm solving it for, I won't solve it well.
Another point - not everything has to be a business - you can always work your day job and build adventure games on nights and weekends purely for fun.
Sometimes the best businesses come out of hobby projects. If not, whatever - it's fun and fulfilling.
The best way imo to break this, is to build a bunch of small things that individually work but collectively point to and solve a more difficult problem. Kaleido.ai is a good example of this, they have created remove.bg and unscreen as individual products but are building something full-fledged.
I'm doing the same with CAD tools for Architects.
I started building https://cadcheck.xyz which brings me slightly closer to a larger solution that would be nearly impossible to build without VC funding.
Not sure if this fits your description, but the first thing that comes to mind are the tidyverse packages
Which one is it then?
I followed a similar pattern and created https://sayoname.com, an app for remotely located workers so they can record names and call each other directly from the browser. A tool so people can easily find how to say someone's name, sneak on what someone does in the company etc.
I almost got a big school hooked up to start paying subscription (it is an international school) but they decided on creating their own solution due to privacy concerns. Extremely disappointing and lowers morale straight away.
I have few hundred profiles but the growth is stale atm. I don't really have time to actively look for new users and would love a co-founder as what they say on y-combinator it is REALLY a lot easier if you have someone you can share thought and can both motivate each other. So my advice is add a step and get a co-founder.
- The header "The simplest tool for remote and international teams" doesn't mean anything. The simplest tool for doing what? I have no idea what this is after reading it.
- On a related note, I'm not really sure what the name of the service is. Is it meant to be like "Say Yo Name"? If so, maybe you could change the header to something like "Say Yo Name! Help your remote and international teammates pronounce your name"
- The undismissable floating "start video chat" box is really awful, especially on mobile where it takes up almost half the screen.
- "the whole team creates profiles and record names" -> "records names”
- "Call users using build in video chat functionality" -> "built-in"
- "Add video chat to any website. It is a couple line of HTML to copy to any website." is awkward. I'd suggest changing the second line to "...with only a couple lines of code" or something similar.
- "Pronunciation is different, though, not easier, at all." is a really awkward sentence. "Pronunciation is different, though not at all easier." is much clearer.
- "Next time don't pretend that your colleague hasn't got a name." -> "Next time don't pretend that your colleague doesn't have a name."
- "Start video chat, share screen, no camera? Just chat!" -> "Start video chat or share your screen. No camera? Just chat!"
Appreciate your feedback, it is probably due to the fact English is my second language.
I'll have a look at updating the website taking into consideration your comments!
I had 2 cofounders in my last company - I agree it's easier.
But so far, building in public has been a great way to replicate some of those benefits without one:
1. I have external motivation to produce results on a weekly basis.
2. I have to be able to justify all my decisions to everyone on the internet (anyone who cares at least...). I end up thinking things through more deeply.
3. I get continuous feedback from others - not nearly as good as a cofounder who's 100% in the business, but still helpful.
Will definitely try to give it a shot.
Feel free to DM me on Twitter if you had more specific ideas! https://twitter.com/AnotherTimJones/
> Twitter is full of interesting and influential people sharing
> thoughts and having public conversations. And they’re all
> accessible - just 280 characters away.
Step 2: Instant Marketing Success
Step 3: Tell everyone how easy social media is
1. Go to http://www.twitter.com.
2. Click Join Twitter today.
3. Type in this Tweet: "I have the perfect product! Email me for quote. #Growth #Product #MVP"
It can be a bit intimidating at first to put yourself out there. And there's certainly strategy required to use it well.
But I think consistency is the name of the game to be successful with it. We'll see!
I agree with the premise of validation, then building. While this is a good rule of thumb, it's not always possible. I like the focus and thinking behind getting users. It can't be "built it and they will come". Having a good, sound plan and sticking with it is the key.
You don't always need to prove out all your growth channels. But it's important to have strong hypotheses and remove at least a little bit of uncertainty around those hypotheses before building.
Your heading "My side projects always fail" makes me think the problem is getting initial adoption (not going from small adoption to huge adoption). The network effects of those three examples don't kick in until after some adoption.
I like the idea of considering not just the product or the market, but also how you to reach that market. It can change your choice of which idea to pursue in the first place. Really, to evaluate as a business idea, not just as a product idea
It is a situation where both are required (`&`).
Good luck with the projects!
Here was my thinking: As a solo, bootstrapped founder, I think people are interested in the person behind the product, at least at first.
I've been using my personal story and the process of building in public to grow an email list and waitlist. The HelloHailey name gives me an opportunity to re-enforce that personal story in the product messaging.
That being said, I'm not ruling out a name change when it comes time for an official launch.
Take this from a guy who spent 2 years studying distribution channels [1]. There's nothing wrong about spending a week or two developing a MVP before focusing on distribution.
I think the key is to start with 1) The minimum thing you can do and call a 'product' 2) Try to promote/distribute it to see the response. So far you've done:
a) A web page explaining what your product is about
Some steps to (progressively) get to a "better" MVP may be:
b) Make a video showcasing your product (which can be a simple Figma design with static screens that show once you click on them)
c) Build a feature that's high on the ICE Scoring model [2], and distribute that
d) Build a meaningfully different feature than c) and promote it as a SEPARATE product. Let your features be like split tests you promote on the same/different distribution channels and see how they perform.
[1] https://firstpayingusers.com
[2] https://university.hygger.io/en/articles/2288376-ice-scoring
Even apart from that, your account is using HN primarily for promotion, which is against the site guidelines (https://news.ycombinator.com/newsguidelines.html).
We ban accounts that do these things, so if you wouldn't mind reviewing the guidelines and taking the intended spirit of the site more to heart, we'd be grateful. The intended spirit is intellectual curiosity, which is not at all the same thing as having something to promote, though it's fine to bring up one's own work as part of good conversation.
I don't plan on spending more than 3-4 weeks building an MVP, which I'll start within 2 weeks.
An advantage that my current approach gives me is a few dozen low-commitment (but qualified) waitlist users that have shown some initial interest.
I obviously have some close friends that will try it out with their teams. But going distribution-first allows me to easily expand beyond that close circle to a more unbiased group of people.
Every day, there are dozens of products being launched on ProductHunt - many of them without code.
The "easy" distribution channels are being flooded.
* One interesting thing I have noticed from being on HN is that lots of start-ups that focus on the tech industry / IT / helping developers. I think it makes sense to pick a niche you understand, but possibly not if it is a 'niche' which is filled with developers.
* Workplace collaboration in a 'knowledge work' environment = red ocean. Application of workplace collaboration tools to new/unexplored industry segments I suspect has lots of blue ocean areas however. I think you have picked something in the red ocean.
* As a small note, you started with a solution (always on video room, inspired by a twitter post) and worked backwards to a problem to solve (teammates not being fully engaged). The usual process would be to start with a problem and then work out how you are going to solve it. I know it sounds like semantics, but there are lots of potential solutions to "teammates feel disconnected" and an always on video room is just one of them! (e.g. coffee roulette, remote pizza parties).
I agree on your first point. This is the easier niche for me right now, but probably not the best niche.
I 100% agree with your second point too. My first step was supposed to be "Choose a problem" (https://www.themvpsprint.com/p/choose-a-problem). But I can spot the flaws in how I presented this - it looks like I was starting with a potential solution someone asked about on Twitter.
That being said, the solution I'll be building is actually quite different from an "always on zoom room" - more focused on teams that operate largely asynchronously.
I'll be formalizing and sharing my product vision over the next week or two :)
But I will also say that I suspect your strategy is possibly a little naive. I hope it's as easy as you've laid out, and I'm envious of the viral aspects of your proposed product. However, I suspect the "top of funnel" portion (hypothesis 1) won't be enough to drive your "land and expand" portion (hypothesis 2). At least in my own experience currently trying to build a B2B SaaS tool [0], it's an absolute grind. And while some of these communities you're mentioning will engage, it's hard to convert that to people entering your funnel in a reliable fashion. You've got to combine it with 19 others things like content marketing, speaking at events, etc.
That being said, we're not engaging in as transparent way as you are so YMMV. I wish you the best of luck!
0: https://kitemaker.co - a crazy fast issue tracker that connects all of your other tools (GitHub, Figma, Slack, Discord) better than anything else out there
I know that everything I'm laying out will be much harder than I've made it seem. I see this strategy as being a north star, but necessarily a hard and fast path.
1. invent a bold new product
2. figure out how to market it
In other words, the "Eureka" moment is in the product ideation step, while the marketing step is basically a schlep. But the inverse approach might actually be better:
1. invent a bold new marketing strategy
2. figure out a product to sell with it
Don't assume that marketing is somehow a lower form of intellectual activity than engineering. It requires a strong aesthetic sense, a deep understanding of human psychology, mastery of technical tools, and the ability to be self-critical.
2. figure out how to sell the strategy
It is the product.
I think that people like me often forget that one of the biggest drivers for working on projects past when they become interesting is the money I receive for working on them. If I'm not being paid, it becomes difficult to fathom struggling for 10 hours on building something past when it's particularly interesting. Once any personal project would require basically any UI work, that's about when I bail (as I have no interest and actively dislike pretty much every UI-based technology I've ever encountered).
Getting paid to work is important to me.
If you have something that solves real problems, you should be able to fight for users. Yeah sure, just because you built a great thing doesn’t mean people will flock to it, you need to do SOME marketing.
It might take two years to get ten users, because turns out it’s very hard to run every aspect of a business by yourself. But it’s progress, and if you maintain a high bar of connection with your user base and product quality, as long as you continue to market and improve it will grow.
There are no “get rich quick” schemes here, I don’t believe in that nonsense. There is hard work and there is giving up, that’s it.
Doing this has allowed me to do so many things, such as figuring out that there is indeed demand for the product, and directly talking to these potential users by setting up a call with them. Having a distribution channel is a powerful thing. It would be even better if I cultivated my Twitter audience, but an email list is a start, and it has some distinct advantages such as owning your distribution channel.
Thinking of open source development, some of this is implied, by platforms like github, and ideas like "release early, release often". So developers are dependent on this promtion/distribution platform, without even realizing they have one.
Some succeed more than others, but they never always succeed.
I wish you good luck for your project but changing your approach is not going to ensure you not to fail.
Marketing magic by marketing gurus is it's own thing. They can artificially prop up a product using efficient advertising, connections, or lots of cash.
Ironically this is going to work because gathering a following for an interesting project is one way to do marketing. Lots of programmers succeed because they make tutorials, or they participate in a community where they build up a reputation.
I would iterate until you find a problem that people are willing to pay a lot of money to fix.