>
1- Startups need early adopters to create a product that really solves problemsWe solved point 1 by being our own early adopters, as we have built our MLOps platform, https://iko.ai, to solve a lot of the problems we face. We're in a privileged position of not coming at this from a background of web developers who want to build "MLOps platforms" or "data science solutions" with no domain/insider knowledge, but from the position of a team that has been doing this for quite some time for projects with actual stakes. This allowed us to gain experience and know what are the actual problems in the field.
>2- Companies usually are not early adopters (eg there's no Kickstarter for B2Bs) since they have to run a business and cannot use incomplete tools
We're a boutique machine learning company that works with large organizations that may or may not already have an internal machine learning team.
When you do good work and are reliable, you build trust and reputation with these organizations even if you are tiny, so people will tend to give you the benefit of the doubt. Some will also notice that you're delivering fast and will ask you how you're doing it because their team is struggling. This happens for example when we work with an org that has an internal team and we're augmenting them or helping them on a problem they don't have experience with and leveraging our experience from previous similar projects in a specific sector or industry.
For example, some huge organizations we have relations with and that already have internal data science and machine learning teams will sit with us and ask us how we're doing our ML projects, what our process is, how we're handling X issue, etc. These are opportunities to know more about their problems, and make them adopt your product.
>3- B2B startups can find early adopters only when their product is good enough, which basically requires capital injections until then
The conversations I described above will surface certain objections to adopting or sometimes even trying the product.
For example, one of the objections was that their team was really too busy to try our platform on a toy project. If they were to try it, they wanted to try it on something they were actually working on, but they couldn't because the information and data were sensitive. This was the objection of the CTO of a "Skunkworks" type organization of a +$500B company. The right answer here is to be polite, understand the problem for this non-adoption/not-even-wanting-to-try-it, and find a way to eliminate that objection either from an engineering stand-point or other ways.
My point is that every meeting is an opportunity to learn, and every objection is an opportunity to refine your product so these objections don't occur in the future and you have to remove these frictions and objections.
Note that these objections were rarely about the product not being "good enough" in terms of features, because when you're solving problems that are real and expensive, the suffering is so high and the tooling is so immature, that the objections will mostly come from a security/confidentiality/governance/trust than be over the fact your stylesheets are not slick.
One other point:
It depends how your product will be used. What are the implications of using it? Does using your product require an overhaul of their entire workflow and processes or even replacing them? Does it require buy-in from everyone? If that's the case, it's more tricky and the adoption and sales cycle will be longer and more "enterprisey". Many meetings, guarantees, contracts,and all the jazz.
Can your product be used by an individual without impacting the whole process provided it won't get them fired? i.e: using your product doesn't violate some policy [which you made sure of after listening to the many objections from all those meetings and conversations I described above]. If that's the case, you could have an adoption from the proverbial "Shadow IT" of organizations you don't have a relation with or, like in the case I described, a blessing from the CTO/CIO/etc you have a relation with. Then you complement this adoption by doing more traditional deals (amount per seat.month, etc).
One more thing:
If you are in these meetings and they ask you about features, please do not succumb to the temptation of implementing these features. I've been in so many meetings where they'll ask me about a feature. A naïve approach is to think they will buy if that feature was in the product and go implement it. We knew better and we always asked probing questions that made it clear that they didn't really need that feature. If you don't have that discipline, you will waste a lot of time, and then you'll have internal problems because some on your team will be convinced that this feature must make it into the product to get you that client. Heck, it may as well get you that client, but how many conversations and how many features will you have to implement like that? So, we ask questions to pin-point the actual problem, compare it with our problems and the problems of other companies, and see if there's a pattern there and if it's valid, and if we can abstract it and solve for a family of issues instead of that particular one.
One more thing:
Beware of chasing features of your competitors or similar products. Again, I've been in so many meetings where they'll tell us that X product does this. And yet, here we are, they were not using X product so if it were the most critical point, we probably wouldn't be sitting down.
There are features that make sense and that you have to have, and these make sense even for our own usage. However, this is a very saturated market and there are a lot of products and platforms trying to do that. The good thing about having our background in the field is that we know what the real problems are, and we know not to try to match features of products solving the wrong problems or problems that don't exist.
These points require discipline or your risk screwing up your product.