6 ms·
I left Palantir in 2014, so this may be a bit out of date, but back then, a lot of the sales of the product were done by engineers, which was effective but expe
by taywrobel 6y ago
I left Palantir in 2014, so this may be a bit out of date, but back then, a lot of the sales of the product were done by engineers, which was effective but expensive.
The general approach would be “give us 2-4 weeks to integrate your data and give you a demo”, and would give organizations a demo of the software using their own data.
There were some well known stories internally, of things like police agencies forgetting to ask about the product at all, and instead taking notes on suspects and investigations being shown to them in the demo for further follow up, because it was making connections and breakthroughs on stalled or cold cases. Those were the ones that they knew were hooked.
The flip side of this is the cost of deploying anywhere from 2-20 engineers into the field to handle the system setup and integration on the fly.
- WrtCdEvrydy 6y ago> taking notes on suspects and investigations being shown to them in the demo for further follow up Not a sales guy, but I would just emailed them the notes later (or printed it beforehand) so they could just sit back and watch it happen.
- brundolf 6y agoI used to work for an "AI" company, who claimed (and largely believed) that their main value-proposition was their proprietary secret-sauce (they didn't do anything especially evil like Palantir, but it sounds like the business was structurally similar). However, most of the time the way they won over their (usually enormous) clients was just as you describe: they took a few weeks to pick through the client's existing data hoards, mapped out what were often dozens or hundreds of disconnected databases, found common identifiers for entities, hooked them all up into a unifying system and then just... queried it. Data unification on its own yielded really impressive results for the clients. To be fair, the company had built up some compelling experience/tech around doing said data unification, but that stopped short of any of the "AI" and was never really how they marketed themselves. Some at the company always saw that part of the process as just a prerequisite for "the real product", but in practice it seemed to be the most useful part. It's amazing how inefficient data-usage is throughout so many large organizations.
- ryneandal 6y agoThis sounds like everything I've heard about IBM's "AI" solutions.
- quacked 6y agoI work for a big organization, and the amount of "wow, you're a data wizard!" comments I get for generating combined keys inside disparate databases and then merging them in Excel is insane. It's making me think that anyone who is not well-versed in at least the basics of database theory is crippled in the information economy. A lot of "tool-based" problems that people complain about are in fact user problems, when certain teams aren't maintaining their data with clear identifiers or internal standards.
- randycupertino 6y agoUmm, I work for a big org and I get called a data wizard for cleaning up and merging two Excel trackers! I just copied your comment into my One Note so I can figure out what you're talking about re: combined keys and level up my wizardry. Any tips to get me started? I work frequently in disparate databases (EPIC, Veeva, Rave, Excel, Suvoda.....). Any big org that is silo'd is gonna have a big problem re: clear identifiers and internal standards. Heck, once we passed 500 headcount even just file naming convention was tough to roll out!
- sjg007 6y agoA combined key in this context likely means a compound / composite key. https://en.wikipedia.org/wiki/Compound_key https://en.wikipedia.org/wiki/Compound_key
- quacked 6y agoYeah, that's right- I just called it the wrong thing.
- brundolf 6y agoPeople at my old company would do a lot of "data archaeology". They would find a table in a T-SQL database named "facilities", and a table in an SAP system called "units", and then would notice that the numeric "facility_id" column's values had a lot of overlap with the string IDs in "unit_id", if you remove the underscore prefix at the front, and then they'd email the client's data people to confirm that these were in fact the same entities, and then they'd associate them in their cross-database-querying tech, and ta-da. A huge amount of new data cross-pollination is available.