The relational spec of what you're actually building. Status rolls up. Marketing can read it.
PD is a structured workspace for the entities your product consists of — solutions, features, models, attributes, controllers, lifecycles, events. Document them relationally. Track status that rolls up from a half-finished attribute to a parent solution. Visualize the dependency graph. Attach decision logs and design notes to any node.
GitHub Projects tracks issues. m18t tracks the product.
Most product organizations use issue trackers (GitHub Projects, Linear, Jira) to manage tasks, and Notion to manage specs. The two never agree. The spec says "we're building a recommendation engine"; the issue tracker has 47 unconnected cards. The marketing team can't tell what's actually shipped. The founder context-switches between both and re-syncs them in their head.
PD takes a different shape. Not tasks. Entities. Your product is a hierarchy of solutions → features → models → attributes, with controllers and roles and policies and lifecycles attached, and the views/layouts/components that render it. Each entity has a status, an owner, and rich-text artifacts attached. The graph between them is the actual product architecture.
When the architecture and the work-tracking are the same workspace, you can't ship something marketing doesn't know about.
A vocabulary for what your product consists of.
Opinionated MVC-flavored. Use the layers you need; ignore the ones you don't. Many solo founders use only Solutions + Features. Technical teams use them all.
Solution
Top-level. A product or a major product area. Holds features.
Feature
A unit of functionality inside a solution. Holds models, controllers, events.
Model
A data entity in your product's domain. Has attributes, controllers, lifecycles.
Attribute
A field on a model. Type plus (for relations) target model with mapped_by / inversed_by directionality.
Controller
A handler on a model (find, create, update, custom). Junctions to roles and policies.
Policy
A reusable authorization rule applied to controllers or models.
Role
A user-role definition in your product's auth model.
Lifecycle
A model hook (beforeCreate, afterUpdate, etc.) with notes describing what runs.
View
A UI page/screen in your product. Holds components and middleware.
Layout
A UI shell wrapping views. Holds components.
Component
A reusable UI block referenced by views or layouts.
Middleware
Request-level interceptor logic, attached to views.
Event
An analytics event your product emits. Folding into PD as pd_events on roadmap.
Capabilities, listed honestly.
13 entity types covering MVC-flavored architecture
Use the ones that fit your product. Solo founders may only use Solutions + Features; technical teams use all 13.
Status rollups from leaf to root
Attribute status rolls up to model, model to feature, feature to solution. See "how done" any layer is at a glance.
Dependency graph visualization
Interactive graph of how entities connect. Click any node to drill in. Useful for architecture conversations with engineers.
Polymorphic artifact attachment
Attach rich-text artifacts (specs, decisions, design notes) to any PD entity. Stop losing context in random Google Docs.
Brand-scoped from day one
Each PD entity is scoped to a brand. Multi-product founders document each product in its own scope; switch brands to see the next.
Connects to content, emails, events
A blog post can link to the feature it describes. A lifecycle email can link to the controller that fires it. Cross-surface integration is the whole point.
PD only earns its keep when it's connected.
A standalone spec workspace is just a fancy Notion. m18t's PD is structurally adjacent to the content, emails, and events your product ships — so the spec actually shapes the marketing.
Link content pieces to the features they describe. Marketing stops drifting from product.
Events emitted by your controllers are named in the events registry. Tied directly to PD nodes.
Lifecycle emails link to the analytics events that should fire them, which link to controllers in PD.
Drop your PD entities onto a whiteboard as live nodes for event-storming and architecture discussions.
Where PD stands today.
Solid today
- — All 13 entity types working
- — Status rollups across the hierarchy
- — Dependency graph visualization
- — Polymorphic artifact attachment to any node
- — Brand-scoping across every entity
- — Owner / assigned-to on every entity
Rough today
- — Onboarding for non-technical founders (vocabulary is opinionated)
- — Bulk operations across many entities
- — PD-to-content linking UX could be deeper
Coming
- — Custom roles with granular permissions
- — Events folded into PD as pd_events
- — State-machine for legal status transitions
Frequently Asked Questions
Try PD with your real product.
Free during beta. The vocabulary is opinionated; we'll walk you through it.