I’ve been developing products since undergrad and managing them since grad school, but after taking AI courses from Google and Anthropic, it’s changed how and what I develop and manage. Things are moving fast, but here’s what I’m currently doing.
1. Evaluate the product idea and apply Porter’s Five Forces against it
Claude or Gemini: “You are a Chief Product Officer. I’m developing a _____ product. What does the landscape look like for this type of product, from the perspective of Porter’s Five Forces? Cite specific companies or sources where you can, and flag anything you’re inferring rather than sourcing.”
I ask for sources up front because this is the step most prone to a confident, well-formatted answer that’s quietly out of date or invented.
2. Sanity-check the analysis against reality
Before I let step 1’s output shape anything downstream, I run it past a handful of real people in the target market — or at minimum a search for recent news/industry reports on the space. An LLM’s Five Forces breakdown is a good first draft of the landscape, not a substitute for finding out whether the problem is one people actually have.
3. Have it brainstorm some differentiation points if step 1 indicates steep competition
Claude or Gemini: “You are a marketing expert in the _____ industry. For the _____ product I’m developing, help me brainstorm features that I could include at launch, with a cost-benefit analysis for each feature. Format that analysis with the following columns: 1) Feature 2) Cost (low/medium/high) 3) Benefit (low/medium/high).”
4. Create a Product Requirements Document conversationally
Claude or Gemini: “Based on everything you know about _____, I’d like to create a product requirements document, including success metrics and explicit non-goals. Are our previous conversations sufficient, or do you have any thoughts / need clarifications before creating that?”
Asking for success metrics and non-goals up front keeps the PRD from turning into a bare feature list — I want a way to know later whether I shipped the right thing, not just a thing.
5. Find a good CLAUDE.md file for the general tech stack
I currently like [https://github.com/josix/awesome-claude-md](Josix’s curated collection). I’ve done enough systems design to have some strong opinions, and it’s nice to have a lot of the hard work done already.
6. Have Claude Code modify the CLAUDE.md file to match the stack and conventions precisely
I do this almost every time because I run most of my stuff on AWS which is a bit more complicated and less popular than more off-the-shelf alternatives, but I currently trust them the most.
7. Design
I’ve used Sketch, but am transitioning to Figma. I pass designs into Claude Design and further refine them in there.
8. Hand off the Claude Design content to Claude Code
9. Start a new Claude Code session in VS Code
10. Build/Refine one feature at a time
I describe what I’m looking to achieve with a particular feature, why, and to some extent, how.
11. Always ask “Do you have any thoughts or need any clarifications on what I’m looking to create?” before generating any code.
I never assume I’ve perfectly provided all context, and it’s easier to fix things before Claude goes down a rabbit hole.
12. Write tests and run a review pass before merging
Claude Code: “Write tests for this feature covering the happy path and the edge cases we discussed, then review the diff for bugs before I merge it.”
I treat this as a separate step from building the feature, not something folded into step 10 — a fresh review pass (a second session, or a teammate) catches things the session that wrote the code is prone to miss.
13. When the review pass is done, commit/push/merge changes into GitHub
14. Repeat steps 9 through 13 until ready to launch
15. Run a dedicated security review before launch
This is a different mode of scrutiny than the feature-level review in step 12 — auth checks, input handling, secrets, dependency vulnerabilities. AI-generated code has some recurring blind spots here (secrets leaking into client-side code, missing auth checks, injection), so I don’t skip it even for small launches.
16. Launch, then close the loop
Instrument analytics for what shipped, collect real user feedback, and feed both back into step 1 for the next cycle. The product management doesn’t stop being iterative just because the code shipped — launch is a checkpoint, not the end of the workflow.
Share: