Silicon Valley Has a Muscle Memory Problem

There’s a pattern doing the rounds right now. An influencer builds a massive audience, pitches a startup, VCs get excited about “built-in distribution,” money gets wired, and then... nothing works. The product doesn’t stick. The audience doesn’t convert. The metrics look great until they don’t.

And Silicon Valley keeps falling for it. 🤦

It’s getting founders killed. For a long time, the playbook was simple: traction = investable. Users up and to the right? Write the check. Engagement growing? Write a bigger check. This produced a generation of beloved products that were genuinely terrible businesses:

• Scott Belsky’s Behance

• Ryan Hoover’s Product Hunt

• Adam D’Angelo’s Quora

• Erik Torenberg’s On Deck/ODF

• Joshua Schachter’s Del.icio.us

Great traction. Passionate communities. Real cultural impact. But the unit economics? Never really there. Each of these people made a fortune for themselves leveraging the reputations of failed businesses.

Product Hunt raised $6M from a16z and was sold to AngelList. On Deck raised $20M from Founders Fund, had 10,000 founders in its community, and laid off over half its staff in two rounds within three months. Quora has been raising rounds for fifteen years. Zombie businesses, kept alive by cheap capital and community goodwill. They earned their place in Silicon Valley’s hall of fame. They never became real businesses.

That era is over.

In the age of AI, bad unit economics can no longer hide inside good traction. Building a unicorn isn’t the bar anymore. Even a clean M&A exit won’t save you if you built a web 2.0-style engagement business with an AI cost curve. AI startups are burning through $100M in roughly half the time it took a decade ago. The median Rule of 40 for enterprise software has collapsed from 21% to 9%. Your compute spend is not a rounding error. It’s your business model.

OpenAI is burning $14 million a day at its current run rate. Most AI-native startups cannot absorb that kind of structural loss. A Web2-style “get users first, figure out money later” approach baked into an AI product is a fast way to burn through runway before you ever find product-market fit. And in an M&A scenario? No acquirer is buying a traction story with Cursor-level infrastructure costs and no margin in sight.

Silicon Valley hasn’t updated its operating system for this reality. Nowhere is that more dangerous than with influencer-founders.

The Influencer-Founder Pitch Is Seductive for a Reason

Built-in distribution. Proven content instincts. A warm audience that already trusts them. No cold-start problem. The pitch writes itself. Which is exactly what makes it a trap: the red flags are hiding inside the green flags.

Fans are not customers. An influencer’s audience will pre-order on launch day, cheer in the comments, and quietly churn by month three. Because they were buying the person, not the product. Arii, an Instagram influencer with 2 million followers, made $0 on her product launch. Something Navy, built on the back of one of fashion’s most beloved influencer brands, collapsed into a fire sale despite a passionate following. Fans validate. Customers tell you hard truths. That distinction is the whole game.

Broad resonance is the enemy of product depth. Great product founders obsess over narrow, specific pain. They build something a small group of people cannot live without. Influencers are trained to do the opposite: optimize for the widest possible appeal, make content everyone can share, file the edges off anything too niche. Those are opposite instincts. One builds a following. The other builds something worth paying for.

The content treadmill and the product roadmap do not coexist peacefully. Influencer-founders feel the pull to keep shipping content, it’s what built the audience, it feeds the algorithm, and when product milestones are slow it fills the gap that silence would leave. Building a real product sometimes requires going quiet, going deep, and ignoring the dopamine feedback of likes and comments. Constantly shipping content while trying to build a company isn’t hustle. It’s split focus.

The audience is a dependency. When the business is the audience, the business is as fragile as a platform’s algorithm. TikTok shifts its ranking. Instagram kills reach. The influencer burns out. What looked like a distribution moat is actually concentrated platform risk with a personal guarantee attached. There is no structural advantage. Just borrowed attention that has to be constantly re-earned.

When It Actually Works

Some influencer-founders succeed. Almost always, it’s because they treated their audience as a customer development shortcut, not the business model itself.

The audience gets you early adopters fast. It compresses the time from zero to first feedback. That compression matters, but only if you’re using it to learn what problem people actually have, not to validate a product that already exists in your head because it “fits your brand.” The influencer who wins treats their audience as a source of raw insight. The one who loses uses it as proof of concept.

The Only Question Worth Asking

This trap isn’t unique to influencer-founders. The ex-agency operator who knows every marketing channel but has never owned product. The senior big-company employee going solo for the first time, armed with brand credibility and zero customer intimacy.

Credentials that impress, instincts that quietly misalign with what early-stage company building demands.

If you’re investing: ask this before you wire the check. If you’re picking a co-founder: ask the same thing. Have they ever found out they were wrong about something that mattered, and actually changed course?

Audience size doesn’t build that muscle. Sometimes it actively prevents it. When you’re used to the world agreeing with you, hearing a customer say “I wouldn’t pay for this” feels like an anomaly, not a signal. That’s the trap.

I was there. I helped build Looker to 700 people. Not for your dashboards - here’s why this rename matters for anyone who builds products with a real brand, then sells them to a large acquirer.

Cursor team - take note.

What the Looker Brand Actually Stood For

Looker wasn’t just a BI tool. It was a philosophy.

The core idea was governance: one semantic layer, defined in LookML, that sat between your raw data and every analyst in the company. You didn’t write ad-hoc SQL and hope everyone agreed on the numbers. You defined your metrics once ( revenue, churn, activation) and every team pulled from the same source of truth. No more “why does my dashboard say 10,000 users and yours says 11,400?”

That idea resonated deeply with a specific community: senior data engineers, analytics leads, data-forward CTOs. People who had lived through the chaos of five teams using five definitions of the same metric. Looker was their answer, and they were evangelical about it.

The brand carried that signal. When someone said “we use Looker,” it communicated something precise about how that company thought about data. It was a badge. It meant your data was governed, trusted, and not a mess.

The Acquisition: Two Products, One Name, Zero Clarity

When Google announced the acquisition in June 2019, it already had its own analytics product: Google Data Studio. Free tier. Drag-and-drop dashboards. Deeply connected to Google Ads, Google Analytics, Google Sheets. Beloved by marketers, freelancers, small business owners, and anyone who needed a quick visualization without writing a line of code.

That’s a great product. Nothing wrong with it.

But it is NOT Looker. The users are different, the problems they’re solving are different, and the underlying philosophy about how data should work is different.

In October 2022, Google decided to consolidate. Data Studio became Looker Studio. The logic, from a product portfolio perspective, was understandable: unify the analytics family under one brand, signal that these tools belong together in the Google Data Cloud ecosystem.

The execution was a branding disaster.

The Damage: When Novices and Practitioners Stop Speaking the Same Language

Data Studio had millions of users. Marketers. Small business owners. Agency folks running Google Ads reports. When the product was renamed Looker Studio, all of those users suddenly became “Looker users.” And when they talked to someone in the data world — a data engineer, a potential employer, a vendor — they’d say: “Oh yeah, I use Looker.”

That broke something real.

Because to a senior data practitioner, “I use Looker” means something specific. It means LookML. It means a governed semantic model. It means your company has invested in the infrastructure to get data right. It’s a signal of sophistication that carries weight in hiring, in fundraising, in vendor conversations.

Now that signal was noise. Real Looker practitioners started having to clarify: “No, I mean actual Looker. Not Looker Studio. The BI platform.” VCs and angels evaluating startups would hear “we use Looker for our data” and have no idea whether that meant a drag-and-drop Google Ads dashboard or a full governed analytics stack. Hiring managers reviewing resumes faced the same confusion.

The Looker brand, built on precision, became imprecise.

Google essentially took a term of art and turned it into a generic.

What Large Acquirers Always Get Wrong About Brand

Google isn’t the only company that’s made this mistake.

When a large company acquires a product with a cult following (especially a technical one), the internal pressure to integrate it into the existing brand portfolio is enormous. Product managers want coherence, marketing wants a unified story, and leadership needs to justify the price tag. Every incentive points the same direction: put the acquired brand on as many things as possible.

But a brand that means something specific to a specific community derives its value from that specificity. Stretch it and you don’t get a bigger brand, you get a weaker one. The precision that made it valuable gets averaged away.

Looker’s brand was built on trust, rigor, and a particular worldview about how data should be managed. Grafting it onto a free drag-and-drop dashboard tool didn’t elevate Data Studio. It diluted Looker.

No one inside a large acquirer has a strong incentive to protect what the acquired brand actually meant. The founders are gone or sidelined. The original community has no seat at the table. The people making the naming decision are optimizing for a slide in a product portfolio deck, not for the subtle but real meaning that “Looker” held in the minds of 50,000 data practitioners.

The Rename-Back: A Quiet Admission

Google’s official language around the April 2026 rename is all forward momentum. “Expanded mission.” “AI era.” “Data Cloud ecosystem.” Data Studio as “the on-ramp for creating and sharing ad-hoc reports.” Two tiers: Data Studio and Data Studio Pro.

Looker is the enterprise BI platform and Data Studio is the lightweight visualization tool, which is exactly where things stood before the 2022 rebrand.

That’s a correction. It might not feel like one from the outside, but anyone who lived through the confusion knows what it is.

Looker gets its name back. Uncontested. No more drag-and-drop users calling themselves Looker users in job interviews and investor meetings. For the data community, that means the signal is clean again, saying “we use Looker” means something again.

What This Means If You’re Building Something

If you’re a founder with a product that has real brand equity with a specific community, protect that signal like it’s infrastructure. Because it is.

When acquisition conversations start, brand architecture questions feel secondary to valuation, earnouts, and employment agreements. They’re not. The way your product name gets used post-close will shape how your community perceives what happened, whether your team stays bought-in, and whether the thing you built retains the meaning that made it worth buying in the first place.

Get commitments on naming, in writing if you can. Understand the acquirer’s portfolio logic well enough to predict what their integration team will do in 18 months. Because that rationalization exercise is coming, and when it does, the brand question will feel like a footnote (right up until the moment it isn’t).

Small product renames are rarely just product renames. This one took four years to undo.

I'm building something new in the personal AI space and posting about it on X, follow me at @sgmlabs. Details dropping soon.

On a more serious note, this might be one of the most consequential deals of the century.

At a high level, it seems like the first phase is a co-development deal - Grok and Cursor will combine their efforts to build the most cost efficient code generation model.

I say most efficient here for a reason.

The goal for Cursor is not right now to have the best or high quality model. They are focused on margins and a way to stop sending 80% of their revenue to Anthropic.

Grok, on the other hand, has one of the best alliances in the industry already: Azure. But without a coding model, the partnership with Azure is superficial.

Developers don’t trust the model. And as long as developers don’t trust Grok, they are not going to use it even for what Grok is actually really good at: writing.

That’s it for now. Let’s see what else is in store this week. My gut is telling me this week will be interesting.

…

Maybe that’s right. Maybe it’s wrong. I genuinely don’t know, but I do know that the person who wrote it does not, because there’s no evidence attached. No app. No production system. Just the confident rhythm of a LinkedIn post optimized for reshares.

Most AI discourse right now falls into the same traps.

The hot take

Bold claim, short lines, confident conclusion. “MCP is dead.” “OpenClaw is taking over.” “Cursor is beating Claude.” The posts rack up thousands of impressions and age out of relevance within 90 days, at which point the same account posts the opposite take with equal conviction. No timestamps, no cost numbers. Just vibes dressed up as arguments.

The enterprise crawl

Meanwhile, most enterprises are nowhere near the hype.

Hundreds of employees get involved. A steering committee forms. A vendor gets selected. Six months later there’s a governance framework, a hundred internal architecture docs, and a press release about autonomous software that nobody had yet shipped. Eighteen months later: a demo environment and a bunch of Services agreements, but no product.

The people making AI investment decisions are rarely the people who will live inside the outputs. The result is a lot of license spending and very little shipped software.

Cursor is the clearest illustration: buy 100 seats, tell the engineering org to “use AI,” and wait for productivity to compound.

But then, in practice, experienced developers stop shipping code. They spend more time in meetings.

Because at the end of the day, the tool was never the outcome.

Cursor or no Cursor, someone still has to define the work.

What proof of work actually looks like

Not a post. Not a thread. An app someone can open. One that someone other than you actually tried, got confused by, or got what they needed from.

A cost that shows up on a real invoice. A workflow that breaks at step three and tells you something true about your assumptions.

What counts is not the take. It’s whether you can turn a workflow that lives in three spreadsheets and someone’s memory into something real enough that another person can try it, break it, and tell you where you misunderstood the problem.

Recall that “MCP is dead” claim above. Well, here is our newest MCP powered apps, which you can try in under 60 seconds and decide for yourself:

We shipped the above MCP-powered product not because it defines our roadmap, but because we genuinely thought others would find it valuable and it will teach us something concrete that another month of abstract AI opinions never will.

The demo compresses what normally takes founders days into minutes - from identifying investors to getting a meeting via a warm network introduction.

Real AI breakthrough in ways even I myself didn’t anticipate.

And if you watched the above and thought “MCP is dead” - I have the receipts (i.e. users signing up daily).

The Cursor call, revisited

A few months ago I wrote about Cursor and made what felt like a contrarian read: that the 2.0 changes were survival tactics, that the margin pressure was existential, and that the co-founder departure likely signaled real disagreements about product direction.

Two things have since happened that prove it right.

Cursor shipped Composer 2, their own proprietary coding model built on top of open-source Kimi K2.5, and they did not frame it as a cost-cutting move. But the numbers make the logic clear. An internal Cursor analysis reported by The Decoder found that Anthropic was effectively burning thousands of dollars in compute per user per month while charging $200. You cannot make the unit economics work when your main supplier is subsidizing your customers at that ratio. At those economics, building your own model stops being a product bet and becomes a basic condition of survival.

The enterprise disappointment is getting documented too. The NYT recently ran a piece on “code overload,” the phenomenon where AI-assisted codebases generate more volume than engineering teams can responsibly review and maintain. 100 Cursor licences doesn’t produce 100x more shipped product. It produces a lot more code that someone still has to understand, own, and defend.

The original thesis, that the tool is the outcome, was always wrong. The enterprises buying in bulk without a plan for what “done” looks like are finding that out now.

What we’re doing about it

We’re going to show our work in public. Sometimes that will be a full product. Sometimes a narrower AI app feature shipped fast. Fewer opinions. More receipts.

We’re not a custom dev shop. We’re looking for recurring problems that are common and painful enough that people are ready to pay someone to solve.

If you keep seeing something breaking despite all the AI noise, tell us what it is: take the survey. If you’re frustrated about an email client, or CRM experience, we want to know. If you think your daily web experience is broken, tell us the specifics.

If it sounds like something worth building, we’ll talk.

Take the Survey

The takes are free. The receipts cost something.


- SG@KLABS

We are just starting out…

Read more

Even if you imagine Cursor to become one of the biggest software companies, it is an astonishing number. Google, for context, raised approximately $1.67 billion during its initial public offering (IPO) in 2004.

But there is another side to that number.

Cursor’s 2.0 Update and Focus on Margins

With the Cursor 2.0 upgrade, the software removed the ability to add specific Git commits into the chat context and restricted other context options, such as including all open tabs.

These changes might look technical, but they matter. If you wanted a quick way to reduce the average number of tokens used per request, this would be it. The tradeoff, however, is a noticeable drop in the quality of generated code.

Cursor Team would say to this that they are focused on Agents and that 2.0 introduced a significant push on supporting the future in which multiple agents (developers) work simultaneously. That’s true. It is also true that multiple agents were also supported before. Whereas the removal of context features is not backward compatible.

So it would be foolish to ignore that a major tradeoff decision was made, and it is not clear it was in favor of existing developers.

The co-founder departure

Earlier in October one of Cursor’s co-founders left. At the time, the news was surprising. One might even recall the famous “What did Ilya see” and restate: what did Arvid (the departing co-founder) see?

In retrospect, it doesn’t take much imagination to connect the dots. His exit likely signals fundamental disagreements about the product’s direction. Cursor’s AI model costs have probably been eroding margins, and leadership seems to have chosen control over cost:

• focus on their own (cheaper & dumber) model over foundational providers

• smaller context windows for average requests

• less hardcore developer focus, and more focus on “vibe” coders

I don’t know what Arvid has said to his friends about his departure, but I imagine he has serious disagreements with at least one of the above pivots from the initial core product thesis.

Is that the right call? Hard to tell. Building software is a never-ending struggle between prioritizing future users over existing users and vice versa.

As for myself (an existing user), I’ve already rolled back to an older version and turned off auto-updates. The 2.0 changes feel less like innovation and more like survival tactics from a company trying to stay afloat in a market where margins are punishingly bad.

Historical Parallels

There’s a historical parallel worth noting:

When it launched, none of us reasonable people could have predicted how a company could afford to pay for all that bandwidth. And it turned out, it could not. But Google could. And it did so for many many years - until the Ad vs Bandwidth equation turned into its favor.

Can Cursor survive another 5+ years to turn its AI token margins in its favor?

Some VCs have made a $2.3 billion bet that it can and it will. How good that is for the company remains to be seen. Was this number the right number? Would it have been better for them to raise, say, $800 million? Dunno.

Valuations do have consequences: talent joins for cash (not equity); exit options narrow down…

These are 20-year-olds running now one of the most influential companies of the AI age. If you thought Mark Zuckerberg’s rise to fortune was quick compared to that of Steve Jobs’s era, the Cursor team is about to see the whole experience at 10x speed. And they are going to make many mistakes. This 2.0 upgrade and the dollar amount raised in hindsight might yet be viewed as their biggest mistake, but it could also be viewed as the boldest move ever. Time will tell.

1)

2)

3)

4)

But all that was written prior to the agentic revolution. Agents don’t behave like data analysts. They speculate: issue many overlapping queries, branch, retry, and steer based on partial results and feedback.

There is argument to be made that we need agent-first data systems to cope with scale, heterogeneity, redundancy, and steerability - characteristics distinct from classic BI/ETL. While the Fivetran-dbt era was optimized for dashboard creation and insights, the next era appears to be optimized for what comes after the dashboards: OUTCOMES.

So with all that, a short revisit is necessary.

ETL Consolidation

To recap, Fivetran has previously acquired Tobiko Data (the team behind SQLMesh and SQLGlot). Separately, dbt Labs acquired SDF Labs earlier this year. The widely reported Fivetran ↔ dbt Labs deal is in advanced talks but not publicly closed. If it does close, SDF would come along for the ride under the dbt umbrella, meaning one company would control the leading connector platform (Fivetran), the most adopted transformation framework (dbt), a next-gen typed SQL toolchain (SDF), and a stateful transformation engine (SQLMesh).

Potential implications for the ecosystem are:

• Consolidation of the “T” (and more): Connect (Fivetran) + Transform (dbt/SDF/SQLMesh) positions Fivetran as a de facto end-to-end data pipeline vendor. Great for procurement; dangerous for optionality if primitives don’t stay open. While Tobiko says SQLMesh/SQLGlot will remain open source, it remains to be seen how likely that is.

• Overlapping roadmaps: dbt’s compiler + SDF’s SQL comprehension + SQLMesh’s state management are partially redundant. Expect convergence pressure: one planner, one type system1, one lineage substrate2. The migration path (macro syntax, state stores3, test/eval semantics) will make or break trust.

• Community stewardship risk: dbt/SDF/SQLMesh each have opinionated communities. A single owner raises the bar for transparent governance, long-term OSS commitments, and fair plugin interfaces. This is where the current approach (open APIs, closed products) can backfire.

• Competitive posture vs. cloud platforms: A combined stack is a clearer counterweight to Snowflake/Databricks “one-stop” narratives. Expect heavier bundling, deeper optimizer integrations, and “AI-ready” marketing.

Agentic Future - Out Data Infra, In Outcomes…

The big question though is how much of the above legacy stack is relevant to the agentic future. In a world in which AI community cares much more about obtaining outcomes without the specialized skills of infra, orchestration, and data pipelines, there is demand for a new kind of stack.

The idea is that you should be able to state intent in business terms and the system builds a typed semantic plan4 (entities, metrics, governance policy) and proposes data paths across sources. It then auto-generates tests, sample sets, and a minimal “proof” run before scaling, and continuous domain capture (not one-off modeling).

With every prompt, domain knowledge is accumulated as first-class assets (concepts, constraints, SLAs, policies). And any changes to definitions are versioned along with their explanations.

In this new stack, data pipelines are self-healing. When schemas drift or upstream quality dips, the system proposes edits (with diffs, impact analysis), runs shadow plans, and performs rollback (or forward deployments) with approvals.

However, existing Data-AI tools appear to fall far short of this vision. Most remain as features rather than complete outcome-focused products. AI that is designed to pull specific data, often missing the larger context of why that data is needed.

The key here is that the above changes are not going to happen overnight. Warehouses and lakehouses won’t disappear overnight. In the near term, the pragmatic path is to augment existing infra with: (1) typed semantics and static analysis (SDF-like), (2) stateful, multi-engine transforms (SQLMesh-like), and (3) agent-aware orchestration layers that budget, cache, and checkpoint aggressively. Cloud vendors and platforms are already moving to support “agentic AI in production,” but the data layer still needs to catch up. Most likely:

• Near term: You will be able to deliver agentic outcomes by bolting on planner layers to your current warehouse + streaming + MCP + vector DB stack.

• Medium term: Expect agent-first data systems to emerge: query planners and storage built around speculative, branching workloads with native governance5.

Bottom line: expect to see an introduction of New (agentic) interfaces, sophisticated retrieval optimizers, new storage with caching6 abilities, and entirely new governance engines for sophisticated permission-handling.

Today, most of that is handled manually by specialized infra engineers. No AI can handle spec-driven development of the data infra. For instance, in the case of dbt, an analytics engineer captures this logic in some sort of semantic layer7 - part of the stack that resides somewhere between the ETL step and the end-user query. This gives a lot of flexibility, but also comes at a heavy cost: developing the model and maintaining the codebase is a lot of work. Nothing significant has changed since Benn Stencil’s original 2023 quote:

The demos run in small sandboxes that don’t resemble real data environments. The test questions are basic, unambiguous, and could be answered by an experienced analyst in a handful of lines of SQL. The distance between current AI start-ups focusing on Data and companies’ actual data ecosystems is staggering. dbt Labs’ CEO, Tristan Handy, said that a meaningful percentage of their customers are using dbt to create more than 5,000 tables. In that environment, there are no simple questions—answering “How many new European accounts did we add last week?” requires defining an account, what new means, where Europe is, when a week starts, in what time zone it should be calculated in, and if “add” means net or gross.

Taking into account all of the above, I could not shake the feeling that I no longer see the Fivetran <> dbt merger as something that can have a significant impact on the future. We might actually be at a pivotal moment in history that these tools risk becoming irrelevant. Even industry leaders like Snowflake acknowledge the shift – calling themselves an ‘AI data cloud’ – but, as Amplify notes, that’s often ‘bolting new marketing onto old architectures’. Fivetran/dbt merger could prove no different.

Opportunities for new AI-native dev tooling

If the dbt acquisition completes, Fivetran won’t just “own transformation.” It will own three overlapping philosophies of transformation:

• dbt: project-oriented modeling with human-maintained semantics,

• SDF: typed SQL comprehension and static analysis,

• SQLMesh: stateful planning and multi-engine recomputation

That could be fantastic if it’s unified into an AI-native dev surface that starts from intent and ends with governed outcomes. Or it could calcify the last era: three compilers, two planners, and one vendor bundle.

More importantly, this by itself does not guarantee that Fivetran is moving away from infrastructure processes toward delivering outcomes.

In an outcomes-first world, standalone connectors and “T” engines become liabilities: more surface area to integrate, govern, secure, and maintain, without guaranteeing the result the business actually needs. Together, Fivetran + dbt can move teams closer, but real gaps remain, and it’s not obvious that the two can be seamlessly unified in practice.

There is a very real opportunity now to rebuild this stack the AI-native way: let AI maintain the codebase, continuously capture domain context, and orchestrate from intent to answer. Five or ten years ago that sounded unrealistic. Today, it’s within reach.

But even more importantly, it is highly unclear what is the future of traditional data engineers? That’s a post for another time. For now, a picture will do (via x.com/@klabsintexas):

That’s the bet behind KLabs’ new AI-native DevTool designed to collapse the distance between a question and a reliable result, while the system handles semantics, pipelines, and governance in the background. The bet is clear: outcomes as the product, with AI maintaining the code and the system absorbing complexity: typed semantics, stateful planning, evals, governance, and agent-aware orchestration. Domain experts focus on what needs to happen, not how to wire it together.

So my “take” on the acquisition is simple: it’s a milestone of the last era. The next era belongs to platforms that make outcomes the product, not the by-product…

The launch was met with fervor. Within hours, DxGPT buckled under a deluge of users, crashing the app and making it slow to load even two days after Satya’s announcement.

But with all the noise of the modern world, from politics to tech, most have failed to notice that the site’s slow performance was/is a “tell” and a revelation: the public’s response underscored a deep, unmet need for accessible, AI-driven healthcare solutions.

Healthcare today is a paradox: information abounds, yet clarity remains elusive. Patients endure long waits for specialist consultations, misdiagnoses plague the system (studies suggest up to 12 million Americans are misdiagnosed annually), and rare diseases, affecting 1 in 10 people globally, often go undetected for years.

DxGPT’s crash wasn’t a stumble; it was a stress test, proving that people are ready to embrace AI as a lifeline in this fractured landscape. The question is no longer if AI will transform healthcare, but how fast and who will lead.

The contenders are many. One such stealth contender is reportedly a high-profile Founder, Adrian Aoun, who, after burning through $400M in funding for his previous healthcare company, Forward, is apparently now building (or so the word on the street) a new healthtech AI stealth start-up.

While I wish Adrian and his start-up luck, one has to wonder where and who actually has the magic “moat” in Healthcare?

Enter Flo.health

Amid this fervor stands Flo.health, a juggernaut in women’s wellness with over 50 million active users and 200 million downloads since its inception, and its unusual founder, Dmitry Gurski:

Dmitry is everything that Adrian is not (and vice versa):

• Adrian studied Computer Science (and Psychology) at one of the most expensive schools in the country, the University of Southern California; Dmitry studied Pharmaceutics at the university for, mmm, well, at Belarusian State University 😅

• Adrian is one of the most fluent communicators in Silicon Valley; Dmitry is a heavy-accented Eastern European whose words are often hard to grasp

• Adrian is a boilerplate “Silicon Valley”. No talk of his misses an opportunity to drop names like Larry Page, Max Levchin, Marissa Mayer… Dmitry talks about his time collecting potatoes as a kid growing up in Belarus, and does NOT live in Silicon Valley (lives in the U.K.)

• Adrian is a Corporate veteran (White House, Microsoft, Google); Dmitry never worked for anyone other than himself.

It is hard to think of Dmitry and an app that tracks menstrual cycles as part of one sentence 🤯, but here we are: The future of Healthcare. (Don’t believe me - be sure to check out their Series C Deck👇🏽)

Flo’s app tracks menstrual cycles, fertility windows, and symptoms, creating a rich tapestry of data that’s both granular and global. Unlike DxGPT’s narrow diagnostic focus, Flo’s mission is expansive: to empower women with insights into their reproductive and overall health. Their dataset spans continents, age groups, and lifestyles. It is a treasure trove with untapped potential - THE MOAT.

Flo’s edge lies in its ability to move beyond generic tracking, such as cycle predictions or ovulation alerts, into personalized, predictive care. Basically an app that not only logs your symptoms but correlates them with environmental factors or lifestyle habits, offering deep recommendations.

Flo.health Series C Fundraising Deck Preview (Full Deck👇🏽)

Interested in full access, including Flo’s Series C 53-page fundraising deck? Subscribe for our deep dives and receive access to the full paid content.

Get 20% off for 1 year

Flo has the pieces; the challenge is assembling them into a picture users can’t ignore.

AI’s ascent in healthcare is no flash in the pan. The past decade has seen titans wrestle with the promise and pitfalls of intelligent systems. Today, adoption is accelerating: a 2023 Deloitte survey found 75% of healthcare leaders plan to invest in AI within two years. DxGPT and Flo.health are not outliers - they’re harbingers. But where DxGPT narrows its lens, Flo casts a wider net, reflecting two sides of the same coin: precision versus personalization. Both must navigate a public eager for solutions but wary of overreach.

Flo.health’s Data Advantage

Flo.health’s dataset is a marvel: millions of women logging cycles, symptoms, sleep patterns, and more, often daily. This isn’t static data, it’s dynamic, revealing trends over time and across populations. With over 50 million active users, Flo commands a sample size that rivals clinical studies, dwarfing the datasets of most health-tech startups. Herein lies their superpower: the ability to craft insights that feel intimate, not impersonal.

Consider the possibilities. A user logs irregular cycles and fatigue; Flo could cross-reference this with millions of similar profiles, factoring in age, location, or even seasonal shifts, to suggest a hormonal imbalance before a doctor’s visit. Or take fertility: Flo could predict ovulation windows with uncanny accuracy, adjusting for stress or diet logged via integrations like Fitbit. Today, Flo offers broad advice, “stay hydrated” or “rest more”, but their data could power a leap to “your cycle suggests X, try Y.” This is personalization as a promise, not a buzzword.

Yet scale alone doesn’t win. The AI must be smart - smart enough to distill noise into signal. Flo’s current offerings are a foundation, but the next step is algorithmic sophistication. Partnerships with medical researchers or AI specialists could unlock this, turning raw data into a competitive moat.

The Privacy Tightrope: Lessons from 23andMe

Read more

The second largest acquisition by Google Cloud before Wiz was Looker. At Looker, I was the 30-something employee, and when I try to visualize the progression from having a CEO lending his car to help move employees across town (true story), to having that same CEO manage an army of thousands 95% of whom he/she does not know, I ask myself if there really is such a difference between Product companies that VCs like to fund and the Services business model.

A 2,000-employee organization after 5 years sure does seem a lot more like a services organization than a product company. For context, Dropbox, which has 3x the ARR revenue, has just 1.5x the # of employees - and that’s an 18-year-old company.

But Wiz is not the only one. Look around, and almost every Series C+ enterprise company looks similar. Every VP / Director is an ex-hyperscaler employee, whose sole job is to come into the new start-up and hire like a machine. At Looker, my teammates and I had a name for our 50-year old VP: The Robot. He did not manage us, he did not lead us - 90% of the interaction was centered around interview schedules and occasional reorgs.

And yet, it is quite possible that this is not what companies are going to look like in the future:

Wiz - the end of an era

Just like Wiz 5 years ago, another company currently with ~40 employees is Anysphere (Cursor.ai). Cursor is three years into its journey with 40 employees, and it is now making $150K in ARR, almost 1/4 of Wiz revenue with 60x fewer employees.

Like Wiz, Cursor.ai started with a team of 4 founders. 4 founders with an average age almost 1/2 of that of the Wiz founders. Age is not the only difference. GTM playbooks are quite different, too. And yet, one can imagine that at their ultimate successful adoption, both product companies look roughly similar: strongly embedded inside enterprise organizations through both technology and relationships (i.e. account management + customer success + professional services).

The striking difference in ARR/employee perhaps highlights not only the background of founders, but also the eras:

Old Era: Experienced Execs leading armies of ICs

New Era: Flat orgs with significant mid-level contributors

The idea is that while relationships will continue to matter, one person can and will be able to handle more.

Shifting tides of ARR/employee - What’s old is new again.

Flashback to 11 years ago: I got hired at Looker as a Data Scientist. Surprise—they didn’t need one. What they needed was someone to solve customer problems. So, I became the first person in Looker’s Professional Services.

For the next two years, I wrestled with two competing internal visions for scaling the team:

Option 1: Scale wide

- Hire more, but increasingly less competent specialists, each handling fewer customers.

Option 2: Scale deep

- Focus on expertise, solve scale problems with smart internal and customer-facing tools.

Leading by example, I was Team 2. While others juggled 1-2 customers, I had 16 concurrent customers, and over two years, 50+ companies such as AbleTo, Carta, Credit Sesame, DigitalOcean, Peloton Cycle, Procore, Plaid, Strava, Wise

👉 Continued on X…

So I am very excited to finally have an in-depth video discussion with my partner-in-crime, Abhishek, on why technology side of AI application development is actually so hard to get right.

AI Application - an Example..

But first, consider an example. One of the very hot AI topics right now is automated SDR agent. The development process for which might look something like this:

Step 1) Product Manager starts playing with prompts on ChatGPT and comes up with a prompt prototype:

You are an expert sales development representative crafting personalized outreach messages. Your goal is to create engaging, professional messages that demonstrate value and encourage response.

Context to use:

- Company: {prospect_company_name}
- Prospect's Role: {prospect_role}
- Prospect's Name: {prospect_name}
- Company Size: {company_size}
- Industry: {industry}
- Recent News/Trigger Event: {recent_news}
- LinkedIn Activity Topics: {linkedin_topics}
- Company Website Key Points: {website_points}
- Our Product/Service: {our_solution}
- Our Unique Value Proposition: {our_uvp}
- Key Pain Points We Solve: {pain_points}
- Relevant Case Study: {case_study}

Guidelines for message generation:

1. Start with a personalized opener referencing either:
    - Recent company news or achievements
    - Prospect's LinkedIn activity
    - Industry-specific challenge
    - Mutual connection (if available)
2. Demonstrate research and relevance by:
    - Mentioning specific details about their company
    - Referencing their role and responsibilities
    - Acknowledging industry-specific challenges
3. Bridge to value proposition by:
    - Connecting their situation to a specific pain point
    - Using social proof from similar companies
    - Highlighting relevant metrics or outcomes
4. Include a clear, low-friction call-to-action that:
    - Respects their time
    - Offers specific value
    - Provides multiple response options
5. Keep the tone:
    - Professional but conversational
    - Confident but not aggressive
    - Focused on their needs, not our features
    - Brief and scannable (2-3 short paragraphs maximum)
6. Avoid:
    - Generic statements that could apply to any company
    - Technical jargon unless prospect is technical
    - Long blocks of text
    - Multiple calls-to-action
    - Excessive formatting or symbols

Please generate a message using the above context that sounds natural, not automated, and focuses on building a relationship rather than just making a sale.

Additional instructions:

- If certain context fields are empty, focus on the available information
- Adapt tone based on prospect's seniority level
- Include one specific metric or result when mentioning case studies
- Keep total message length under 150 words
- Format with appropriate spacing for readability
- End with a question that's easy to respond to

Step 2) Next stage is to map out all the systems required. This might include a waterfall approach to email address discovery, a crawler for scrapping data from LinkedIn, plus some 3rd party software for overall email deliverability and drip automation.

Step 3) Finally, all this is packaged together into some “black box” interface, and the whole thing seems like a clear winner product idea.

Except, it won’t be!

“Dumb as a rock” AI and how to avoid one

The problem with these approaches is that they blindly assume that once you have gathered some unstructured data, it is magically usable in a highly structured approach:

- Recent News/Trigger Event: {recent_news}
- LinkedIn Activity Topics: {linkedin_topics}
- Company Website Key Points: {website_points}

What they fail to recognize is that even in this simplistic example, figuring out how to work with scrapped data is a lot harder in practice than it seems.

Consider the Airtable product example I wrote about previously. Abhishek walks us through the challenges of Airtable data, and how even the use case so seemingly simple as a spreadsheet table can turn into complex spider web of decisions:

But you just need TEXT, right?

Wrong! One of the misperceptions about data preparation for LLMs is that as long as everything is in the text format, LLMs will figure out the rest.

However, when it comes to AI engineering, we don’t just care about text - we care about the meta information conveyed in text. Not all sources of text are created equal when it comes to meta data, so it is important to normalize things first:

The takeaway!

If you have watched my other podcasts before, you know there is always a single takeaway that I like the viewer to walk away with. Altogether, Abhishek and I covered about 7-10 important points one should keep in mind about data when implementing LLMs via RAG.

Watch Full Recording

And it was difficult to highlight a single advice. Investors can keep calling all these things “AI wrappers”, but if this discussion has a single conclusion, it is perhaps this: building good software is still hard and you need a lot more planning when it comes to data for LLMs than just “let’s move things to a vertical database and hope for the best”.

Also, I stand by my words. Sam is one of the more obnoxious VCs out there with little to no visible empathy gene. Everyone knows it and he is probably quite proud of it, so whoever is claiming that I “hate” him or “dislike” him (actual comment on X), is imagining that this is a game of checkers, while us, actual adults, are playing chess. (Former chess player here…)

But let’s talk substance….

Ideal Founder Archetype: Older is Better!

To give Credit where it is due, Sam posted this earlier in the week:

Those who read this publication regularly know how critical I am generally of YC lately precisely for this point. They have tilted recent batches to the similar age demographics they had during the early days of YC (College students, drop outs, and recent grads), and the result is that we’re seeing a flood of copy cats that are pursuing ideas on the surface without own genuine deep insight into the problem space.

The ARR numbers look great because YC is designed to make the numbers look great. Everyone knows that once you get into YC, other founders offer to buy products from you while you’re raising, but ultimately offer no long-term guarantees that the subscriptions are going to stay around.

Even if you’re building yet another AI SDR agent of which there might be 10 other YC companies, with 300+ Late stage YC alumni companies to sell to, that’s still 30+ customers each (or at a minimum $1,000 x 30 x 12 = $360K ARR) on day 1. Pretty awesome until they all churn!

But this newsletter is not aiming to be a negative critic (even though sometimes it comes across as such). It is meant as a medium that proposes solutions. So here goes my solution to Sam’s challenge…

Ideal Founder Archetype - Mir’s Appendix

The ideal founder age is indeed shifting older. For the first time in 10,15+ years, the key way to take advantage of tech is not to rediscover the wheel, but to apply one’s knowledge of why the new generation of wheels can be built differently because of AI.

Or, the example that I personally like to use (wait two weeks before every Founder pitch uses this): imagine a new car battery is invented that is 10x more efficient. While it probably makes sense to invent a new type of car from scratch, it still helps to know how and why the old car was built the way it was.

Which brings me back to the challenge: who is the ideal archetype of 2025?

Professional Services…

“ProServ..” - The words that should never be mentioned in a fundraising meeting

Anyone raising $$ for an enterprise software in Silicon Valley knows one golden rule: initial businesses are built via services, but money is raised for them without ever mentioning services. VCs hate to hear that revenue is services-led. Never mind that some of the most successful enterprise companies were built this way: Looker, Palantir, Oracle - to name a few.

Now, the criticism of services is understandable. On average, owners of IT service firms are not the smartest of the pack. It is literally the business where being a schmoozer at conferences is rewarded, and being a technical domain expert is not. Companies bring on PS firms for highly technical domains, even though Partners have barely completed their University of Phoenix English degree. The main skill that matters is whether this Partner goes to all the right parties - less so if they have the chops. Often (not always) even their technical employees are 3rd tier.

Furthermore, building a services organization is very different than building a product - requires a different kind of Founder DNA. Someone Uber-successful at Services probably has no Product DNA. Looker was unique here - Lloyd Tabb, the Founder, had both, the consultant’s DNA and the Product builder’s DNA - but such Founders are rare. And it is difficult.

And yet, the trend is clear. Yours truly is leveraging AI on top of what previously would have been Data Engineering work. Many of the more capable people in my network, who previously were in services are now starting their own software product firms where they leverage AI on top of the manual processes that they already had before.

In essence, it is the perfect business model. Take a customer-centric business that is filled with flawed human interactions, and replace it with an automated AI agent service. Still plenty of questions about quality and level of sophistication, but if we’re being honest, most PS firms in IT with more than 20/30/50 employees are pretty low standard - not to mention the typical 200+ employee outsourcing shops.

Alright, enough of the weekend drama. Stay heathy and have a good weekend!

First, Perplexity, his darling investment, blew up on X when numerous stories came out that the company was giving away their priced version for free, and many of those users subsequently switched to something else.

Then, on Friday, another one of Elad’s premium investments, Cognition Labs (aka Devin), made a major splash, when a well known AI influencer published his comprehensive test - showing that Devin’s accuracy is less than 20%.

Not even a day passed since the publication, but X blew up with comments - some outright calling the founder, Scott, “fraud”.

X link to post, Publication

Of course, loyal readers of this newsletter will remember our warning back in April of 2024, but alas, Cognition’s VCs doubled down. Oh well!

Implications

If this post feels like it is about Elad, it is not. Everyone makes mistakes. And a Solo VC with a billion AUM is likely to make more mistakes than most.

The real implications is that now there are at least two companies out there with tons of capital to spend, and no clear way of getting out of this mess.

And when internal efforts fail, companies inevitably start to look elsewhere - via M&A.

How many such over-funded firms out there in the AI space? Many!

This leads to only one possible conclusion: 2025 is going to be a great year for M&A. Companies will either be bought or they will be doing the buying.

In the case of Elad’s two companies, it might actually be both. Time will tell. For now, the two CEOs (Scott and Aravind) clearly diverge. Aravind, rightly or wrongly, is claiming to be a buyer:

And Scott is either warming up to Microsoft, or just should not be Cognition’s CEO to begin with.

Because one thing is clear about 2025, things are about to accelerate, so if you’re an AI company, and you don’t know whether you’re in the buying business, or the selling business, then you probably have no business being the CEO.

-SG

Call this newsletter anti-VC, BS opinions, but if you trace the timing to what eventually happens, it does predict things by about 6-12 months.

I am not actually that anti Perplexity. I think it is an awesome search, and there is still tons of potential. But everything is relative. Relative to competition, the price point, the required investment.

Right now Perplexity is on the Sam Altman type of fundraising curve with an even worse business model. Meanwhile, Sam Altman actually is just going to build the next Google because he has to and has no other choice.

Elad Gil can ignore this at his own peril:

1)

2)

Those of us who grew up learning Excel MACROS had a moment of instant gratification when back in March of 2024, Airtable announced the release of several AI features. Finally, it seemed AI would take care of the pain Excel caused so many.

But the moment was fleeting. Today, no one I know who actively uses Airtable has knowingly subscribed to their AI features. Yours truly had tried their AI formula suggestions for a month, and walked away unimpressed.

The experience, while unusual for a company with such a strong product DNA as Airtable, is actually quite representative of the broader problem trying to introduce AI as features by the incumbent players.

To name a few, Asana and my own alma mater, Looker, are currently facing similar challenges. Product ideas that are obvious on the surface, fail in real life as AI capabilities feel raw and unpolished.

AI vs Traditional Product Life Cycle

I was speaking to a potential customer the other day about AI Product features, and we arrived at a new notion: AI engineering needs to have a separate timeline from Product Feature Development.

Consider traditional engineering-based product development lifecycle:

1. Identify and validate customer needs

2. Create and refine an MVP

3. Beta test and prepare for release

4. Plan early adoption

5. Market

6. Gather feedback and scale

Note that something is missing here. The whole item list is about minimizing Go-to-market and adoption risk.

What’s missing is that AI’s value proposition is actually most of the time obvious enough that it is not the source of adoption risk. Consider a similar list for a typical introduction of an AI feature set:

1. Identify the problem and scope (AI)

2. Assess technical feasibility and gather data (AI)

3. Train and validate (AI)

4. Create raw model / technology prototype (AI)

5. Test and make changes (AI)

6. Create and refine an MVP (Product)

7. Beta testing and prepare for release (Product)

8. Market (Product)

9. Gather feedback and scale (Product)

Note how only the last 4 items are similar, while the first 5 are entirely new R&D / AI items that did not exist in the traditional product development. And so, I would argue, the risk in AI product feature adoption is from technical capabilities, not from Go-to-Market (as in traditional product development).

AI is hitting a Wall

Those who have been paying attention will know what I’ve been publicly saying for months now (and privately for several months before that) - namely that AI is going to hit a wall. This idea finally seems to have quietly gained general consensus (as noted by CEOs of Scale.AI and Databricks) and did not require us to wait for an entire year as I originally suggested:

While potentially bad for dumb capital allocators (cough--Softbank--cough) who essentially give AI companies $$ to buy NVIDIA’s GPUs, the development is really good for the rest of the ecosystem. Finally, we can treat OpenAI, Anthropic’s Claude, and the rest of them as a commodity services, that they are, and stop debating who has a better model (Spoiler: they do not compete on quality).

And what that means is that as an ecosystem we have to become less dependent on artificial boosts in the quality of output from Large Language Models, and start building quality AI end-user applications.

Basically, we cannot continue introducing AI into Products as we normally would other features. Instead, every AI application development team needs to be viewed as a R&D lab. An R&D lab whose end output is a technology / model / methodology / framework feeding inputs into the new product development lifecycle.

Why Airtable?

Those who follow this blog for awhile will note that when it comes to data, I typically like to talk about Snowflake, Databricks, and my own alma mater, Looker. I also occasionally cover other business Intelligence tools.

What very few know is that I am secretly a spreadsheet nerd. And I don’t mean just an average IB Analyst-level Excel junkie. From Macros to entire BI applications on top of Spreadsheets, I’ve done it all. I’ve integrated spreadsheets with databases. I’ve built entire loan underwriting platforms on top of Spreadsheets. I’ve probably found more ways to hack spreadsheets than the original developers ever intended. So when Airtable came along and introduced its AI formulas, I was “all in” for it.

But looking at AI in the context of spreadsheet is important for other reasons as well. Today, there are thousands of conversations happening around the traditional Data Stack and the introduction of AI capabilities into it. Databases and BI tools market new features. Integration platforms pitch to investors their big visions about uniting the world of tools. Everyone has grand AI visions.

And many of these pitches, no doubt, are indeed directionally accurate. The only problem is that when it comes to technology, directional correctness is not enough.

AI products are like vectors. Vectors require both direction and magnitude. In some markets, magnitudes are obvious; in others, an incorrect magnitude is a difference between a billion $ outcome, and a complete failure; analytics is one such market. Hundreds of teams have attempted to build Unicorn companies, but only Tableau and Looker have succeeded in breaking through the billion dollar exit. These two companies had the correct vectors - both in direction and magnitude.

Perhaps in other markets the difference in magnitude is not as severe. Maybe it is totally OK for Asana to have a crappy AI Helper interface. Or maybe a developer in India will copy all of Asana’s functionality, cut the price in 1/2 and introduce a really well fine-tuned AI helper interface. Would that be enough for me to exit out of my Asana subscription. Probably…

-SG Mir

Head of AI, Data, and Product

Voting was just never a big priority for me. At some point in my early 20s, I did a quick calculus on the whole electoral process and realized that my vote won’t matter in my then-native state of California.

Family members called me apolitical, but it was not true. For many years I have watched politics from the sidelines, and largely was in awe of the striking difference between politics around the world—where political manipulation was plainly evident—and the United States—where it was often hard to follow how exactly the sausage was getting made.

Speaking of which, Dick Cheney, now a person from another era, whose name recently again came up in the context of endorsing Kamala Harris, of course, deserves the top prize for political manipulation. I was just coming of age when Bush Jr. declared the war on Iraq. When it all happened, like everyone, I naively watched the events unfold with little context as to what it all means.

Meanwhile, across the world, by some broad estimates, as many as 500,000 (likely more) people were killed in the ensuing violence, giving birth to, among other things, ISIS, and the modern makeup of Iran-Iraq alliance. More deaths around the world resulted from the war in Iraq than the deaths of all the American soldiers since the signing of American constitution. Nuclear weapons were never discovered, and largely everyone understood that Iraq was a personal Bush-Cheney project, setting the Republican Party back for more than a decade.

But that was early 2000s. As I think about this year’s presidential elections, I am amazed at how American politics is starting to resemble the politics of a banana republic I was so used to seeing in other parts of the world as a child.

Perhaps it is just me aging… But I don’t think so! For one, this is not just about presidential politics. The politics of tech has changed too.

The banana republic politics of Data Tooling

This blog originally started with me talking about data vendors - not politics. And over this time, I have made my views quite public. So in the continuation of that same tradition, here goes nothing…

For 15+ years, we, as data professionals have debated the best practices and the best choice of a tool for one use case, or another. And perhaps like in the world of politics, many of us are now walking away disillusioned:

There is so much wrong in the data vendor selection process that U.S. politics might actually be a more honest competition. At least in the politics, candidates are tasked with putting themselves up on stage in first person (many founders of data vendors hire armies of Sales People to do it on their behalf).

Yet, one common problem current data vendor landscape has with elections is: Identity Politics

Believe it or not, data vendors have Identities:

1) Alteryx & Atscale

A & A tailor to the boring corporate buyer:

2) DBT & MotherDuck

DBT & MD tailor to the alternative view points (or as a friend would say: “Business Intelligence engineers who want to get paid 1.5-2.5x the market salary and be called under a special title”)

3) Looker & PowerBI

Looker and PowerBI tailor to the main street buyer. You pick one of these like you would if you were buying a kitchen pot, while shopping for groceries at Walmart - it is just convenient.

4) Tableau & Oracle

And finally, Tableau and Oracle tailor to the type of buyer, who buys from Accenture because no one ever got fired for hiring Accenture.

Reclaiming my North Star

Perhaps I am just naive about both politics and the data vendor landscape. I remember crystal clear the moment I decided to become good in data. The year was 2008. I was interning for one start-up and looking at their web logs. No one inside the organization could make heads or tails what any of it meant. Right there and then I decided that I wanted to understand facts and the truth of how systems and the world work.

But in my many years in this profession, I have encountered many types of people. And just as in politics, people enter the data profession for different reasons. Increasingly, fewer and fewer people practice the craft for the desire to understand the real truth. People do it for all reasons but the truth and facts. Vendors are picked for their perceived political identities. Investments are made in companies based on anything but the fundamentals.

It was not always like this. For instance, back in 2015, everyone at Looker was deeply passionate about data. And it was also an organization without a political polarization. I remember one engineering kid loudly announcing to the entire org. that he was a conservative republican - something no one really cared about. Would that be possible today inside Google’s Looker? Would that be possible today inside DBT? I suspect, the answer is a “no”. And if so, can those organizations honestly claim to respect the truth of data if internally they are not tolerant of all political views?

In the midst of thinking about this I realized that 2024 is when I do finally vote in the presidential elections. And my thinking went something like this:

You Vote at the booth so you can tell your kids you did.

You Vote with Polymarket so you retain your ability to tell which way North is.

So that’s how I voted! 😄

And if you read this far, I suggest you take another 1-2 extra steps and follow me on here:

About a month ago I made a prediction to my inner circle that as soon as OpenAI releases GPT5, the industry will learn that further improvements in quality have significant diminishing marginal returns (the reverse of exponential curve) - essentially making any future progress at the foundational level quite costly, if not impossible.

OpenAI came up with a workaround, and reset their model # to an obscure o1. Nice trick, but this will not protect them from PR info-wars forever. Even with o1, the industry is starting to notice that improvements are only marginal1.

So it is likely we're going to see OpenAI try to delay the release of GPT5 as long as possible, or avoid it entirely.

What to make of this “AI Ceiling”? Honestly, this is very good. Good for the industry and especially good for application developers. The focus is finally going to shift to satisfying customer use cases with real product feature sets, and not chase artificial boosts through what essentially amounted to juicing software products with RedBull.

But you don’t have to believe me. We can wait and see this game play out in real terms and check back a year from now.

Until then, I am busy working and proving my theories in practice, but can always be reached at:

• LinkedIn

• x.com/getdml

  
  

If there is one business rule to stick to, it is that you never want to go against Nike’s Marketing team - the folks who predicted Michael Jordan.

And here it is again, on July 19th, Nike 👟 released this video 👆, which speaks for itself.

In this publication, I like to vocalize my analysis and take positions on what’s going on in the world of tech, AI, and data.

Sometimes I also talk about seemingly unrelated stuff. Here is, for example, what I wrote about how I voted in this election:

But if there is one lesson to take away from this Presidential Election it is this:

No level of SWAT analysis by consultants, Venture Capital-drafted spreadsheets, founder pitch decks, analysts dashboards, or even of this very “Report”…

can beat just “going out there, and doing the damn thing”.

or as Jon Stewart put it:

So in the true spirit of this new era’s founder-mode, and without further ado, are you looking for an Interim Director of AI / Data?

Do you need an owner who will setup your infrastructure?

Are you tired of wasting money on expensive Snowflake/Databricks/DBT/Looker deployments?

Do you just need someone to “do the damn thing“?

Maybe, you just need me!

Anton posted this on X today, and while I whole heartedly agree with him, it missed the point. We’ve done this same thing with every other branching of engineering: frontend dev, data engineering, devops… Hardly anyone calls a Frontend Developer today a “Programmer”. The reason we do it this way in tech is to broaden out the category and get more folks into it.

Frontend Devs all feel like a group to each other because they all can identify the difference between writing in TypeScript vs old vanilla Javascript, while to everyone else it is all just Javascript.

Data Engineers identify themselves in other Data Engineers because they can all tell the difference between a Luigi and a Cron Job, while to the rest of us it is all just ETL.

Analytics Engineers are all able to laugh at names like “Coalesce” (the Conference), but to everyone else it is just a strange word with no meaning.

Bottom line, you want to matter and start a movement - you better come up with your own language, or you will not survive and something like Oracle will come, and eat you alive.

Happy Friday!

p.s. here is Anton in his own words:

Last week I wrote a post about my belief that any vision of Perplexity becoming the next Google is entirely misleading. Since then Google once again made a huge public blunder with its AI-assisted search. Examples are all over the web now - from glue in pizza to misleading statements about ideal temperature for cooking a chicken.

So is Google done? Should I take my words back?

The short answer is “No”. What Google is going through is a clear lack of product leadership. Anyone who has ever ran a great engineering team knows the feeling. A great engineer coupled with a great product leader is magic. Remove product leadership and I don’t care if you quadruple engineering, the team just won’t build anything good. They will be focused on the process - ultimately shipping something that is not for consumption. This is what Google is going through.

But there is actually a solution to such engineering problems: customers. Within limits, it is possible to avoid the need for strong product leadership by just putting the product in front of customers. From my experience, this won’t give engineers PMF-level feedback, but it will get them to dial down issues in architecture and AI. And basically this is what’s happening now with Google - on unprecedented scale.

Soon we will learn that Google does not need to innovate in the search, because they can just put the product in front of 10 million people, and watch feedback on twitter accumulate. Sensible strategy? Not really. Is it absolutely destroying my trust in Google’s talent pedigree? Yes - probably would not hire anyone directly from Google again. But will they recover? In search, yes!

Meanwhile, something else is happening. Devin AI is all about kissing up to Redmond’s executives like never before, and people are starting to make a bet that there is a strategy behind the scenes to execute a quick flip of Cognition to Microsoft.

If so, it would be a first in Satya Narayana’s awesome streak (LinkedIn, Github, OpenAI…). Anything is possible, of course. The last 4 years have shown is that we live in the upside-down times.

But what would actually make much more sense: Satya acquiring Perplexity.

Perplexity → MSFT

People nowadays have a very short memory, so it is easy to forget what exactly makes Google, Google. People tend to forget that in the late 90s the were many search engines. That it wasn’t clear that Google would win on just search itself. Yes, it had that thing called “PageRank”, but by early 2000s, that was neither the differentiator nor the core of its technical IP. Arguably, by the early 2000s the bigger things were: massive self-hosted server locations and brand. But, of course, the biggest differentiator of all: Adwords.

Will Perplexity discover its own version of Adwords? Dunno. This is not 2000. Ads are much more lucrative in social media than in direct search. And it is not even clear how receptive people will be to ads in AI-powered search. Also unclear how any paid model would be executed in the face of all the easy wrappers on top of ChatGPT.

Meanwhile, MSFT has all the ways to monetize search and actually has a pretty good mass-scale brand to go with it. Not saying this is a clear thing. Valuation expectations might make the whole thing impossible. Yet, this is actually what would make things very interesting, and would probably get me to become a loyal Perplexity/Bing user.

Have a good weekend! And, as always, let me know what you think..