10,000-word sharing by the Chief Product Officer of Anthropic: Why is it so difficult to produce a "phenomenal product" in the AI era?

Mike Krieger, the co-founder of Instagram and the Chief Product Officer of Anthropic, used Claude to rebuild a product in just two hours that had taken him an entire year to develop previously. Not only was the functionality complete, but it even had a few additional photo filter features.

This in itself isn't that important. What matters is, how do you know you're working on the right thing? Mike has seen too many teams racing faster and faster in the wave of AI acceleration, piling on more and more features, yet making the products increasingly difficult to use. Eventually, they end up creating a bunch of flashy but useless things that users don't actually need.

Therefore, in the "AI & I" podcast, Mike repeatedly asked: Why, in the era of AI-accelerated development, haven't there been any phenomenal products?

He pointed the finger at the "efficiency illusion" brought about by "Vibe Coding." The rapid efficiency boost brought by AI actually makes it harder for developers to make real judgments about the product: what to keep, what to cut, and when to start over.

When writing code becomes as easy as having a meal, more and more products have become "trees in a greenhouse" that are carefully nurtured. They may seem lush, but they've never experienced the wind and rain of user feedback and are very fragile.

Mike's solution is to be more decisive in "starting over from scratch," to throw the product into the real world earlier to face the challenges, and to shift towards true "Agent-native" design. That is to say, make software no longer a cold command tool, but a collaborative partner that can autonomously call underlying functions and truly understand the user's intentions.

So, what exactly does an Agent-native product mean? How should teams be structured in the AI era? And why are "starting over from scratch" and "releasing earlier" the most underestimated product methodologies right now? The answers are in the following conversation.

Participants in the conversation:

Dan Shipper: CEO of Every, an AI media lab, and host of the "AI & I" podcast

Mike Krieger: Co-founder of Instagram, Chief Product Officer (CPO) of Anthropic, and one of the leaders of Anthropic Labs

Image source: Screenshot from "AI & I"

The following is the full transcript of the conversation (compiled):

Function redundancy under the efficiency illusion in the AI era

Dan Shipper: As we were discussing before the recording, there have been significant changes in the underlying infrastructure and the entire process of product development. So, in product development, what has become easier, what has become more difficult, or perhaps remained unchanged? Tell me about your current experiences compared to when you were at Anthropic or Instagram in the early days. What has changed?

Mike Krieger: We all know the story of Instagram. Back then, we had another product called Burbn, and we spent a year on it, but it didn't work. Later, we pivoted to Instagram. The development and launch of Instagram basically only took about three months.

I started thinking about what things are now trivial and what fundamental aspects of the development process haven't become easier. During that one - year period, we could have identified those dead - ends earlier, but the process itself was actually valuable. For example, we initially made the product overly complex and then had to simplify it.

I've found that even today, models are very good at adding features, but not necessarily at figuring out what to cut from the product. Because this requires a lot of real - world application experience to understand.

The current process is to incrementally add things.

Today, especially for some of the things we're developing in the lab, you can take a product from 0 to 1, or even from 0 to N, in just a few hours. But in this process, the model makes a lot of decisions on its own. Even if you can ask it for follow - up and feedback, developers need time to develop an intuition about "which features are essential and which can be discarded."

So, I've been reflecting on why, in the era of AI - accelerated development, there haven't been many phenomenal products.

I think part of the reason is that even though AI can improve efficiency, it still takes time to figure out what kind of impact you want to make on the world and then base your development on that. Once you know what to build, the actual building process is indeed much easier. I had Claude re - develop Burbn, and it only took about two hours to have a fully functional product. It also added filters that Burbn didn't have at the time, which were later developed for Instagram. Claude anticipated the final direction of the product and incorporated the filters in advance.

I remember one week, my partner Kevin went to develop all the filters for the first version of Instagram, while I went to build the rest of the application. At that time, I would stay up until 4 am and then sleep until noon. That was my routine.

In this process, you make a lot of decisions. For example, how should the location feature work? We need to find a way to accelerate development while also helping people build an understanding of these decisions. Otherwise, we'll end up with either very mediocre products that are unlikely to stand out or products that don't reflect a deeper understanding of the domain or the product.

The "greenhouse trees" brought about by Vibe Coding

Dan Shipper: This makes me think of two things. One is an idea that's always been in my head: if you plant a tree indoors and don't let it be exposed to the wind, it won't grow strong. Because during the growth process, it needs these external forces to be tempered to become a real tree. If you plant it indoors in a windless environment, you can still grow a tree, but it will be tilted and very fragile, nothing like a tree in the wild.

I think the situation you're talking about is the same.

Our development pace is very fast now. The incremental process of doing one thing at a time and then getting user feedback has changed. Now you can "grow" a complete tree indoors. You have this complete thing, but each step hasn't been tempered by the same level of intuition and experience, which are essential for creating great products.

Mike Krieger: I also like this metaphor. When we first started working on Instagram, we were very infatuated with Eric Ries (the creator of the Lean Startup methodology) and the Lean Startup, as well as the entire YAGNI (You Ain't Gonna Need It) principle.

But I found that in a recent project in the lab, we over - developed the V1 version before the early access phase. You might think, "Oh, since there's this option, why not add that too?" It's just the work of a PR (Pull Request). So, if you find a great process in Claude Code, you give the command, go have lunch, and come back to find it done. You'll think, "Great, we added it."

But we realized that although we created a matrix of features, it's very difficult to test and maintain before the release, and it's even difficult to explain to new users. Another metaphor I really like was given to me by someone else: it's like "getting to know the characters in a TV show episode by episode." Compared to "being thrown directly into the last episode," you'll think, "Wait, what are these things for? Who are these people? I'm supposed to have all the background information already."

I have the same feeling when developing something over a long period. I think the tree metaphor is also very appropriate. Showing someone a fully grown tree is really too much information. There must be some tricks here. Today, it's important to develop products and keep them simple, rather than just putting everything you "can do" into the first version.

Dan Shipper: I've also encountered the same problem. Just last night, I stayed up until 4 am to debug and fix an app called Proof that I casually developed at Every. It's an Agent - native collaborative marketing editor where you can quickly share planning documents with your team or other agents.

This is my second or third end - to - end iteration of the entire product, which is really interesting to be able to do now. But in the previous iterations, I found that because Vibe Coding (where developers no longer write specific lines of code but drive the AI to generate the entire application by "communicating intentions, adjusting emotions, and describing feelings") is so much fun and addictive, I thought, "Yes, I'll do this and that." As a result, I created a cumbersome and difficult - to - use product.

Later, I was inspired by another product of ours called Monologue. I'm not sure if you've seen it. It's a very simple voice - to - text app run by GM Naveen. It focuses on doing one simple thing extremely well. Here, I saw how effective something that is extremely refined and good at its job can be in this era where "anyone can develop a product."

So, I threw away the original product and re - developed a very simple version, which is just a shareable Markdown link. Then this product started to spread virally within Every, and everyone was using it non - stop.

Now that we've released it, it's become a huge hit. So, I stayed up all night last night trying to fix it, thinking, "I'm too old for this. I can't do this anymore." This made me think of the days when I was in my 20s or in college, delving into technology and development. It was fun but also exhausting. Now that everything is possible, I find that I really need to adjust my mindset. So, how do you deal with this problem?

Spending a few days to start over is better than patching things up

Mike Krieger: By the way, I remember that when we were working on Burbn, our biggest mistake was constantly adding features over time instead of removing them. You might think that if eight features can't make a good product, maybe the ninth one will. But the opposite is true. It just makes the product more and more complex.

I think there are two ways to deal with this problem. One is that we're now more willing to rewrite. According to classic theories, such as what Fred Brooks mentioned in "The Mythical Man - Month," you shouldn't rewrite software because you'll mess up all the essence of the V1 version, and there's also the so - called "Second System Syndrome."

Image source of "The Mythical Man - Month": addictbooks

These theories are still very valid, but the difference is that now models can help you with code comparison (Diff), which basically allows you to check if you've missed anything from the first version. Secondly, it's no longer a year - long rewrite plan that could potentially sink a company, like the famous Netscape rewrite. Now, rewriting only takes about a few days, especially based on the existing source code.

So, we actually have several projects where we initially built a complete version, but when we realized we made it too complex or had some wrong core assumptions, we directly started over with V2 and iterated on that. Of course, this usually happens before the release.

You don't think, "Oh, my god, I wasted a year building this," but rather, "Oh, that was last week. I can start over this week and cut out a lot of useless things."

In terms of functionality and from the perspective of product development, we're learning to release earlier. We have a strong enterprise - level customer base, and people have expectations for the initial version.

But we can't assume that we know every connector or feature that the product needs to add before the release. Instead, we need to rely on user feedback. We have a group of powerful internal testers, whom we call "Ant foodters" (Note: In the tech circle, there's a well - known term called "Dogfooding," which means a company's internal employees use their own products. Anthropic's employees call themselves "Ants," so they jokingly call their internal testing "Antfooding"). We can first get internal test feedback. But this can only take you so far before the product really enters the real world.

Take Co - worker as an example. We've been refining this type of product for a long time. Once we decide to release, we'll build a V1 version, aiming to solve the problem in the most minimalist way and launch it within 10 days. This is a good incentive for us to realize that even though V1 could have 100 more features, it doesn't have them now. It just needs to be useful enough to prove something. I'm not sure if spending another two months and adding 50 more features would make it more useful.

In fact, we could build a "greenhouse tree" there, but once it enters the real world, users will say, "Actually, no one wants to do that. They want to do something else." So, I think the original intuition of the Lean Startup still applies, but it's manifesting in different time scales and ways.

What does "Agent - native" product design mean?

Dan Shipper: I'm really interested in hearing your views on product design and how products work. Everyone at Every will tell you that the most frequently used term I use in software development is "Agent - native." That is, an agent must be able to use any function in the application just like a user. Of course, there are some other principles regarding "Agent - native," but I basically borrowed them from you.

I think Claude Code is a great example of how a product can work efficiently. It's an agent that can do anything you can do on a computer, and it's customizable, flexible, and scalable. It's not only easy to use but can also do many things that designers didn't even think of in advance. I think this is a very good model for AI product development, but this is my understanding after observing your approach. I'm really curious to know what you think about it. How would you describe the development of this type of product?

Mike Krieger: I really like the article you wrote about "Agent - native." For me, it's the most authoritative exploration of this concept. Thank you for clearly expressing these ideas. I'd like to talk about it from a few aspects.

First, I recently talked to a non - technical person. He said, "You guys have been talking about agents and all that. It's actually that computers are finally usable now." I've always hoped that computers could work according to my wishes. It wasn't possible before, but it is now. This is a very interesting phenomenon. If you used to know the right "spell" and could install things via "brew install" on the command line, you could make it work, but ordinary people don't do that.

Now, Claude can do these things for you, so the computer now feels like a tool that accompanies you. I think the core is that this is not only about adding power and features to new software but also unlocking functions that should have existed or been available but were extremely difficult for ordinary people to operate.

Image source: apidog

Second, when comparing our products that are doing well and those that aren't. I think Claude Code is doing very well, but Claude AI (web version/App) still needs a lot of evolution. For example, I saw someone using the project function of Claude. They built an artifact or a new document and said, "Great, can you add it to my project knowledge base?" Claude AI replied, "Okay, let me tell you where to click the button to add it to my project knowledge base." This is wrong. It should have been able to do this natively.

So, in such products, you can also see a 2024 product