I became a one-person product team. Here's what it taught me.

I have what Rick Rubin would call "no technical ability."

I am a product person. Over ten years working with engineers and designers. Never written a line of code in my life. And yet, over the last few weeks, I have used Claude Code to launch Career Badger end-to-end: iOS app, web app, marketing website. No engineering team. No design partner.

Just me, a $90 Max plan from Anthropic and the terminal.

TLDR? I would describe this as equal measures of inspiration, frustration, messianic ecstasy and boredom.

Tell me what you think? www.careerbadger.io

Here is the story so far...

Why I tried it now.

Last year I had a go at this with Lovable and ChatGPT's design and prototyping features. The results were mixed. Not all bad, not all good. Promising in flashes, frustrating in stretches, not yet good enough to launch anything I'd put my name on.

Then earlier this year I caught a podcast where someone from Anthropic said, roughly, that "100% of the code in Claude Code is now coded by Claude Code." Try saying that quickly. The line stuck. So I thought it was time to try again.

Sat in front of terminal, I kept being reminded of the next part of the Rick Rubin interview.

"So what are you being paid for?" Anderson Cooper asks.

Rubin's answer: "The confidence I have in my taste. And my ability to express what I feel."

It's a quote that has been widely co-opted, perhaps misguidedly by us product managers. So I imagine myself sat opposite Cooper as he quips;

"Okay then. Let's see if that's true, shall we?"

How I'm building with Claude Code

The loop has settled into something repeatable.

Start in Chat, not in code.

I take a feature idea into Claude in Chat mode first, desktop or browser. I describe the customer problem and the solution in plain language and ask Claude to turn it into a PRD-style spec with scenarios, edge cases and acceptance criteria. I give it the simple version. Claude thinks through the failure modes I'd have missed.

Tell it not to write the technical spec.

I am a believer in a "Church and State" division between product and engineering. I would never write implementation detail into a user story for a development team and I do not write it into a prompt for Claude either. Left alone, Claude will happily produce a deeply detailed technical approach down to which deployment tools to use. So I tell it explicitly to focus on the feature, the outcome, the acceptance criteria. The architecture decisions are better made later by Claude Code, which has more context on the actual code base and tool set.

Move into Claude Code in plan mode.

After two or three iterations in Chat, often with screenshots attached, I paste the refined spec into Claude Code in the terminal in Plan mode.

Prototype the UI first.

This is the step that improved things dramatically. For most features the first release is now a clickable UI prototype that Claude Code builds in plain HTML and CSS. I can feel the feature, iterate the idea and surface UX problems while they are still quick and low cost to fix. Five or more prototype iterations is normal before Claude Code writes a single line of the production solution. I also use this step to strip the spec down to a real MVP and scope the "fast follow" features for later.

Build and test locally.

Claude Code then uses Expo to build a local version of the product. There are limitations as a solo builder, e.g. I don't have a full staging environment. I test locally and iterate. I push to production quickly and continue testing there.

Important.

The one instruction I lean on at almost every step:

"Ask clarifying questions, flag issues, make suggestions as needed."

That single line does more for me than any prompt I have written. It turns Claude from an order-taker into a thinking partner. It surfaces ideas and edge cases I would never have considered on my own and sometimes some impressive design flourishes. It is also, not coincidentally, exactly how product people should work with human engineers and designers.

What have I learnt from this experience?

Ultra agility is here!

Claude Code gives me multiple high-fidelity prototypes in minutes. The only real constraint on producing new versions and variants is how quickly and accurately I can "express what I feel" i.e. give actionable feedback. Then I need the "confidence in my taste" to decide which updates to develop and launch first.

Good judgement and decisiveness have never been more valuable. So you'll be relieved to hear that Claude Code also helps with this. Asking for trade-offs on feature selection and Claude's recommendations increases decision making speed and avoids painful errors.

So what does this mean for the classic trio of product, engineering and design?

Product (Valuable)

Picking the right problem to solve and framing it clearly. Knowing what good looks like and what to cut. The judgement calls an AI tool cannot make for you because it does not know your users, your market, or your strategy.

This is the Rubin job.

Engineering (Feasible)

This is how engineers really bring value with AI built products, deciding on technology solutions to answer questions like; Will the product hold up under thousands, perhaps millions, of users? Is customer data secure? Do the systems work cost-effectively? Will the architecture still work a year from now?

When a product person can take an idea to a working solution, engineering spends far less time translating specs into code. What's left is the high-leverage work that decides whether the product survives human customers (and bots) in the real world.

Design (Usable)

Is it easy to use and does it achieve the customer's job to be done? Do all the edge cases still work, not just the happy path? Is the design language and the mental model consistent across the product?

Once a working v1 can be built in hours, the design loop changes dramatically. The first release becomes the baseline version. Design is free to run A/B tests against it, watch cohorts, optimise flows in hours or a few days rather than weeks, months or quarters.

The danger I see...

A team of three with Claude Code should now be able to achieve a lot more, a lot faster, than a team of ten to fifteen was one or two years ago. So far so good...

But the risk is that these disciplines stop collaborating with each other and work alone with their own AI agents. Siloed working; the thing that product managers have (mostly) been advocating against for... as long as I can remember!

This is what I would worry about most when running a product org right now. The fix is not to do less with AI. It is to invest harder in the collaboration, sharing and communication that have always been the hallmarks of strong product teams. Shared discovery sessions. Cross-functional reviews. Pairing between disciplines.

For high performing team AI does not weaken the need for these things. It should strengthen it!

Try Career Badger: a week of Plus, free. Career Badger is live and free to use. Sign up with my referral link and you also get one week of Career Badger Plus, which includes unlimited CV downloads.

I'm building it in public and writing more about the method as I go. If you're rethinking how your product, engineering and design teams work together in the AI era, I'd love to compare notes.

Or if you're looking for a product person who can think in problems and launch solutions, whether that's a role or a consulting brief, my inbox is open.