Polly Allen opened the episode by telling her audience that I scream vocals in metal bands.
That is true. It is also, I promise, relevant. The drumming and the screaming are how I stay sane, and staying sane is the whole reason ClearList exists.
Polly hosts the AI Product Leader Podcast. She used to be a principal product manager on Alexa AI, so she asks the questions a PM would ask, not the questions a hype account would ask. We talked for forty minutes about how a product manager with no engineering team built a working product with Claude Code, and what I would tell anyone about to try.
A quick note before the rest. We recorded this a few months ago, and two things have moved on since. The prices I mention in the episode are the old launch prices. Today it is $20 for up to 50 items or $39 for up to 200, one-time, no subscription. I also mention a move to Istanbul. That plan changed.
Where this started
My father smuggled a computer into Syria from Lebanon in the nineties. As far as fifteen-year-old me could tell, it was the only one in Damascus.
That computer is why I studied computer science in Istanbul. From there I ended up as the UX and localization lead on an Arabic Farmville clone at Peak Games, then spent more than a decade in product management, Zynga included. It is not why I built ClearList. Facebook Marketplace is why I built ClearList.
I had moved enough times to know exactly how selling my stuff would go. Fifty "is this still available?" messages a day. I say yes. Silence. Someone else says they will come Saturday. Saturday arrives. They do not.
So I wrote down the outcome I wanted, and it was not a feature. It was: sell everything I own without losing my mind.
Start with the outcome, not the app
This is the first thing I told Polly, and the mistake I see most often.
People open Claude and type "build me an app that sells my stuff." Then Claude fills every gap with its own assumptions, and you find out which ones were wrong three weeks later, after it has built on top of them.
I did it the product manager way instead. I used Tony Ulwick's outcome-driven innovation, which is jobs-to-be-done with a way to rank the jobs. I had Gemini dig through Reddit for the problems people actually complain about when they sell before a move, and ranked them by how often they came up. "Is this still available?" was not subtle. There are thousands of those threads.
Then I brainstormed several answers to "how do we cut the back and forth?" before picking one. A reservation system won. But it won against alternatives, which is different from being the first idea Claude offered.
Draw the worst path
Once I had the happy path, I asked Claude to imagine the worst one with me. Everything that could go wrong between a seller and a buyer, all of it, and then to draw it as a diagram.
The diagram is the part I would not skip. The model wants to reach a solution quickly, and it will happily skate past the messy middle. A drawing makes it put every failure on the page. The buyer who reserves and then vanishes. Two buyers who both want the couch, and only one of them gets it. Once those were visible, the order of what to build next mostly picked itself.
That is where ClearList's queue came from. If the first buyer does not show, the next person in line gets their turn, and the seller does not have to scroll back through old messages to find them.
Minimum lovable, because code is cheap now
My first working version was tiny. One item, up to five photos, a generated listing, and pickup scheduling.
I could have shipped that. I did not, because the outcome was my sanity, and that version would not have saved it. Code is cheap now, so I went for a minimum lovable product instead of a minimum viable one. I kept building until I would actually trust it with my own apartment.
Today you can walk around the house photographing everything, drop up to 50 photos in at once, and a group of agents sorts out which photos show the same item and drafts each listing with a price range. When it is unsure how it grouped something, it flags it so you can split or merge the photos yourself. Then it all goes on one link, and buyers add several items to one basket instead of messaging about each one.
The plan matters more than the code
I cannot say this strongly enough. Most of my time goes into the plan, not the code.
The full plan lives in my CLAUDE.md, so Claude Code always knows what comes next. Some nights I am watching Netflix and my phone tells me a task is done. I read it, I say "what's next on the plan?", and it keeps going.
Two lessons came the hard way.
Keep CLAUDE.md small. As the product grew, that file grew, ate more of the context window, and Claude started getting sloppier. The rule I try to hold now: a short main file, with a smaller CLAUDE.md inside each feature folder and links from the main one. Claude reads only what it needs for the part it is working on.
Ask whether the answer is current. Claude's knowledge stops months before today. It recommended Next.js 14 when newer versions were already out, and I lost a weekend rebuilding. Now I ask "is this the best option as of today? Go check the docs."
Four rounds of review, because nobody else reads my code
I do not have an engineer reading behind me, so I built a chain of reviewers.
Claude writes a plan. Then I hand it to Codex and ask it to break the plan. Claude fixes the holes, builds it, and reviews its own code. Codex attacks the code. When the pull request opens on GitHub, Kilo Code reviews it again with a different model. On top of that I run a security review from Garry Tan's gstack skills and Matt Pocock's "improve codebase architecture" skill, which finds the fragile shortcuts a model takes when it is racing toward the goal.
Different models catch different things. That is the whole point of the chain.
Ask why, every time
Polly asked whether I understand everything these tools tell me. Honestly? With patience.
In more than ten years as a PM I never really touched GitHub. The problem with learning technical product management is that you need engineers to sit with you, and they never have the time. Claude has the time.
So I do not say "fix this." I say: why is this the best solution? What else could we have done? Which other files does this touch? What happens to the user if we ship it? And when the answer goes over my head, I tell it to explain it like I am in tenth grade. It never gets grumpy about it.
I am not an engineer now. But I can find my way around GitHub and Firebase now, and I can read a cron job and tell you what it does. That happened one "why?" at a time.
The rest of the toolkit
- Google Stitch for UI design. I prototype a flow there, then hand the screens to Claude Code and build from them.
- Remotion, through a Claude skill, to turn app screens into short how-to videos for social media.
- Claude Opus for planning, Sonnet for most coding, which is how I stretch my plan's limits. When I hit them anyway, I pet my dog and stare at the wall until they reset.
If you have a pile of stuff to sell
That is the part ClearList does. Try it on one item without making an account, or see how to run a whole sale from Claude, ChatGPT, or another assistant.
And if you are building your own thing with Claude Code, watch the episode. Polly's questions are better than my answers. I will keep sharing the workflow on LinkedIn as I go.