Discover why cultivating agency beats building skills in AI-driven product development. Max Schoening shares insights on designing better software and buildi...
Why Agency Matters More Than Skills in the AI Era: The Ultimate Guide to Building Products in 2024
Core Takeaways
- Agency beats skills: In the AI era, the ability to take initiative and shape outcomes matters far more than technical expertise alone
- The first 10% is free: AI tools have dramatically reduced the cost of exploring initial product concepts and prototypes
- One tiny superpower wins: Great products succeed by perfecting a single core feature extraordinarily well, not by adding endless features
- Malleable software is the future: Products should empower users to customize and adapt them to their needs, creating deeper engagement
- Taste is trainable: Like machine learning models, developing good product taste requires continuous iteration, feedback, and deliberate practice
Understanding Agency in Product Development
The concept of agency—your ability to recognize that the world around you is malleable and that you can actively shape it—represents the most crucial skill for modern product leaders. Max Schoening, Head of Product at Notion and a veteran of Google, GitHub, and Heroku, argues that this distinction has never been more important than it is today.
For decades, people have used skill gaps as excuses. "I can't do this because I lack expertise in X," has been the comfortable refrain. But here's what's changing: as AI tools like Claude and ChatGPT put advanced capabilities at your fingertips, the limiting factor is no longer skill availability. You can access any skill you need within seconds. The real differentiator is whether you believe you can change things, whether you're willing to try, and whether you possess the audacity to "drive Notion like it's stolen."
This realization hits differently when you understand it fundamentally. One day you wake up and realize the world is built by people no smarter than you. This awakening is transformative. It dissolves the mystique around product development, design, engineering, and building things. If ordinary people created the products and systems you admire, then you—with modern AI tools—can absolutely participate in creation too.
The challenge is that agency isn't evenly distributed. Some people inherently understand they can change things. They experiment, iterate, and ship. Others stay trapped in prescribed roles, asking "What does it mean to be a PM?" or "What's my job as a designer?" rather than asking "What needs to be built, and can I build it?" The shift from the second mindset to the first is the real leverage point in the AI era.
How AI is Transforming Product Teams and Workflows
The transformation happening in product teams isn't primarily about individual contributors suddenly becoming 10x more productive, though that's part of it. Instead, it's about role dissolution and the emergence of what Schoening calls "malleable roles"—positions that aren't constrained by traditional job descriptions.
At Notion, this manifested in an unexpected way. When the team started building AI chat interfaces for the product, they realized something critical: you can't design AI experiences purely through static mockups in Figma. You need to feel the AI, understand its latency, experience how it responds. This led to what they called "the worst possible playground"—a small, LLM-friendly codebase that made it easy for designers and product managers to prototype directly in code.
The genius of this approach wasn't forcing non-engineers to become engineers. Rather, it was lowering the barrier to thinking in the medium of the final product. When designers prototype in code rather than Figma, they're forced to consider the actual constraints, possibilities, and behaviors of their design. They understand agent loops, state management, and the real technical implications of their ideas. This understanding doesn't come from reading documentation; it comes from building.
As model capabilities improve, something remarkable happens: the same designers and PMs who started in the playground begin contributing to the production codebase. Not because they became "real engineers," but because they developed genuine understanding of the material they're working with. This isn't about democratizing code; it's about democratizing the ability to think clearly about complex systems.
The practical impact has been dramatic. The first version of any project is essentially free now. What previously required extensive specification documents, stakeholder alignment meetings, and weeks of planning can now be explored in hours. You can spin up multiple versions of an idea, get feedback, and iterate. The traditional waterfall approach—design, build, ship—has been replaced by rapid experimentation.
Yet Schoening harbors an important caution: "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." This observation cuts to the heart of a critical distinction: shipping more code faster doesn't automatically mean building better products. The tools have made ideation and prototyping nearly free, but the hard work of refining, testing, and engineering for reliability remains unchanged.
The Economics of Product Development Have Fundamentally Shifted
Understanding how AI has changed the economics of product work is essential. The "first 10% is free" concept that Schoening emphasizes refers to the exploration phase of any project. What used to require detailed product requirements documents (PRDs), extensive research, and weeks of planning can now be validated through rapid prototypes.
Consider the traditional product development workflow: You'd write a PRD, circulate it for feedback, revise it, get stakeholder buy-in, then brief the engineering team. This process could take weeks. Now? You can build a janky but functional version in hours. Instead of debating what the product should do based on written specifications, teams can react to an actual working prototype. The question shifts from "Does this make sense?" to "How does this feel?"
This democratization of building extends to startups. The barrier to entry for founding a company has collapsed. What once required substantial capital, a founding team with deep expertise, and months of preparation can now be accomplished by one person with basic product sense and access to AI tools. You can build the first version 0.8 of nearly any software product in a weekend. The limiting factors become taste, distribution, and market timing—not technical execution.
However, this abundance creates new problems. The easier it becomes to build, the more important becomes the ability to say "no." Every feature is now possible; the constraint is deciding which features matter. This is where the concept of "obviously good" becomes critical—the idea that truly great products do one thing so well that everything else flows naturally from it.
Taste: The New Competitive Advantage in AI-Driven Product Development
As AI handles more of the execution, taste becomes the scarce resource. In Schoening's elegant formulation, taste 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."
This is trainable. It's not some innate quality that only certain lucky individuals possess. Like training a machine learning model, developing taste requires repeated iteration with feedback. You propose something, get feedback, understand why it worked or didn't, and refine your mental model. Do this hundreds of times, and you develop genuine taste in your domain.
The parallel to model training is instructive. Models improve through exposure to examples, feedback signals, and iterative refinement. Humans develop taste the same way. A Japanese ceramicist doesn't become excellent by reading about pottery; they become excellent by throwing hundreds of bowls, getting feedback from mentors and audiences, and iteratively improving. The same principle applies to product taste.
Schoening observes that designers and PMs with the best taste typically share two characteristics: they maintain side projects where they own the complete experience end-to-end, and they constantly tinker with new tools and applications. They're the "annoying person" who says, "What if we tried this?" dozens of times. This exposure to different solutions, different approaches, and different design decisions builds pattern recognition.
The environment matters too. At Notion, conference rooms are named after famous designed objects: the first typewriter, the Macintosh, a Porsche 911. When you sit in a room and pay attention to these objects, you're reminded that nothing you're currently building compares to the craftsmanship and thought that went into them. This creates productive dissatisfaction—a drive to do better.
Why the "SaaS Apocalypse" Predictions Are Greatly Exaggerated
There's a persistent narrative that AI will make SaaS obsolete—that companies will simply build their own Notion, their own Salesforce, their own specialized tools rather than pay subscription fees. Schoening calls this narrative greatly exaggerated, and his reasoning reveals important truths about software economics.
The issue is that people conflate "possible" with "desirable." Yes, you could theoretically rebuild Notion. You could invest months of engineering time, build your infrastructure, manage your databases, handle your security, stay current with evolving standards, and maintain everything forever. The question is: why would you?
Software is like a garden—it requires constant tending. You pay for SaaS not primarily for the initial features but for the ongoing maintenance, the specialist thinking about your problem, the security updates, the performance optimizations, and the continuous evolution. Schoening uses a telling metaphor: people don't want to go hunting; they want to go to Costco and have the steak in styrofoam packaging, never thinking about the animal.
What will change is the character of SaaS. Tools will become more general-purpose—like the spreadsheets, word processors, and FileMaker databases of the 1990s—but they'll still exist as services. The reason Notion AI has been transformative is partly because Notion is relatively general-purpose; it works for nearly any information organization problem. As these general-purpose tools become more malleable and more intelligent, the specialized single-purpose SaaS tools will face pressure. But the "as a service" part—the ongoing maintenance and evolution—won't disappear.
Consider Slack. It's not a product most companies would reasonably rebuild internally. Yet when you talk to companies like Anthropic, Slack is their operating system. Everything runs through it. The same applies to Notion, Figma, GitHub, and other platform-like tools. The friction of rebuilding these systems internally vastly exceeds the friction of paying for them.
This insight has profound implications: the future isn't SaaS death; it's the commoditization of specialized tools and the rise of more malleable, general-purpose platforms that become increasingly integral to how work happens.
Malleable Software: Empowering Users to Shape Their Tools
The concept of malleable software—tools that users can adapt, customize, and modify to their specific needs—represents a fundamental shift in how we should think about product design. This philosophy contrasts sharply with the modern app ecosystem, where users are passive consumers of fixed interfaces designed by corporations.
Imagine your home. If you couldn't rearrange furniture or reconfigure rooms without the architect's permission, it would feel absurd. Yet this is exactly how most software works today. Applications come with rigidly bound functionality, data structures, and interfaces. A user who finds an app 90% perfect but wants to make minor customizations faces an impossible task.
True malleable software requires a different architectural approach. It needs an underlying platform—like an operating system or a foundational tool—that inherently encourages customization. Open-source options like Linux offer malleability, but at the cost of requiring users to invest significant time learning and building. The ideal is a system that's both accessible to non-technical users and infinitely customizable for those inclined to customize.
Notion represents an attempt at this ideal. Blocks, slash commands, and templates give users significant flexibility. The new Notion AI agent extends this by allowing users to describe what they want and have the system figure out the implementation. But Schoening is honest about the current state: "I like Notion, and I consider Notion to be fairly malleable, not enough. I think it should become more malleable."
This philosophy extends beyond software ergonomics. It's about acknowledging that tools are made by humans and therefore can be changed. It's about recognizing that the best tools aren't museum pieces; they're everyday implements that evolve with their users. The design philosophy of Dieter Rams—emphasizing that good design is useful first, beautiful second—aligns perfectly with malleable software thinking. The goal isn't to create perfectly designed products that never change; it's to create products that users feel empowered to shape.
This empowerment creates ownership. When you can modify your tools, you develop a relationship with them different from passive consumption. You notice possibilities, tinker with configurations, and gradually deepen your understanding of what the tool can do. This is the opposite of the modern app experience, where users are expected to accept the designer's decisions as immutable.
The Core Insight: One Tiny Superpower Makes Great Products
After analyzing countless products across his career, Schoening has identified a pattern that separates great products from merely good ones: "All the great products have something tiny that is a superpower, one tiny core that is so exceptionally good."
This principle cuts against the modern tendency to add features constantly. It's a common trap: if the product isn't perfect yet, surely one more feature will tip it over the edge. This logic never works. Instead, great products obsess over one thing and make it so good that everything else flows naturally from it.
Examples abound. The iPhone's multi-touch interface wasn't just a feature; it was a superpower that made every other feature better. GitHub's pull request mechanism wasn't a feature; it was a new way of thinking about code collaboration that enabled countless innovations. Notion's blocks and slash commands—simple concepts that enable infinite composition. Figma's seamless blend of real-time collaboration and individual work. Heroku's git push heroku master command—taking the complexity of deployment and reducing it to a single, intoxicating line.
The pattern holds across different domains. Dropbox's icon in the menu bar was so elegant at syncing files that users could even use it to check their internet connection better than their operating system could. Snapchat's disappearing photo concept was so right for the moment and the use case that it defined an entire category.
Notice what these examples share: they're not about having the most features, the most sophisticated technology, or the most money behind them. They're about identifying something essential—something users actually need and will use repeatedly—and perfecting it to an almost embarrassing degree.
This creates a crucial insight for product leaders: the biggest pitfall is the "one more feature" trap. The temptation is always to add. But this is precisely backwards. The question should be: what's the one thing we're going to make absolutely perfect? Everything else should serve that core.
For Notion AI, this super power is context-aware assistance within a connected workspace. The agent understands relationships between documents, permissions, and data structures in ways other AI products don't. This capability flows from Notion's foundational architecture; it's not a feature bolted on top.
Building Products with "Obviously Good" as the Standard
At Notion, Schoening and his team use an internal standard called "obviously good." The definition is intentionally vague: "You know it when you see it." But the examples are crystal clear. Nobody had to argue about whether the first iPhone was obviously good. Nobody debated whether ChatGPT was obviously good. These products had a quality that transcended specification sheets and feature lists.
The trap many companies fall into is isolation. They work in secret until they have something "perfect," then launch it with great fanfare. The problem is that perfection is defined in a vacuum. A better approach is what Schoening calls "incremental correctness"—the ability to iterate rapidly, gather feedback continuously, and refine based on reality rather than assumption.
This requires overcoming the fear of shipping something imperfect. Notion deals with this by running multiple approaches simultaneously and then consolidating. The team has six different automation primitives currently in the product (combining traditional automation, buttons, database formulas, and various agent capabilities). This seems redundant, and it is—until you consolidate them all into a single, elegant core that captures the best thinking from each evolutionary branch.
The real work of product leadership happens in that consolidation phase. Any product team can ship features. The challenge is stepping back and asking: "What's the atomic truth here? What's the simplest possible expression of this capability?" Then you have to be willing to delay the next feature to get that consolidation right.
This explains why software quality has become harder to maintain even as development velocity has increased. Shipping fast is easy. Shipping fast while maintaining clean architecture and conceptual integrity is hard. It requires discipline, taste, and a willingness to say no.
How Product Work Has Changed in the Age of AI
The transformation of product work isn't about everything becoming easier. Rather, different parts of the work have been completely restructured. The exploration phase—the first 10% where you're figuring out what to build—has become nearly free. The last 10%, which is the hard work of refinement, quality, and shipping something people genuinely want to use repeatedly, remains as hard as ever.
Two years ago, Schoening's job looked different. Product managers would write detailed requirements documents. Designers would iterate extensively in Figma. Engineers would build based on those specifications. The process was sequential, with handoffs between disciplines.
Now, the emphasis has shifted dramatically to "demos, not memos." If you're going to write a PRD, just write the changelog—the thing users would see and read. Or better yet, build a working prototype that people can interact with. This immediately surfaces questions and possibilities that no amount of written specification could capture.
For designers, the shift is profound. They're no longer creating static mockups; they're thinking in code, understanding how their interfaces behave under different conditions, experiencing the latency and responsiveness of their designs. This forced engagement with the actual medium of implementation eliminates vast categories of design mistakes.
For product managers, the job has shifted toward judgment and prioritization. The cost of exploring multiple directions has plummeted. You can send off ten different prototypes exploring ten different solutions, then converge on the best direction. This increases the "shots on goal"—the number of bets you're making. With more bets, better outcomes emerge naturally.
Yet this raises a new problem: knowing when to stop. The abundance of possibility creates decision fatigue. Every direction is feasible; choosing between them requires taste and judgment. This is why the "obviously good" standard becomes so important. You're not asking "Is this possible?" You're asking "Is this obviously good?" Is this something people will immediately recognize as valuable?
The Future: Inference Speed and the Modality Question
As AI models become more capable, an interesting technical question will reshape how we work: Will inference speed matter more than raw intelligence?
Currently, if you ask an AI tool to do something and it takes 30 seconds to respond, you often walk away, think about other things, then come back to review. This context-switching is the reality of working with slower models. But what happens when responses come back in milliseconds?
Schoening hypothesizes that if inference becomes nearly instant, the nature of the interaction changes fundamentally. Instead of batch processing—queuing up tasks and reviewing them later—you'd return to direct manipulation. You'd be molding the clay directly, getting instant feedback, iterating on the fly. It would feel more like playing a musical instrument than submitting a job to a server.
This raises a deeper question: Is there a saturation point for intelligence? Schoening uses the Retina display as an analogy. Once the pixel density becomes fine enough that humans can't perceive individual pixels, making them even finer provides no additional benefit. You don't need smaller pixels; you might want a different modality or faster response time instead.
Similarly, for many knowledge work tasks, there may be a "good enough" ceiling of intelligence. Once a model reaches that threshold, additional raw capability provides diminishing returns. What matters instead is the UX, the speed, the cost, the ability to run locally, and the modality of interaction.
This reframes the competition among AI labs. The assumption that companies will always want the smartest, frontier model may be incorrect for most use cases. For cancer research or financial modeling, yes. For writing an email or generating a SQL query? Maybe a smaller, cheaper, locally-run model that's 95% as capable is sufficient—and vastly preferable due to speed and privacy.
This insight explains Schoening's skepticism about token spend as a metric for productivity. When Meta created a leaderboard of who was spending the most tokens, it faced criticism for gaming the metric. But the underlying point—getting people to identify their work and enlist agents—is valuable even if the metric itself is flawed.
Agency: The Advice for Developing It
If agency is the most important skill in the AI era, how do you develop it? Schoening's advice is both simple and profound: make things. Continuously.
The realization that changes everything comes from direct experience. You build a chair, and you realize it's not that hard. You tweak a recipe, and you realize that cooking is just informed experimentation. You try to build a simple feature, and you realize that shipping is about decision-making more than coding. Making things—any things—builds this foundational understanding that creation is within reach.
The challenge is that making things feels risky. What if you fail? What if people judge your work? What if you're not talented enough? This is where Schoening's Steve Jobs quote becomes essential: "One day you wake up and you realize the world is made up by people no smarter than you." This realization is transformative. It dissolves the mystique. If those people made those things, why can't you?
For people working in large organizations, the question becomes: How do you exercise agency within constraints? How do you recognize that you don't have to accept the prescribed role? A designer doesn't have to wait for engineers to build their ideas; they can prototype themselves. A product manager doesn't have to wait for a design team; they can think through the experience in code. A marketer doesn't have to wait for engineering resources; they can build custom analytics using AI tools.
This requires audacity and a willingness to be slightly annoying. It requires asking "What if we did it this way?" dozens of times. It requires tinkering with new tools and approaches. It requires maintaining side projects where you own the complete experience. It requires reading history and recognizing that many people who built important things weren't obviously the "smartest" in the room; they were simply willing to try.
The Notion AI Agent: Why It Worked
The Notion AI agent represents a case study in product execution during the AI era. Unlike many AI features that feel bolted-on or gimmicky, the Notion agent feels native—like it was always meant to be part of the product.
Part of this success stems from timing. Notion had spent years building a connected workspace where documents relate to each other, permissions flow through hierarchies, and information is structured but flexible. When you add an agent to this architecture, the agent understands context that isolated AI tools never could. It knows your document relationships, your team structure, your custom properties and schemas. It can reason about your workspace in ways that generic AI can't.
Another part is architectural. Schoening describes Notion as "an operating system more so" than a traditional SaaS application. This framing is important. Operating systems provide a stable foundation on which other things are built. They enforce certain patterns and standards while allowing flexibility within those bounds. When you add agent capabilities to an operating system, the agent inherits that architecture's strengths.
The team also had important intuitions early. Before ChatGPT launched, Notion had already experimented with AI assistance. When GPT-4 became available, the team wasn't starting from scratch; they understood the possibilities and constraints from direct experience. They had a playground for rapid experimentation, a team comfortable with code-based prototyping, and a product that naturally lent itself to AI augmentation.
But Schoening is appropriately humble about this: "I would like it to be even better. I'm like my sort of own worst critic, I guess. I've spent most of my day thinking about where it falls short, not how great it is." This perfectionism, this unwillingness to accept the current version as final, is characteristic of leaders who build great products. They see the gap between what is and what could be, and that gap drives them.
Practical Wisdom: Building for Quality While Shipping Fast
The tension between shipping fast and shipping well isn't new, but AI has made it more acute. Tools make it easy to ship code. What's hard is shipping code that's reliable, that users trust, that doesn't regress with each update.
Schoening's internal standard at Notion is "obviously good," but he acknowledges this is vague. How do you operationalize this in practice? Part of it is discipline. At Notion, they've chosen to sacrifice some shipping velocity to consolidate primitives. They have multiple ways of automating workflows; the work ahead is unifying them into something conceptually simple.
Another part is cultural. Designers who truly understand agent loops are more valuable than designers who can write perfect CSS. Engineers who think about the full experience are more valuable than engineers who optimize for local code quality. Product managers who can prototype ideas are more valuable than PMs who write perfect specifications. You're selecting for people who understand the whole system, not people who optimize locally.
For code review, Schoening makes an important distinction: code shouldn't need human review because humans are better at reviewing than at writing. Code needs review because it's error-prone, and the review should catch those errors. The goal should be architecture and patterns that reduce the need for review, not multiplication of the review process.
This gets at a deeper truth: as AI handles more code generation, the value of engineers shifts toward architectural thinking, system design, and quality standards. The grunt work of writing correct syntax-compliant code is increasingly automated. The human value is in recognizing when a design is wrong, when patterns conflict, when shortcuts will haunt you later.
The Speculation That Can't Be Escaped: Universal Basic Income Already Exists
Schoening's hottest take might be his argument that we already have Universal Basic Income, and it's called knowledge work. This isn't a rhetorical flourish; it's a serious observation about modern economics.
Consider what humans actually need to live: shelter, food, basic healthcare, maybe some entertainment. For much of human history, obtaining these required constant effort. Now, in developed economies, knowledge work—sitting in front of a computer, writing documents, attending meetings, building software—provides far more income than is necessary for basic survival.
The system has become elaborate. We've created hierarchies of jobs, distinctions between roles, and complex incentive structures. But underneath all that, knowledge work is a form of UBI. You exchange 40 hours a week for far more money than you need to live on. The employer gets value from your work; you get value far exceeding your basic needs.
This realization is liberating if you let it be. You don't have to be anxious about joining the last train or missing the next big thing. You could probably be fine with much less income than you currently make. This doesn't mean you shouldn't work hard or be ambitious; it means you can be ambitious about things you actually care about rather than things that feel like desperate necessity.
The corollary is uncomfortable for some: if you have this level of economic security (and if you're reading this, you likely do), why spend your limited heartbeats doing things you don't find meaningful? This isn't an argument for immediate resignation. It's an argument for calibrating your anxiety to reality rather than to FOMO.
Closing Reflections: Living with Uncertainty and Building Agency
Schoening closes with philosophical advice that cuts against the frenetic culture of Silicon Valley: zoom out. Read history. Realize that the world changes constantly, and building great things isn't about catching the exact right wave; it's about having skills and judgment that remain valuable across many waves.
His favorite life motto is: "The universe is change and life is what you make it." This sounds like fortune cookie wisdom until you truly internalize it. Humans crave certainty and predictability, but neither is guaranteed. You could walk out of a room and that could be the end of your life. Given this reality, optimizing for security and status seems backwards. Better to spend your time on things you find genuinely interesting, in service of people you respect, working toward futures you believe in.
The German word "Tüftler"—tinkerer—captures this spirit. It implies someone who experiments, tinkers, and improvises. Similarly, "Verbraucher" (consumer) literally emphasizes using-up, reminding us of the impermanence of what we build. This perspective—that we're creating things that will be used and eventually discarded, so they should be genuinely good—is grounding.
For people worried about the future, Schoening's advice is practical: observe how everything around you was built by humans no smarter than you. Walk through your city, your neighborhood, your workspace. Notice the buildings, the systems, the tools. Recognize that people decided to build these things, faced constraints and uncertainty just like you do, and built them anyway. Within six to nine months of focused effort, you could probably understand how to build most of what surrounds you.
This recognition is the seed of agency. And agency, as he's argued throughout, is the differentiator that matters in the AI era and beyond.
Conclusion
The shift from a skills-based to an agency-based world represents a fundamental reorientation of what matters in building products and creating value. Max Schoening's insights—that the first 10% of every project is now free, that one tiny core makes great products, that taste is trainable, that malleable software empowers users, and that agency can be developed—provide a framework for navigating the AI era.
The most actionable insight is perhaps the simplest: make things. Build small projects. Get feedback. Iterate. Notice what works. This continuous practice of creation, more than any theoretical knowledge, develops the judgment and intuition that separate leaders who build great products from those who don't.
As AI continues to change how we work, the companies and leaders who succeed won't be those with the most sophisticated AI tools. They'll be those with the deepest understanding of what users need, the taste to recognize when something is right, and the agency to keep refining until it's obviously good. Everything else—the tools, the technology, the features—will follow naturally.
Original source: Why cultivating agency matters more than cultivating skills in the AI era | Max Schoening (Notion)
powered by osmu.app