Your First Solution

Create a Solution, add Features under it, and add Models under a Feature in m18t's Product Manager. Build the minimum useful PD scaffold step by step.

What you'll learn

  • How to create a Solution, add Features under it, and add Models under a Feature.
  • The minimum useful PD scaffold — enough structure to be worth the effort, no more.
  • Where to go once the spine exists.

This is the hands-on follow-up to The Product Development Concept. If you haven't read that yet, read it first — it explains why PD is shaped this way.

The goal: a usable spine

You don't need to fill twelve entity types to get value from PD. The useful minimum is the spine: one Solution, a few Features under it, and a few Models under those Features, with Attributes on the models that matter. That's enough to read a status distribution and render a dependency graph.

Everything below assumes you've picked the right brand in the switcher — PD is brand-scoped, so a Solution belongs to one brand.

How to do it

  1. Open Product Manager in the sidebar (/studio/product-development).
  2. Click the Solutions tab, then the Add Solution button (top right).
  3. Give the Solution a name and save. Name it after a standalone product or a large body of work — for example, a billing system or an onboarding flow.
  4. Switch to the Features tab. Click Add Feature and assign it to the Solution you just made. Add one Feature per distinct capability — "Checkout", "Invoice history", and so on.
  5. Switch to the Models tab. Click Add Model and attach it to a Feature. A Model is a data structure the Feature needs — a Cart, a CartItem.
  6. Open a Model (click its row) and add Attributes — the fields on that structure. Each attribute has a scalar type; relation attributes also carry a cardinality (OneToOne, OneToMany, ManyToOne, ManyToMany).

That's the scaffold. Click Visual Analysis to see it rendered as a dependency graph, or read the rows back as a status distribution.

Variations

  • Top-down vs. bottom-up. You can create a Model without first having a Feature and attach it later, but the spine reads best top-down: Solution first, then Features, then Models.
  • Add satellites only when needed. Controllers, Lifecycles, Views, Policies and the rest are there when your design calls for them. Don't add them to feel thorough — empty branches just add noise.
  • Attach the thinking. Once a node exists, attach a brief or decision doc to it as an artifact so the reasoning lives next to the structure.

FAQ

Why can't I add a Feature without a Solution? Features belong to a Solution — that parent relationship is what makes the status rollup and the graph work. Create the Solution first.

Can I move a Model to a different Feature later? Yes — open the Model and change its Feature. The structure is editable; it isn't locked once created.

My Solution doesn't show up — where is it? Check the brand switcher. PD is brand-scoped, so a Solution created under one brand won't appear while another brand is active.

How many Features should one Solution have? However many distinct capabilities it has. There's no enforced limit; readability is the only constraint.

What's next

Was this article helpful?