James Lal

I use Claude Code all day as a Product Manager. I built 18 custom Claude Code commands that I'm giving away for free. See comments for the link. I use these in Nimbalyst as its the best way to work with Claude Code - https://nimbalyst.com, but these custom commands will work however you use Claude Code: /plan - Feature planning /prd - Create structured PRDs /strategy - Strategy documents /competitive - Competitive analysis /research - Market research synthesis /customer-interview - Customer interview guides /customer-interview-simulate - Simulate customer interviews /feedback-analyze - Analyze customer feedback patterns /understand-feature - Examine codebase for feature context /mockup - Generate UI mockups /documentation - Create documentation /edge-cases - Identify edge cases /bug-report - Document bugs /triage-requests - Triage incoming requests /status - Development status updates /github-status - GitHub progress summaries /launch - Launch announcements /sales-enablement - Sales enablement materials

176

29 Comments

I thought this was a good and very reasonable talk by Eleanor Millman on how to prioritize projects for a platform engineering team: https://lnkd.in/gaYtUHRH A few insights I took from it: - Unlike product features which can be more directly tied to revenue, platform engineering work is a couple steps removed. But that doesn't mean it's unimportant! Far from it, platform engineering projects can make everyone at the company more efficient, able to produce higher quality software, etc. - While "urgency" is always going to be a factor, you don't want to just be putting out fires, you want be able to prioritize work which is "high impact" ... even if that impact isn't felt immediately. - Good rule of thumb: prioritize "highest impact for lowest effort". - The talk has some ideas on what factors to choose for impact, and how to blend them. For instance "speed of development" is one factor, "cloud cost optimization" might be another. The weighting of different impact factors can change over time, depending on the needs of the business. I would say that a lot of companies don't have much methodology here but I can really see the value in codifying it. You can always change the methodology or the weighting if it's spitting out results that don't pass the smell test or you really feel it is leading the company astray. Clarity can give the org more freedom to put resources behind projects that would otherwise never be taken on. When things are unclear, prioritization still happens implicitly, but the decisions tend to be a lot more random and fear-based and the org is worse off as a result.

15

3 Comments

During the "Ambient Agents" meetup last week, Brace Sproul gave us a walkthrough of Open SWE, a coding agent built on Langgraph. Open SWE monitors GitHub issues. When it gets a new one assigned, it kicks off a multi-agent architecture with a Manager, Planner, and Programmer. It can receive messages from users at any time during the process and incorporate them into the state. Check out the slides for diagrams explaining each agent: https://lnkd.in/g3PnNHqG And the code: https://lnkd.in/gY68TKYy I found the takeaways really interesting: * Summarization is hard: Especially with code changes that can get quite long, you literally can't send the entire context history to the LLM, and highly detailed old diffs may distract it. IIRC, the agent sends the last 20 messages, and summarizes the changes before. * Agentic > hard coded: Open SWE tends to use the agentic approach of "here are your tools, pick which one to use" for almost all tasks. Except for one.. * Explicit error handling: When an error happens, Open SWE stops everything and focuses on resolving the error. Otherwise, it could get too far afield and be unable to get back to a good place to solve the error. (Hopefully I didn't mis-represent anything I heard!) #Langchain #Langgraph

93

3 Comments