6GTM Track · Module 6 · 3 min

Competitive Positioning

How to position against GitHub Spec Kit, Anthropic's harness, LangChain agents, and (soon) every closed-loop entrant. The Dunford "alternatives, differentiated value, ideal customer" frame applied to PM33.

In this module

  1. The category-creation framing
  2. vs. AI codegen tools (Cursor, Copilot, Cline, Replit, Devin)
  3. vs. traditional PM tools (Jira, Linear, Asana, Productboard, ProductPlan)
  4. vs. status quo (spreadsheets + Notion + standups)
  5. What NOT to position against
  6. The research foundation — Dunford, Play Bigger
  7. Anti-patterns

The category-creation framing

PM33 is a category-creating product, not a feature comparison in an existing category. This distinction is structural to how you position competitively.

Two canonical frameworks:

April Dunford, Obviously Awesome (2019) — the practitioner-canonical positioning book. Her core insight: position against the customer's most likely alternative, which is often "do nothing" or "use the tool they already have," not your obvious competitor.

Play Bigger (Ramadan, Peterson, Lochhead, Maney 2016) — the category-creation canonical. Don't compete in existing categories — define and dominate a new one. The "Category King captures 76% of category economics" claim originates here. Christopher Lochhead's 2024 evolution at Category Design Advisors emphasizes "point of view" (POV) as the load-bearing artifact — more useful framing for PM33 than the original "lightning strike" tactic.

PM33's POV: the closed loop from strategy to outcome to recalibration is the new product category. AI codegen, PM tools, spreadsheets — all serve different layers. We don't replace them; we add a layer they don't have.

The competitive conversation should never be "PM33 vs. competitor X." It should always be "here's the category PM33 occupies; here's where competitor X sits; here's where the gap is."

vs. AI codegen tools (Cursor, Copilot, Cline, Replit, Devin)

Wrong frame: "PM33 is better than Cursor."

Right frame: "Cursor is a productivity tool. PM33 is a strategic execution platform. Different categories. Coexistence is the answer, not displacement."

The talking points

  • "AI writes code" is table stakes in 2026. Every PM tool, dev tool, and IDE makes this claim. It's no longer a differentiator.
  • "AI-driven strategy → outcome attribution → recalibration" is the product category. This is what's actually scarce.
  • PM33 doesn't replace Cursor. Engineers can still use Cursor in their editor. PM33's harness coordinator invokes Claude Code (which works alongside Cursor); the layers compose.
  • The two tools optimize for different things. Cursor optimizes for keystroke-velocity. PM33 optimizes for outcome-attribution velocity. Conflating them is a category error.

Honest acknowledgment

If the buyer says "we have a deep Cursor adoption" — that's a positive signal. It means the team is already comfortable with AI-augmented coding. PM33's harness extends the same Claude Code workflow they're using. The conversion shape is: "your team's already adopted AI-assisted coding; now add the closed-loop attribution layer."

The reverse-question

If a buyer compares PM33 to Cursor directly, ask: "Help me understand the comparison — are you evaluating us as an alternative to your AI coding tool, or as something that works alongside it?" Their answer tells you whether you have a positioning problem or a category problem to solve.

vs. traditional PM tools (Jira, Linear, Asana, Productboard, ProductPlan)

Wrong frame: "PM33 is better than Jira."

Right frame: "Jira is a work-item database. PM33 is a closed-loop platform. PM33 sits on top, doesn't replace. Bi-directional sync means migration risk is zero."

The talking points

  • Traditional PM tools store work items. PM33 attributes outcomes to those work items.
  • PM33 has bi-directional sync with Jira, Linear, Asana, GitHub Issues, Productboard. Your team's existing workflow stays intact. The closed-loop layer sits underneath.
  • No rip-and-replace. This is the single most important point. Most enterprise PM-tool customers have multi-year commitments and adoption costs they don't want to write off. PM33 adds a layer; it doesn't replace tools.
  • The closed loop is the missing layer. Jira doesn't compute outcome attribution. Linear doesn't. Asana doesn't. Productboard does some, but at the planning layer, not the post-ship attribution layer. PM33 occupies the empty space.

The "we just bought Productboard" objection

This is a structural objection (not surface). If a buyer just made a 3-year commit to Productboard, the question is whether PM33 can layer over Productboard or whether Productboard is their de facto closed-loop attempt.

Honest response: Productboard does discovery + planning well. It doesn't close the outcome-attribution loop the way PM33 does. We sync bi-directionally with Productboard; you keep using it for what it's good at and add PM33 for what it doesn't do. Pilot scope: 1 strategic objective, 6-12 weeks. See if the attribution layer pays for itself.

vs. status quo (spreadsheets + Notion + standups)

Wrong frame: "PM33 is more sophisticated than your spreadsheet."

Right frame: "Acknowledge the spreadsheet works for 1 PM with 2 objectives. Ask what it costs you at your current scale."

The talking points

  • Acknowledge the path of least resistance. "Yeah, you can do this in spreadsheets." Don't insult the buyer's current solution; recognize they're rational.
  • Then ask what it costs. "How many hours per quarter does your team spend assembling attribution data from spreadsheets for the QBR? When was the last time the QBR data revealed something the team didn't already know?"
  • The math is breakdown-by-scale. Spreadsheets work for 1 PM with 1 objective. Break down at 5+ PMs and 10+ objectives because attribution becomes manual, stale, and incomplete.
  • The cutover moment is usually a quarterly review where the attribution memory failed. "Tell me about your last QBR — was there a strategic objective where the team couldn't agree on whether shipped work moved the metric? That's the moment PM33 exists for."

The Notion / Confluence / Coda variant

Many orgs run sophisticated knowledge bases that feel like outcome-attribution systems. They're not. They're well-organized memory. PM33's bi-directional sync with Notion / Confluence / Coda means the team's existing documentation stays canonical; PM33 adds the computational layer for predicted-vs-realized.

The "we'll build it internally" variant

Some orgs (especially well-resourced ones) propose building closed-loop attribution internally. Engage directly:

  • Build time: 4-6 engineer-quarters to feature parity with mature commercial platforms (rough estimate from in-house attempts we've observed). Vendor adoption: 2-3 quarters to operational maturity.
  • Compounding cost of delay: every quarter spent building internally is a quarter without compounding workspace priors.
  • The honest framing: if you have a platform team that wants this as a strategic build, go for it. If your platform team is over-committed and this is "we'll get to it next year," adopt PM33 now and migrate later if needed (all data is exportable).

What NOT to position against

Three patterns that hurt more than help:

Don't position against internal AI tools

If your buyer's company has built an internal AI tool, don't compete with it — partner with the AI team. The internal AI team usually wants their tool adopted; they don't want a third-party tool displacing their work. The right framing: "PM33's harness invokes Claude Code, which can call your internal models. We're the orchestration + attribution layer; your AI team owns the model layer."

Don't position against other closed-loop platforms

As of 2026, there isn't a serious closed-loop attribution competitor. GitHub Spec Kit, Anthropic's harness, Cursor's internal tooling — all converge on similar patterns but none ship the full closed-loop attribution layer. If a buyer mentions a competitor you're not aware of, ask: "What specifically would you want to compare?" Their answer tells you whether the competitor is real or imagined.

Don't position against the buyer's prior failed AI tool

If the buyer's company tried an AI tool that failed, don't relive the failure. Acknowledge it ("that's the Gartner 60% abandonment experience"), then pivot to why PM33 is structurally different (closed-loop attribution as differentiator, not productivity claim).

The research foundation

Dunford on positioning (practitioner-canonical)

April Dunford's positioning framework is the most actionable guide for B2B SaaS positioning. Three of her tools directly inform this module:

  1. Position against the customer's most likely alternative — for PM33, that's often status-quo (spreadsheets) or "do nothing," not Cursor.
  2. Define your market category — PM33 occupies "closed-loop AI product development," a category we're actively creating.
  3. Lead with differentiated value, not features — outcome attribution is the value; the harness, AR(1) priors, etc. are the proof.

Play Bigger on category creation (practitioner-canonical)

Play Bigger (2016) and Lochhead's Category Design Advisors current work emphasize:

  • Category King captures 76% of category economics. The structural argument for being explicit about the category, not just the product.
  • POV is the load-bearing artifact. PM33's POV is "the closed loop from strategy to outcome to recalibration is the new product category." This is what wins the long game.

Honesty flag on Crossing the Chasm

Crossing the Chasm (Moore, 1991) is widely cited but somewhat dated for AI-era category creation. Moore's chasm model assumes a stable category with predictable adoption curves; category-creating AI products often have no chasm because there's no category yet. Cite Moore only for the early-majority/pragmatist psychology, not for the adoption-curve mechanics.

Anti-patterns

  1. Feature-by-feature comparison. "PM33 has X; competitor has Y." This frame loses because it implies you're in the same category. Always pull the conversation up to category.
  2. Disparaging competitor tools. "Jira is bloated" / "Cursor is just autocomplete" — these read as defensive and disrespect the buyer's prior choices. Acknowledge what competitors do well; explain where PM33 occupies different space.
  3. Avoiding competitive questions. If a buyer asks about competitor X, engage directly. Evasion looks like fear. Engagement looks like confidence.
  4. Over-explaining the category. "We're a closed-loop AI product development platform that..." If you need more than 8 words to name the category, the category isn't clear yet. Practice the one-sentence category statement.

Sidebar — how PM33 supports competitive positioning

Three resources to send the buyer before the competitive conversation:

  1. The case study — engages METR, Perry, DORA counter-evidence directly. Establishes intellectual honesty.
  2. Executive Module 1 — strategic case for why the category matters. The McKinsey 5.5% number is the wedge.
  3. Executive Module 3 — DRI sponsorship pattern, which preempts the "we already have AI tools" framing.

If the buyer reads these before the competitive conversation, they arrive pre-anchored on category, not on feature comparison. The competitive conversation becomes 5 minutes of confirmation, not 30 minutes of fight.

Discussion prompts

For team practice:

  1. The category-statement test: state PM33's category in 8 words or less. Practice. Refine. The team should converge on the same statement (consistency matters).
  2. The competitive-pivot test: a peer raises a feature comparison ("Cursor has X, does PM33?"). Practice pulling the conversation up to category without dismissing the question.
  3. The honest-acknowledgment test: a peer says "our team loves Linear." Practice acknowledging the team's prior choice (Linear is good!) while introducing the category gap (Linear doesn't close the outcome-attribution loop).
  4. The "we'll build it" test: a peer says "we have a platform team that wants to build this internally." Practice the build-vs-buy conversation without sounding defensive about competition.

Further reading