Overview
Philip Inghelbrecht, Belgian co-founder of Shazam, gives a keynote at SuperNova Conference 2018 recounting the company's history from its founding in December 1999, years before smartphones existed. He describes how universities laughed off the music-recognition problem until Stanford's Julius Smith pointed him to Avery Wang, who invented the core algorithm; the team then built its own GPU infrastructure, ripped 120,000 CDs to create the largest digital music database, and launched via the dial-code 2580 on feature phones. He distills two lessons: focus on hard problems and solve them with simple, elegant solutions (illustrating with the slim but worthwhile odds of blockchain fixing music rights), and 'think big or think bigger' — something he says Belgians are bad at and Americans excel at. He closes by envisioning adaptive and AI-composed music as the problems worth working on today.
Talks about
Insights & ideas
The through-line
Everything here circles one idea: go after the problems everyone else has written off, then solve them as simply as you can. "Focus on the difficult, on the hard problems, and try to solve them with simple solutions" [1] is the compressed version, and the Shazam story is the proof he keeps returning to. The corollary is ambition as a practical tool rather than a slogan: "If you want to land on the moon you got to shoot for the stars, and if you do, and you do so with simple solutions, the payoff can be rewarding" [1]. The two questions he leaves audiences with are the same two he applies to himself: "Are you solving the hard problems and are you thinking big enough?" [1]
Running underneath is a strong sense that success is improbable and only legible backwards. He is candid that Shazam's outcome was not engineered: "the probability of Shazam succeeding in the year 2000 was virtually none. If you look at each component in isolation and you multiply it through, we should not have been here" [1].
On hard problems and simple solutions
The music-recognition problem was rejected as unsolvable by the institutions best equipped to judge it, with Xerox PARC, MIT Media Lab and Carnegie Mellon all laughing it away; what got Shazam through was perseverance plus one optimistic Stanford professor [1]. The payoff of that stubbornness is that breakthrough answers look trivial once they exist. People who read the Shazam patent today say they would have done the same thing, even though nobody could solve it the year before [1]. That asymmetry is the whole case for working on hard things: the difficulty is the moat, and the simplicity of the eventual solution is what makes it usable.
The 2580 dial code is his cleanest illustration. It was chosen because people cannot remember phone numbers but do remember patterns, and 2580 is the only vertical thumb-stroke of digits down the middle of any handset keypad in the world [1]. Constraint met with an almost embarrassingly simple observation. The engineering side shows the same instinct in a harder register: because cloud computing did not exist in 2000 and 2001, Shazam built everything from scratch, and even now runs on GPUs with custom-written software rather than cloud services or CPUs [1].
On thinking big, and why he finds it hard
He treats ambition as a discipline he has not mastered and a cultural trait he lacks. "Think big or think bigger. By the way, this is something we Belgians suck at. This is something I fail at every day. This is something Americans are incredibly good at" [1]. The mechanism he describes is not motivational, it is operational: "If you can dream ridiculously big and you start acting like it, then all of a sudden building towards it becomes so much easier" [1]. The size of the goal changes what decisions look reasonable, which is why the ambition has to come first rather than being earned incrementally.
On probability, timing and the limits of planning
His framework is to break a venture into its component bets, estimate each one's odds, and multiply. Applied to Shazam in 2000, the product should never have existed [1]. Applied forward to blockchain for music rights, he does the same arithmetic: roughly 10% odds on standards emerging, roughly 5% on rights-holder buy-in, plus the problem of integrating legacy catalogs and something like a coin flip on execution, which makes the overall odds incredibly slim [1]. The conclusion is not that nobody should try. One company will eventually do it, and when they do it will look obvious in retrospect [1], exactly as the Shazam patent now does.
Timing is the part of the multiplication nobody controls. Shazam flatlined for its first six or seven years, from 2002 to roughly 2013 on the chart he shows, because the iPhone did not arrive until 2007 and the App Store a year after that [1]. The product preceded the platform that made it work, and none of that was planned [1]. The lesson is that surviving the gap between building the thing and the world being ready for it is a large share of the outcome.
On what Shazam's data revealed about music
Once at scale, the value shifted from the recognition trick to what the aggregate behaviour showed. Shazam became a leading indicator for the music industry, with songs peaking on Shazam before they peak in sales or on radio, and artists including The Weeknd and Demi Lovato using Shazam's geographic data to plan where to tour [1]. Intent to identify a song turns out to precede commercial signal, which makes a consumer utility into an industry forecasting instrument.
On where music goes next
He is dismissive of playlist recommendation as the frontier. What interests him is adaptive music: fluid playlists that respond to place, time and the company you are in, rather than static lists [1]. Beyond that sits AI-composed music generating an infinite catalog on the fly [1]. Both extend the same logic as the rest of his thinking, moving from cataloguing what exists to generating what fits the moment.
Takeaways
- Pick problems that experts have declared unsolvable; the ones Xerox PARC, MIT Media Lab and Carnegie Mellon dismissed became a company [1].
- Judge a solution by how obvious it looks afterwards, not by how clever it feels: readers of the Shazam patent now say they would have done the same thing [1].
- Set the goal absurdly high first, because "if you can dream ridiculously big and you start acting like it, then all of a sudden building towards it becomes so much easier" [1].
- Multiply the odds of each component bet before committing, then decide whether the payoff justifies terrible aggregate probability, as with blockchain music rights at roughly 10% on standards and 5% on rights-holder buy-in [1].
- Expect to sit in the dark while the enabling platform catches up; Shazam flatlined from 2002 until the iPhone and App Store arrived in 2007 and 2008 [1].
- Design around human memory, not systems: 2580 worked because it is the only vertical thumb-stroke down the middle of a keypad, and people remember patterns rather than numbers [1].
- Usage data can be worth more than the product feature; Shazam predicts chart peaks ahead of sales and radio, and shapes tour routing [1].
This page shows public professional information only, each fact cited. Is this you? send a correction, or ask for removal within 24 hours, no questions asked.