[{"data":1,"prerenderedAt":74},["ShallowReactive",2],{"help-article-the-product-development-concept":3},{"data":4},{"title":5,"excerpt":6,"content":7,"help_category":8,"seo":11},"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.","\u003Cp>\u003Cstrong>What you'll learn\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Why m18t models your product as a relational tree instead of a flat board.\u003C\u002Fli>\n\u003Cli>The PD hierarchy — Solutions → Features → Models, and the satellite entities (Attributes, Controllers, Lifecycles, Events, Views, Layouts, Components, Middleware, Policies, Roles).\u003C\u002Fli>\n\u003Cli>How status, the \u003Ca href=\"\u002Fhelp\u002Fthe-dependency-graph\">dependency graph\u003C\u002Fa>, and \u003Ca href=\"\u002Fhelp\u002Fattaching-artifacts\">artifacts\u003C\u002Fa> hang off that structure.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>The nav label for this workspace is \u003Cstrong>Product Manager\u003C\u002Fstrong>. The underlying concept — and everything in this category — is called \u003Cstrong>PD\u003C\u002Fstrong> (Product Development). You'll find it at \u003Ccode>\u002Fstudio\u002Fproduct-development\u003C\u002Fcode>.\u003C\u002Fp>\n\u003Chr>\n\u003Ch2>The problem: specs that drift\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>PD's answer is to make the spec \u003Cem>structured and relational\u003C\u002Fem> 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 \u003Ca href=\"\u002Fhelp\u002Fstatus-rollups\">status distribution\u003C\u002Fa> of any branch, render a \u003Ca href=\"\u002Fhelp\u002Fthe-dependency-graph\">dependency graph\u003C\u002Fa>, and keep the design connected to the \u003Ca href=\"\u002Fhelp\u002Fthe-unified-content-table\">content\u003C\u002Fa> and \u003Ca href=\"\u002Fhelp\u002Fattaching-artifacts\">artifacts\u003C\u002Fa> around it.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Chr>\n\u003Ch2>The 12 entity tabs\u003C\u002Fh2>\n\u003Cp>The Product Manager page has twelve entity tabs, each backed by its own table. They are: \u003Cstrong>Solutions, Features, Models, Attributes, Controllers, Policies, Roles, Lifecycles, Views, Layouts, Components, Middleware.\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>There is a thirteenth PD entity — \u003Cstrong>Events\u003C\u002Fstrong> — but events are authored in the \u003Ca href=\"\u002Fhelp\u002Fthe-analytics-event-registry\">Events Manager\u003C\u002Fa>, not in a PD tab. PD reads them and shows them against the models and controllers they belong to.\u003C\u002Fp>\n\u003Cp>The entities aren't a flat list; they form a tree with satellites.\u003C\u002Fp>\n\u003Ch3>The spine: Solutions → Features → Models\u003C\u002Fh3>\n\u003Cul>\n\u003Cli>\u003Cstrong>Solution\u003C\u002Fstrong> — the top layer. A standalone product or a large body of work. Example: a billing system.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Feature\u003C\u002Fstrong> — a distinct capability inside a Solution. Example: "Checkout", "Invoice history".\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Model\u003C\u002Fstrong> — a data structure a Feature needs. Example: a \u003Ccode>Cart\u003C\u002Fcode> model and a \u003Ccode>CartItem\u003C\u002Fcode> model under "Checkout".\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>This is the part you read top to bottom. A Solution holds Features; a Feature holds Models.\u003C\u002Fp>\n\u003Ch3>The satellites\u003C\u002Fh3>\n\u003Cp>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:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Attributes\u003C\u002Fstrong> — the fields on a Model (a \u003Ccode>quantity\u003C\u002Fcode> integer, a \u003Ccode>product_id\u003C\u002Fcode> relation). Attributes carry a \u003Cem>scalar\u003C\u002Fem> type, and relation attributes carry a \u003Cem>cardinality\u003C\u002Fem> (OneToOne, OneToMany, ManyToOne, ManyToMany).\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Controllers\u003C\u002Fstrong> — the endpoints\u002Fhandlers that act on Models. Each carries an HTTP method, a path, and an auth flag.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Lifecycles\u003C\u002Fstrong> — hooks that fire around a Model's writes (before\u002Fafter create, update, and so on).\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Policies\u003C\u002Fstrong> and \u003Cstrong>Roles\u003C\u002Fstrong> — authorization rules and actor types attached to Controllers.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Views\u003C\u002Fstrong>, \u003Cstrong>Layouts\u003C\u002Fstrong>, \u003Cstrong>Components\u003C\u002Fstrong>, \u003Cstrong>Middleware\u003C\u002Fstrong> — the front-end side: a View renders on a Layout, composes Components, and runs Middleware.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>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.\u003C\u002Fp>\n\u003Chr>\n\u003Ch2>How to start\u003C\u002Fh2>\n\u003Col>\n\u003Cli>Open \u003Cstrong>Product Manager\u003C\u002Fstrong> in the sidebar (\u003Ccode>\u002Fstudio\u002Fproduct-development\u003C\u002Fcode>).\u003C\u002Fli>\n\u003Cli>Confirm the \u003Ca href=\"\u002Fhelp\u002Fthe-brand-switcher\">active brand\u003C\u002Fa> — PD is brand-scoped, so each brand has its own tree.\u003C\u002Fli>\n\u003Cli>Go to the \u003Cstrong>Solutions\u003C\u002Fstrong> tab and click \u003Cstrong>Add Solution\u003C\u002Fstrong>.\u003C\u002Fli>\n\u003Cli>Open that Solution's \u003Cstrong>Features\u003C\u002Fstrong> and add the capabilities it contains.\u003C\u002Fli>\n\u003Cli>Under a Feature, add \u003Cstrong>Models\u003C\u002Fstrong>, then open a Model and add its \u003Cstrong>Attributes\u003C\u002Fstrong>.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Step-by-step, that's the \u003Ca href=\"\u002Fhelp\u002Fyour-first-solution\">Your First Solution\u003C\u002Fa> walkthrough.\u003C\u002Fp>\n\u003Chr>\n\u003Ch2>What ties the structure together\u003C\u002Fh2>\n\u003Cp>Three things make the relational spec worth the effort:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Status\u003C\u002Fstrong> rolls visible as a distribution across each branch, so you can see how far along a layer is without reading every record. See \u003Ca href=\"\u002Fhelp\u002Fstatus-rollups\">Status Rollups\u003C\u002Fa>.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>The dependency graph\u003C\u002Fstrong> turns the tree into navigable views — Galaxy Map, Insights, MVC Blueprint, ERD \u002F UML, and Event Flow — reachable from the \u003Cstrong>Visual Analysis\u003C\u002Fstrong> button. See \u003Ca href=\"\u002Fhelp\u002Fthe-dependency-graph\">The Dependency Graph\u003C\u002Fa>.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Artifacts\u003C\u002Fstrong> let you attach rich-text thinking — a brief, a decision, a mockup link — directly to any PD node, so the \u003Cem>why\u003C\u002Fem> lives next to the \u003Cem>what\u003C\u002Fem>. See \u003Ca href=\"\u002Fhelp\u002Fattaching-artifacts\">Attaching Artifacts\u003C\u002Fa>.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>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.\u003C\u002Fp>\n\u003Chr>\n\u003Ch2>FAQ\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Is Product Manager the same thing as PD?\u003C\u002Fstrong>\nYes. "Product Manager" is the sidebar label; "PD" (Product Development) is the concept name used throughout the docs and the code. Same workspace at \u003Ccode>\u002Fstudio\u002Fproduct-development\u003C\u002Fcode>.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Do I have to use all twelve entity types?\u003C\u002Fstrong>\nNo. 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.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Where are Events?\u003C\u002Fstrong>\nEvents are a PD entity but they're authored in the \u003Ca href=\"\u002Fhelp\u002Fthe-analytics-event-registry\">Events Manager\u003C\u002Fa>. PD displays them against the models and controllers they relate to.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Is PD shared across my brands?\u003C\u002Fstrong>\nNo. PD is brand-scoped. Switch brands and you're looking at a different tree. See \u003Ca href=\"\u002Fhelp\u002Fthe-brand-switcher\">The Brand Switcher\u003C\u002Fa>.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Can my teammates work in PD with me?\u003C\u002Fstrong>\nYes. 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.\u003C\u002Fp>\n\u003Chr>\n\u003Cp>\u003Cstrong>What's next\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Ca href=\"\u002Fhelp\u002Fyour-first-solution\">Your First Solution\u003C\u002Fa> — build the minimum useful scaffold.\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"\u002Fhelp\u002Fstatus-rollups\">Status Rollups\u003C\u002Fa> — read the status distribution across a branch.\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"\u002Fhelp\u002Fthe-dependency-graph\">The Dependency Graph\u003C\u002Fa> — the Visual Analysis views.\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"\u002Fhelp\u002Fattaching-artifacts\">Attaching Artifacts\u003C\u002Fa> — put the thinking next to the spec.\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"\u002Fhelp\u002Fwhiteboards-overview\">Whiteboards Overview\u003C\u002Fa> — sketch the same entities on a free-form canvas.\u003C\u002Fli>\n\u003C\u002Ful>\n",{"slug":9,"title":10},"product-manager","Product Manager (PD)",{"meta_title":12,"meta_description":6,"keywords":13,"canonical_url":14,"og_title":12,"og_description":6,"og_image":15,"robots":16,"json_ld":17},"The Product Development Concept | m18t Help","product development concept, PD hierarchy, solutions features models, relational spec, entity tabs, brand-scoped, m18t","https:\u002F\u002Fm18t.com\u002Fhelp\u002Fthe-product-development-concept","https:\u002F\u002Fm18t.com\u002Fog-default.png","index, follow",{"@context":18,"@graph":19},"https:\u002F\u002Fschema.org",[20,33,58],{"@type":21,"headline":5,"description":6,"articleSection":10,"inLanguage":22,"datePublished":23,"dateModified":23,"image":15,"author":24,"publisher":28,"mainEntityOfPage":31},"Article","en","2026-06-25",{"@type":25,"name":26,"url":27},"Organization","m18t","https:\u002F\u002Fm18t.com",{"@type":25,"name":26,"url":27,"logo":29},{"@type":30,"url":15},"ImageObject",{"@type":32,"@id":14},"WebPage",{"@type":34,"mainEntity":35},"FAQPage",[36,42,46,50,54],{"@type":37,"name":38,"acceptedAnswer":39},"Question","Is Product Manager the same thing as PD?",{"@type":40,"text":41},"Answer","Yes. \"Product Manager\" is the sidebar label; \"PD\" (Product Development) is the concept name used throughout the docs and the code. Same workspace at \u002Fstudio\u002Fproduct-development.",{"@type":37,"name":43,"acceptedAnswer":44},"Do I have to use all twelve entity types?",{"@type":40,"text":45},"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.",{"@type":37,"name":47,"acceptedAnswer":48},"Where are Events?",{"@type":40,"text":49},"Events are a PD entity but they're authored in the Events Manager. PD displays them against the models and controllers they relate to.",{"@type":37,"name":51,"acceptedAnswer":52},"Is PD shared across my brands?",{"@type":40,"text":53},"No. PD is brand-scoped. Switch brands and you're looking at a different tree.",{"@type":37,"name":55,"acceptedAnswer":56},"Can my teammates work in PD with me?",{"@type":40,"text":57},"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.",{"@type":59,"itemListElement":60},"BreadcrumbList",[61,65,69,72],{"@type":62,"position":63,"name":64,"item":27},"ListItem",1,"Home",{"@type":62,"position":66,"name":67,"item":68},2,"Help","https:\u002F\u002Fm18t.com\u002Fhelp",{"@type":62,"position":70,"name":10,"item":71},3,"https:\u002F\u002Fm18t.com\u002Fhelp\u002Fcategories\u002Fproduct-manager",{"@type":62,"position":73,"name":5,"item":14},4,1786312171509]