đšď¸ /problem-first: a simple skill to invert bad ideas
+ New skills: Bug Gaslight & Wise Session
Hello!
This is đš prodmgmt.world | Becoming Top PMs Together
đ In todayâs edition:
đ /problem-first: a simple skill to invert bad ideas
đ New AI Skills
/problem-first: a simple skill to invert bad ideas
If youâre a PM who walked in on day one to find a roadmap full of solutions the team wants you to ship, you know the bad feeling already. You canât push back without looking obstructionist, and you canât say yes without losing your conviction. The move that gets you out: treat every solution someone hands you as a compressed, imprecise confession of a problem the team senses but hasnât articulated, then decompress it back into the problem underneath.
The team handed you âwe need a new notification system.â Your job is to decompress that into the problem underneath, then check whether the solution they picked is one of three reasonable responses to that problem, or whether they jumped to the wrong one entirely.
This is the most reliable move Iâve learned as a PM walking into a roadmap thatâs already been written. It also runs in reverse for the opposite PM problem, which is when youâre the one with too many half-baked ideas and no way to triage them. Same skill, both directions.
Invert, invert, always invert
Most discovery advice says to stop, do research first, and come back when you have a problem statement. The people giving that advice assume the team will let you slow them down. In real life, teams holding solutions have political and emotional momentum behind those solutions. Telling them to halt and do research is how you burn your influence on day 30.
Instead, you use the solution as the starting point for the research. You treat the proposed solution as a research artifact: evidence of a real pain someone on the team felt, compressed into an answer. Your job is to decompress it back into the underlying problem so the team can see what they were actually responding to.
That gives you a different posture in front of the prebaked roadmap. Instead of standing in front of it blocking it, youâre digging underneath it to find the problem it was meant to solve.
/problem-first
Let me walk you through a real example. Team says: âwe need to build a new notification system.â
The `problem-first` skill runs in one AI call and returns eight sections. This is what comes back:
Solution-jumping diagnosis. What signal did the team detect that made them propose this? Probably: users miss things, support tickets about lost context, complaints that the product doesnât tell them when stuff changes.
Underlying problem. Users canât see when state changes inside the product, and the gap in visibility erodes their trust that the product is doing anything on their behalf.
Assumption challenges. Each with risk-if-wrong and a validation test. Examples:
Assumption: users want more notifications. Risk if wrong: we add noise, adoption drops. Validation: pull notification engagement data from current system.
Assumption: the delivery mechanism is broken. Risk if wrong: we rebuild plumbing and the problem stays. Validation: read the last 50 support tickets tagged âmissed update.â
Assumption: users want real-time push. Risk if wrong: we ship interruption and they turn it off. Validation: ask in the next 5 user interviews.
Problem statement. Users who rely on the product for time-sensitive decisions struggle to know when their context has changed, because the product doesnât surface state changes proactively, which leads to lost trust and reactive support load. Success would mean users discover relevant changes without checking manually.
Three alternative framings. Three framings that surface the jump most teams made at this stage:
Framing A: users donât know when context changed. Solution space: state-change indicators, activity feeds.
Framing B: users donât trust the system is working. Solution space: status visibility, audit trails, confidence signals.
Framing C: users want to delegate watching to the product. Solution space: subscriptions, smart digests, agent-driven alerts.
Notice none of those are âa notification systemâ in the way the team meant it. The first framing points to a UI state pattern, the second to a trust-and-status problem, and the third is closer to an agent. Each one would lead to a different build, but the teamâs brief had folded all three into a single feature spec. Thatâs the move you want to catch before it becomes a quarter of engineering time.
Three sections in there that a human PM under pressure reliably skips: the assumption challenges with risk and validation, the three alternative framings, and the draft message. Skip the framings, and you commit to one solution before seeing the two equally viable alternatives that would have led to different builds. Skip the message, and you end up in an awkward Monday standup where youâve quietly stopped working on the roadmap and nobody on the team knows why.
The reverse use, for the ideas person
This is the version that helped me most personally. Iâm the kind of PM who has a lot of ideas, so my notes fill up faster than my conviction can keep pace with. Lots of generation, lousy triage.
I started running the skill in reverse. You feed in your own idea, ask it to extract the problem you think itâs solving, and check the evidence status field.
Most ideas die at âEvidence Status: none.â
I ran this across a backlog of about 50 ideas. 90% died at evidence status. 3-5 survived with real problems underneath. 1 got pitched the following week with the evidence pack already assembled.
Running this triage protocol finally unblocked the part of me that has lots of ideas. Yes, agents can build anything these days, but you still need to spend time on each idea, even just to write a spec for /goal to execute (and usually it takes more work to babysit).
Being more disciplined about generating ideas doesnât help me, and probably doesnât help other PMs wired this way. In my experience, the real constraint is triage capacity, not idea generation. When you run the skill, you get a triage protocol that addresses the actual bottleneck.
Why this runs better on AI than in your head
You can do this mental work without AI. People have been doing it for decades, after all. A human PM with an hour and a quiet office can produce most of these sections, but under time pressure most PMs skip the hard ones. They skip the assumption challenges with risk and validation. They skip the three alternative framings. They definitely skip the draft message, which is why so many new PMs end up either quietly executing without conviction or making the team feel ambushed.
Running this in AI ensures every section runs every time, because you have to complete all eight outputs before the run produces anything you can use.
Running the skill takes about 90 seconds and produces all eight sections. Writing the same output by hand takes about an hour, and tends to miss the harder sections.
Where this skill lives
`problem-first` is one of the 200+ skills inside PM OS, the Product Managerâs AI Operating System. It runs in Claude Code, Cowork or Cursor on top of your company context files, so the assumption challenges and validation plans come back grounded in your product, your users, and your real constraints, instead of generic PM advice that could have come from any blog post.
You donât have to assemble any of it. PM OS wires `problem-first` into the broader operating layer alongside workflows for strategy, research, decisions, stakeholder work, and measurement.
If you want the full system, itâs here.
New AI Skills
Todayâs skills are engineering-focused, but I think we PMs should not shrink from this, especially if youâre AI-pilled and âvibe codingâ.
Bug Gaslight: This was inspired by a post by Peter Steinberger (OpenClaw creator) that I turned into a skill. Gaslight your own recent code into confessing - assume it is overengineered, has a smaller-delta alternative, an inelegant shape, an incoherent fit, and a latent bug, then prove or rule out each accusation and apply fixes inline before the human reads it.
Wise Session: This was inspired by a post by an Anthropic member of technical staff. Teaches the user to deeply understand a coding or work session through incremental verification, a running checklist doc, why/what/how drilldowns, and AskUserQuestion quizzes.