Digital Products — Product Philosophy¶
This document restates and extends the company-level product philosophy (../../../../docs/company/product-philosophy.md) specifically for the class of products this venture builds: structured digital tools, initially delivered as Excel workbooks.
Auditable calculations¶
A customer should be able to trace any output back to the inputs and formulas that produced it. This means:
- Calculations live in clearly identified areas, not buried inside cells that also look like inputs.
- Formulas favor clarity over cleverness. A calculation that would need a footnote to explain should probably be broken into labeled intermediate steps instead.
- Complex calculations are documented with a worked example (see ../standards/calculation-and-formula-standard.md).
- Assumptions (rates, dates, compounding, rounding rules) are visible and editable in a configuration area, not hardcoded inside formulas.
Auditability is a trust feature, not a nice-to-have. Customers paying for a structured tool are often making decisions that matter to them (a retirement date, a renovation budget, a business forecast); they need to be able to see the tool's reasoning, not just its answer.
Clear separation of concerns¶
Every product should make a visible distinction between:
- Data entry — what the customer types in.
- Calculation — what the tool derives from that data.
- Output/reporting — what the tool presents back, summarized for a decision or for sharing.
This separation is both a UX principle (so the customer never has to guess which cells are safe to edit) and an engineering principle (so calculation logic can be tested, reused, and reasoned about independently of layout). See ../standards/workbook-architecture-standard.md and ../standards/data-modeling-standard.md.
Proportional complexity¶
Not every product needs a dashboard, a configuration tab, and a reporting layer. A simple household inventory tracker and a multi-scenario retirement planner have very different structural needs. This venture asks builders to size the architecture to the problem:
- A low-complexity product should not be forced into a heavy multi-tab structure because a template exists that has one.
- A high-complexity product (multiple scenarios, sensitivity analysis, many interdependent inputs) should not be squeezed into a minimal structure for the sake of speed.
- Complexity should be visible to the customer only where it's necessary for them to trust or use the result — internal complexity that doesn't serve the customer should be hidden or eliminated.
Reuse without forcing uniformity¶
The component catalog (../../components/component-catalog.md) exists so that recurring problems (a KPI dashboard, a validated input pattern, a configuration block) don't get solved from scratch every time. But reuse is a tool, not a mandate:
- A component should be adopted when it genuinely fits the product's problem, not because it's available.
- A product-specific need that a component doesn't serve well should get a product-specific solution, documented as such, rather than a forced-fit component.
- Patterns that prove useful across two or more products should be proposed back into the component catalog rather than re-implemented independently a third time.
Excel quality is not sacrificed for theoretical platform neutrality¶
Some products may eventually extend to other platforms (Google Sheets, Notion, Monday.com, web apps). That possibility should never degrade the quality of the Excel version. Features, formulas, or design choices are not avoided in Excel merely because they might be hard to replicate elsewhere. Platform extension, when it happens, is evaluated and built per product — see ../architecture/future-platform-strategy.md.