Visual summary of operating lessons from Mike Krieger.

Lessons from Mike Krieger

Mike Krieger scaled Instagram to a billion users and launched the news reader Artifact before becoming Anthropic's Chief Product Officer. These lessons track his evolution from relying on strict engineering constraints in the early mobile era to building Claude in the bottom-up, model-driven reality of modern AI.

Part 1: The Early Instagram Constraints

  1. On doing the simple thing first: "When faced with scaling challenges, we always asked what the absolute simplest thing was that could possibly work, and we did that first." — Source: [YC Startup School]
  2. On server limits: "In the early days, our database was running on a single machine. The constraint wasn't our ambition, it was simply keeping the servers from catching fire." — Source: [First Round Review]
  3. On early user feedback: "We watched how people used the app in the wild. If they struggled to upload a photo for even a few seconds, we knew we had to rewrite the network stack." — Source: [Lenny's Podcast]
  4. On feature parity: "We delayed building an Android app for a long time. It wasn't because we hated Android, but because we couldn't maintain the exact same quality standard on a second platform with two engineers." — Source: [The Verge]
  5. On the value of launch day: "Launch day is a starting line. The initial version of Instagram didn't have hashtags or comments, it only had likes and follows." — Source: [TechCrunch]
  6. On choosing technology: "We picked Postgres and Redis because we understood exactly how they broke under pressure." — Source: [High Scalability]
  7. On surviving outages: "Every time we went down, we wrote a post-mortem. We didn't blame the engineer who broke it, we blamed the system that allowed it to break." — Source: [Instagram Engineering Blog]
  8. On the first hundred users: "Kevin and I personally reached out to the first users, asking them what they liked. We treated them like co-designers, never mere consumers." — Source: [NPR How I Built This]
  9. On visual hierarchy: "The photo had to be the absolute center of the screen. Any UI that detracted from the image was immediately cut during the design phase." — Source: [Fast Company]
  10. On mobile network latency: "We designed the app to upload the photo the second you selected it, even while you were adding a caption, to trick the brain into thinking the network was faster than it actually was." — Source: [The Atlantic]

Part 2: Scaling to a Billion Users

  1. On hiring engineers: "We didn't look for people who knew our exact stack. We looked for people who had debugged incredibly difficult, ambiguous systems before." — Source: [First Round Review]
  2. On the pressure of growth: "Scaling is like rebuilding a car's engine while driving it down the highway. You can't stop the car, but you absolutely have to swap the parts." — Source: [YC Startup School]
  3. On database sharding: "We delayed sharding our database for as long as humanly possible, because once you introduce that complexity, development velocity permanently drops." — Source: [High Scalability]
  4. On caching: "Memcached saved us on multiple occasions. If you can serve a stale read that is still accurate enough for the user experience, you do it." — Source: [Instagram Engineering Blog]
  5. On dealing with spam: "As soon as we hit a certain scale, spam became our biggest existential threat. We had to shift from building features to building defense mechanisms." — Source: [Lenny's Podcast]
  6. On integrating with Facebook: "After the acquisition, the hardest part was deciding which of their internal tools to adopt and which of our own to keep. We kept our core stack for years to preserve our speed." — Source: [Wired]
  7. On rewriting code: "Never rewrite a system from scratch unless the current system is fundamentally preventing you from operating. Incremental refactoring is almost always better." — Source: [Software Engineering Daily]
  8. On global latency: "We realized users in Brazil were experiencing terrible load times. We couldn't optimize the app anymore, we had to rethink our CDN strategy entirely." — Source: [The Verge]
  9. On the explore tab: "Building a discovery engine meant moving from chronological data fetching to complex ranking. It required an entirely different engineering mindset." — Source: [TechCrunch]
  10. On maintaining culture: "When we grew past 50 people, we could no longer rely on everyone knowing what to do by osmosis. We had to write down the engineering principles that were previously assumed." — Source: [Fast Company]

Part 3: Simplicity in Product Design

  1. On editing features: "Product management is mostly about saying no. For every feature we shipped, there were ten we prototyped and threw away." — Source: [Lenny's Podcast]
  2. On the three-tap rule: "We wanted users to be able to open the app, take a photo, and post it in exactly three taps. Any more friction than that would kill engagement." — Source: [The Atlantic]
  3. On copying competitors: "When we launched Stories, we didn't hide that the format came from Snapchat. We focused on making it fit natively into the Instagram ecosystem." — Source: [TechCrunch]
  4. On user onboarding: "The empty state of an app is the most critical screen. If a user sees a blank feed and doesn't know who to follow, they will never return." — Source: [First Round Review]
  5. On visual constraints: "Forcing photos into a square ratio wasn't a philosophical statement at first, it was a UI constraint that made the feed look uniform on early, low-resolution iPhone screens." — Source: [NPR How I Built This]
  6. On icon design: "We agonized over the camera icon. It had to clearly communicate 'this is a camera app' while feeling like a physical object you wanted to touch." — Source: [Wired]
  7. On feature bloat: "Every new button you add cuts the usage of the existing buttons. You have to treat screen real estate like the most expensive property in the world." — Source: [Lenny's Podcast]
  8. On animation: "Animations shouldn't be decorative, they need to explain the spatial model of the app. A menu sliding in from the left tells the user where it lives." — Source: [Fast Company]
  9. On algorithmic feeds: "Moving away from chronological sorting was painful, but users were missing the best content. We optimized for connection over strict recency." — Source: [The Verge]
  10. On direct messaging: "We resisted messaging for a long time because we wanted to be a broadcast platform. We only built it when we saw users hacking the comments section to talk privately." — Source: [TechCrunch]

Part 4: Artifact and AI Personalization

  1. On leaving retirement: "I didn't want to start another company unless I felt a genuine curiosity about a new technology. Large language models provided that exact spark." — Source: [The Verge]
  2. On the premise of Artifact: "We wanted to build a text-first network where the algorithm understood the semantic meaning of the article, rather than strictly looking at engagement metrics." — Source: [Platformer]
  3. On cold starts in AI: "With Artifact, we learned that asking users to select topics during onboarding is useless. People don't actually know what they want to read until you show it to them." — Source: [Lenny's Podcast]
  4. On clickbait defense: "We used AI to automatically rewrite clickbait headlines into neutral summaries. It was an attempt to realign the incentives of news consumption." — Source: [TechCrunch]
  5. On summarizing content: "The value of AI lies in compressing long, noisy information into high-signal summaries for the user." — Source: [Wired]
  6. On social vs algorithmic distribution: "At Artifact, we realized that the social graph is no longer necessary for discovery. A good model can predict your interests better than your friends can." — Source: [Stratechery]
  7. On market realities: "You can build the best technology in the world, but if the market category itself is contracting, you will hit a ceiling." — Source: [Observer]
  8. On shutting down Artifact: "We looked at the data and realized the market opportunity simply wasn't large enough to justify the venture scale we were accustomed to." — Source: [TechCrunch]
  9. On selling to Yahoo: "The acquisition allowed the core recommendation engine we spent years building to reach millions of users, even if the standalone app didn't survive." — Source: [Fast Company]
  10. On the lesson of scaffolding: "Artifact taught me that the raw model isn't the product. The UI, the speed, and the specific workflow you build around the model are what retain users." — Source: [Lenny's Podcast]

Part 5: The Shift to Generative AI at Anthropic

  1. On joining Anthropic: "I joined Anthropic because I realized the frontier models were going to be the platform upon which the next decade of software is built." — Source: [Anthropic Blog]
  2. On bottom-up product development: "In traditional software, product is planned top-down. In AI, you invert it. You vibe with the model to see what it can do before writing a spec." — Source: [20VC]
  3. On the origin of Artifacts in Claude: "The Artifacts feature wasn't a top-down mandate. A designer and an engineer were playing with the model, realized it was great at writing code, and built a UI to render it." — Source: [Lenny's Podcast]
  4. On model capabilities: "You discover a model's true capabilities months after it finishes training. The product team's job is to excavate those capabilities and build interfaces for them." — Source: [The Verge]
  5. On AI as a thought partner: "I use Claude for product strategy. It has crossed the threshold from summarizing my thoughts to offering genuinely novel angles I hadn't considered." — Source: [Lenny's Podcast]
  6. On safety and alignment: "Building a helpful model and a harmless model are parallel goals. The same steering mechanisms that make a model safe also make it follow complex instructions reliably." — Source: [Anthropic Blog]
  7. On the interface layer: "The chat box is a starting point. The future of AI interaction is multimodal and deeply integrated into the specific surfaces where people already work." — Source: [TechCrunch]
  8. On enterprise adoption: "Companies don't want a generic chatbot. They want a model that understands their specific codebase, internal documents, and tone." — Source: [Wired]
  9. On the Model Context Protocol (MCP): "MCP solves the integration bottleneck. Instead of building custom connectors for every tool, we need an open standard so models can securely read external data." — Source: [Developer Content from Anthropic]

Part 6: The AI Engineering Paradigm

  1. On AI writing code: "For some of our internal products at Anthropic, 90 to 95 percent of the code is generated by Claude. The workflow has completely changed." — Source: [Lenny's Podcast]
  2. On the new bottleneck: "The bottleneck is no longer writing the code. The delay rests entirely in decision-making and alignment across the team." — Source: [20VC]
  3. On the cost of meetings: "When code takes hours instead of weeks to write, an alignment meeting that delays a decision by a day becomes vastly more expensive." — Source: [Lenny's Podcast]
  4. On vibe coding: "The most productive engineers right now are engaging in vibe coding. They iterate rapidly based on the feel of the model's output rather than sticking to a rigid architecture." — Source: [20VC]
  5. On the shift to reviewing: "In a few years, software engineers will spend the majority of their time delegating tasks to models and reviewing the output." — Source: [TechCrunch]
  6. On debugging AI: "Debugging an LLM feature feels more like managing a person than fixing a machine. You have to ask why it made a certain choice, rather than reading a stack trace." — Source: [The Verge]
  7. On multidisciplinary engineers: "The line between product manager, designer, and engineer is blurring. If the model writes the code, the engineer's primary job is understanding the user experience." — Source: [First Round Review]
  8. On avoiding the wrapper trap: "If your startup is merely a thin UI over an API call, you are vulnerable. You must build unique scaffolding or vertical-specific workflows to survive." — Source: [Lenny's Podcast]
  9. On code quality: "AI writes code that works, but not necessarily code that is architecturally elegant. Human oversight guarantees the system remains maintainable over years." — Source: [Software Engineering Daily]

Part 7: Team Operations and Management

  1. On co-founder dynamics: "Kevin and I survived because we had clearly delineated zones of ownership. He owned the business and design, I owned the engineering and infrastructure." — Source: [NPR How I Built This]
  2. On resolving disagreements: "When Kevin and I disagreed, we built prototypes to resolve arguments rather than debating them in a conference room." — Source: [Fast Company]
  3. On scaling a team: "The hardest transition is moving from a team where everyone knows everything by osmosis to a team that requires structured communication." — Source: [First Round Review]
  4. On hiring criteria: "I always look for a trajectory of rapid learning. I care entirely about how fast you acquired the skills you have today, rather than what you knew a year ago." — Source: [YC Startup School]
  5. On management overhead: "A manager's job is to unblock their team. If an engineer is waiting on you for a decision, you are failing at the core function of your role." — Source: [Lenny's Podcast]
  6. On organizational debt: "Just like technical debt, you accumulate organizational debt when you put the wrong people in leadership roles to fill a gap quickly." — Source: [Wired]
  7. On shipping cadence: "You have to maintain a steady cadence of shipping. If the team goes too long without putting something in users' hands, they lose their sense of reality." — Source: [The Verge]
  8. On handling failure: "When a launch flops, you can't sweep it under the rug. You dissect it openly so the team learns the lesson without internalizing the shame." — Source: [TechCrunch]
  9. On cross-functional teams: "The best features are built by small, autonomous pods containing an engineer, a designer, and a PM sitting right next to each other." — Source: [Fast Company]

Part 8: Founder Psychology and Growth

  1. On imposter syndrome: "Every time Instagram hit a new milestone, I felt like the system was going to break and everyone would realize I didn't know what I was doing." — Source: [Tim Ferriss Show]
  2. On managing burnout: "I learned the hard way that heroic engineering efforts are not sustainable. You build systems that allow your best people to sleep." — Source: [YC Startup School]
  3. On continuous learning: "The moment you stop treating yourself as a student of your industry, your product begins to stagnate." — Source: [First Round Review]
  4. On leaving Instagram: "Leaving the company we built was agonizing, but it was necessary when we realized we could no longer run it with the autonomy we needed." — Source: [The New York Times]
  5. On wealth and motivation: "Financial success removes baseline stress, but it doesn't give you purpose. Purpose comes from solving hard problems with people you respect." — Source: [Wired]
  6. On the pressure of success: "After Instagram, starting Artifact felt terrifying because the baseline expectation from the industry was that it had to be a billion-dollar hit." — Source: [Lenny's Podcast]
  7. On trusting your intuition: "Data can tell you what is happening, but intuition tells you why. You build enough context in your market to trust your gut when the data is noisy." — Source: [The Verge]
  8. On legacy: "I don't think about legacy in terms of user metrics. I think about whether the tools I built made people's daily routines slightly more delightful." — Source: [Fast Company]