[Jugurtha]

>This is another site that needs the "invite code" for new users to register? I know the arguments of controlling the influx of new people and having a trust-chain so that comments are decent etc... but it just feels so elitist.

Well, we're guilty of that, too. It's not about elitism, we let thirty of our colleague's students use our ML platform[0] for their final year projects, and send invites to people who go to our Slack workspace. There are some things to fix before we can onboard everyone, that's all.

I don't say they're doing it for the same reasons, but it's not necessarily elitism. It can be limited resources, etc.

>but you can't be part of the party, you're not one of the cool kids

You're one of the cool kids. Where do I send the invite link?

- [0]: https://iko.ai

[code_scrapping]

Like I said - I understand that there's probably a good reason why you're limiting user numbers, but it's a bad mechanism for doing so.

Good luck, I'll take a pass on the invite, and wait for the site to become open, if that happens. As you're not limiting viewing of articles, I'm not losing much, and the biggest downside is that you'll miss-out on the early adopters and hype-surfers, but mostly it's just bad PR.

[Jugurtha]

I think you may have missed the part that explains we're not the original link. I'm not OP.

I was explaining why we're doing it on https://iko.ai to manage compute resources, as it is a machine learning platform. Early users help make the product acceptable for a wider audience. Building product in a void and launching is not the way to go in my opinion.

The fact you take a pass means you don't need it that badly. Generally speaking, early users do need the product badly and are willing to accept certain imperfections, and have extremely helpful feedback to improve the product so it eventually becomes appealing to a wider audience.

The pattern also helps limiti g the number of disappointed people. When it is a low stakes 'job to be done', you can open for everyone. When it's a bit more demanding, you need to get a few things right. Again, I'm not OP and the product I'm talking about is something else.

[code_scrapping]

Thanks for clarifying, you're right - I missed the fact that you're not talking about the same product. Thank you for the offer, but you're right - it would be lost on me.

> early users do need the product badly and are willing to accept certain imperfections

Agree on the second, but the first parts is a wild exaggeration. You get to discover that for yourself.

[Jugurtha]

>You get to discover that for yourself.

We spent seven years delivering ML products to enterprise, and are building something based on what we discovered. However, this is not a photo sharing application where the use case is very narrow and one developer is enough to pin-point the need and execute on it. This is a meta-product that enables people to build products.

There is some complexity in that the ML landscape is varied and it is precisely why many are trying to do that. We can discover part of this and we did, but we want to uncover more by having users try it out.

A concrete example: during the first months of the pandemic, our colleague had thirty students with machine learning final year projects. These were in a hot COVID spot. We had total lockdown, and these students did not have the possibility to go to university to access computers. They also did not have means to buy a costly workstation just for the project. We onboarded them on the platform as "early users" so they could train machine learning models, deploy them, and build applications that used them, and as a result, were able to graduate on time.

Now, I don't know what you think of that approach, but preventing 30 students from losing an academic year is not a bad thing. Did the platform suck in some ways? Absolutely. They graduated on time, though. 30 * one academic year = 30 years saved because that product, even in its primitive form, existed.

We can either develop in a void and wait until the product is complete and perfect to show to the world and allow everyone to use it, but I don't think anybody who actually shipped useful products in their life ever does that.

Whenever someone asks how they could focus more when building their product, even a personal project, I tell them to get the right kind of users. Early users help uncover the unknown, and help focus on some of the knowns.

For example, you have a long backlog. Without users, prioritizing can be done but is tricky. With users: after the 20th user complains about a bug/UX, you know what your next issue/ticket is going to be. The result is faster development on what matters, and the consequence is instead of shipping the product to the wider audience in a year, it'll be in 6 months.

Having early users helps tear down things we might have ignored and accelerates bringing this value to more users.

[code_scrapping]

You seem to have the impression that I don't see the value of early users, which is not true. They are crucial.

Could those 30 students have gotten GCP access and carried out their assignments? Probably. I wouldn't portray myself as a savior while trying to sell a product. I'd say that those 30 students were doing you a favor. (In the same way Autodesk, Microsoft etc are giving away student licenses to get you into their eco-system. It's really not a new thing)

But, to my original quote that you seem to have disliked - you are a small company (I saw 10-ish people?) that's entering a highly populated and competitive market with the assumption that your early adopters "need your product badly". I can only assume you have one helluva product. I'd say in 2-5 years you'll have the answer (not that it has to be bad news).

[Jugurtha]

>You seem to have the impression that I don't see the value of early users, which is not true. They are crucial.

I'm not assuming you don't see the value of early users. I'm giving examples of them being crucial.

>Could those 30 students have gotten GCP access and carried out their assignments? Probably.

Assumptions of this [for the students]:

- They have a payment method and can set up a billing account [they don't]

- They know how to set up VMs [they don't]

- They know how to set up notebooks [could do it difficultly]

- They know how to install dependencies [they had trouble with that]

- They can afford storage and compute including GPUs [nope]

- They can version their code and track their params/metrics/models [nope]

- They can deploy their models to use them in web applications [nope]

- They can get their models to their machines [slow connection, + dependencies]

- Thirty students can easily show their progress to their supervisor [nope]

- A group of students can collaborate easily on different machines [nope]

And the last assumption is that they care about all these things. They don't. The job to be done is to study something, train models, and write a dissertation on different approaches, not to entangle themselves in dependency hell and containers. That is overhead.

>I wouldn't portray myself as a savior while trying to sell a product.

I'm not portraying myself as a savior. I'm stating that the product saved a lot of time.

>I'd say that those 30 students were doing you a favor.

I believe I have given examples of this being true by saying that having users focuses development by uncovering unknowns, and focusing on what matters.

I so believe this that the whole series of replies goes in that direction.

>But, to my original quote that you seem to have disliked

What do you mean by disliked, and what lead you to believe that?

>you are a small company (I saw 10-ish people?) that's entering a highly populated and competitive market with the assumption that your early adopters "need your product badly"

We are our own early adopters, and we do need our product badly. We would have used something else had we found one that solves problems we encounter in the real world.

>I can only assume you have one helluva product.

Not really. We're working on that, though. We want it to be useful for us, first.