Nicole Ginosar
I threw out my 30-60-90 plan on day two of my last AI PM role. Not because I'm above onboarding plans, but because I realized the traditional 30-60-90 plan was built for a world that moved more slowly.
Thirty days to learn the landscape, sixty to build relationships, and ninety to propose a strategy assumes the ground holds still while you study it. On an AI product, the ground moves faster than your onboarding does. A model you benchmark on Monday can be overtaken by a release on Thursday. By the time a 90-day plan pays off, the product it was written for has already changed.
So I run 3-6-9 now: three days, six days, nine days. Same spirit, compressed to the clock speed the work actually runs at.
The reason the compression works is simple: in modern AI organizations, PMs can safely ship changes to production.
Not specs that sit in a backlog waiting for someone else to implement them. Production changes that reach real users. When the distance between "I have an idea" and "customers are living with it" is a prompt edit and a deploy, onboarding can run on the same clock as the ship cycle. If you're still writing tickets and waiting, none of what follows works. That's worth sitting with, because it's a signal about how the role itself has changed.
None of this is a heroic PM story. It's possible because R&D and the algorithm team built the infrastructure that makes it safe for a PM to own more of the agent: the eval harness, the guardrails, and the deployment pipeline that lets a prompt change reach production without becoming an incident.
That scaffolding is what makes shipping production changes a normal part of the AI PM role instead of an exception. The more of that surface engineering builds well, the more of the agent a PM can safely own, and the faster the whole loop runs. When you land somewhere and find you can move this fast, that's not luck. Someone built the rails.
Days 1–3: Ship one real change to production
Not a document. A production change.
In my first weeks as an AI PM, I shipped a prompt change to how our agent handled a specific workflow, and it reached actual customers within days. It was small enough to be safe and real enough to teach me almost everything: how we deploy, who reviews a change to model behavior, where the guardrails are, and what nobody was watching.
I learned more from one shipped change than I would have from thirty coffee chats. The deliverable for your first three days isn't a strategy. It's a working mental model of the loop from idea to production to user, earned by going around it once with your own hands on the keyboard.
Days 4–6: Evaluate the thing you're responsible for
Now that you can ship, the next question is whether what you ship is any good.
Build or borrow a way to measure the agent, or the workflow, against real cases. What does it get right? Where does it fail? How often?
On an AI product, this is the work, not a QA afterthought, because the output is probabilistic and your intuition about it will eventually be wrong. In this stretch, I go from "the demo feels good" to "here is the metric, here is the failure mode, here is the case it fails every time."
By day six, you should be able to explain where your product is unreliable with evidence, not adjectives. That's the thing most new PMs never do, and it's why they spend months managing a product they can't actually measure.
Days 7–9: Turn a process you've now done twice into a skill
By day seven you've shipped and you've measured, which means you've already repeated something. Maybe you've run the same eval three times. Maybe you've manually reconciled the same outputs to verify the agent's work.
That repetition is the signal.
Take the process you keep doing by hand and turn it into something reusable: a script, a skill, or a saved workflow the whole team can run. The reason to do this in your first nine days instead of your first nine months is that codifying early forces you to truly understand the process, and it compounds. Future you gets the leverage. Every teammate who comes after you gets it too.
A nine-day-old grand strategy is a liability.
A nine-day-old reusable skill is a gift you keep unwrapping.
The honest caveat is that 3-6-9 depends on the maturity of the organization you join, not on how bold you are. Shipping to production in your first few days is only safe when the rails exist, when you can roll back a bad change in one move, and when the team trusts the system enough to let a small change through without a committee.
That maturity is real infrastructure and real culture, and not every company has built it yet. If your organization can't roll back cleanly or doesn't yet trust the system to absorb a change, don't force the pace. Getting to a place where a PM can move this fast is itself the goal.
And speed is not the same as understanding.
Shipping on day one feels productive, and it's easy to confuse "I deployed something" with "I understand the business." You still need the context, the organization, the customers, and the economics of the business. Nine days isn't nearly enough time to absorb all of that.
3-6-9 is the fast learning loop running on top of the slow one, not instead of it. It simply refuses to let you spend ninety days reading documentation before you've touched the product.
If you're starting an AI PM role next week, ask yourself one question on day one:
What's the smallest safe production change I can ship myself?
Finding that answer will teach you more about the product than ninety days of observation ever could.
Nicole Ginosar is Head of Product at Emerix, where she leads the development of AI systems that move enterprise operations from recommendations to autonomous execution. Before Emerix, she led Data Engineering and Product Analytics teams, spent more than two years at Google, and co-founded Data Queens, a community dedicated to advancing women in data. She writes about AI product management, agent evaluation, and building production AI systems.