Product¶
The product layer is the why and what of Tomoda — the story behind each feature and the spec each feature has to honour. It sits above the engineering docs: by the time you reach Architecture or Backend Services, the product layer has already told you what experience the code is meant to produce.
How this section is split¶
The product layer is three layers stacked from most narrative to most precise:
| Layer | Voice | Reader's question |
|---|---|---|
| Vision | Pitch / manifesto | What is Tomoda and why does it exist? |
| Bible | Per-feature narrative — the story of one system | Why does this feature exist? What experience are we trying to create? |
| Domains | Per-feature spec — states, rules, invariants | What are the rules of this system? What does it promise? |
Read top-down: vision is the elevator pitch, the bible is the PM-to-designer explanation of each feature, and the domains are the engineer-to-engineer reference for the rules each feature has to obey.
Reading order¶
- Vision — start here. One page. The elevator pitch.
- Bible → Brand — the voice, the principles, the way the product feels. Everything else inherits from this.
- One bible page per system you care about (identity, events, friends, discovery, moments, chat, presence, payments, locations).
- The matching domain spec when you need rules, not story.
What lives where¶
| You want… | Read |
|---|---|
| Pitch / elevator copy | Vision |
| The story of a feature ("why is it like this?") | Bible |
| The rules of a feature ("what are the states / invariants?") | Domains |
| How a screen behaves for the user | ux/ (coming soon) |
| Visual tokens, components, colour, motion | Style Guide |
| How a feature is wired in code | Backend Services / Frontend |
Editing this section¶
The product layer describes the present. If a feature isn't built yet, either omit it or mark it explicitly with a stub admonition — don't pretend it ships. When a feature lands, update the matching bible page (story) and domain page (spec) in the same change.
The bible's voice is manifesto-adjacent: it's allowed to be opinionated and narrative. The domain's voice is reference-adjacent: tables, short prose, no marketing. Don't mix the two.