Max Schoening on Agency, Malleable Software, and the "Tiny Core" of Great Products
Lenny's Podcast
Max Schoening has been a product manager at Google, head of design at Heroku, a design leader and part-time engineer at GitHub, and a two-time founder. He is now head of product at Notion. In this conversation with Lenny Rachitsky, he argues that as AI makes skills easier to acquire, the trait that matters most is agency: the belief that the world around you can be changed, and the willingness to change it. From there he covers why Notion's designers and PMs work in code, why he thinks the "SaaSpocalypse" is overstated, why software has grown in quantity but not in quality, and his theory that every great product rests on one small, exceptionally good core.
How Notion's designers started prototyping in code
Lenny opens by noting that many people at Notion credit Schoening with getting designers and PMs to ship code. Schoening declines the credit and says it probably would have happened anyway. He does describe how it started. When he joined Notion, the team was building many chat interfaces and designing them in Figma. He cites Bret Victor's talk "Stop Drawing Dead Fish": a static image of a chat is the dead fish, because you have to feel how the AI behaves.
So two designers and Schoening built what he calls "the worst possible playground you could think of." It was a small codebase that is friendly to LLMs and uses the tools LLMs are good at. All prototyping for the chat interfaces moved there. Notion's main codebase carries a decade of patterns and iterations, so it isn't always the most agent-friendly environment. The playground was designed to be as unintimidating and "one-shottable" as possible. Once people got past their fear of the terminal, the work became chatting. The team recreated many of Notion's existing patterns and UIs inside it.
Schoening describes the playground as a way to "get people on the treadmill." As models have improved, the same designers and PMs now also contribute to the production codebase, though to a lesser degree. He expects the amount of work they can do to keep growing as model capabilities improve.
Why he wants designers to code, whether or not it ships
Schoening says he is uncomfortable predicting the future because exponentials are hard to predict. His long-held position is that designers should code. At GitHub, before LLMs, he says roughly 10% of the top contributors to GitHub's own codebase were designers.
He points to processes that are now breaking. Some Notion designers mostly prototype in code, and then marketing teams ask them to reverse-engineer that work back into Figma so the marketing team can make video assets. He calls this busywork. Small changes and styling tweaks going to production are now a given. But he has a broader complaint about vibe coding: he doesn't think software quality has improved much in the last 12 months. There may be more software, but reliable software is still hard to find. For him, the goal isn't designers deploying to production. It is designers thinking and designing in the medium that becomes the real product once engineering takes over.
Lenny raises a counterargument. Engineers now move so fast that designers and PMs are already stretched, so maybe their time is better spent keeping the product coherent than writing code. Schoening says he doesn't care at all whether designers' code lands in production. The value of coding is that it forces you to consider the medium, and if the code gets thrown away afterward, that's fine. He compares two hypothetical people. One can use Codex or Claude Code to tweak UI details but doesn't understand how an agent loop works. The other deeply understands agent loops and can design them. He would much rather have the second. He believes the only way to really understand agent loops is to build them in the material they're made of, which is currently code. He compares today's coding harnesses to the operating systems of the '90s. Once someone discovers a new material, he says, they often do start writing production code. But the point is to become "a master of the material," not a cog in the machinery that delivers the idea.
Agency as the dividing line
Asked what separates the designers and PMs who thrive from those who fall behind, Schoening says it is agency. He suspects this has always been true, and that we used to describe it as the difference between founders and non-founders. Previously it was easy to say "I'll never be able to do this" because of a skill gap. Now an "AGI-adjacent model" can put skills at your fingertips, so what remains is agency. He says agency is not evenly distributed. People who understand that the world around them is malleable will do well. People who keep asking what a PM, designer, or engineer is "supposed" to do will have a much harder time.
He says Notion employees, especially on the design team, have surprisingly high agency compared to other places he has worked. His first example is Brian Lovin. Lovin already blurs engineering and design, but Schoening also calls him probably Notion's number one recruiter: he sees what the org needs and goes out to find people. Schoening's point is that this is outside Lovin's day-to-day role and shows someone who wants to effect change regardless of how. He gives the question he asks himself: "Do you drive Notion like it's stolen?" The current team came in after Notion already had strong product-market fit, but people can still contribute with a sense of agency instead of sticking to their role.
His second example is Eric Liu. Liu once asked Schoening whether he would be hired if Schoening started a startup. Schoening said not in the first ten hires, because he wouldn't need a product manager. Liu responded that he would build the skills to be hired in the first five. He started by spending more time in Figma instead of writing long PRDs. Then he asked why he needed Figma at all when he could build a prototype and do his thinking there. Schoening describes this as high agency: changing the role into what you think it should be.
What could be lost as roles merge
Lenny asks what might be lost as the lines between engineer, PM, and designer blur. Schoening's answer is specialists. He uses a hardware metaphor. A hardware startup's first enclosures would be 3D-printed, with visible layer lines, and nobody would think of selling them. Then comes a long road until, if you're lucky, you manufacture the product for 100 million people. At that point engineering means optimizing the factory for yield and precision.
He thinks this is largely missing from current software discourse, which focuses on how many tokens can be spent and how many features can be shipped. The engineering part is making sure something works for 100 million or a billion people. On the design side, anyone can now take a design system off the shelf and build a usable interface that gets at the essentials, but he asks where the delight and craft will come from. He says it would be sad to lose the specialists at the edges as roles merge.
How to develop agency: start by making things
Asked how someone can build agency, Schoening cites the Steve Jobs line that one day you realize the world was made up by people no smarter than you. He says people either realize this on their own or have a teacher early in life who encourages it. The strongest common thread he has seen is making things. If you tinker and build, you find it isn't that hard to learn how to make the chair in your office or modify it. He counts a home-cooked meal as a form of tinkering.
He contrasts this with how many people understand agency: as maneuvering inside a big machine, working around a bad manager to get what they want. His advice is to just start making things. As you get better, people eventually notice, and "it just really awakens you to the idea that you can just change things."
Malleable software and ownership of your computing life
Schoening defines malleable software as software that serves the interests of the people who use it more than the interests of the company that makes it. He calls himself a big Apple fan, but says he doesn't want to use software designed purely by "the ivory tower in Cupertino." His analogy is a home where you can't rearrange your living room and the kitchen must stay exactly as someone else set it up. People wouldn't accept that in a home, but that is roughly the state of software. Apps glue together the interface, the data ownership, and every other layer, and when you want to change an app's behavior slightly, you usually can't.
The other extreme is running your own Linux distribution. Then you find that you like the malleability but also have other things to do, and you don't want to start from scratch figuring out why the trackpad doesn't work. For Schoening, the question comes down to whether you own your computing life, and he thinks increasingly we don't. People are now discovering they can make their own tools, which is a form of malleable software. But he argues this needs a platform or operating system that encourages it. Otherwise everyone ends up with an individual tool, and he likes working with people and using communal tools. He mentions that Ink & Switch is at the forefront of this thinking, and that he now works daily with Geoffrey Litt on how to make software more malleable without giving up real-time collaboration and security.
Dieter Rams and "useful first, then beautiful"
Lenny asks about the Dieter Rams video pinned to Schoening's X profile, in which Rams walks through a museum criticizing designer chairs. Schoening jokes that the one thing he shares with Rams is being German, and that he aspires to point disapprovingly at things with a walking stick and say they aren't good enough. He says the clip is among the funniest he has seen if you understand German. His serious reason for pinning it is that he believes design should first be useful and then beautiful. Many of the pieces in the video are made for display, and if you tried to sit on them you'd wonder what the nonsense was. Schoening recalls Rams saying of one cabinet something like it is "neither orderly nor properly chaotic." Lenny says what struck him was Rams puncturing the assumption that a famous designer's work, such as something by Frank Gehry, must be great.
Schoening connects this to malleability through The Timeless Way of Building and Stewart Brand's How Buildings Learn. The idea is that the best home for you probably wasn't built by an architect. It adapted over a long time to how you want to live. That is an expensive form of malleability if it means tearing out a wall. But he takes Rams's main point to be that something should be useful, and a good way to discover what is useful is to be able to change and tweak it.
Why the SaaSpocalypse is overstated
On the idea that companies will build their own tools instead of buying SaaS, Schoening first breaks down the acronym. It would be silly to claim that 2010s-style SaaS will stay equally relevant. He describes much of that era's SaaS as "a very, very fancy form around a spreadsheet." Its value was guiding people to fill in the form correctly, which made it deliberately less malleable than a spreadsheet. But he thinks the "as a service" part is what really matters, because most people don't want to maintain a full software stack.
He admits he has tried rebuilding Notion in a weekend for himself, to push on things that frustrate him. But he doesn't think most people want that. His analogy is that most people don't want to hunt. They want to buy steak in styrofoam at Costco. He also cites Bret Taylor's description of software as a garden that needs tending. What you pay for in a service is maintenance plus specialists thinking hard about a problem, and he doesn't see that going away.
His prediction, which he acknowledges is biased because he works at Notion, is that tools will become more general. Software may return to the '90s pattern of general tools like the word processor, the spreadsheet, and FileMaker Pro, but delivered as services. Specialized tools, for example in security, will still exist where people go the extra mile on a user problem. He mentions that journalist Joanna Stern recently posted something like: thanks to Notion AI, she finally understands and uses Notion. He jokes about what that says about Notion, but takes it as evidence that Notion was never traditional SaaS. It was hard to get started with, and AI now acts as a tutor that helps people build more. He concludes the SaaSpocalypse is "greatly exaggerated," though things obviously won't stay the same.
Lenny mentions that Cat Wu, head of product for Claude Code, described Slack as effectively Anthropic's operating system. Even Anthropic doesn't try to build its own Slack. Schoening adds that one great thing about the US is specialization: paying for Notion is cheap compared with building it yourself. He also brings up the well-known flowchart showing Slack's decision process for delivering a notification. He says that level of detail only comes from real users, real scale, and years of understanding the customer.
The first 10% of every project is now free
Asked what has changed most in his own work, Schoening says the first 10% of every project is now free. There is little reason to write a PRD when you can build a rough version and demo it. He adds that building a version 0.8 of a startup now takes almost no effort. Even if you generously say the first 90% is done, the last 10% is still effectively 90% of the work.
Because exploration is cheap, you can send ten agents to explore ten directions and see whether you were right. At GitHub, product reviews used the phrases "demos, not memos" and "give me something to react to." If you were going to write something, you wrote the changelog or blog post a user would read. Now it is much easier to show an actual version of the product, get the reaction "what if we did it this other way," and produce that version too. He says this builds iteration in much earlier and makes waterfall pointless.
Open questions about how building changes next
Asked what the next shift will be, Schoening says he is conflicted. He believes in "never bet against plain text" (a line from a well-known forum post). Plain text, markdown, and code are durable, and he thinks expressing thoughts in code is valuable. But he also wonders whether building will really just mean chatting back and forth. Figma's future interests him. Some Notion designers use it less, while others find its AI tools wonderful. He can't predict whether direct manipulation disappears because the agent now does it.
He also describes a fork between automation and augmentation that depends on inference speed. He mentions very fast models, such as Spark and a fast variant of Opus, and says you can run up a bill of around $3,000 a day. When inference is slow, you queue jobs, walk around the building, and come back to review. He doubts this frantic multitasking produces flow. If inference becomes nearly instant, he wonders whether we return to direct manipulation, molding code like clay. He doesn't know.
That leads to one of his less conventional views. He thinks the labs assume people will always want the smartest model. That may be true for cancer research or other work where millions of dollars are at stake. But companies don't hire a PhD for everything. His analogy is the Retina display: once you can't see the pixels, you don't need smaller pixels. He suspects many cognitive tasks will reach "good enough," after which people will want models that are faster, cheaper, local, or use a different modality. He says society is largely not limited by intelligence, noting that Tyler Cowen has said something similar while being careful not to put words in his mouth. He is more interested in AI as an "exoskeleton" than in "a god in a box" in a data center.
Token spend, ROI, and getting people to change how they work
Lenny mentions that one Notion PM is reportedly the company's top token spender. Schoening says he believes Notion's policy is unlimited, though he isn't certain. When something new appears, he thinks it's worth letting people explore. For an individual, he estimates spending in the thousands of dollars, possibly tens of thousands, depending on the person, and assumes it is far below spending at OpenAI and Anthropic. He predicts that in 6 to 12 months many companies will start asking hard ROI questions, and that those will be uncomfortable conversations. For now, he says, he has the luxury of not caring.
He warns against treating token spend as something to boast about. He compares it to bragging about lines of code, noting that even the largest software projects don't have that many millions of lines. Still, he has some sympathy for leaderboards like the one Meta was criticized for. He is surprised how much prodding it takes to get people to identify the "outer loop" of their work, hand it to an agent, and build a "software factory" for it. At the scale of tens of thousands of employees, a leaderboard is one way to push people, and they'll find useful things along the way.
At Notion, what works varies by role. People further from engineering hardly need persuading. The gap between what they could do before and after is so large that it's "intoxicating." With them, the challenge runs the other way: explaining why a particular PR can't be merged. On the engineering side, he cites Notion co-founder Simon Last's view that any manual intervention in code suggests something is wrong in the verification loop or the software factory. This excludes code review. Schoening thinks people should put more effort into reviewing code than they currently do. But on the writing side, he says, every human intervention should feel a little like a bug. He calls this a good test of how "agent-filled" you are.
On tools, he corrects the impression that Figma is declining. There are two camps, and a Jevons paradox could mean Figma use and vibe coding are both rising. He says he dislikes Silicon Valley's rivalry discourse, where one company must lose for another to win. What surprised him is the terminal. It scares people at first, but once PMs are in Claude Code or Codex, things are fine. He encourages them to use the TUI rather than GUIs, because he expects them to get curious, pull on other threads, and eventually understand more of how computers work. Designers mostly use developer tools now, including Conductor.
Which roles AI transforms next: "software is eating the world" accelerates
Asked which role AI will transform after engineering, Schoening offers what he calls a hot take and admits the labs might laugh at it. Empirically, models are clearly improving at coding at an exponential rate. He isn't impressed with progress in other domains. He doesn't think models have gotten significantly better at writing, and he still hates reading AI slop. His argument, referring to Marc Andreessen's "software is eating the world," is that if the cost of writing ordinary software and encoding business practices in code approaches zero, there will simply be much more software. Software engineering will spread into other fields. Notion's HR team, for example, is automating things without having to ask an engineering team. When labs announce progress in a non-coding domain, he thinks they have often applied coding principles to that domain. Lenny connects this to the Codex product lead's view that winning agents will be coding agents that build what they need. Schoening agrees that every agent harness, open source or from labs, including Notion's, resembles a coding agent.
Model economics and the Heroku–Kubernetes lesson
Asked how the ROI reckoning might play out, Schoening describes two scenarios. In one, the gap between frontier labs and open-weight models widens. He dislikes that world because he hates centralized power, and in it the labs get to decide what the world looks like. In the other, the gap doesn't widen, and capability spreads. Companies get comfortable running and doing RL on their own models, as he says Cursor and Intercom are doing and Notion is "dabbling" in. It becomes an ROI calculation: whether sending a task to a smaller, cheaper model without the lab's profit margin is good enough.
He calls the current situation one of the luckiest possible timelines. The US has three competent labs competing, maybe four with Meta, and he'd love a dozen. If that competition stopped, he would worry. If it continues, he expects something like the cloud wars, where layers commoditize and businesses avoid lock-in. He draws on his time at Heroku. Kubernetes was much more successful than Heroku despite what he considers a worse user experience. Heroku's pitch was to replace your ops team. Kubernetes promised to make your ops team superheroes and not lock you into one cloud. Businesses want choice.
Lenny brings up Kathy Sierra's idea that products should make users feel like superheroes. Schoening applies it to AI code review. He argues that automated code review tools struggle because you push code in front of your team and a machine criticizes it. With Claude Code or Codex, you publish the work of you plus the tool and get bragging rights for being a good developer.
Why Notion AI works
Lenny says he keeps hearing praise for Notion's AI agent. Schoening says he is his own worst critic and spends most of his day on where it falls short, but admits he is surprised at how good it is. He notes Notion has long been early on AI; he believes the first Notion assistant launched before ChatGPT, and credits Ivan Zhao and Simon Last with the intuition that AI would change a lot. He jokes that companies declaring themselves "AI native," like "cloud native," make him wonder whether they have a chance, and says he's surprised how quickly it happened for Notion, taking almost no credit himself.
His explanation is that agents need context and don't like being forced through a narrow opening to reach another data store. For the first time, he says, it is obvious why a connected workspace is valuable: agents can roam around it. He thinks of Notion as an operating system, which makes it more similar to the Unix environment coding agents work in than people might expect. Sometimes Notion is also "dumb enough to try hard things," such as the automatic permission handling in its enterprise search, which he says others don't do. Lenny returns to his opening Bible quote, "for such a time as this": Notion's years of accumulating company context turn out to be what AI needs. Schoening adopts the line and notes the parallel with malleable software, which also existed for a long time but was always slightly too hard to be worth it.
Shipping faster without giving up quality
Schoening says the answer depends on a company's culture. He has been in a similar position twice. When he joined GitHub, it had huge product-market fit but was going through something of an identity crisis about its next act, with many debates about what to ship. He puts Notion in the same category. In that situation, much of the job is reminding people they don't have to be precious. Users will be more upset if the company doesn't innovate than if it accidentally breaks something, though he acknowledges it's a balance. The people who built the first act can likely build the second, but they have to try. Internally Notion talks about "shots on goal," and cheap experimentation increases them. He says Notion has been on a roll with new features over the past six months or so.
Still, he calls feature count as silly a metric as lines of code or tokens. He would rather have fewer, very good features whose combinations let you do everything. Software quality is something he is still struggling with, and he says the labs aren't exempt. He lives in the CLI and loves their tools, but cites regressions roughly every two weeks of things fixed three weeks earlier, and a TUI that still can't render at a reasonable frame rate. He wants the industry to get back to "Apple-esque machined unibody aluminum" engineering.
His team's standard comes from a sticker: "obviously good." When people ask what that means, he says you know it when you see it. Nobody argued the first iPhone or the first ChatGPT wasn't obviously good. The mistake is to hide in a cave until something is obviously good. One of his core values is "incremental correctness": get very good at iterating. Customers regularly criticize Notion for having about six automation primitives if you count agents. He says Notion let several ideas grow to see how they worked, but someone then has to consolidate them into "the naked robotic core" of the idea, which can delay the next launch. He says Notion still has work to do here and so does the industry, mentioning someone's joke about why the Claude desktop app has three tabs.
Taste as a mental simulation you train through reps
Asked how to build taste, Schoening first says he isn't sure he has great taste. The common factor he sees is iterations with feedback. Taste in one domain takes a long time to build and can sometimes carry over to others. His definition is that taste means being able to run "a virtual machine in your head": given an idea, you can predict whether a particular in-group will like it. If you're the only person on Earth who likes something, it isn't good, but you also don't need to build for 8 billion people. He says he has never built consumer software and would probably be bad at it. You choose your in-group and get better at simulating its reactions through reps.
He notes this resembles training a model, which makes him skeptical of the claim that taste is the one thing humans have left: input an idea, observe reactions, adjust, which looks like backpropagation. He points to Japanese craftspeople who paint bowls for years, and advises increasing the frequency of reps.
For software designers specifically, he has noticed that those with the best taste both have side projects they own end to end and constantly try new apps. They're the ones proposing a new tool for the 49th time. He thinks exposure to other people's ideas matters, as does surrounding yourself with well-made things so your own work feels lacking. Notion's conference rooms are named after famous objects like the first typewriter, the Macintosh, and the Porsche 911. When he sits in one and pays attention, he feels nothing he's doing measures up.
The tiny core behind every great product
Asked what matters most in building successful products, Schoening says he has contributed to great products rather than built them. Over his career he has come to believe the team building a product is the most important thing, which he didn't think early on. He doesn't see one common thread. The best design doesn't always win, and many products succeed where design barely matters, which can give designers an identity crisis. The best engineering doesn't always win either.
What he does see is that truly great products have "one tiny core that is so exceptionally good." Finding it is partly luck, and then the market agrees. His examples: multi-touch on the iPhone; GitHub's pull request, where anyone can suggest a change and you can see it; Notion's blocks and slash commands; Figma's blend of real-time collaboration and design. At Heroku it was git push heroku master, a one-liner that took an app from your computer to a URL at a time when deploying was hard. He describes Heroku as "the first Vercel" for people who don't remember it. Dropbox's core was the menu bar icon, which synced so reliably that people used it to check whether they had internet, since it detected connectivity better than the Mac did. When Dropbox spent years expanding its surface area, he kept thinking it should pull back to that one job. Lenny adds Snapchat's disappearing photos.
The main pitfall, he says, is believing one more feature will finally make the product great. That never works. He also thinks being first is overrated. Network effects or head starts in model training may matter somewhat, but AirPods weren't the first Bluetooth headphones and Apple wasn't first to MP3 players. They got it right. With attention so scarce, people chase virality, but he says durability matters, and suggests thinking about how you'd build a generational company like IKEA. On Lenny's example of Anthropic overtaking OpenAI despite starting later with less funding, Schoening is most impressed that Dario Amodei succeeded twice, first at OpenAI and then at Anthropic.
Jobs to be done as a zoom-out tool
Schoening says that if he reread Clayton Christensen he probably wouldn't fully agree with it. He uses jobs to be done to ask whether you've thought holistically about what users hire your product for, and whether you're honest about what users want versus what you want them to want. In large companies he sees people switch off their judgment when reviewing their own work. They evaluate as employees who made something rather than as users. The framework prompts them to be the user and ask whether they'd buy what they just made. Often the answer is that they hadn't considered it.
His recent example involves an upcoming feature's landing page. When people write landing pages, he says, their writing gets worse because they want to sound clever and fall into marketing language. He asks them to explain it as they would to a friend at a whiteboard, then compare that explanation to what they actually designed and check whether they match.
"We already have universal basic income"
Schoening's hot take, which he says is partly a joke and partly serious, is that "we already have universal basic income. It's called knowledge work." He includes his own job. Humans need far less to live and be content than the hierarchy of jobs we've built suggests. He expects that, as the species that considers itself most important, humans will keep inventing reasons to stay in the loop with agents. He doesn't know whether it will look the same. He adds that he's in an air-conditioned room having a good time, that not everyone has that luck, and that the people discussing this most tend to be the lucky ones.
If AGI meant he didn't have to work, he says he'd do the same thing, a question he asks nearly everyone Notion hires. He'd spend less time in meetings and managing. He says he hasn't yet replaced 80% of his job with agent loops and envies Notion's engineers and designers who can. He codes for the intellectual challenge, like chess or Go, and is sad that Lee Sedol seemed to give up Go after losing to DeepMind's AI. It doesn't matter if a machine is better, he says. He'd tinker, build, and try to make the world more malleable. He mentions that someone emailed him that morning asking what robotics might mean for malleable software, a question he'd never considered because it's so far from his skills.
Contrarian views and failures
His contrarian view is that inclusivity isn't always good. He believes in small-group theory: the world is run by group chats of eight or fewer people. If Notion aimed for 8 billion users, it would upset its first 500 million or so, because the top of the class wants different things than everyone else, and everyone is at the top of the class in something. He caveats that he doesn't mean exclusive hiring at a McDonald's that is the only employer in town. He means building for the best in a field, which by definition excludes others. Lenny compares this to TBPN, which he says designed its show for a small, influential audience and was acquired for hundreds of millions of dollars.
On failure, Schoening says he fails a lot every day. Organizationally, at a time when designers who could code were hard to hire, he loosened that requirement and didn't foresee how fast it became a slippery slope. He would rather have had fewer, more polymathic designers. On the product side, he says GitHub Actions should have had better package management, and the world would be better if the team had thought harder about it.
His biggest example is a Notion competitor he started in 2014. The week True Ventures was going to give them a term sheet, Notion pivoted from website building to document collaboration, and True Ventures withdrew because of the conflict. His team spent a long time polishing the editor with markdown folding and features now found in Obsidian. Notion's first editor, by comparison, was terrible. Everything was blocks and you couldn't even select across two blocks. It didn't matter. His team kept adding features and asking whether it was good yet, in what he calls a "death spiral," but the core wasn't good. He considers it a case of working diligently on the wrong thing for far too long. He says you can usually tell when something is obviously good. The core idea may still fail in user studies, and then the important thing is not to abandon it. The core is 80% of the work, and the remaining 20% is relentless iteration until it clicks with users.
Advice to young people in Silicon Valley
Schoening says Silicon Valley is unusually full of people who don't love computers. Everyone wants to make money, himself included. But he sees the "last train" and "permanent underclass" mindset as harmful to deciding how to spend "your heartbeats in life." He tells people not to let the frenzy distract them from what they care about. He also says young people are better off working very hard from about 18 to 25 and working less later. His objection is to the frantic fear of missing the last train, which he calls a hollow way to live. He recommends reading history, including computer science history.
Pressed on practical concerns, he cites a comedian, possibly Chris Rock, joking that following your passion is great "if it pays." He isn't saying to ignore money. He's saying to turn down the amount of worry, recognize that history repeats more than it's new, and not insist on certainty about how things unfold. To people convinced everything will change, he asks how any particular move they make would protect them, and whether they want to live in that kind of insular society.
Lightning round
His book recommendations: Charles Petzold's Code, which he says contains no code until around chapter 27 and explains how computers work, something he's surprised many professional programmers don't know; Ivan Illich's Tools for Conviviality, which contrasts tools that support human ingenuity and autonomy with industrial-scale tools that erode it; and James C. Scott's Seeing Like a State, which he gives to executives. He argues executives create "fake legibility," such as status reports that make them think they understand their teams, when spending time with those teams would show otherwise.
He says he deliberately has bad taste in movies because he wants pure entertainment. He liked the Project Hail Mary adaptation, and jokes internally that a great "Notion OS" might someday help a small crew explore the galaxy. He is also watching The Handmaid's Tale late and says it feels heavy if you replace God with AI.
Products he recommends include the Ghostty terminal emulator, whose creator Mitchell he admires; Moshi, a paid phone app he's exploring because he now mostly codes on his phone, joking that he doesn't have a real job; the Corne split keyboard, which is open source enough that you could send the schematics off for PCBs and build it yourself, part of his effort to "claw back as much agency in my compute life as possible"; and a high-quality pocket knife, because he likes physical tools.
His life motto is "The universe is change; life is what you make it," which he attributes to Marcus Aurelius. He adds that he doesn't want spoilers for how life ends. His favorite German words are tüfteln, a gentler version of "tinker" without the derogatory tone the English can have, and the German word for "user," which emphasizes using something up and makes him think about how impermanent and wasteful products can be.
Asked how listeners can help him, Schoening asks them to walk through a human-made environment, notice that everything around them was made by people no smarter than they are, and realize that in six to nine months they could probably learn to make most of it from scratch. That, he says, means they have more agency than they think, and they should use it.
Before it was very easy to always say, well, I will never be able to do this because insert skill issue. We're realizing that even if you have the skills at your fingertips, the thing that matters is agency. I don't think agency is very evenly distributed in the world.
Do you have a piece of advice for someone that wants to develop this within themselves?
I tell this to myself. Could you drive Notion like it's stolen? One day you wake up and you realize the world is made up by people no smarter than you. It just really awakens you to the idea that you can just change things.
If you think about your job a couple years ago, what's most changed?
The first 10% of every project are now free. It takes almost no effort to now build the first version of a startup.
Taste comes up a lot now.
Taste actually means you're able to run a virtual machine in your head where given an idea, you can predict for a certain in-group whether they're going to like it or not. You just have to do reps. It's almost like training a model.
What do you think matters to building a successful product?
All the great products have something tiny that is a superpower. One tiny core that is so exceptionally good. One of the biggest pitfalls is if you get into the loop of if I just add one more thing to the product, it will be finally great. That never works.
Give this hot take on universal basic income.
We already have universal basic income. It's called knowledge work.
Today my guest is Max Schoening. Max is a hard person to describe. He was a product manager at Google. He ran the design team at Heroku. He was a design leader and an engineer at GitHub under Nat Friedman. He's also a two-time founder and is now head of product at Notion. He is one of the most successful AI-forward product leaders out there and, as you'll soon see, one of the deepest thinkers on how AI impacts how we build and how we use software.
Before we get into it, don't forget to check out lennysproductpass.com for an insane set of deals available exclusively to Lenny's Newsletter subscribers. With that, I bring you Max Schoening.
Max, welcome to the podcast.
Thank you for having me.
I am so excited to have you here. I feel like there's this quote I think about when I think about you and you being on this podcast. It comes from the Bible. And just paraphrasing, the quote is, "I was made for such a time as this." I feel like there's all this talk about roles merging, designers becoming PMs, engineers, everyone's the same. The Venn diagrams collapsing. You've been that for a long time. It's like hard to even describe what you are and what you've done. You've done all the things. So, I feel like you have such a unique insight into where things are heading.
I want to start with just kind of this broad question. What have you seen about where things are going for product teams, for product building, as AI becomes more powerful, as we integrate it more into our workflows? And I ask you this because I've heard from so many people at Notion that you are the reason that designers are shipping code, PMs are shipping code. You're not just living in the future, you're like pushing the whole team and company to live in the future. And so, coming back to the question, just like what are you seeing about where things are going? What will change? What will people realize in the next few months, years that you're already seeing?
Well, first of all, when you said a quote from the Bible, I was very curious where this was going to...
It's the first time I've quoted the Bible on this podcast.
I think I wouldn't take credit for the designers at Notion and PMs at Notion now code. I think that would have probably happened anyways.
But I can tell you the origin story of it, which is when I joined Notion we were building a lot of chat interfaces and we were designing the chat interfaces in Figma. And there's this great talk by Bret Victor, Stop Drawing Dead Fish, which essentially is, I mean, the static image of a chat is basically the dead fish here. You have to feel the AI to some degree. And so, two designers, myself, just put together the worst possible playground you could think of of a small codebase that is very LLM friendly, used the tools that LLMs are very good at using. And then we moved all of our prototyping for specifically the chat interfaces to that.
And just to understand this playground concept, essentially this is an idea of people work within this separate kind of area with AI tools versus like their whole Notion codebase, making it really easy to get started and try stuff.
Yes. And that was the first version. It sort of aligned with model capabilities at the time. At Notion, the main codebase is not always the most agent friendly because of iterations and a decade of patterns. And so we optimized for, okay, how can we make this the least scary and most one-shotable, so that people would just have to overcome this sort of fear of the terminal, but then it just becomes chatting. And we recreated a bunch of the patterns and UIs that exist in that playground.
Now the good news is that's just to get people on the treadmill, because as model capabilities get better, now we have the same designers and PMs also just contributing to the production codebase, to a lesser degree of course, but like you can see where the trend is headed. As model capabilities get better, the amount of work that you can do is obviously going to increase exponentially.
This episode is brought to you by our season's presenting sponsor, WorkOS. What do OpenAI, Anthropic, Cursor, Vercel, Replit, Sierra, Clay, and hundreds of other winning companies all have in common? They are all powered by WorkOS. If you're building a product for the enterprise, you've felt the pain of integrating single sign-on, SCIM, RBAC, audit logs, and other features required by large companies. WorkOS turns those deal blockers into drop-in APIs with a modern developer platform built specifically for B2B SaaS. Literally, every startup that I'm an investor in that starts to expand upmarket ends up working with WorkOS. And that's because they are the best.
Whether you are a seed-stage startup trying to land your first enterprise customer or a unicorn expanding globally, WorkOS is the fastest path to becoming enterprise ready and unblocking growth. It's essentially Stripe for enterprise features. Visit workos.com to get started or just hit up their Slack where they have actual engineers waiting to answer your questions. WorkOS allows you to build faster with delightful APIs, comprehensive docs, and a smooth developer experience. Go to workos.com to make your app enterprise ready today.
Maybe give us a sense of where things are today, like how much are designers shipping stuff, PMs, and then just what do you see about where things might be heading, seeing all this actually happening at a company like Notion?
I feel so uncomfortable predicting the future in terms of where things are heading because, well, predicting exponentials is really hard. But I'll take a stab at it. It is very, very useful for designers to move from manipulating Figma documents into code. That has always been useful. I've always been camp designers should code. In a previous life I led design and product at GitHub, and GitHub designers before LLMs contributed to GitHub. I think in the top contributors to GitHub itself, like 10% were designers.
Right now processes are sort of breaking. One is we have designers who now mostly code and prototype in code, and then they are asked by other teams in marketing and so on to reverse engineer that in Figma, because they use that to create assets for videos and so on. And so obviously that is kind of silly, right? That seems like busy work.
On the pushing to production, I think it's a spectrum. Obviously small changes, styling tweaks and so on, it's a given that you can just do that now. I do have a general sort of maybe issue with vibe coding in the sense of I don't feel like the quality of software has increased all that much in the last 12 months. I think maybe the amount of software has, but it's very, very hard to find software that is reliable. And so the way we see it is it's not so much about pushing to production and having designers deploy. It's about them thinking and designing in the medium that will actually end up being the real thing once engineering takes it over.
There's all this talk about designers should be shipping code, PMs should be shipping code. And then there's the flip side of, because engineers can move so fast, there's so much more happening. Things are moving all the time, designers and PMs are squeezed more and more because it's hard to stay on top of all these things that are constantly shipping. And so maybe it doesn't actually make sense for designers and PMs to be spending time coding, and instead their time is better spent making sure things are moving in a direction that makes sense for the business. It's cohesive. What's your thoughts on just that balance?
I actually don't care at all whether designers write code that lands in production. The reason I like thinking in code is because it forces you to consider the medium. If then all of that gets thrown out, great.
So, for example, I think the two extremes would be if a PM or a designer knows how to tweak with, pick your favorite, they're all the same, Codex, Claude Code, whatever. If they know how to tweak small details of the UI, but they don't understand how an agent loop works, I would much rather take the designer or PM that deeply has an affinity for understanding how agent loops work and can design those than someone who can sort of write traditional software and tweak styles. And that's really hard because I think the only way that you can actually get to understanding agent loops is if you build them in the material that they're made of, which is currently code, and increasingly so if you look at all the coding harnesses, basically the operating systems of the '90s, right?
And so I think that's why I care that people code, not because of the utility of shipping to production, but because it forces you to really interrogate the material that you're designing with. So, it's more the prototyping use cases than we're just going to be shipping more features because we can. It tends to be that once you awaken someone to a new material, at some point they also blur the lines and then write production code. But I think it's really important not to forget that the reason why is to become a master of the material, not a sort of cog in the delivery mechanism for the idea.
That is really interesting. What do you find is key to people being successful in this new world? Like, you know, there's a lot of designers, a lot of PMs at Notion. What do you find is separating the ones that are thriving and will do well in this coming future versus ones that may fall behind?
I suspect that this is also something that has always been the case and we would just categorize this as founder versus not, and do you start a startup versus not, which is agency. I think before it was very easy to always say, well, I will never be able to do this because insert skill issue. And I think we're realizing that even if you have the skills at your fingertips, because now, I don't know, an AGI-adjacent model helps you, the thing that matters is agency. And I don't think agency is very evenly distributed in the world. And I think people who have true agency and understand that the world around them is malleable will do great, and the folks who stick to, tell me really, what does it mean to be a PM, what does it mean to be a designer, and what's my job as an engineer, I think that will be much harder. And yeah, cultivate agency. I think that's the thing.
Is there an example of someone using agency, a good example at Notion of someone just leaning into that and maybe shipping something, changing the way something was happening at Notion, just to give us a like, oh wow, I see what you're talking about?
Ninos are, and this was surprising to me, especially on the design team, way above average agency compared to other places that I've worked at.
And Ninos, by the way, are Notion employees.
Yes. Sorry. Once you're boil. I would say one example would be someone like Brian Lovin, who you should probably have on the podcast at some point.
He was on our sister podcast, How I AI. We'll link to that episode.
Ah, there we go. Yeah, you should cut this one short and have him on. I think the way I would describe it is, and I tell this to myself as well, which is like, okay, do you drive Notion like it's stolen? Which is, you know, we're not the founders, we're coming in after there was already insane product-market fit, but you can still contribute to the company in a way that you feel agency and you're not sort of just like, what's your role. And so Brian obviously already blurs engineering and design, but he also is probably our number one recruiter in terms of, hey, this is what the org needs, I'm going to go out and talk to people and find someone. And I think that is a thing that sort of just demonstrates it's out of the day-to-day, and it demonstrates that, you know, I want to just effect change. I don't care how it happens, right?
Eric Liu is another one. The fact that he went from sort of writing a lot of strategy docs to, he asked me at some point, he's like, hey, look, at some point in the future if you started a startup, would you hire me? And I said, well, not in the first 10, I don't need a product manager. He's like, oh, okay, I'm going to work on the skills so that you would hire me in the first five. And that led to first spending more time in Figma instead of, you know, writing long PRDs, and now it's just, why do I have to do the Figma thing, can't I just build the prototype and at least show you what I think and do the thinking in there, right? So those are just sort of signs of high agency of, I'm going to change the role to how I think it should be.
Something you mentioned earlier, which I love, this idea of just rethinking what is this role of engineer and what should it be if we didn't have this kind of meme already for it. I wonder what we lose as these roles start to merge. We used to have this clear engineer, product manager, designer. And as people start to, you know, as you talk about malleable software, we'll come back to this, but like malleable roles almost, there's something we lose, like clear career paths and design consistency, things like that.
I think if we're not careful, we will lose specialists. And so the way I would describe this is I sometimes like to think about software in terms of physical metaphors, right? And physical metaphors somehow make it so much clearer what a prototype is versus what an engineered thing is. And if you and I were to build a hardware startup, well, we would make the first enclosures and prototypes with 3D printing. And you would see all the layer lines. It would be very, very obvious to you that this is not a thing that you should just give to people to pay for. And then there's a long windy road all the way to the end where at some point, if you're very lucky, you get to manufacture that product for, I don't know, 100 million people. And so then the engineering is actually the, how do I optimize the factory so that we have enough yield and so that we have enough precision.
And that to me I think is very absent right now from most of the discourse in software, which is it's all about how many tokens can we spend and how many features can we ship. I'm like, okay, but where's the engineering part? And the engineering part is you make sure that this thing works for 100 million people, for a billion people.
And on the design side, I think there is the, yes, anyone can now very quickly take a design system off the shelf, build a very usable user interface, get to the core of what's really important, but where is the delight in craft? And so I think we have to make sure that we, in this sort of merging of roles, don't lose the specialists on the edges. And yeah, I would say that's something we
could it would potentially be sad if we lost it.
I want to come back to this agency piece because I feel like people hear this word a lot on this podcast. Yes, agency. For someone that wants to build this within themselves or even just understand, do I have agency? I don't know. I think I do. I imagine everyone listening is like, yes, I am huge. I have huge agency. I'm such an agent. I'll do what needs to be done. Do you have a piece of advice for someone that wants to develop this within themselves?
Partially the reason why I'm in software is the thing that I care most about is the Steve Jobs quote. One day you wake up and you realize the world is made up by people no smarter than you. And there are basically people who realize this by themselves or they have an amazing teacher early on in their life that encourages this.
And the biggest throughline I've found is making. I think if you tinker and if you make things, then you are now on this treadmill of just creating and then you're like, "Oh, it's actually not that hard to learn how to make that chair in my office or let me tweak it a little bit or maybe, I don't know. It's like a home-cooked meal is a form of tinkering, ironically, right?"
And I think the more you can do that in life, I think actually sort of making things is the innately human, like sort of tool making, creating art and so on. So just do that versus, I think when a lot of people hear agency, they think of themselves as they're in this big machine and they're like, "Oh, okay. I'm going to circumvent my terrible boss or manager or whatever so that I get X, Y, and Z." It's like, no, no, just start by making things. And usually when you get better at making things, at some point people pay attention and it just really awakens you to the idea that you can just change things.
I love this. There's this meme on Twitter, you could just do things. I love this version of it. You could just change things. Which is a good segue to something you've been a big, I don't know, advocate of and proponent of, this idea of malleable software. Something you mentioned earlier. It feels like something that wasn't actually possible and now is like, okay, I could see exactly what you're talking about now. Like you've been on this from before the AI revolution. Talk about just this idea. Malleable software, why you think it's so important, what you think people need to be thinking about here.
Malleable software is the idea that software works closer to the interest of the people that use it than the interest of the corporation that makes it. Maybe that's how I'd frame it. And in particular, I don't want to use software that is specifically just designed by the ivory tower in Cupertino. And I say this as a huge Apple fanboy, but
imagine you lived in an environment where you do not get to rearrange your living room and the kitchen has to be exactly set up the way that someone else decided. We would not take that, right? But that is kind of the world that we have in software right now where we have this world of apps and apps are like this very, every layer is glued together, of like the user interface, the data ownership and so on. It's like this little square on your phone and the moment you're like, okay, this is a really great app but I just want to change a little bit, that is usually not possible, right, the behavior. You have the flip side, which is you could run your own Linux distribution and go that way, and I think then what happens is you realize, oh, okay, I like the malleability but I also have other things to do and I don't always want to start from scratch and figure out why the trackpad doesn't work.
And so to me it just comes back down to do you have ownership over your computing life, and I think increasingly we don't.
Now, you brought this up presumably because I think you may have sort of not thought about malleable software too much before, but now you're like making your own tools, maybe for podcast recording, for prepping for shows, or I don't know, whatever. There's a myriad examples and people are awakening to this idea of like, oh, I can just make tools, and that is a form of malleable software. But it has to be built on top of a platform or an operating system that encourages this, because otherwise we're just doing individual, like everybody has their own individual little tool, and I don't know, I like working with people and I like communal tools.
And I don't know, this is a thing that the folks at Ink & Switch are obviously sort of at the forefront of. I get to work with Geoffrey Litt every single day now, who spends a lot of time thinking about how would we make software more malleable so that we feel more ownership over it without going back a long time and not having real-time collaboration and sort of the security aspects and so on.
I really love, and I just want to make sure we highlight, this idea you're sharing. It's something that I learned also from Brian Chesky at Airbnb. This idea that you can change things, that the things around you are just made by other people that may not actually be smarter than you. And it's just this really empowering thing to always think about, that things can change. This isn't the way things have to be forever. Humans made this thing, like humans made this phone, and there are better approaches that other humans, that you can come up with, other people will come up with.
What I think about as I think about this is there's a video that you pinned to your Twitter profile that we'll link to, which I think is Dieter Rams. Is that who the person is? Okay. So, he's walking around. He's just criticizing all these designed chairs. Talk about what that video is trying to, why you pinned that to your profile.
There's many reasons. One is I think maybe the only thing that I have in common with this very accomplished person is that we're both German. And so sometimes I joke that I also aspire to disapprovingly just point at things with my walking stick and say, "This isn't good enough. This isn't good enough."
The reason why is because I think if you speak German, this is one of the funniest clips that I've ever, I just die laughing every single time. I'm actually curious how you think about how it ties to malleable software, because the main reason why I use that as a clip of reference is I'm very much in the camp of design should be first useful and then beautiful. And I think a lot of the pieces there are predominantly things that you put in a museum for display, and if you try to sit on them you'd be like, what is this nonsense?
What I felt there is just like, you see all, like you would think it was Frank Gehry and all these famous designers' pieces put up in a museum, and I think to most people it'd be like, wow, this is so incredible and beautiful. Like you see somebody that has a status and a reputation and you assume this is great. And I love that he breaks that veil of like, no, this is so stupid. What is this? What is this bunch of cabinets tied together? Doesn't make any sense.
Yeah, he said that's for that cabinet. I think he says something like it is neither orderly nor properly chaotic. I understand the connection. Now, The Timeless Way of Building and Stewart Brand's sort of How Buildings Learn, I think, idea is also that it's very likely that the best homes for you are not actually built by an architect. They are the thing that over a long time adapt to exactly how you would love to lead your life and they learn over time versus, you know, immediately. And so then that is obviously a very costly version of malleability, right, if you have to rip out a wall or whatever. But I think the main thing that Dieter Rams points out there is it should be a thing that's useful. And a good way to figure out how something is useful is if you can change it and tweak it. Makes sense.
It all connects. It all connects.
I get it now.
There we go. I won't link to it. It's really funny to watch. I wish I understood the German. I want to come back to this idea of malleable software from a perspective of SaaS and the SaaSpocalypse. There's all this talk about we will not need SaaS tools any longer. We will build all our own tools. We don't need Salesforce. You know, I imagine some people are like, we don't need Notion, I'm going to build my own Notion. You have a hot take there. Talk about what you think is going to happen.
If you just think about what SaaS, the problem is the moment you have an acronym, it means a lot of very specific things. And if you're going to say, hey, is this type of SaaS that we've built in the 2010s just as relevant as it was in the 2010s? The answer would be, it would be silly to say, no, nothing's going to change, it'll be the same. Because I think you can sort of say a lot of SaaS in the 2010s was a very, very fancy form around a spreadsheet or something more generic. And the thing it did is it just guided people in the right direction to fill out that form, as in it is less malleable than a spreadsheet. And that sort of is the value.
The as a service part is I think the thing that actually matters, which is I don't think most people actually want to maintain the full stack of software. And so whenever I see someone, and I am someone here, say, oh, I just rebuilt this piece of software. I've tried rebuilding Notion in a weekend for myself, just to, you know, push at the edges of frustrating things. I don't think people want that. I think for the most part it's nice if you can just, people don't want to go hunting either. They just want to go to Costco and have the steak in styrofoam packaging and pretend that it wasn't hunting or, you know, an animal in the first place.
I think with software it's like, Bret Taylor says this too, software is like a garden. You need to tend to it, and the thing you pay for in the as a service is the maintenance and a bunch of specialists thinking really hard about a problem. And so I don't think that's going away.
What I would probably say is that tools will become more general. I mean, I'm obviously biased. I work at Notion. I like Notion and I consider Notion to be fairly malleable. Not enough. I think it should become more malleable. We internally joked, Joanna Stern, a journalist, recently tweeted something along the lines of, oh, thanks to Notion AI I finally understand and use Notion. I don't know what that says about Notion.
And to me this is a great example of Notion wasn't SaaS in the traditional way. It's kind of hard to get started, but because of AI now people can sort of, they have a tutor essentially, and can build more things. And so I suspect that software will go more back into the '90s of general tools, word processor, spreadsheet, FileMaker Pro, that kind of thing, but those will still be as a service. And then you'll still have specialized tools around security and so on, of just people who go the extra mile to really solve a user problem. So I think to some degree the SaaSpocalypse is greatly exaggerated. At the same time, are things going to stay the same? Of course not. Like, why would they?
I completely agree. I think people think about just the, okay, I'll create something that's pretty cool and close, and then they don't think about, exactly as described, like I have to maintain this thing forever and I have to keep adding features, taking people's feedback. One of the funniest things that I see again and again, I just had the head of product for Claude Code on the podcast, Cat Wu, and she talks about how Slack is basically the OS for Anthropic. Everything runs through Slack. And you think of all companies that would just be like, we'll just build our own, what are we doing with Slack? Like, no, they're using Slack like crazy. And I think that's just one example of like, nobody wants to rebuild a tool like Slack. And Workday, I think, is another example.
I don't know, I think it's maybe even more unique in the US, but one of the great things about the US is actually specialization. It's that I get to spend dollars on something like Notion because it's not that expensive compared to me building it, and then why would I waste my time? I want to do other things with my life, right? So I don't know, that's not going to go away.
Yeah. I agree, like people at Anthropic, their time is better spent building AGI than trying to build a better Slack.
I also love the Slack example because, I mean, there's this graphic of what it takes to deliver a notification in Slack, the sort of decision flowchart. And that is just something that you only get to when you have real users, real scale, and decades of just, yep, we understand the customer.
I want to come back to how product building is changing and how it's different. I know you've done a lot of different jobs, but like your job, I don't know, a couple years ago. What's most changed, like what part is most, something you don't do anymore or you do a lot more of now with AI emerging as a big part of your process?
I think the first 10% of every project are now free. That's how I would describe it. So there is no point for most things to, for example, write a, I don't know, the thing has changed. I've never really been great at this. But there's no point in writing a PRD if you can just do the janky version and sort of, you know, do the here's the demo of what I think we should build.
So the first 10%, that's such an interesting way to frame it, the idea there's just like the thinking through of it, you can go a lot further really quickly.
Yes, and if you look at a lot of the, it takes almost no effort to now build sort of the first version of a startup, right, or like version 0.8. And then I think the last, or maybe even if you're generous and say the first 90% are now done, the last 10% are still actually 90%. That's always the hardest. So I think it's cheaper to just explore a lot of paths. You can now afford to say, I'm going to send off 10 agents to explore 10 different things and then see if I was right.
We used to say this at GitHub in our product reviews a lot, which is demos not memos, and then we would say, give me something to react to. Which is, okay, if you're going to write a PRD, just write the changelog or the blog post that a user would read. Now it's much easier to give people something to react to, as in, yeah, here's the version of the product, and it's like, okay, what if we did it this other way? Oh yeah, here's that version. And so I think that is just amazing. It sort of builds iteration into the product much earlier, right? Like waterfall is sort of, why bother?
What do you think is the next kind of leap or shift in how we build? What are you seeing that's like, okay, this is now the new thing that's emerging that is going to change how we operate?
I'm very conflicted on this because on one hand, I do believe the never bet against plain text. So, a famous forum post at some point. Plain text, markdown. It's just such a durable thing. Code is such a durable thing. I think that expressing your thoughts in code is probably a really good thing. We can talk about why. But at the same time, I'm like, are we really going to just be chatting back and forth? And so what is the future of Figma, for example, is a really interesting example to me, because on one hand I do see sort of a drop in usage of Figma in some designers at Notion, and then others are like, nope, these AI tools are wonderful. It's very hard for me to predict of like, is direct manipulation going away because the agent is doing the direct manipulation?
The other thing that I'm curious about is there is this automation versus augmentation fork. If I look at the really, really fast models like Spark, and I forget what the Anthropic variant is, where
Haiku.
No, sorry, you still get a smart one. It's Opus, but like Opus fast or something, just, yeah, like
you very quickly run up a bill of like $3,000 a day. But the speed of
Inference really changes things. If the inference is slow, then you're queuing up a bunch of jobs and then you're walking around the building thinking about other things and then come back and review, versus if it's nearly instant. Are you still going to do this? Is this sort of multitasking, the frenetic kind of thing that we currently have going on, actually the thing that gives us flow state? Well, no. But if the inference becomes instant, do we get back to direct manipulation? Right? Do you instantly sort of mold the clay that is the code? Right? I don't know. I think it depends on model capabilities, which is: is there a saturation on intelligence or not? The analogy I like to give is a retina display, which is after I can't see the pixels, I can't see the pixels. I don't need you to make them smaller. Is it not the same for a lot of cognitive tasks, which is at some sort of level of intelligence I don't need more, and instead I want a different modality and faster. So I don't know, those things I'm excited about.
Interesting. So that last point you're making is it's like smarter models will not significantly impact how teams operate because they've gotten so good, and it's other blockers now, like UX essentially.
Yeah. I think in general I'm actually very curious. The labs sort of operate, I feel like they operate under the assumption that people will always want the smartest model, like you want the frontier model. And I think for certain domains that is probably true. I think if we're going to do cancer research and so on, and if we're going to spend millions of dollars on something, that's likely true. But that's not how we run companies either, right? Like we don't have a PhD for everything. And so I think for a lot of knowledge work tasks, probably sometime we'll get to good. And once you get to good enough, then you can optimize other things, like they run locally, they're cheaper, they're faster. And I don't know why, the absolute intelligence thing doesn't interest me very much. I think society is largely not capped by intelligence. I think Tyler Cowen says something similar. I don't want to put words in his mouth. And so I'm much more interested in the exoskeleton versus the "I have a god in a box in some data center somewhere and we're all sort of, you know, twiddling our thumbs."
Mhm. I have a bunch of questions along these lines. So interesting. You talked about how this one PM is the highest token spender. This is across all of Notion?
I would assume this may not include our automatic security vulnerability scanning and bug triaging. It's like when—
Yeah. A human kicks off jobs. Yeah. Yeah.
What's your policy on token spend? Is it spend as much as you want? Here's a limit for everyone? Do you keep track of—
Given that I don't know what the policy is, I think it is unlimited. I mean, you can imagine at some point there would be, but right now I think it's just the wrong thing to optimize for. It's like when something new comes along, it's worth letting people explore. I do suspect in six to 12 months from now a lot of companies are going to actually start asking questions around ROI, and I think that will be an uncomfortable conversation for a lot of folks.
In terms of spend, what are the numbers for, say, Eric, or broadly in terms of—
I am the wrong person to ask.
Okay, it's just a lot.
That is just the... I don't... I would assume they pale in comparison to the folks at OpenAI and Anthropic just by the nature of the work they do and so on. But it is definitely, for an individual, in the, you know... I don't even want to put numbers in, but like thousands for sure, but maybe tens of thousands. I don't know. Depends. Yeah.
I think just the fact that you're head of product and not on top of that means that it's just, let's not worry about this, let's just see what we can do, and then, you know, in six months, as you said, we'll figure out if this is ROI positive.
Yes, I have the luxury to right now not care.
Yeah, I'm sure someone's looking at it. It's not going to be out of control. I think there's this big, I don't know, milestone of when does token spend exceed someone's salary. That's something people talk about now more and more, just like, should that be higher than your salary, should that be lower? How does that all connect?
Yeah, I think there's a real danger in sort of making the token spend the metric to boast about, which is the same as when people boast about how many lines of code they've written in a day.
Yeah. And I'm like, why do you have so many lines of code? You have, I don't know, the largest software projects in the world have not that many millions of lines of code. Like, why are we bragging about that? I don't actually care about how many tokens someone spends. Yeah, it's not a metric that's useful.
Yeah, such a good point. I know Meta got some flack for this recently where they're trying to create a leaderboard of who's doing the most.
To be fair, I do understand why companies do that, which is I am surprised by how much work it takes to get people to identify the outer loop of their work and enlist an agent and build sort of the, I don't know, the term right now is like factory, right? Like the software factory for the work that they do. It is surprising to me how much prodding you need to do to get people out of the way they're used to working. And so if you're dealing with tens of thousands of people at the scale of Meta, I have some sympathy for, okay, a good way to do this is just start a leaderboard and encourage people to do it. They will find good things and useful things to do with that as they learn, right? So it's a... Yeah.
It's such a good point. Like you have to overindex to change people's default easy behavior. "I'm just going to do things. I'm just going to write these PRDs the way I've always done it. I'm going to run the meetings the same way I've done it." I think that makes a lot of sense. What have you seen actually work within Notion to get people to significantly change the way they work?
Depends on the role. So roles that are perhaps further away from engineering, actually you don't have to convince them all that much, because they're like, "Whoa, I have superpowers now. Look at this amazing thing I've just built," because the capability gap of what they were able to do before versus after is so huge that it's intoxicating. And then you have to actually almost do the opposite, which is like, "Yes, but do you understand why we can't merge this PR?"
I think on the engineering side, something that Simon Last talks about a lot is sort of any manual intervention in code is kind of bad. You probably did something wrong in the verifiability loop and in sort of the software factory. This excludes obviously reviewing code, right? Like I am still very much in the camp that you should probably put more effort into reviewing code than you do. But at least on the writing side, every time there is a human intervention, it should feel a little bit like a bug. I think that's a good litmus test for, I don't know, how agent-pilled you are.
I want to come back to the tools that you use. You mentioned Figma is kind of trending down within the design org, which is really interesting. Is there anything that's trending up? Anything else that's trending down in terms of tools in the tool stack of your team?
So, I'm actually not positive that Figma is trending down. I think it's more that there's two camps. I could totally believe the Jevons paradox, which is Figma is actually going up, and then of course vibe coding is going up. In general, I really, really dislike the rivalry discourse that exists in Silicon Valley, which is for Anthropic to win, OpenAI needs to lose and vice versa, and that kind of thing. So I don't want to perpetuate that with sort of the Figma versus coding.
I think the terminal is actually surprising, which is it's initially kind of scary for people, and you could do so much, but now PMs are slowly... once they're in Claude Code or Codex, everything is fine, right? And I generally encourage them to not use the GUIs. I encourage them to use the TUI, because I just know that over time they're going to be curious and pull at other threads, and one day they wake up and they're like, "Oh, I understand more of the substrate of how computers work."
That is so interesting. So the designers are using the terminal.
Yes. Yeah. And then, I don't know, Conductor is another one. They're basically just mostly using developer tools. It's not that different from what developers use.
I am so excited to tell you about this season's supporting sponsor, Vanta. Vanta helps over 15,000 companies like Cursor, Ramp, Duolingo, Snowflake, and Atlassian earn and prove trust with their customers. Teams are building and shipping products faster than ever thanks to AI. But as a result, the amount of risk being introduced into your product and your business is higher than it's ever been. Every security leader that I talk to is feeling the increasing weight of protecting their organization, their business, and not to mention their customer data. Because things are moving so fast, they are constantly reacting, having to guess at priorities, and having to make do with outdated solutions.
Vanta automates compliance and risk management with over 35 security and privacy frameworks including SOC 2, ISO 27001, and HIPAA. This helps companies get compliant fast and stay compliant more than ever before. Trust has the power to make or break your business. Learn more at vanta.com/lenny. And as a listener of this podcast, you get $1,000 off Vanta. That's vanta.com/lenny.
AI has completely transformed the work of a software engineer. Like two years ago versus today, it's completely different. Almost all your code is now AI. And we've been talking about when will 50% of engineers in the world be writing 100% AI code? It's probably in a year, which is insane, how much that job has changed. Which role do you think AI transforms next? Is it marketing? Is it growth? Is it sales? Is it design? Do you have a sense of where things are starting to really change other than engineering?
Okay, this is maybe a hot take, and I actually don't have enough... it's very likely that the labs are like, "Haha, look at this guy." My take: it's very clear, at least empirically, that models are getting better at coding at some exponential rate, right? And I don't think that's changing. Now, I'm not that impressed with the progress in any other domain. I don't think they've gotten significantly better at writing. I still very much hate reading sort of AI slop writing. But the thing is software... Andreessen, right? Like, software is eating the world. Well, if the cost of software and creating software and encoding business practices in code, and I just literally mean the old software 1.0 kind of code, if that cost is very much going to zero, we will just have a lot more of it. And so I think in that case it's more that software engineering will go into all the other domains, not necessarily that there is some sort of... yeah, like, I don't know, our folks in HR are automating a lot of things because now they don't have to bug an engineering team to write that code. And so I think that's how it's going. And if you look at when the model companies say, "Oh, we've made great progress in this other non-coding domain," I was like, "You just applied coding principles to this domain, which is wonderful, but that's what it's getting better at, right?" And so I just think software eating the world is going to accelerate.
That is a really interesting take. So it's basically just the acceleration of software eating the world, versus it's going to now do a different kind of job. This makes me think about the head of product for Codex, who said the same thing: there's all these different kinds of agents, and his take is every agent that will win is going to be a coding agent that builds the thing it needs, versus it has a certain number of capabilities. OpenClaw is such a good example. It's just like, "I will build a skill for myself and now I know how to do this thing."
Yes, all agents are also like... if you look at all the harnesses, whether it's the open source ones or the ones from the model companies, ours as well, they all resemble a coding agent.
I'm going to come back to the ROI piece. I think this is really interesting. As you said, there's just like, okay, we're going to spend, spend, spend, just see what happens, learn, accelerate, lean into all this stuff. You're saying that in maybe six months, something like that, you think a lot of companies are going to start really looking at the cost here. I know you said you don't like to predict things, but what do you predict is going to start happening?
I probably spend more time than I should on this, because I have literally zero impact on any of this, on how it plays out. But you can imagine a world where the delta between the labs and open weight models and so on widens. That is a world that I very much don't like, because I hate centralization of power. But in that world, I think the labs just kind of get to decide what the world looks like. I think if that gap doesn't widen, then you will just see a diffusion, and people will get very comfortable running their own models, RLing their own models, right? Like you see this with Cursor, you see this with Intercom. Notion is dabbling in it as well. We're dabbling right now, but obviously at some point we might become more serious about it. And then it may not be the frontier, but for a lot of tasks it'll be good enough. And so I think in that case that is just an ROI calculation, that is: is it cheaper for me to send this task to a smaller model that is cheaper to run, where I remove the lab's profit margin kind of thing? I think that may happen, but it only happens if there isn't a fast sort of, you know, "Oh yeah, the gap is now so big."
The other one that's interesting is right now I think we're actually in one of the luckiest possible timelines, which is we have, at least in the US, three competent labs that are all sort of duking it out, and who knows, maybe Meta now. So four, maybe we can make it six at some point. I would love a world where we have like a dozen frontier models in the US versus having to always rely on other places in the world to do this. But that's sort of pretty good. If that stopped, I would be somewhat worried. And then it's hard to predict, right, what would happen.
But if that doesn't, then I think it's going to look similar to the cloud wars, which is at some point layers commoditize. Businesses are not going to want to lock into one single provider. I don't know, in a past life I worked at Heroku, and Kubernetes was much more successful than Heroku, even though I think from a user experience perspective it was much worse. But the delta was Heroku was saying, "Hey, we're going to replace your ops team," and Kubernetes was, "We're going to make your ops team superheroes, and also we're not going to lock you into a cloud. You can choose." And obviously that's what businesses want, right? Businesses want choice. And so, I don't know, it's really hard to predict because it depends. It's so asymmetric in terms of model progress.
When you say the products that win often are the ones that make you feel like superheroes, I always think about Kathy Sierra. Do you remember that at all as the thing?
It rings a bell.
Okay. It's from the olden days at this point. Shows how old I am. She was just something that really stuck with me, and I think it's informed a lot of how people think about product, at least in the past. Her whole pitch was, instead of making talking
about your product and how amazing it is, it's about we will make you a superhero. Like it's like Mario getting the little flower and having superpowers now versus look at our incredible product. I think it's actually a thing that the coding companies had to learn when they tried to move to, like, why do code review tools, automatic code review tools, not work that well? I think this is actually a subtle thing, which is you push your code publicly, or publicly within your organization or your team, and then a thing roasts your code and tells you how terrible of a developer you are, versus if you think about what Claude Code and Codex does is you're coding and then you publish the work of you plus Claude and you get bragging rights of how good of a developer you are, right? And so I think the superhero stuff is definitely true.
Speaking of superhero, I wasn't planning to talk about this, but I've been hearing a lot about how much people love your agent, the Notion AI agent that you all released. It's just coming up a lot of just like, wow, this is actually really useful, with a lot of different people. It'd be interesting to hear what you think made it so successful. I know it was a long time before you guys launched it. Just, what do you think is helping it be this useful and successful as a product out in the world?
I would like it to be even better. So I'm like my own worst critic, I guess. I've spent most of my day thinking about where it falls short, not how great it is. But I agree with you that I'm actually surprised at how... this sounds so weird. I'm surprised how good it is, if that makes sense. Notion has always been fairly at the forefront of AI. Like I think the first Notion assistant was actually launched before ChatGPT. And so I think both Ivan and Simon had the intuition of, hey, this is going to change a lot of things, and so that's a huge sort of reason why. But every company wants to become AI native now, whatever that means. It's kind of like cloud native. I'm like, if you have to say it, then do you really have a chance? But I'm surprised how fast that happened for Notion, and I'll take almost no credit in this.
I think what's good about it is agents need context to operate. Agents don't really like walls of like, oh, I have to go through this narrow orifice to talk to this other data repository. And I think for the first time it is kind of obvious to people why a connected workspace is actually valuable, because it's great, I can have agents roam around and do that. And it touches on malleable software. I think of Notion as an operating system more so, and then in that case it resembles the environment that coding agents are in with Unix much more than one might maybe intuitively think. So I think those all contribute. And then sometimes we're just dumb enough to try hard things. And so I think our enterprise search is sort of like this thing where we do a lot of automatic permission handling and so on that others don't. I don't know, you have to care.
I'm going to come back to my quote from the Bible. I feel like that actually is an answer to this question, that it was made for such a time as this. The fact that Notion basically has all the things about everything in your company is the perfect source of context for using AI and helping you work. So it's just like being around long enough for, wow, okay, this is exactly what we've been meant to be.
It's nice. Nice job.
It's the same as malleable software, right? Like I love that people are waking up to malleable software now, but it's been around for a long time. It was just always slightly too hard and slightly too like, why would I do this? And so I think, yeah, I'm going to use this quote from the Bible. Thank you.
There it is. The original quote is "for such a time as this," and the interpretation is you're destined to do this thing. This is a very Bible-heavy episode. Oh man.
Going back to the way your team operates, because I think this is something that a lot of people are thinking about right now. There's all this talk of productivity, pace, getting things out, like Anthropic's launching a massive product every day, basically. Your job as head of product is to help people ship consistently, regularly, often, ship great stuff. What has worked in allowing you guys to ship more quickly, if you are, and stuff that you're proud of, stuff that works?
I think this answer is so specific to a company's internal culture. I've been in this situation sort of twice in my career. One is when I joined GitHub, which obviously had, I think, insane product-market fit. It just so happened that at the time that I had joined there was a little bit of an identity crisis, or like, oh, what's our next act, what do we do, and lots of debates about what to ship, because it's such a tough act to follow if your first act was just incredible, right? And I would put Notion in the same bucket. And so in this case it's just reminding people that, hey, you can just do stuff, we don't have to be that precious. I think there's this preciousness that develops over time. It's like, oh, what do we do? Our users are going to be upset. Well, our users are going to be upset if we don't innovate more so than if we accidentally break a thing. So it's obviously a balance. But I think just reminding people that the same group of people that was able to do the first act is very likely going to be able to do the second one, but you have to try.
Shots on goal is a thing that we say internally a lot, which is like, great, how do you increase shots on goal? Which of course, if we go back to it being easier to experiment now, you're increasing the shots on goal, right? So I think that has worked really well. Just shipping feature after feature doesn't... We have been a little bit on a roll in terms of shipping new functionality maybe in the last, I don't know, six months or so, but at the end of the day, feature count is the same silly metric as lines of code or tokens consumed or whatever. I would rather have fewer features that are really, really good and where the combinatorics let you do everything.
And so I think something that I'm still very much struggling with is software quality. And I will also say I don't think the labs are exempt from this. Like I love their tools. It's great. I live in the CLI, but a regression every two weeks of a thing that was fixed three weeks before, and they still can't render a TUI at, I don't know, a frame rate that's reasonable. And so I think, yeah, quality is a thing that's missing. Like this Apple-esque machined unibody aluminum kind of engineering, I would like us to figure out how to get back to that as an industry.
Is there something you've done to help improve that? So there's code quality and then there's actual software quality. If you're shipping, you know, shots on goal, there's always this balance of, okay, but wait for it to be awesome. I know this is just a very hard question to answer, but what's your kind of communication to the team of here's where we're going to find that balance?
And this is a very frustrating thing for people, but I can't show you because I'm using my laptop, but we have "obviously good" stickers, which is: let's just only make obviously good stuff. That's the origin, which is like, okay, wait, what does that mean? And I'm like, ah, you know it when you see it. Like, I don't think anyone argued when they saw the first iPhone that it's obviously good. I don't think anyone argued when ChatGPT first came out that it's obviously good. And so I think that's the bar, just make obviously good stuff. I think the mistake that maybe a lot of companies then make is, great, we're going to be in this cave in isolation until we have it be obviously good. One of my core values is incremental correctness, which is sort of iterate, get really, really good at iterating.
And so, I don't know, it's probably a union of, okay, increase shots on goal. Like, here's a great example. We get roasted by our customers all the time, which I love, about how we have like six automation primitives inside of Notion, right? If you include all the agents and so on. I'm like, yep, we let a bunch of different ideas sort of grow. We look at how they work, but then you do have to do the hard work of consolidating it back into the naked robotic core of that idea, and that's hard, right? Because you have to be okay with perhaps then shipping the next thing slightly delayed as you reconcile. I don't know. I think we have work to do there at Notion, but as an industry too. Like somebody was joking, why does the Claude desktop app have three tabs of Cowork and, I don't know what, the first chat or whatever. Why do we have six automation primitives? Well, because someone has to sit down and reconcile them and figure out what's actually the core simple thing that should outlive the other evolutionary branches of that same idea.
This idea of knowing when things are obviously good, there's an element of having taste. And there's this word taste that comes up a lot now, and this is what we will need more and more, because AI is building the thing, now our job is taste: is this great, is this good? I feel like you're someone that has really great taste. A question people always ask: how do I build taste, do I have taste? Do you have any advice for someone that's like, I want to develop my taste?
First, I don't know if I have great taste. I look at others and I look at how they exercise taste, and I think the common thing is iterations with feedback. So it takes a really long time to build up taste in a specific domain. Then you maybe often can extrapolate into other domains with that taste. But if I had to describe what taste actually means, this is such a nerdy way of describing it: you're able to run a virtual machine in your head where, given an idea, you can predict for a certain in-group whether they're going to like it or not, right? The extremes are, if you are the only person on the planet that thinks something is good, is it good? No. But maybe you also don't need to build a product for 8 billion people. I've never built consumer software. I would probably be terrible at it. But you decide what your in-group is and then how good do you get at emulating how they will react to it.
And to do that, you just have to do reps. It's almost like training a model, which is also why I'm not super, you know, on the whole "the one thing that we have left is taste." I'm not so sure. If you think about the loop, it's input idea, how do people react? That seems very back propagation. I don't know, it seems very much how we train models too.
So what I love is that basically you build taste by just doing the thing, getting feedback, iterating.
Look at Japan, like Japanese craftspeople, right? They've just been, I don't know, painting the bowl for however long, and it just takes a while. And so I think the more reps, increase the frequency of reps, that's what I would say.
It's so funny. That's exactly how agents learn and develop, how, as you said, models learn. Just doing the thing, seeing, was this good, was this correct? No? Okay, learn. So it's just doing the thing, learning, getting feedback.
And there's no way to speedrun this. This is why often people with the best taste have been doing this for a long time. The one thing I will say that I've noticed, specifically for designers, is the designers that I think have high taste, at least in software design, are the ones that both have side projects that they build where they're responsible for the full thing end to end, and they're also always tinkering with some new app. Like they're the annoying person that is like, "Hey, what if we tried this in our team?" I'm like, "Really? This is the 49th time that you suggested a new tool. Do we really need this?" It's exposure to other people's ideas. It's also really important to surround yourself with tasteful things so that you feel like the thing you're making is lacking, right? Like one of the things we do at Notion is all of our conference rooms are named after famous objects, like the first typewriter, the Macintosh, a Porsche 911 and so on. And so inevitably when I'm sitting in one of the rooms and I pay attention to the room, I'm like, nothing I'm doing amounts to this. I've got to do better.
You've built so many successful, great, loved products. What do you think matters in the end to building a successful product, if you had to just kind of boil it down?
Yes. Here's the one trick that I'll sell a course on next week.
Please, I'll sign up.
First of all, I think I would actually say that I have contributed to some really great products, not built them. Because I did not used to believe this early on in my career, but the longer I'm in this, the more I care about what's the team that's building the thing. I used to think that was such a, I don't know, not important thing, and now I'm like, it's the only thing. I don't think that there is a through line out of the things that I've contributed to where I can pinpoint it. I think that you can't say that the best design always wins. I think there's many products where design just doesn't matter, and then as a designer you can have this identity crisis of, why am I doing this? I think you can't even say that the best engineering always wins.
I think one of the biggest pitfalls is if you get into the loop of, if I just add one more thing to the product, it'll finally be great. If I really look at the truly great products, they all have one tiny core that is so exceptionally good. And that is both a combination of you stumbled upon it by luck and then the market agreed. But I think it's: what's the tiny core? I don't know, multi-touch on the phone. GitHub is probably the pull request, right? This idea that anyone can suggest something to you and you see it. I do think that at Notion it's the blocks and the slash commands. Figma, it's sort of the seamless blend between real-time collaboration and not. All the great products have something tiny that is a superpower, versus, oh yeah, if we have this suite of things and we add one more thing, it'll finally be useful. That never works.
And for GitHub, interesting, it was the PR. Other examples of that at other places you worked? Because this is really interesting, just like, what's the tiny core that makes everything else work?
At Heroku, for sure, I think it was the git push heroku master. At the time it was really hard to deploy apps, right? It's sad because people don't remember Heroku, but I have to explain it as it's the first Vercel.
Did it get bought by Salesforce?
Yes, yeah.
Okay.
Yeah, git push master was just this very simple one-liner that went from the thing on my computer to now I have a URL, and that's so intoxicating that everything else sort of flows from there.
Dropbox is a great one, right? I think Dropbox is such an interesting study, where it was the little menu bar icon that was so good at syncing that you could even use it as a signal for do I have internet or not, because it was better at figuring out whether you had an internet connection than your Mac itself. And that's the job: get out of the way, and all my files are always there. And then for years they tried to increase the surface area, and I kept thinking, no, no, no, push it back. I don't want more. This is the only job I want from you, right? And so I think the tiny core is the thing that makes great products.
And Snapchat, obviously, just like the
The disappearing photo concept is so interesting. I heard you've also talked about just like being first doesn't matter that much either.
You have to be right. Not first. I don't know. Like I think, I mean, there are probably elements of, like if you talk about network effects and like perhaps now with like training models, it does make sense if you have sort of a head start, but I think it's overrated. I don't know, like my favorite example is like Bluetooth headphones were kind of crappy and then you have the AirPods and like, oh, they connect and so on, and they weren't the first. Like, I don't know, they weren't the first MP3 player, they weren't the f— like you just got to do it right. I don't think being first is all that useful.
I think we're currently, because it's so hard to keep people's attention, we try to like, we're like, "Oh, how do I become, how do I go viral, right? How do I do the Clo thing?" And I'm like, "Yep, I don't— durability matters, right?" Like, think of how would you build IKEA, like a generational company that is not concerning itself with whatever is trending on Twitter today.
I think speaking of models, a good example is Anthropic, which was way behind, started after OpenAI, got less funding, and now is just killing it and dominating.
The thing that I find the most impressive about, I don't know who to give credit, but like obviously you give the CEO a bunch of credit, but like Dario, is that he wasn't— oh, he wasn't just lucky once at OpenAI. He did the same thing twice and it was successful twice. And like I think that's actually really cool.
I know you're also a believer in jobs to be done as a way of thinking about product, which is kind of this, it's been a long time controversial topic on this podcast, mostly because of Shiram, who's very anti-jobs to be done. What's your kind of framing of how you find this framework useful in thinking about product?
I bet that if I reread all of the Clayton Christensen stuff I would also not identify super strongly with it. I use it mostly as: have you thought holistically about what the user wants to hire your product for, and are you honest about what the user wants versus what you want the user to want?
And then the other thing that I find happens very frequently in larger organizations is that people sort of turn off the brain when they're reviewing their own products from a "I'm a user. Is this a good experience?" And they're more like "I'm an employee of this company and I made a thing." And so I think jobs to be done might encourage people to zoom out and sort of not get lost in the sauce of like making the thing. That's why I like the framework. It's a good reminder of like, no, no, no, the user hires you for a thing. Be that user for a second. Would you even buy the thing that you just made? And the answer often is like, oh, I hadn't thought about that. Right? Like, and so that's how I use it.
Is there an example of this from some of the products you worked on, just to make this real for people, other than like the milkshake example, obviously?
There's a very recent one which is more about communication. We're launching a new feature soon and we're working on this landing page to describe the feature. And I found that when people make landing pages, first of all, their writing skills just like deteriorate immediately because they want to sound clever and like marketing speak comes out of their mouth. And I'm like, wait, that's not how you would explain it to a friend. And then if I'm communicating this product to you, just pretend you're standing in front of a whiteboard. What's the manic thing that you're drawing on the whiteboard to communicate this, versus, okay, now go back to the thing you just designed, look at it. Are you telling me that those are the same thing? Are you telling me that you understand what this thing does, and like that zoom out? So, I don't know. Yeah, I don't know. I don't want to pick on individual recent things, though.
Okay. As we close out this conversation, there's something I want to get your— you have this hot take on universal basic income. This is completely out of the blue, but I think it's interesting to hear. There's this idea that, you know, with AI emerging, we may not need to work. We'll all just get some UBI and enjoy our life. And you have this hot take that maybe we already have universal basic income. What's going on?
Yeah. So please extend me some grace here because I both mean it as a joke and maybe somewhat real, like it just depends on which altitude of human nature you look at. My take is that we already have universal basic income. It's called knowledge work. And I don't exclude my job from it. But if you really look at what do we actually need to live and like to be content, it is a lot less. And we've built this hierarchy and all these jobs and all these things that are absolutely necessary. And so to me it's like, yeah, we already have it. It's UBI, and we'll come up with other ways in which we as humans, because we're the most important species in the universe, insert ourselves into the conversation around agents. Will it look the same? I don't know. But yeah, I don't know. We are so inventive and we come up with new reasons of why we absolutely must be in that loop. And so I think that's my hot take.
People have always joked like we get paid so much just to sit in front of a computer and put the right sorts of words and letters into this thing, and we get paid a lot of money to do it. And now it's like, oh, maybe I won't be paid this much in the future because AI is going to take over. And so your take there is just like, this is a pretty sweet gig we already got. Enjoy the UBI.
Yes. I think all things considered, how lucky are we? Like, I don't know. I'm sitting in an air-conditioned room right now talking to you, having a good time. I don't know, like, yeah, just to be clear, not everybody has that luck, but I think the folks that I find discussing this the most are the ones that are in the bucket of luck.
Say we have AGI, you don't have to work, you could just do anything. What would you be spending your time doing?
I actually ask this to almost everybody that we hire. I would be doing the exact same thing. I would probably spend less time having meetings and managing. One of the sad things about my job is that I have yet to replace 80% of it with agentic loops. I envy our engineers and designers who get to do this. So hopefully at some point I won't, like, I won't have a job. But yeah, I would do the same thing.
I think I am someone who, I don't code because of a utility. I code because it's also an intellectual challenge. So I think of it as playing chess and Go. I'm very sad that Lee Sedol, after losing against, I think, I don't know if it's AlphaGo or AlphaZero, but one of the two, sort of like, it seems like he gave up on Go. And I'm like, who cares if some machine is better at it? Like, it's the human stuff, like just, you know, keep going at it. And so I think I would do the same thing. I would tinker. I would build stuff. I would try and make the world around me more malleable.
I just got an email this morning from someone who asked me about, oh, you think a lot about malleable software. Have you ever thought about what robotics might do? And it just blew my mind because I had not, because it's so far from the skills that I have. But yeah, I don't know, something like that. I would just do the same thing.
Amazing. Okay, I'm going to take us to two recurring corners of the podcast to see what we find there. The first corner is contrarian corner. Is there something that you have— you have a lot of these already. I'm curious if there's anything else. Is there something you have a contrarian opinion about? Something you believe that a lot of people don't?
It's becoming so hard to have contrarian views because I think the algorithms just try and get contrarian views out of people, sort of, you know, with an insane force. Depending on the era, like this may not be contrarian, but I think that inclusivity isn't always all that great. I very much believe in small group theory. Like I think the world is run by group chats of eight people or fewer. And so sometimes it's great to be exclusive.
And what I mean by that is I even think about this in terms of Notion. Notion could have the ambition to say we are going to have 8 billion users, so every single person on the planet uses Notion. And I think if we did that, we would very much upset the first, call it 500 million, because the top of the class wants different things than everybody, and everybody is in the top of the class at something. And so I think being okay with being exclusive sometimes is okay.
I will have to caveat this with: if you're McDonald's and you have exclusive hiring practices and it's the only job in a location, that is not what I'm talking about. But like going back to the comfy, air-conditioned job kind of thing, it's like, great, just work with and for the top of the class. It is sometimes a winning thing, and just build a really, really good product for them, which by definition means you're going to exclude others.
The TBPN guys have a really good way of describing this exact concept, which is, you know, they had like, I don't know, 8,000 listeners and like a conversation, they got acquired for hundreds of millions of dollars, just like, what's going on there? And the way they pitch it is, you know, like if we have millions of people listening to this thing, we've done something wrong. This is specifically designed for like the people in power of tech, to influence them, to teach them what's going on. And it worked out great for them. So it's exactly what you're describing.
Okay, I'm going to take us now to fail corner. So people like you come on this podcast, they're like, "Okay, look at all these wonderful things he's done. He's just killing it all the time. Everything's working." In reality, I'm sure not everything has worked in the course of your career. What's one example where things didn't work out and what did you learn from that experience?
Oh my god, like this is such a weird— I don't think about win versus fail. I kind of feel like every day I fail a lot.
What are big ones that annoy me culturally? I think like sort of in running teams, I think a mistake that I made is at some point, because hiring— now it's easy, but at the time hiring designers that can code was quite challenging. And so then if you loosen that requirement, I did not sort of predict how quickly that becomes like a slippery slope, and I would rather have had fewer designers that are more polymath. So I think that's one on the organizational side.
On product, oh my god. I mean, GitHub Actions and their— I don't know, like it's very technical, but the fact that we also thought we didn't need good package management for the actions, like, I don't know. I think the world would be better off if we had thought about that slightly harder.
This is maybe like— I had started a competitor to Notion in 2014, and I didn't think of it as— in fact, it wasn't a competitor of Notion, because the week that we were going to get a term sheet from True Ventures, Notion pivoted from website building to document collaboration, and so True Ventures was like, hey, sorry, we have a conflict, and we're like, yep, no worries. And we spent so much time polishing the editing experience. We did markdown folding, all the stuff that you now have in Obsidian. Like we sort of did that back in 2014. And we thought that's the thing that really matters. And then Notion by comparison, the first version of the Notion editor was terrible. Like there was like no— it was all blocks. You couldn't even select between two blocks. But it turns out it didn't matter. And so I think that is like just working diligently on the wrong thing for way too long. Huge fail.
That's so interesting. Just coming back to your insight of when a product works, there's just this tiny core thing that is the thing that makes it amazing and what people want to come back to, no matter how bad everything else is. I think that's a really interesting takeaway.
We actually kept adding new features. At some point you go down the death spiral. So we kept adding yet another feature of like, okay, is it good now? Is it good now? And it's just, you know, nope. The core wasn't good.
That's interesting. And in your experience, can you tell pretty quickly, okay, wow, this is really taking off, we found something really powerful here?
I think you can tell. I think you could. Yeah, I think it's the obviously good thing. I think you're like, yep, this is good. And then it may be good in a way that you give it to users and every single user study that you do or whatever, like, it just falls flat and they don't know how to use it. I think the important thing is actually to not give up on the core idea. And so that's 80%, but then the 20% is like relentlessly iterate until it actually clicks with the folks that you're working for.
Max, is there anything else that you wanted to share with folks? Anything else you want to leave listeners with before we get to our very exciting lightning round?
When I talk to like young— it's so funny to say that, but like when younger people in Silicon Valley— right now I think that Silicon Valley is uncharacteristically full of people who don't actually love computers. What I mean by that is like, it's sort of like, oh, I want to make money, and of course everybody does. I like making money too. I think there is this idea of this is the last train, or like what do we call it, like the permanent underclass kind of stuff, and it is so detrimental to thinking about how you want to spend your heartbeats in life. And so, I don't know, the advice I would give is like, just don't let the rush or the frenzy sort of distract you from the things that you actually care about and are passionate about in life. I think it'll find a way.
And that is not to mean that you shouldn't work hard. I think you're actually way better off if you work incredibly hard from like 18 to 25 or whatever. Like that's the way to go. You should work a lot, right? And then later you can work a little less. But so it's more about the frenetic nature, like you're so worried that if you don't win, if you don't like take that last train out, you're going to be screwed. And it just doesn't seem right to me. And I think it seems like a very hollow way of leading life. So I would encourage people to zoom out and not think about it that way. Read history. Read computer science history.
Maybe it's easy to hear that and feel like, okay, I'll be all right. I'm just going to work on things that I'm excited about, and then like, okay, but how will I actually have a job in the future? I love the sentiment, like don't be so stressed about missing out on things and being in the permanent underclass. Is there anything there that you think is important for people to do while not being overly stressed and worried about missing that train?
I don't know if it's Chris Rock, but like there's a comedian that has this joke that is like, it's great to follow your passion, and then he has this pause, and like, if it pays. And so obviously there is a little bit to that. I'm not suggesting that you don't worry about this at all. I think it's more that you just tune down the amplitude of how much worry there is, and then just sort of realize that history repeats itself more so than it is completely novel and new. And then of course, yeah, if you tie it to agency, and if you're not so stuck in "oh, I need certainty of how the world is going to unfold," you're probably going to be fine.
And in the extreme, this is the other side of things, which is often if I then talk to people who are like, yeah, but you know, everything's going to change, like, okay, great. So, how is a move that you are going to make
really going to shield you from it? And do you want to live in a society where all of this, like, I don't know, it just seems so insular, that mindset.
With that, we have reached our very exciting lightning round. I've got five questions for you. Are you ready?
Sure.
What are two or three books that you find yourself recommending most to other people?
It depends on the person. I would say Code by Charles Petzold, which is The Hidden Language of Computer Hardware and Software. It's basically, do you know how computers actually work? It is actually surprising to me how many professionally employed programmers don't know how computers work. The funny thing is it does not have a line of code in it until like chapter 27. So, exceptionally good book.
I have a weird one, which is Tools for Conviviality by Ivan Illich. It's sort of the contrast between, you look at the history of technology and tools that let users exercise human ingenuity and autonomy versus tools that are more at industrial scale that almost have become destructive to human autonomy.
And then the last one that I give mostly to executives that I think are creating a lot of systems is Seeing Like a State, which I think there is a famous Slate Star Codex post that sort of popularized this, but it's the idea of: are you actually just designing a system so that you have legibility, but the way that you've created that legibility completely neglects the reality of the system on the ground? And so I think of it as, great, you're the executive and you have these status reports and you think you know exactly how your teams work. If you actually spend time with the teams, you would realize that none of that is actually true. And so I think executives love creating fake legibility for themselves because we don't like noise as humans, right? We want the signal, but there's often less signal in it than one might think.
Favorite recent movie or TV show that you have recently enjoyed?
I have purposefully terrible taste in movies, which is I want to watch movies that I never think about again after watching them. I just want to be entertained, and I mostly just want to see things that I couldn't remotely experience in real life. So you should not ask me for movie recommendations.
I did like Project Hail Mary a lot. I liked the book and I think the adaptation was really good. I think it also makes me super excited about any kind of future of humanity, which is, I sometimes joke to our teams internally, like, okay, if we're really, really good, at some point Notion OS will be the thing that empowers like five to eight people to explore the galaxy somehow, and everything will be organized for them in Notion. I don't know, I like this idea of sort of pushing into space.
TV show, I'm late to this: The Handmaid's Tale. If you replace the concept of God with AI in that TV show, and then you don't actually have to squint that far to replace the Eyes with ICE in that TV show right now, it becomes a very, I don't know, heavy show to watch, in a good way.
Wow. I had not thought about that. "Under his eye." Was that one of the things? Yeah.
Under his AI.
Whoa. Oh, no. Okay. I'm afraid, I used to watch it. I'm more afraid to watch it now. Okay. Favorite product you've recently discovered that you really love. I know you put together a list of beautiful products that people buy. What's something recent?
Well, that list that I put together was for products that I think people should buy, or that I thought, I actually did the taste emulation. I'm like, "Oh, I think a lot of people are going to find this useful." I have weird ones now for you, which is...
Yes.
Okay, so this is not a... you can just, it's a product, it's great. It's the Ghostty terminal emulator. Most people use terrible terminals. Don't do that to yourself. Just use Ghostty. Huge fan of the work that Mitchell is doing. And then there is a new one for the phone called Moshi, M-O-S-H-I. That one's not free, but it looks very well done. I'm currently exploring it. I mostly code on the phone now because I don't have a real job.
There is an open source keyboard called, I don't even know how to say it, Corne, C-O-R-N-E, which is a split keyboard. It looks very weird. The reason I like that one is I'm trying to claw back as much agency in my compute life as possible. This one is very open source. If you really wanted to, you could download all the schematics, send them off to China, and you have the PCB back and you can just build it from scratch.
And then this one's silly, but I like tools. I like physical tools. A Civivi pocket knife, which is pretty high quality, maybe more expensive than what most people would spend on a pocket knife, but I think a good pocket knife is a good tool to have.
These are awesome. Very, very legit products. Okay, we'll link to them all. Two more questions. Do you have a favorite life motto that you find yourself coming back to in work or in life?
It is very hard to remind yourself of that day-to-day, but I try to. The universe is change and life is what you make it. I think we love to cling to certainty, and there is no certainty, you know. I could walk out of this room and it could be the end of my life, and, like, live in the moment kind of thing. And "life is what you make it," I think it's a Marcus Aurelius quote, I believe.
And then, do you really want to know how it's going to end? Like, no spoilers, just, you know, enjoy the ride.
Final question. You speak German. Do you have a favorite German word?
I do. Tüfteln, which is like tinker, but to me it sounds like it has a less... tinker can sometimes be a little bit derogatory, and I think with the German equivalent it's just not that harsh. And then the other one is Verbraucher, which is the word for user, but it puts so much more emphasis on using up. As in, if you think about user, it's like you're using it, but using it up, like you've... And so then you think a lot more about the impermanence slash the wastefulness of products that you might build if you use that word.
I love it. I love that you had quick answers to this question. Max, this was amazing. Thank you so much for doing this. Two final questions. Where can folks find you online if they want to ping you about anything? And how can listeners be useful to you?
I am unfortunately on X or Twitter. I would like to be less addicted to that thing. max.dev. I don't even know if I linked to X, but I'll put it on there for your listeners.
How can listeners be helpful to me? Go for a walk in whatever city you're in, or forest, wherever you want to go. Actually, no, it's better if it's man-made, or human-made. And just carefully look at how everything around you is made up by people that are no smarter than you, and realize that probably in the span of 6 to 9 months, you can, for most things around you, figure out how to make it from scratch. And therefore, you have much more agency than you think. And so just exercise that.
What a beautiful way to end it. Max, thank you so much for being here.
Thank you for having me.
Hi, everyone. Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving a review, as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at lennyspodcast.com. See you in the next episode.
Article published · Updated