* Just sell data or;
* Just sell applications powered by your proprietary source of data
Do not:
* Sell derived/refined data as a half-measure
* Sell both applications and wholesale data at the same time
If you feel like that doesn't make sense, you are not alone. Almost everyone in the industry disagrees with my views on this topic based on how they run their businesses. Satellogic is one notable exception. But I can't think of a single other provider that would agree with me.
And its not just Planet that is hung-up on this same failed business model. Its also Hexagon, and a myriad of other earth-observation providers. Some are so difficult to work with its literally cheaper to go buy an airplane and a wide format camera and roll your own.
There’s a new one like every picosecond.” It’s “delivery, but for dorm rooms” for space tech.
Bloomberg comes to mind since they offer wholesale access to data in addition to all the terminal functions.
(1) is a desktop (and now mobile) application that trader, sales, etc. use to communicate, view raw data, and view derived data in "mini-apps" (price this bond under scenario X, etc.) The base cost is about 25K USD per year (there are local IT costs above the terminal license fees). There is a raw data access API for Excel, but very limited. They block your API access if you try to download too much data. The days of pricing any kind of volume of products from a Excel Bloomberg API is mostly gone. Also, you cannot run it on a server and just screen scrape / use data API all day long.
(2) is a raw data feed service, akin to Reuters. Not well understood by industry outsiders: There is no "all you can eat data service" anywhere in finance. Period. Every primary data source is now carefully guarded with license costs and special rules (no redist, etc.). Some stock exchanges make more money selling data licenses than collection trading fees! I have no idea about BPIPE prices, but I assume expensive and per data source with nearly infinite granularity.
About revenue: (1) Wiki says: https://en.wikipedia.org/wiki/Bloomberg_Terminal
If you believe it: 20K USD per terminal and ~325,000 terminals as of 2016. That is 6.5 billion USD per year. Nice.
About revenue: (2) No idea. I cannot find any reliable published stats.
Lastly: I regularly see people argue on HN about an open source version of Bloomberg. It is impossible for two reasons: (a) Network effect in the communication channels -- lots of people mostly use Bloomberg chat / email and hardly use data, besides the trivial. Most people on the buy side (money management, hedge funds, portfolio managers) join Bloomberg to talk to other people on Bloomberg. And: (b) data licensing.
I've heard so many founders try to describe their business as "Bloomberg for.." when trying to describe a mixed focus offering of products that I immediately hear alarm bells nowadays.
Disclaimer: never actually used their system, just saw presentations about it, which show how one can train an algorithm to count... stuff.
What we are trying to do is indeed allow customers to build algorithms tailored to their use cases. We often joke that the reason our ML works is because we are overfitting to customer datasets/use cases. But I think that's somewhat true in the sense that we are not going for "worldwide trees counting" but more for "reliably count cars on these 50 parcels".
It's also interesting to note that a sizeable chunk of our revenue is coming from companies with drone data where it makes even more sense to be specific to customer data (resolution, time of day, geo, etc...).
You don't always have to order the biggie fries and drink, you can just order the standard meal.
The OPs point is that it won’t be profitable/effective, that’s all.
If they wanted to be crushing it, lower the cost/ barrier to entry on the pixels themselves. Get it out into peoples hands and use more open, easier to build on licenses. Let people actually use the data.
I've been on the other side of 5 failed attempts to work with Planet at large, medium, non-profit and startup scale projects, as early as 2016 and as late as 2021. They just don't get it. If your data isn't easy to use, I wont. If your license is going to prevent me from building what I need to from that data, I wont use it.
There is a large market gap between the sensor platform providers and the would-be end users of that sensor data. Business is constrained by the fact that the end users are not capable of consuming what is being produced and neither party in the transaction is really qualified to solve that problem.
Sensor platform companies can't make their data more consumable because they only know their data, not the analytic nuances of the end users nor the other sensor modalities that the end user may be using. They try, with the hope of improving revenue, but it almost never comes off. The end users are experts in their analysis problems and application domains but usually have no skill or capacity to write custom performance-engineered infrastructure software to bring the sensor data into their domain. This software often has pretty hardcore computer science requirements and there is minimal tooling, certainly not in open source, to make this easier or more scalable. There is clearly a market opportunity, but neither of the obvious parties is in a position to address it even for their own immediate benefit.
There are a few companies with expertise in building high-performance data tooling for analytic workflows across sensor modalities with enough application understanding to bring it into the end user's domain. There is a lot of commonality across application domains from the view of tooling requirements but you have to have expertise in several vertical domains to see it, so it is repeatable. These companies have neither the data nor the application but they bring them close enough together that they can "make the market" as it were. Currently this is a high-end contracting business rather than a general platform, so it doesn't scale. But if this tooling became part of a general platform, it would let the sensor data platforms focus on data collection without worrying about how to make the data more consumable for various application domains, which they were failing at anyway.
The state of software tooling for these sensing data applications is primitive, overfitted for single data sources, and not nearly scalable enough. Most other problems in the sensor data market are consequences of this reality.
The workloads and computer science are very different, but bringing them together would add a lot of value. At least with current platforms on the market, one is always to the exclusion of the other.
1. People don't want satellite data they want their problem to be solved
So a company like Planet shouldn't (just) get satellite data they should solve problems.
2. Companies can't do 2 things at once well
So Planet actually has to choose between solving problems or just getting satellite data
3. Companies like Arturo have good focus and solve the problem of climate risk for insurance
So Arturo should stay focused on that, but where do they get the data from? Planet right? So Planet does have a set of customers for its data?
--
Edit: I re-read the article and maybe I'm just confused on the wording. Is he saying that raw data is valuable and worthwhile for satellite companies to sell but they should not do anything to the data before try to sell it?