Hacker News Reader

Funny you mention Dropbox because they did exactly what you say not to do, provide a video demo that doesn't actually work, it just looks like it's working [0]. Their Show HN thread has more details [1].

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.

[0] https://www.youtube.com/watch?v=7QmCUDHpNzE

[1] https://news.ycombinator.com/item?id=8863

> ...provide a video demo that doesn't actually work, it just looks like it's working

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.

That is true, the founder did have an alpha version working by the time they did the Show HN, but still, if he had made the video without having anything technically made (but just by visual effects), would it still have been less effective? I doubt it, people know what they want and don't want when watching the video, and it would have been clear to the founder that people wanted it and he could've started building it after people expressed their demand. So in the end, even if he hadn't made the full product, Dropbox would still be where it is today.

It was really inspiring and grounding to see a “Show HN” thread with Dropbox, pre-fame. Thanks!

The first comment is also legendary in the HN community.

I had a great time reading the comments! Amusing to see the (natural) mixed skepticism and praise for a new product.

I think selling a product that doesn't yet exist may work without an MVP, especially if it's a completely novel idea where none exists. We launched recently (and got paid customers on day 1, no mailing list, no large # of followers, no marketing spend) in a relatively established market niche and didn't run into the problems of finding customers, because customers were already looking for that solution and liked what they saw. We also needed to build out the whole product before the first revenue dollar.

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.

I'm only advocating for reducing uncertainty around distribution before building; not eliminating it entirely.

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.

I think this is a fair point, and maybe I was too critical. There's been a trend of "fake it 'til you make it" lately, which I think really appeals to non-engineer types. Engineers have the opposite problem: building too much before anything is validated.

I think I understand both viewpoints: it is indeed not feasible to fake it before you make it in case of Dropbox. However, if you are offering automated reports once a week, there is no problem putting together an HTML template, some excel sheet and an email script where a person does the work for a few pilot customers. So I think when you mentioned "particularly novel or value-generating product" you meant that the idea scores close to 0 on a "fake it before you make it" scale? Is there even such a scale? Barrier of entry is closest I can think of.

I think a lot of folks get confused between various MxPs (where x = [remarkable, viable, loveable, marketable/sellable]), I know we did, and thought we must be doing something horribly wrong.

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 think the problem is the with the name. An MVP is most often not a product, but a prototype that you use to test some hypothesis. That’s it. It you are lucky and validate them, great. Trash the Prototype and build the real product.

I think the idea is you do give a demo, just that you dont go crazy engineering-wise to implement NASCAR login, kubernetes scale-out and all sorts of stuff before you've tested the market for interest. It is basically taking the idea of MVP down a notch to BVP (barely viable product).

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.

What is NASCAR login?

A NASCAR login is a stack of login options (Login with Apple, Login with Google, Login with Facebook, Login with Twitter, Login with Github...) where you end up having so many stacked logos that it starts to look like a NASCAR racecar (because they have tons of logos on them.)

https://nascar.nbcsports.com/wp-content/uploads/sites/9/2020...

Google Identity reference to NASCAR Login: https://developers.google.com/identity/toolkit/images/federa...

NASCAR logins are particularly great (easy entry to convert interested users) and at the same time having a huge number of super-ugly edge cases:

1. If you log in with john.q.doe@gmail.com but originally had registered your gmail as johnqdoe, then your login automatically changes to the non-dot form.

2. If you have already registered via email on john.q.doe@gmail.com, then you cannot login-with-Google in the above case, as both accounts are separate and distinct in the host system.

3. If you have two accounts under your school and work account, but log-in-with-Facebook, and Facebook has both your emails, it gets confused.

4. There are cases where you simply cannot log in due to the network of conflicts across the identity services.

...and yet this is also awesome because you get to convert a registered user ASAP in 95% of the cases.

A login page that has a million logos on it (login with facebook, login with google, etc)

Just today Redpanda hit HN front page https://news.ycombinator.com/item?id=25075739 and I cannot see how would you give a demo of such a system without having such a system developed in the first place. At the very least, the whole of HN would laugh at such a salesman trick. I do think there is a spectrum of fake-it-before-you-make-it ability for each idea. For some like Instagram is close to 100% and for things like Redpanda it's close to zero.

Yes I think you described this approach well. I've worked on a bunch of things built this way... as an overall approach it will certainly minimize the chance that you waste time building something totally un-sellable.

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.

>> reflecting some lack of ambition/conviction/vision at the top

Sure, but my assumption would be -- if you suddenly get registrations, signups, or even conditional trial accounts, great! Now I have some validation, and I'd jump in immediately and start building out the product fully.

...then, if I get even more engagement, even greater! Now I can start planning some scale-out.

What's the definition of MVP then?!

Indeed! M means minimum! If anything, the step below an MVP should be called a NYVP ("Not-Yet Viable Product"), which should hopefully remind eager sales folks that it might be ready to demo but not ready to sell.

vaporware