I was going to build a project management system and sell it as a product.
The idea was simple: I juggle over a dozen client projects at a time, and it's exhausting. So I'd build a tool to help myself — and then help others. Dashboards, task tracking, status reports — the whole package.
Then I deleted all of it.
It wasn't because the product was bad. It was because while building it, I noticed something contradictory:
The way I managed the "management tool project" had nothing to do with what the tool assumed management should look like.
I didn't write a spec. I didn't plan sprints. I didn't look at burndown charts.
What I did was: tell the AI "just build me something." If it wasn't right, I'd subtract. Cut it down until it was close enough, then ask another round of questions, and iterate again.
Where did the files go? I didn't care. The AI organized them however it wanted. I never once opened the folder to check how it structured things.
Andrej Karpathy coined a term for this: vibe coding — "fully give in to the vibes, forget that the code even exists." I'm not sure what I do qualifies as vibe coding, but "forget that the code even exists" — that's literally my daily life.
This made me realize something.
We used to care about clean processes, neat structures, and readable intermediate steps because we were the ones who had to go in and deal with them. You had to manually edit that file, so the file structure needed to be clear. You had to visually track progress, so you needed a dashboard. You had to personally assign tasks, so you needed a Kanban board.
But what if you're no longer the one doing any of that?
What it looks like inside literally doesn't matter.
Here's how I actually manage a dozen-plus projects now:
I don't go look. I ask.
"What's the status of these projects?" Three-minute report. "Did anyone follow up on what the client said on LINE last week?" Instant lookup. "Is there anything I should be worried about?" It spots problems before I do.
I don't check dashboards — I ask questions. I don't assign tasks — I describe the outcome I want. I don't write SOPs — I iterate through conversation.
More like a CEO. Less like a PM.
Then I looked back at the management tool I'd built.
It assumed the user would "look" — at dashboards, progress bars, category tags. But I'd already stopped looking.
It assumed the user would "organize" — to-dos, categories, report formats. But I'd already stopped organizing.
It assumed the intermediate process needed to look good, to have order. But whether it looked good had already stopped mattering to me.
I'm not saying those management methods are "wrong."
Scrum, OKR, Kanban, Gantt charts — the core problem they solve is: how to align a group of people.
Meetings exist because of information asymmetry. Sprint planning exists because limited manpower needs prioritization. Specs exist because you're afraid what gets built isn't what everyone agreed on. Kanban updates exist because without them, nobody knows what's going on.
These processes are expensive. But when many people work together, they're worth the cost.
But what about when your scenario is "one person + AI"? Sam Altman says his CEO friend group has a betting pool on when the first "one-person billion-dollar company" will appear. Anthropic's CEO says it could happen as early as 2026.
No need to align — there's no second person to align with. No need for consensus — you're the one who decides. No need for rigorous specs — if something's wrong, one sentence fixes it. No need for meetings — you just ask and get an answer.
The problems those processes were built to solve no longer exist in this scenario.
What I'm really saying is something more fundamental:
Management is shifting from "seeing" to "asking."
We used to manage by "seeing the full picture" — Gantt charts, Kanban boards, dashboards. All tools designed to help you see. Someone mapped the evolution across three generations: paper reports, spreadsheets, dashboards. Each generation let you "see faster." But the next generation isn't a better dashboard — it's not needing to look at all. You ask.
You don't need to see the full picture. You just need to ask the right questions.
Asking the right question is faster and more precise than seeing the full picture. Because seeing the full picture requires you to judge where the problems are. Asking the right question cuts straight to the problem itself.
So I deleted it.
Not because the product was bad, but because the world it assumed no longer matches the world I live in.
Speaking of asking the right questions — I'm reminded of something.
Early in my career, my former boss told me: Before you solve a problem, learn to ask the right question first.
I thought it was wise. Did I actually do it? Hard to say. Projects came in hot — clients needed deliverables, production had bugs, just fix it and move on. Every time I'd tell myself, "This time we'll just power through, next time will be different."
But every next time was the same.
Always chasing deadlines, chasing clients, chasing fires. Never time for PDCA, never time for feedback loops, never time to iterate.
So experience accumulated the old way: you make the same mistake 10, 20, 30 times before you level up a little. People with sharper instincts learn faster; the rest of us pay with more time and more mistakes.
But in the AI era, those costs of time and failure feel like they've entered a hyperbolic time chamber.
And the one thing that keeps causing failures in this new model? It's almost always that the original problem definition was wrong. AI can be as smart as it gets — if your problem definition is wrong, your product definition is wrong, your requirements are wrong — it will never produce the right answer from a wrong premise.
That's when I finally understood what my former boss meant.
"Ask the right question first" was no longer just wise advice. It was something a Silicon Valley founder earned with his life, his youth, his sweat — a principle he lived by every single day. The PDCA cycles, the management frameworks, the methodologies he taught us — maybe some came from books originally, but they were forged through the practice of actually building things.
And I had treated it as just another quote from a book.
It wasn't until now — walking the entrepreneurial path myself, managing projects, deeply collaborating with AI — that I realized what he said wasn't just something to understand. It was something you had to do.
How? Not through dashboards. Not through management theory. Not through SOPs. It comes back to the essence of human thinking — your intuition, your ability to think something through clearly and quickly.
So it always comes back to: Don't rush to solve the problem. Define it first.
And here's the paradox: the way to define a problem is to use questions to clarify questions. You have to wrestle with yourself — this is also something my former boss taught me — debate your own thinking, challenge your own assumptions, until you arrive at a reason that convinces yourself and can convince others too.
In an era where AI is this capable, maybe you don't need as many people, as much time, or as much rigor. Maybe you don't need to spend time in meetings iterating toward consensus.
Maybe all you need is to ask a good question.