agentsclimarketplace

Pm market problems

Skill julianoczkowski/product-manager/skills/pm-market-problems

Run Pragmatic Institute market discovery and validate real market problems before anything gets built. Use when a PM says "I want to build a feature", "do market research", "talk to customers", "discovery", "validate this idea", "is this problem real", "NIHITO", or "who should I interview". Enforces the outside-in rule: build only for problems that are urgent, pervasive, and that the market will pay to solve. Produces a Market Discovery Document and a Market Problems Table as a Markdown or Word .docx artifact.From its SKILL.md

Install
npx -y skills add julianoczkowski/product-manager --skill pm-market-problems

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

SKILL.md

6.1 KB, ~1.4k tokens by cl100k_base, as published. Nobody here has run it

Market Problems — discovery & validation (Framework: Market → Market Problems)

Rule: The answers to most of your questions are not in the building. Discover, collect, analyze and communicate problems found in the market, then validate they are urgent, pervasive, and that the market is willing to pay to solve them. See ../pm-copilot/references/framework.md for the full map.

Who to listen to

The Noisy 20% vs. the Quiet 80%. The noisy 20% (your most excited/unhappy customers plus loud internal voices — an exec's advisory board, a big-client sales rep, support) give a limited, skewed view. The quiet 80% won't come to you; you must go find them (industry conferences — leave your booth; professional associations; LinkedIn; end-user training). Noisy customers don't represent the whole market.

The four market segments — each is "a person with a problem." Balance interviews across all four:

SegmentLens they speak throughThe question to ask
Customers (bought yours)your product"What other problems should we be solving for you that we aren't solving today?"
Competitors' Customersthe competitor's product"What other problems should we solve that your current product isn't solving?"
Evaluators (shopping now)win/loss — don't disrupt the sale"Why did we win (or lose) your business?"
Potentials (not shopping)no lens — best for innovation"What problems are you facing, and why are you not looking for a solution?"

NIHITO — Nothing Interesting Happens In The Office. Recommend ~10 market visits per product manager per quarter. It feels like cold calling, but you aren't selling — state what's in it for them and expect many "no"s.

Discovery techniques

Observation — take thorough notes, look for patterns, minimize interruptions; if something catches your eye, ask. Answer: What do customers do / how / why? What's done manually that could be automated? What's multi-step that could be streamlined? How do they interact with your product? When do they use other systems, search for info, or need help?

Interview — prepare beforehand; use high-gain, open-ended questions; spend most of the time listening, not educating. Ask: What obstacles keep you from your goals? How are your goals measured? What do you think about our product/company? What else have you considered? How bad is the problem? How bad do things have to get before they're fixed? Where does this fall on your priorities?

Validate the problem — the three-part test

An opportunity is the intersection of all three (fail any one → don't build):

  • Urgency — When is it urgent? Where is the urgency coming from? What's the level?
  • Pervasiveness — Is it big enough to build a business on? (look for the quiet 80%)
  • Willingness to pay — Is it painful enough to pay to solve? Who will pay — and will they pay you?

Validate quantitatively with surveys (close-ended questions on the three criteria — avoid leading questions) and experimentation (inexpensive, low-fidelity tests of your hypothesis).

Interview the user (batch questions)

  1. What product/feature area, and who do you think has the problem (persona/segment)?
  2. What evidence do you already have (interviews, tickets, win/loss, usage, surveys)?
  3. Which of the four segments have you actually talked to? Which are you missing?
  4. For each candidate problem: how urgent, how pervasive, would they pay — and what's the proof?

Artifact templates

Market Discovery Document (one per visit/interview — one file each, named

01-market-discovery-<contact-or-org>.md per artifact-output.md)

# Market Discovery Document

**Company:** <company>  ·  **Feature / Product:** <feature / product name>
**Author:** <author>  ·  **Date created:** <date>  ·  **Version:** 1.0

## Contact Info
- **Name:**  |  **Title:**  |  **Organization:**
- **Work phone:**  |  **Email:**  |  **Website:**

## Product Info
- **Product name:**

## Purpose of Call
<why you're talking to them>

## Call Notes
<what they said — verbatim where possible>

## Key Observations and Problems
<problems in the persona's first-person voice; note urgency / pervasiveness / willingness-to-pay signals; which segment>

Market Problems Table (roll-up across discovery)

# Market Problems Table — <product / market>

**Company:** <company>  ·  **Feature / Product:** <feature / product name>
**Author:** <author>  ·  **Date created:** <date>

| Persona | Problem Name (first person) | Market Evidence | Impact (1–5, 99999=contractual) | Priority (Evidence × Impact) | Group |
| :--- | :--- | ---: | ---: | ---: | :--- |
| <persona> | "I can't …" | <count of inputs> | <1–5> | <=E×I> | <theme> |

**Market Evidence** = tally of documented occurrences across inputs (interviews, surveys,
sales calls, support tickets, win/loss, analyst reports, reviews, usage data).
Sort by Priority descending. Problems that clear urgent + pervasive + willing-to-pay
become candidate requirements.

Deliver the artifact

Follow ../pm-copilot/references/artifact-output.md: confirm inputs (flag thin evidence and recommend specific NIHITO visits to fill it), ask Markdown or .docx, write the .md, and convert to .docx on request via your environment's native document-creation capability. Then offer the next stage: define pm-personas for the people who have these problems, or write pm-positioning around the validated problems.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most docs writing skills give in ~1.4k tokens

Counted across 1,951 of the 3,904 authors here whose files we hold, read 2026-09-06

  • Use third-person for skill descriptionsin 54 of 1951, across 35 files
  • Start descriptions with Use whenin 43 of 1951, across 29 files
  • Run baseline scenarios before writing any skillin 40 of 1951, across 26 files
  • Use active voicein 40 of 1951, across 36 files
  • Map file responsibilities before defining tasksin 36 of 1951, across 29 files
  • Use checkbox syntax for tracking stepsin 35 of 1951, across 27 files
  • Ask one question at a timein 35 of 1951
  • Offer execution options after saving the planin 33 of 1951, across 24 files
  • Include complete code in every stepin 33 of 1951, across 27 files
  • Design units with clear boundaries and interfacesin 31 of 1951, across 23 files
  • Announce the skill usage at the startin 30 of 1951
  • Verify agent compliance after adding the skillin 29 of 1951, across 17 files

Said here and by no other author read

  • Discover and analyze problems found in the market
  • Validate problems are urgent, pervasive, and worth paying for
  • Balance interviews across four distinct market segments
  • Conduct ten market visits per quarter
  • Listen more than you educate during interviews
  • Use open-ended questions to identify obstacles

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.