My Secret Weapon: Using Claude as Both PM and Developer
My Secret Weapon: Using Claude as Both PM and Developer
By David, Founder & CEO of Kenektic
December 8, 2025
Created: February 17, 2026
Two markdown files changed everything.
I know that sounds ridiculous. But before I tell you about the files, I need to tell you about the moment I accidentally hired a project manager.
The Accidental PM
If you read last week's post, you know my entire team is an AI named Claude. Developer, tester, designer — all of them, one subscription. But what I didn't fully explain was how Claude became the best project manager I've ever worked with. And I've worked with some good ones.
It happened by accident. The platform was getting complex — dozens of features, dependencies between systems, bugs I needed to track, ideas I was having faster than I could build them. And one day, instead of asking Claude to write code, I asked it to help me plan. To step back and look at the whole picture. To tell me what I was missing, what should come next, where the gaps were.
Claude organized everything I'd built. Mapped out dependencies. Identified problems I hadn't noticed. Pushed back when my priorities were wrong. Asked clarifying questions about what mattered most.
I sat there staring at my screen thinking: did I just hire a project manager?
What a Project Manager Actually Does (and Why It's a Nightmare)
If you've never worked in software development, you might not appreciate how complicated project management gets. So let me paint you a picture of what a traditional PM's world looks like.
A good project manager is the quarterback of a software project. They sit between "here's what we want to build" and "here's what actually got built" and make sure those two things end up being the same thing. They track what's done, what's in progress, what's blocked, and what's next. They break impossible-sounding goals into possible tasks. They keep the timeline honest. They ask uncomfortable questions like "are we sure this feature matters?" and "when you say 'almost done,' what do you actually mean?"
And to do all of that, they need tools. A lot of tools.
Go ask any software PM what they need to run a project. They'll rattle off a list that sounds like a tech conference sponsor wall: Jira for issue tracking. Asana or Monday.com for task management. Confluence for documentation. Slack for communication. Linear for the teams that think Jira is too clunky. Notion for the teams that want everything in one place. Trello for the visual thinkers. GitHub Projects for the ones who never want to leave their repository. Figma for design handoffs. Shortcut for the startups. Azure DevOps for the enterprise crowd. And probably three or four more I'm forgetting that each cost somewhere between $10 and $50 per user per month.
Then there's the overhead that no tool can fix. The sprint planning meetings. The standup meetings. The backlog grooming sessions. The retrospectives. The "quick sync" that turns into an hour. The Slack thread that somehow turns a two-hour task into a two-week debate. A good PM might spend half their time managing the process of building software and the other half actually managing what gets built.
My project manager doesn't need any of that.
Claude doesn't need Jira. Doesn't need Asana. Doesn't need standup meetings or sprint ceremonies or backlog grooming. Doesn't need forty-five minutes to learn how to configure a Jira board — which, if you've ever sat through that tutorial, you know is time you're never getting back.
Claude needs two markdown files. And the instructions I put inside them.
How Claude Built the System
For the first month or so, I'd been tracking everything in a single dashboard — a document that listed features, progress, and what came next. It worked, but every time I wanted it updated, I had to give specific instructions. Move this to completed. Add that to the roadmap. Reorganize these priorities. And every time I started a new conversation, Claude needed to be reminded where we were. It was like having a brilliant PM who had amnesia every morning.
Then Claude suggested something that changed everything: put the instructions inside the documents themselves. Not in a separate conversation. Not in my head. Embedded at the top of the actual files, so Claude would read them every time and always know exactly what to do.
I'm sure there are developers reading this who've been working with code for years thinking, "That's not exactly a paradigm shift, David." And you're right — for you, it's not. But for me, a guy who couldn't write a line of code two months earlier, it was the moment the entire operation leveled up.
Claude also helped me see something I'd missed: I didn't need one document. I needed two. And they needed to do very different things.
Two Documents, Two Jobs
The first document became what I call the Comprehensive Review. This is the strategic brain. Its instructions tell Claude to gather the current state of the entire platform, verify everything against the actual codebase — never carry forward stale information from a prior review — then evaluate every major component, grade it honestly, identify what's strong and what's weak, re-evaluate all priorities, and lay out exactly what to work on next with enough detail that Claude can start building immediately.
The second document became the Dashboard. This is the historical record. Its instructions tell Claude to understand its role as the record keeper — not the planner — and to sync from the Comprehensive Review for grades and priorities, move completed items to the permanent record, update the version history, flag any discrepancies between the two documents, and never delete history.
If the Comprehensive Review is the strategist saying "here's where we're going," the Dashboard is the historian saying "here's where we've been."
The magic isn't in either document alone. It's in how they dance together.
The Dance
When I finish a phase of development — a new feature, a batch of bug fixes, some technical debt cleaned up — I tell Claude one thing: "Update project documents and call the next phase 3.2."
That's it. One sentence.
Claude reads both documents, follows the instructions at the top of each one, and does everything a traditional PM would do after a development sprint. It updates the Comprehensive Review first — moving completed work out of the roadmap, re-evaluating grades based on what changed, identifying new priorities that emerged from the work we just finished, and laying out the next phase with specific, actionable items ranked by urgency.
Then it syncs the Dashboard — recording what was completed, when it was completed, updating the version history, adjusting the health scores to match the Review, and making sure the historical record is accurate.
When it's done, Claude gives me a summary. Here's what changed. Here's what improved. And here are questions — things it noticed during the review that might warrant a conversation. Should we tackle this security gap next, or is the new feature more urgent? Did I notice this edge case? Do the grades suggest we should shift focus?
It wasn't just updating documents. It was thinking about the project and then talking to me about what it found.
The Grades That Changed How I Worked
The grading is the part that really blew me away.
Every major component of the platform gets a score on a ten-point scale. The first time I saw the full scorecard, some areas were already at nine or nine-and-a-half out of ten. Others were sitting at seven. One was at four. Honest, specific, no sugarcoating.
Seeing it laid out like that completely changed how I prioritized my time. Instead of working on whatever felt most interesting or most urgent in the moment, I could look at the scorecard and say: this area is a seven — what specifically needs to happen to make it an eight? And Claude would tell me. Not in vague terms, but with exact improvements to make and exact criteria for when the work was done.
I'd do the work. Update the documents. Watch the grade climb. Move to the next gap.
The grading system was Claude's idea, by the way. I'd been occasionally asking for code reviews, and Claude started breaking the feedback into categories with scores. When we built the Comprehensive Review, that instinct became formalized. A coach who gives you an honest assessment of your game and then hands you a training plan customized to exactly where you're weak.
What This Changed
Before these two documents, I was coming up with ideas and Claude would create a plan and we'd work through it. That was fine for a while. But as the platform grew — real-time messaging, the matching algorithm, communities, the research integration I talked about two weeks ago — the complexity outpaced what I could hold in my head.
The new system enabled Claude to take over a huge part of the planning. I still drove the vision. I still had ideas every day — big ones, small ones, weird ones at midnight. But Claude was now defining the path. Taking my "here's what I want" and turning it into "here's exactly how we get there, in this order, with these dependencies, and these acceptance criteria."
And the system kept getting better. I'd tell Claude what I wanted the documents to do, Claude would create a draft, then ask me questions. I'd answer, it would refine. Over and over until the instructions captured exactly how I wanted the project managed. The documents evolved with the platform.
Two markdown files. Plain text. Technology that's been around since the 1980s, powered by an AI that makes it smarter than Jira, Asana, Linear, Confluence, and Monday.com combined.
The entire project management layer of Kenektic — a production platform with AI personality engines, real-time messaging, matching algorithms, and nine hundred tests — runs on two text files and one sentence: "Update project documents and call the next phase."
What Comes Next
Next week, I'm going to tell you what it actually felt like when the building accelerated — when features started coming together faster than I thought possible, when the platform stopped looking like a project and started looking like a product, and when the guy who couldn't code two months earlier suddenly felt like Superman.
But his superpower was coding. And he was just getting started.
What's your system? Whether you're building software, writing a novel, running a business, or managing a household — have you ever found a system that changed how you work? Something that took the chaos and gave it structure? I'd love to hear what your version of "two markdown files" looks like.
Kenektic is in development and will launch soon. If you want to be notified when we're ready, or if you want to share your story with me directly, reach out at hello@kenektic.com.
Coming Next: "I Suddenly Was Superman, But My Superpower Was Coding" — When building stopped being learning and started being creating.