💡 Life is like an oyster, you never know what happens at the next moment.
Three months ago, by a twist of fate, I joined a veteran tech giant that still had plenty of fight left in it, and became a PM on its AI team. I expected the usual big-company experience: being another cog in the machine, doing execution work against clearly defined goals, and helping build out the boss's grand vision. Instead, the team was reorganized almost as soon as I arrived, and mine was suddenly left without anyone at the helm. No boss. No goal. The old product went into maintenance mode. So we all started looking for something useful to do.
Meanwhile, I was the new kid who still couldn't put names to all my colleagues, let alone understand the company's internal politics. Together with my manager and another PM who had just transferred in, I formed a three-person team and started doing what startups do. Our brief was simple: take a fuzzy objective, build something, then pitch it to others inside the team—including our own developers—until they wanted to join us as partners and actually use the product themselves. If we could pull that off, we'd call it a win.
Our entire brief was one sentence: 10x the team's productivity in the age of Agents.
What should we build? How should we build it? No idea. Overnight, I went from an execution-focused PM to an exploratory PM. I was lost and completely out of my element. To be honest, I'm still rebuilding myself even now. But the process has already overturned a lot of what I thought I knew, and I can tell it will keep doing so.
At my manager's suggestion, I decided to write down what I'm learning from doing startup-like work inside the team—not just to consolidate it for myself, but because some of it might actually be useful to other people.
I want to start with how radically different it feels to be an execution-focused PM versus an exploratory PM.
Execution-Focused PM: Training My Muscles
In my previous role at another tech giant, I was an execution-focused PM. It looked nothing like the popular claim that a PM is the mini-CEO of a product. My job was concrete, practical stuff. We had a mature commercial product, real enterprise customers, and clear product and revenue targets. In that sense, the job wasn't fundamentally different from taking exams at school: you work toward a number that somebody else recognizes. Back then it was a grade; here it was a product metric or revenue target. The path was fairly clear. The only real difference was that students improve their scores by practicing questions, while employees have a wider range of ways to hit a goal.
There were challenges, of course: dealing with difficult enterprise customers; communicating with salespeople, architects, engineers, algorithm specialists, and everyone in between; navigating people from different teams with different interests; and being the point of contact who kept things moving toward the final target. Still, things mostly went smoothly. The job didn't demand as much—or as deep—thinking from me, and I could see progress relatively quickly. It was exhausting and rewarding at the same time, like studying hard for an exam, doing well on a quiz, feeling reassured, and carrying on.
After three years, though, I started wanting out. First, I could see that the business was already very mature. Second, I had become very good at the execution work. Put those together, and there simply wasn't enough room left for me to grow. Honestly, I hesitated. I wasn't the backbone of the team, but I had built some personal influence and liked thinking of myself as an “important link” in the system. At the very least, I felt safe. (Looking back, that was naive. Big companies have a lot of built-in tolerance, and the more execution-oriented the work, the easier you are to replace. That sense of security was a classic boiling-frog trap.)
That doesn't mean the experience was meaningless—quite the opposite. As a Junior PM, it gave me confidence, although some of that confidence collapsed once I became an exploratory PM. It trained the most basic and essential PM skill: communicating with all kinds of people. It also taught me how people and work actually move through a big company and dragged me out of the ivory tower of campus. Those lessons were invaluable. I still think execution-focused PM work is a great stepping stone into the role, because most of us learn from the concrete before we can grasp the abstract.
Exploratory PM: Training My Brain
I call my current role exploratory PM work. I'm still at a big company, but I'm doing startup work: no clear goal, no mature product, and nothing but empty space to explore. If we can't prove our value, we could be cut at any time. (Then again, proving it may not save us either 😅.)
I've been doing this for all of three months, so I'm in no position to make grand claims. But I can be honest about what it has felt like.
Compared with execution-focused PM work, this is much more mentally demanding. Being organized and polishing every detail to a high standard are no longer my priority. My priority is finding users' real needs, getting an MVP built and validated fast, then pitching and upselling the product. That is COMPLETELY DIFFERENT from my last job. And because there are no ready-made metrics, we have to define those too. All of it takes an enormous amount of thinking, doing, scrapping, and starting again. In that sense, it is much closer to the “mini-CEO” idea people talk about.
Following an existing road takes legwork. Finding a road where none exists takes brainwork.
Every problem I've run into so far could be an article of its own: “All the traps in finding a user's real pain point,” “How an MVP sprawls while you're building it,” “How easy it is to fall into building in a bubble,” “Why pitching a product is a craft,” and so on. Then there are all the problems I haven't hit yet but surely will. Most important, after all that work, the product may still turn out not to be viable. When that happens, how do you turn the failure into something valuable you can carry forward? (Start with the most important belief: failure ≠ no value.)
Moving from execution-focused PM to exploratory PM means breaking a lot of my own habits.
First, attention to detail and being organized helped me avoid risks in execution work. In exploratory work, though, I need to keep my eye on the big things and let the small things go—to avoid getting lost in one detail and missing the core problem we're trying to solve. Scoping an MVP is a classic example.
Second, as an execution-focused PM, shipping something that isn't fully ready can make you look unreliable. As an exploratory PM, you need the courage to put a half-finished product in front of people, because negative feedback is just as valuable as positive feedback. The goal is to iterate quickly, improve step by step, and build credibility—not to keep your head down and hope for one spectacular reveal. Most of the time, the big reveal you've been quietly building lands with a thud and no response.
Finally, this work demands deeper, more fundamental, and more dialectical thinking—and far more willingness to challenge myself—than execution ever did. In execution work, if you get the job done and nobody objects, you're fine. When you're exploring and creating something new, countless people—investors and users alike—will challenge whether the product has any value at all. That forces me to think much more clearly instead of letting my ego take the wheel.
I won't pretend these reflections are necessarily right. They're simply what my experience so far has made me think. Next, I want to put them into practice and see whether these new learnings really can help me find a new road—or whether future experience will overturn them as just another set of naive ideas.
For now, at least, being an exploratory PM has made me realize that my previous execution-focused work never trained me to think deeply. That was the missing piece. And right now, I believe deep thinking is what can actually make me “safe”: it is something I can carry with me and reuse wherever I go. AKA: Transferable Skills.
One last thing: PM work has far more than these two categories, and neither is higher, lower, better, or worse. Everyone has their own preferences and strengths. For me, getting to experience two completely different kinds of PM work has been painful—in many ways, it feels like starting from scratch—but it has also felt lucky and deeply worthwhile. I'll keep writing about what this experience teaches me.