PM Toolkit

Overview

PM Toolkit is a personal product management intelligence system that transforms an Obsidian vault (markdown files with YAML frontmatter) into a web-based strategic planning dashboard. It provides strategy-to-execution traceability for individual PMs who want to own their data and generate stakeholder-ready artifacts without a database or SaaS platform.

Core value proposition: Screenshots and exports look professional enough to share directly with stakeholders — no additional formatting needed.

Target users: Individual product managers using Obsidian + Jira/Workboard, who want a unified view from customer signals through strategy to shipped outcomes.

What It Does

• Strategy graph visualization (React Flow + dagre) with interactive node/edge manipulation
• Customer signals pipeline with vectors, KANO grid, and Cost-of-Delay scoring
• Now-Next-Later kanban and Opportunity Solution Tree for planning
• Bidirectional sync with Jira, Workboard, GitHub, and Miro
• Daily task management with Obsidian write-back (line-level conflict detection)
• Stakeholder-ready exports — PDF, PNG, Markdown without post-processing
• Obsidian plugin with validation and quick capture; Chrome extension for Jira/Confluence capture
• CLI for sync, reporting, and changelog generation

How It Fits Together

Next.js App Router monorepo with React + Tailwind + shadcn/ui for the dashboard. All content lives as YAML-frontmatter markdown in an Obsidian vault — the web app reads files via server components, computes dashboard aggregations server-side, and passes pre-computed props to client components. Write-back uses server actions with line-level string surgery and expectedRawLine guards for conflict detection. A shared-schemas package defines Zod schemas for all 23 content types, consumed by the web app, CLI, and Obsidian plugin. Four API client packages handle bidirectional sync with external tools.

Architecture Decisions

• Markdown over database — User data ownership, portability, version control. The tradeoff is no query language and O(N) file scanning for aggregations (mitigated with ISR).
• Schema registry for 23 content types — Exhaustive Zod validation at every boundary. The cost: adding a new content type requires updating the enum, registry, Obsidian detector, and switch cases — four places to forget.
• Line-level write-back — Fine-grained mutations that preserve manual edits, using an expectedRawLine guard for conflict detection. More complex than whole-file writes but essential for a tool that coexists with hand-edited Obsidian files.
• Custom API clients over vendor SDKs — Fine-grained control over rate limiting, retry logic, and sync state tracking. Each client is ~300-400 lines.
• Server actions for write-back — Avoids an API layer; leverages Next.js for direct file access. Tight coupling to the framework is the accepted tradeoff.

Iteration and Lessons

The most significant architectural change came after extended dogfooding: Key Results were promoted from inline OKR sub-objects to first-class file-backed entities. OKR files now hold only a keyResults: [slug] array. This wasn't feature creep — it was a data model correction that only surfaced from sustained real use. KRs are the team-level execution unit; the original model treated them as OKR metadata, which broke every downstream visualization.

The tool grew from a simple changelog viewer to a 23-content-type system with four external integrations. The scope expansion was partly justified (each content type maps to a real PM artifact) and partly a velocity trap — it's easier to add another dashboard panel than to validate whether the existing ones are useful.

The demo mode and feedback infrastructure shipped in v3.3, but no external PMs have used the tool. This is the most honest weakness: months of sustained building without a single external user session. The tool works well for my workflow, but "works for me" is not validation.

The project also documents explicit AI collaboration anti-patterns in dear-new-pm.md: AI cannot replace customer relationships, AI confidently generates plausible-but-wrong strategy, AI hallucinates connections between signals, and the velocity trap (producing artifacts faster while the real bottleneck is judgment).

Weaknesses & Open Questions

• No external validation — Demo mode shipped but no external PMs have used it; building continues without user feedback
• Tag parsing collision risk — Task parser and signal extractor both scan daily notes for #tags; interference is possible
• Sync state partial failures — Can leave inconsistent state between vault and external tools; needs atomic writes
• Schema registry coupling — New content types require updates in four places; easy to miss one
• Write-back race conditions — Two rapid toggles on the same task could read stale line content
• Open question: Is the 23-content-type breadth justified, or would fewer types with deeper analytics serve PMs better?
• Open question: Should this become a multi-user tool, or is "personal intelligence system" the right scope?