The Computomatix Times

Shazam could name any song back in 2002, on flip phones, with zero AI. You dialed the number 2580, held your phone up to the speaker, and hung up. 15 seconds later, a text came back with the song name. That same core trick still runs the app today.

The inventor was Avery Wang, a Stanford PhD in audio signal processing. His problem was brutal. Match a short clip recorded on a 2002 cell phone mic, in a noisy bar, against a database of a million songs, in seconds, over a phone call.

His solution treated music as geometry instead of sound.

The algorithm converts audio into a spectrogram, a picture of the song, then throws almost all of it away. It keeps only the peaks, the loudest frequency points at each moment in time. Bar chatter and blown-out speakers can wreck most of a recording. The peaks survive. Shazam only ever needed the peaks.

Those surviving points form what Wang called a constellation map, because it looks like a star field. Pairs of peaks get converted into hash numbers, and identifying a song becomes a dictionary lookup rather than an audio comparison. That made it fast enough to search a million tracks on 2002 hardware.

Wang published the full method openly in 2003 in a paper called "An Industrial-Strength Audio Search Algorithm." Anyone could read exactly how the magic worked. The moat was the database and the deals with carriers, never the secret.

Apple bought the company in 2018 for a reported $400 million. People have tagged over 100 billion songs since the very first one, Jeepster by T. Rex, during the beta in April 2002.

One deterministic signal-processing trick, written before most people had heard the phrase machine learning, and it's still so good that in 2026 everyone assumes it must be AI.

Ohio once dissolved an entire town because its main business was writing speeding tickets.

New Rome had 60 residents and a 14-officer police force. One cop for every four people in town. They collected around $400,000 a year in fines, 92% of the village budget, mostly by working a stretch of road where the speed limit dropped from 45 to 35.

A state audit then found the village was spending 82% of that budget on the police force. The town's only real industry was funding the thing that funded the town. In 2004 a judge ruled New Rome had effectively dissolved itself through corruption and erased it from the map. Its land got absorbed into the neighboring township.

Missouri ran the same experiment with Macks Creek, population 272, sitting on the highway to Lake of the Ozarks. The town wrote 2,900 tickets a year. Eight a day, almost all tourists who would never drive back to fight them. More than 75% of town revenue came from fines.

Then an officer there pulled over a state legislator. He went back to the capitol and passed a law capping how much of a city's budget can come from traffic tickets. Macks Creek lost its revenue stream, went bankrupt, laid off its entire police force, and disincorporated. The IRS seized the town's bank account.

Speed traps cluster wherever a highway full of out-of-towners meets a sudden limit drop in a state that lets the town keep the money. Missouri now caps ticket revenue at 20% of a city's budget. Ohio had to pass a law aimed at one specific village.

A speeding ticket heatmap doubles as a map of who's allowed to keep the fine money.

The serious answer to how Shazam worked is it took the peaks of a spectrogram of short clips of every song, find the peaks from the highest amplitude bits, hash it with the value being (time stamp, track id) and then the actual recognition is a hashtable lookup.

We did this for a college CS project. The original paper is fantastic:

A $400K grant from Google is worth $400K.

A $400K grant from OpenAI is worth about $242K today.

Same number on the offer letter. You can sell Google stock the day it vests. OpenAI is private, so you sell only when the company runs a tender.

Here's the formula I use for any private grant:

Value = Quoted equity × P(payout) ÷ 1.15^years to liquidity

The 15% is your discount for money you can't touch. For a late-stage company with real revenue and a tender history, P(payout) is 70-90%.

OpenAI, 2 years to a sale at 80% odds: $400K × 0.8 ÷ 1.15² = ~$242K.
1 year at 90%: ~$313K. 3 years at 70%: ~$184K.

Earlier stage gets brutal. A $400K grant at a Series C with an IPO 5 years out at 40% odds: $400K × 0.4 ÷ 1.15^5 = ~$80K.

The formula gives no credit for growth past today's price, and OpenAI has had a lot of it: $157B to $852B in 17 months. So treat the number as your floor.

Compare offers on what the equity is worth today. Then negotiate the gap in base and sign-on.

To become an AI PM, you need six skills on top of core PM. Here's the order to learn them.

The pay gap is why it's worth it. Glassdoor puts the average AI PM at $198K in total pay, against about $151K for PMs overall.

Most AI PM learning maps I see are generic PM concepts with "AI" in the title. They skip what hiring managers screen for, which is proof you've done the work.

So in this map, every stage ends in something you can show.

1. Learn how the models work

Tokens, context windows, embeddings, tool calls, agents. You don't need to train a model, but you should be able to sketch everything that happens between a user's prompt and the reply. A PM I coach hit exactly this depth check in technical screens at both Nvidia and Glean.

2. Engineer the context

Everyone rents the same models, so the edge is what you feed them. Climb only as far as you need. Prompting first, RAG when answers depend on your data, fine-tuning when a style has to stick. Your proof is a Claude Project loaded with your past PRDs that drafts a spec your team would sign off on.

3. Hand work to agents

Chat answers a question. An agent finishes the whole task, as long as your brief has a goal, the right context, the tools it can touch and a clear definition of done. Your proof is one recurring task, like a weekly competitor recap, running on Claude Code or Codex while you only review the output.

4. Prototype it yourself

Alex Danilowicz, CEO of Magic Patterns, said on my podcast that the classic mistake is spending two hours debugging a database when all you needed was a clickable mockup to show five customers. Reach for Bolt.new when you need real data and logins, and Magic Patterns for flows on your design system.

5. Ship it to real users

AI fails in ways no demo shows. Before launch, instrument task success rate, human handoff rate, cost per successful task and how often users hit regenerate. Then put your prototype on a live URL and synthesize feedback from 20 real users.

6. Prove it with evals

A vibe check is an eval. You're using your own brain as the scoring function, which works right up until you're the bottleneck. Hamel Husain and Shreya Shankar walked me through the sequence I'd copy. Read 100 real traces, name the failure modes, add cheap code checks, then build one LLM judge per failure mode and check it against your own labels.

Your proof is your top five failure modes, each with an eval that catches it.

Stack all six proofs and you have an AI PM portfolio.

A deep dive for each stage

1. AI foundations → news.aakashg.com/p/ai-foundations-for-pms
2. Context engineering → news.aakashg.com/p/context-engineering
3. AI agents → news.aakashg.com/p/ai-agents-pms
4. Bolt.new guide → news.aakashg.com/p/pm-guide-bolt
5. AI evals → news.aakashg.com/p/ai-evals
6. LLM judges → news.aakashg.com/p/ai-pm-llm-judge
7. AI PM portfolio → news.aakashg.com/p/vibe-code-pm-portfolio

Learn the stage. Then ship the proof.

At Amazon, a strong L5 with 7 to 8 years of experience can cross ₹1 Cr+ CTC. At L6, compensation can go well beyond ₹1.5 Cr+ depending on team, location, stock, and level.

But the interesting part is not just the money.
Look at why recruiters reach out for these roles.

It is because their background shows they understand hard systems, and they have enough proof of work that people can see it.

Today I am a Principal Engineer, but if I were starting in distributed systems from scratch and wanted to turn that skill into career leverage, this is exactly how I would do it.

[1] Build the fundamentals before touching big scale

I would first get comfortable with the building blocks:
→ networking and request lifecycle
→ databases, indexes, transactions
→ caching
→ queues and async processing
→ replication
→ sharding
→ consistency
→ retries, idempotency, backpressure
→ observability and failure handling

Basically, have the understanding to see what happens when one normal backend service gets slower, busier, or partially unavailable.

[2] Build systems where the tradeoffs come into the picture.

Do not only watch architecture videos.
Build things.

Start with:
→ URL shortener
→ rate limiter
→ notification service
→ job scheduler
→ file upload system
→ search service
→ payment workflow

Then deliberately make them harder.
– What happens at 10x traffic?”
– What if Redis dies?”
– What if the same event arrives twice?”
– What if one shard becomes hot?”

[3] Read engineering blogs and reverse-engineer decisions

Uber, Netflix, Stripe, Discord, Cloudflare, LinkedIn, Meta, Amazon.
There’s golden material out there.

While reading, ask yourself:
– Why did they choose this?
– What was breaking before?
– What tradeoff did they accept?
– What new problem did their solution create?

That is how engineers actually learn architecture.

[4] Put your thinking in public

This part is massively underrated.
Write about what you learn.

Publish:
→ design breakdowns
→ architecture diagrams
→ GitHub projects
→ incident analyses
→ open-source contributions
→ performance experiments

Build enough public proof that when someone searches your name, they can tell what kind of engineer you are.

That is when learning starts compounding.

You study distributed systems to become better at engineering.
Then that knowledge helps you design better systems.
Those systems give you better stories.
Those stories become public proof.

And eventually, opportunities start finding you instead of you constantly chasing them.

That is the leverage.