The Economics of Building Knowledge Bases(blog.diffbot.com)
blog.diffbot.com
The Economics of Building Knowledge Bases
http://blog.diffbot.com/the-economics-of-building-knowledge-bases/
9 comments
This is a compelling article, but then when you try to see what the product is, you have to submit your email / request a demo. In my experience, hiding your product behind a demo is a bad sign that the product has flaws. It also puts you in contact with a salesman or account manager which is typically geared towards a high pressure sale event of the product. I'd be interested to hear other people's experiences with this model, though.
Also for certain products it's almost impossible to sell at scale without an enterprise sales team. Developers won't be "willing" to pay or admit the need for what's basically a glorified web scraper concept that has existed for as long as the web itself. For this sort of product to be successful you need enterprise sales, tons of funding and marketing, among other stuff. Even if your actual product is terrible you will still have a larger segment of market compared to a competitor product that may be more advanced functionality-wise. This is not something that's popular on HN because of the constant myth that "if you build a well-engineered product, customers would magically show up".
Here's some more of diffbot.. They've built basically a knowledge graph search engine. I am guessing PoCs are the way to sell this. https://www.forbes.com/sites/jilliandonfro/2019/05/13/the-we...
I think there can very much be two segments. Both a high-volume self-service segment (I know this is what I prefer when evaluating developer tools) as well as a high-touch enterprise segment for training and implementation (think Bloomberg Terminal model). Diffbot has a free 14 day self-service evaluation for its individual extraction API, but it is not quite implemented yet for the Knowledge Graph.
I think diffbot looks complex enough that you might buy a license and a 100 hours of consulting time for your first MVP.
For such products, having a meeting where the product and it’s benefits can be shown, followed by a business case planning session is a reasonable way of selling the service.
For such products, having a meeting where the product and it’s benefits can be shown, followed by a business case planning session is a reasonable way of selling the service.
Sometimes with products like this one the value that it provides to the customer varies significantly depending on a use case and it's hard to put up pricing without either cutting out a long tail of smaller users or losing money on the big deals.
I have an API that market research and medical customers are willing to pay 100x more for than consumer social, at the same time the consumer companies have 100x the volume.
I have an API that market research and medical customers are willing to pay 100x more for than consumer social, at the same time the consumer companies have 100x the volume.
Find a way to segment that into two markets based on features or volume. Don't try to do it by making your customers take a phone call before telling them anything about the product. That's a move that even Oracle sales would think twice about...
DiffBot - sounds like it alerts me when a page changes.
Freebase was not just "shut down" out of nowhere. A data dump is still available, and some of it was merged into Wikidata but overall the resource was found to be of poor reliability. It may have had very accurate data on average, but this was not enough for many Wikidata use cases.