The Product Development Concept

Why m18t models your product as a relational tree instead of a flat board: the PD hierarchy of Solutions, Features, Models, and the satellite entities.

What you'll learn

  • Why m18t models your product as a relational tree instead of a flat board.
  • The PD hierarchy — Solutions → Features → Models, and the satellite entities (Attributes, Controllers, Lifecycles, Events, Views, Layouts, Components, Middleware, Policies, Roles).
  • How status, the dependency graph, and artifacts hang off that structure.

The nav label for this workspace is Product Manager. The underlying concept — and everything in this category — is called PD (Product Development). You'll find it at /studio/product-development.

The problem: specs that drift

Most teams describe a product in free-form text. A product manager writes a doc describing a feature and the data behind it. Engineering reads it, hits a constraint the doc didn't anticipate, builds something slightly different, and tracks the real work in a separate issue tracker. The original doc is now wrong, but nothing flags that. Marketing reads the stale doc and announces a capability that got cut.

That gap between "what we wrote down" and "what actually exists" is silo drift. It happens because the spec and the work live in different tools with no shared structure between them.

PD's answer is to make the spec structured and relational rather than prose. Instead of a paragraph describing a shopping cart, you create a Feature, give it Models, give those Models Attributes, and attach the controllers and events that touch them. Because the spec is a graph of real records, m18t can show you the status distribution of any branch, render a dependency graph, and keep the design connected to the content and artifacts around it.

This is more opinionated than a Kanban board, and it has a real learning curve. PD is in beta and the structure rewards teams who actually think in models and relations. If you just want a checklist, PD is heavier than you need. If you're describing a system, the structure pays off.

The 12 entity tabs

The Product Manager page has twelve entity tabs, each backed by its own table. They are: Solutions, Features, Models, Attributes, Controllers, Policies, Roles, Lifecycles, Views, Layouts, Components, Middleware.

There is a thirteenth PD entity — Events — but events are authored in the Events Manager, not in a PD tab. PD reads them and shows them against the models and controllers they belong to.

The entities aren't a flat list; they form a tree with satellites.

The spine: Solutions → Features → Models

  • Solution — the top layer. A standalone product or a large body of work. Example: a billing system.
  • Feature — a distinct capability inside a Solution. Example: "Checkout", "Invoice history".
  • Model — a data structure a Feature needs. Example: a Cart model and a CartItem model under "Checkout".

This is the part you read top to bottom. A Solution holds Features; a Feature holds Models.

The satellites

The other entities describe how a Model behaves and how it's exposed. They hang off Models, Controllers, or Views rather than extending the spine:

  • Attributes — the fields on a Model (a quantity integer, a product_id relation). Attributes carry a scalar type, and relation attributes carry a cardinality (OneToOne, OneToMany, ManyToOne, ManyToMany).
  • Controllers — the endpoints/handlers that act on Models. Each carries an HTTP method, a path, and an auth flag.
  • Lifecycles — hooks that fire around a Model's writes (before/after create, update, and so on).
  • Policies and Roles — authorization rules and actor types attached to Controllers.
  • Views, Layouts, Components, Middleware — the front-end side: a View renders on a Layout, composes Components, and runs Middleware.

You don't have to fill all twelve. Most operators start with Solutions, Features, Models, and Attributes, and add the rest only when the design needs them.

How to start

  1. Open Product Manager in the sidebar (/studio/product-development).
  2. Confirm the active brand — PD is brand-scoped, so each brand has its own tree.
  3. Go to the Solutions tab and click Add Solution.
  4. Open that Solution's Features and add the capabilities it contains.
  5. Under a Feature, add Models, then open a Model and add its Attributes.

Step-by-step, that's the Your First Solution walkthrough.

What ties the structure together

Three things make the relational spec worth the effort:

  • Status rolls visible as a distribution across each branch, so you can see how far along a layer is without reading every record. See Status Rollups.
  • The dependency graph turns the tree into navigable views — Galaxy Map, Insights, MVC Blueprint, ERD / UML, and Event Flow — reachable from the Visual Analysis button. See The Dependency Graph.
  • Artifacts let you attach rich-text thinking — a brief, a decision, a mockup link — directly to any PD node, so the why lives next to the what. See Attaching Artifacts.

A quick note on scope: PD documents your architecture. It is not a code generator and it does not run your app. It is team-aware, though: any PD entry can be assigned to a teammate, who gets a notification.

FAQ

Is Product Manager the same thing as PD? Yes. "Product Manager" is the sidebar label; "PD" (Product Development) is the concept name used throughout the docs and the code. Same workspace at /studio/product-development.

Do I have to use all twelve entity types? No. The Solutions → Features → Models → Attributes spine is the useful minimum. Controllers, Views, Policies and the rest are there when your design needs them; leaving them empty doesn't break anything.

Where are Events? Events are a PD entity but they're authored in the Events Manager. PD displays them against the models and controllers they relate to.

Is PD shared across my brands? No. PD is brand-scoped. Switch brands and you're looking at a different tree. See The Brand Switcher.

Can my teammates work in PD with me? Yes. Members with access to the brand work in the same tree, and you can assign an entry to a specific teammate. There is no real-time co-editing — coordinate who edits what.

What's next

Was this article helpful?