The Hidden Curriculum of Product Careers
Lenny Rachitsky's latest Community Wisdom edition captures something rare: the unfiltered anxieties of professionals navigating career transitions, hiring pitfalls, and workflow bottlenecks in real time. What makes this collection notable is not the polished advice but the raw uncertainty beneath it—engineers wondering if they can call themselves product managers, founders about to make their first growth hire, teams drowning in bug reports while AI promises automation.
The Resume Title Trap
Scott Yoshi Komada posed a question that haunts anyone pivoting careers: after ten years as a software engineer doing product work without the title, what should his resume say? Product Engineer? Product Manager? Associate Product Manager? The tension between honesty and aspiration is palpable.
Lenny Rachitsky writes, "Your resume is supposed to be helpful to a hiring manager in figuring out who you are." This reframes the entire problem—the resume isn't a legal document, it's a communication tool. Joshua Herzig-Marx adds bluntly: "If you're applying for product management jobs and you can honestly call what you were doing product management, then absolutely give yourself the product management title."
The community's verdict leans toward confidence. Miroslav Pavelek suggests "Lead Product Engineer." Roi Lavan pushes further: "I'd change to full-stack engineer turned product. It doesn't mean that you have to hold the title officially, it means that you did the work."
Critics might note that this advice assumes hiring managers reward clarity over credentialism. In large organizations with rigid HR systems, self-appointed titles can backfire. The tension between "who you actually were" and "who the system recognizes" remains unresolved.
Roi Lavan, who co-led the product team at ZipRecruiter, delivers the hardest truth: "The average recruiter spends 6 seconds on your resume to determine if you're worth contacting." Any noise or generic description plays against you. Scott's original resume listed "Measure product outcomes using analytics (Mixpanel) and iterate based on data to achieve measurable improvements"—which roi Lavan correctly identifies as literally describing the job, not demonstrating impact.
"Product + Engineering + Design(?). That is the trifecta!!! You're the product. That's it."
This anonymous comment cuts through the anxiety. Scott's unique position—spanning code, product decisions, and likely design coordination—is an asset, not a liability. The challenge is making it visible.
Growth PM Hiring: Where Companies Stumble
Travis Bjorklund asked about mistakes when hiring a first growth product manager at Boldin, a retirement planning app. The responses reveal systemic patterns that repeat across startups.
Călin observes from design work with seed to Series B companies: "Growth PMs need ample design and eng support." Ilya Subkhankulov lists structural failures: "Growth team either overlapping, conflicting or misaligned with the Marketing team. Whichever is closest to CEO has more authority. Growth team with minimal design/eng resources/support. Perception of poor ROI by CFO."
Critics might note that these aren't hiring mistakes—they're organizational design failures. A growth PM hired into a company without design capacity or with marketing/growth turf wars will fail regardless of individual skill.
Anuj Adhiya identifies a deeper error: "Not knowing what your biggest vector for growth is going to be. For example, product-led growth or paid ads might be what you need, and as a result not hiring somebody who would be a force multiplier for that vector you need for the next stage of growth." This echoes classic growth hacking doctrine—know your lever before hiring the operator.
alexa delivers the most specific warning, relevant to fintech products like retirement planning: "Conflating domain expertise (SME in tax laws) with growth skills (convincing people to buy the product)." When teams hire a subject matter expert to run growth, "it results in a risk-averse and exact experience. Those traits are great for compliance, but for growth every field becomes 'required,' with a 30-inch legalese page and 9 checkboxes." The consumer app ends up mimicking a Fortune 500 bank experience.
Critics might note that in regulated industries like retirement planning, compliance isn't optional. The tension between growth velocity and regulatory constraint is real—alexa's warning risks understating how much fintech growth is compliance-limited.
AI Bug Reporting: Culture Over Tools
A third thread asks about using AI to speed up bug reporting. The prototype builder wants to "point at things and make bug tickets appear"—a universal frustration.
Marc Dupuis frames the cultural divide: "Team A: Needs bugs filed in a backlog and they need to be pushed and prodded to prioritize them and fix them. Team B: You just ping them on Slack with a screenshot or recording and they take ownership and just fix it." His principle: "If prioritizing a bug is taking longer than it would to fix it, we're doing something wrong."
Neal Oliver describes an emerging pattern: "I have seen setups where Claude lives in Slack and they just at-Claude to report the bug and Claude fixes it and submits a PR." Huy confirms this works in practice: "Make a PR, then dev will review it later." Another setup: "store all bug screenshot in a folder, connect Claude Code to that folder and ask it to write bug report and push to Jira using Atlassian MCP."
Chris Timms reports engineering teams automating "maybe 80% of the process, from reporting to investigation to communicating the severity." For minor bugs, resolution happens automatically. The constraint: "this is hard, because it's a brownfield 15-year-old codebase with... shall we say, customisations."
Critics might note that these workflows assume teams have already adopted tools like Playwright for test automation and have CI pipelines capable of auto-merging AI-generated PRs. Teams without that foundation will find AI bug reporting adds friction, not speed.
Bottom Line
Lenny Rachitsky's community threads expose the gap between professional identity and institutional recognition. The resume advice is sound—claim the work you did—but assumes hiring systems reward clarity over credentials. The growth PM warnings are sharp, especially the SME trap, though they understate compliance constraints in regulated sectors. The AI bug-reporting workflows are real but require cultural readiness that most teams lack. The trifecta—product, engineering, design—is rare. The infrastructure to support it is rarer.