🚀 When the PM doesn't just write the PRD... it creates the real thing.

🚀 when the PM doesn't just write the PRD... but creates the real thing.

"Lessons from the new speeds of AI teams that are changing the way products are built globally."

In the traditional Product development world, we are familiar with this path.

"PM writes PRD → Designer, interprets → Engineer, develops → QA, tests → and then gradually sends it to the user to experiment."

This process is not wrong, and it has been a success formula for many organizations to grow over the decades, but what many teams have never seen clearly is the "hidden costs" along the way, the costs that do not appear in the budget, but accumulate in lost time, and the understanding that gradually deviates.

* That is the time and distortion of the substance during the forwarding.

* The more work passes through many hands, the more discrepancy.

The more through multiple teams, the longer the development cycle.

* And over time, the organization will begin to feel

"Why are we slowing down the development of new things, and the team is getting bigger?"

And one of the most talked about examples over the past year is Anthropic.

* Anthropic, the Claude family of AI model developers, has attracted a lot of attention for its speed-based product-building approach to experimentation and learning.

* Anthropic's Product team no longer relies on long-form PRD documents, but uses tools like Claude Code to quickly create the first version of the feature and have people in the organization try it out before experimenting with external users.

* By early 2025, the company had run-rate revenue of about $1 billion, but by the end of the year, the numbers had grown many times more than that, and AI coding products became one of the key growth engines.

* The key issue is not just income, but how to work that reduces traditional forwarding and allows ideas to become experimental in a significantly shorter time.

So the idea that's emerging isn't just about new tools, it's about changing the way Product teams work.

* Instead of PM writing a long document and forwarding it to another team to create, PM can use AI tools to create a feature prototype within days or sometimes within hours.

* Teams within the organization can then experiment with real users (dogfooding) to learn, improve, and gradually expand into experiments with real users.

* What changes is therefore not just the speed of "building things," but the speed of "learning from what is built." And in an age when the market is changing fast, the need for users is changing fast. Who learns faster... is often more advantageous.

📉, a problem that most organizations don't know, or "Handoff Drive."

Every time a task is passed on, something called Handoff Drift, or substance distortion, occurs.

* PM intends one thing, Designer understands another, Engineer creates another, and user experiences another.

* Nobody makes a mistake on purpose, but the slightest difference in understanding at each point, when combined several times, becomes a product that doesn't match the actual problem.

In many organizations, one feature experiment can last 4-8 weeks from idea, document, design, develop, test and release approval.

* But in the case of a team like Anthropic, when the PM was able to prototype itself, the experimental cycle was condensed from a multi-week scale; only a few days remained.

* It's easy to think if a competitor can experiment once a month, but you can experiment every week or every few days.

* In a quarter, you will have many times more opportunities to learn, and within a year, the user understanding gap will be so wide that you will not catch up.

"Today's competition is not just who creates better features, but who" learns faster and adapts better, "because in the digital world, the advantage is not from the first idea, but from the experiment and the right thing."

⚙️ Tools are not heroes... organizational structure is the answer.

Many organizations read this story and then quickly thought, "Need to buy AI tools for the team to use immediately"?

* But the truth is, even if everyone builds Prototype faster, if the organization still has to go through several pre-trial approval procedures or the roadmap is locked up for a quarter.

* The speed of acquisition only helps to get to the same stage faster.

"What makes a case like Anthropic so fast is not just tools, but organizational structures."

Organizations that go real fast often share common characteristics, such as

* The system and code are designed to be easily improved. Not tied to the whole system.

* Reduce unnecessary approval procedures and allow the team to make decisions near the page.

* Open up space for teams to experiment and learn without fear of small failures.

* Value learning more than not doing

Because in the end, "Build Speed means nothing if Decision Speed is still slow." Building things quickly, but making decisions slowly, is the same as building things and having to wait.

📝 PRD didn't disappear... but it changed the pattern...

Many people worry that if the PM creates the Prototype itself, will the PRD document disappear?

* The truth is, the important thing is never the document, but the thought process behind it.

* The PM still always has to answer the same question.

* Who does this feature solve?

* What are you doing for?

* How to measure success?

* Are there technical, business or legal restrictions?

* The only difference is that from the beginning, these answers were in the document, and now they are converted to a Prototype that everyone tried.

* Instead of reading a 20-page document and interpreting it differently, everyone can try to use it and understand it more closely.

* Spec therefore did not disappear, but it became tangible and reduced the interpretation of discrepancies between teams.

"The important thing is not to stop writing papers, but to make the team's thoughts and intentions transmitted in a way that everyone understands together faster."

⚠️ Be careful... speed can lead to ease.

The other side of this is risk.

* When Prototype is created very quickly, the organization may accidentally conclude that "it is ready, let go."

* In fact, it has not been tested with real users. Edge Cases have not been thought of or have not been structured to support large-scale use.

* Results may become a good-looking system in Demo, but create real problems in customers' daily lives.

Prototype should be the beginning of dialogue, not the end of thinking.

* Speed is only worth using it to learn faster, not just to release things faster.

* An organization that uses speed effectively is an organization that uses Prototype to ask more questions, not to end conversations faster.

✨ Important question for the organization today?

This phenomenon tells us that the era of PMs who only "command" is reducing their role.

The new PM needs to get closer to building the real thing, understand the limitations of the system, understand the user experience, and understand the business impact, and the winning organization in the future may not be the organization that buys the most expensive tools or has the largest team, but the organization that makes "ideas get to the hands of customers the fastest."

Ask yourself, in your organization, does the distance from "idea" to "customer's hand" take days... or months?

* And in each moment, are there any steps that create real value, or are they just inherited steps that no one dares ask if they are necessary?

* That answer may determine whether in the next few years your business is still leading... or trying to run after others.

* Because in a world where everyone has similar technology... the real advantage is the speed of learning and adaptation.

And that's not about tools, it's about ways of thinking, organizational design and work culture.

"Fast organizations do not work harder, but make the change of ideas real... happen faster and learn from them faster."

# Two stories a day

# ProductManagement

# AIWorkforce

# OrganizationalDesign

# FutureOfWork

# Anthropic