Skip to content

Product Philosophy

This document sets the practical rules for how products get designed and built across all ventures. It applies regardless of product type (app, workbook, service) or venture.

How a product starts

  • Begin with a defined user problem. No product or feature should start from "this would be cool to build." State the specific problem, for a specific user, before designing a solution.
  • Define non-goals. Alongside what a product will do, state explicitly what it will not do, at least for its current version. This bounds scope and prevents feature creep from being mistaken for progress.
  • Separate evidence from assumptions. Every claim behind a product decision should be labeled as one of: verified fact, observed evidence, customer statement, hypothesis, assumption, inference, or recommendation, per docs/company/research-and-evidence-principles.md. Do not let an assumption get treated as a fact just because it's been repeated.
  • Specify business rules before implementation, where practical. For anything involving calculations, pricing, or conditional logic, write the rule down in plain language before writing the code or formula that implements it. This makes the rule reviewable independent of its implementation, and catches disagreements early.

How a product is shaped

  • Favor clear products over overloaded products. A product that does one job well is preferable to one that tries to do many jobs adequately. Resist the urge to bolt unrelated capabilities onto an existing product just because the audience overlaps.
  • Design for maintenance and support, not just launch. A product's ongoing supportability (can it be debugged, can its data be inspected, can a customer's issue be diagnosed without heroics) is a design constraint from day one, not something addressed after problems appear.
  • Documentation, testing, accessibility, and packaging are product features, not optional extras layered on afterward. A product that lacks these is incomplete, not "done except for polish."
  • Reuse components only when reuse actually reduces risk or effort. Do not force two unrelated products into a shared abstraction just because they look superficially similar. Premature platform abstraction — building shared infrastructure before there are at least two concrete, proven use cases that need it — is a common and costly mistake; avoid it.
  • Avoid template clutter. Don't create templates, boilerplate, or reusable scaffolding for a pattern that has only been used once. A second real use case should exist before something is generalized.
  • Do not launch based solely on aesthetic polish. A product that looks finished but has not been validated against its stated user problem, business rules, and non-goals is not ready, no matter how refined its visual design is.

General product philosophy

Across the whole portfolio, the company favors:

  • Durable, useful products over shallow volume. Fewer products that solve real problems well, rather than many thin products chasing trends.
  • Clear problems and value propositions. If the problem and the value cannot be stated in a sentence or two, the product isn't ready to build yet.
  • Trust, accuracy, and maintainability as core product qualities, not nice-to-haves — see docs/company/customer-trust-principles.md.
  • Explicit assumptions and evidence-based claims in both internal decision-making and external marketing. See docs/company/research-and-evidence-principles.md and docs/company/commercialization-principles.md.
  • Reusable patterns where they genuinely apply — not as a default, but as a deliberate choice made after the pattern has proven itself.
  • Transparent business logic. Calculations and rules embedded in a product (pricing formulas, spreadsheet logic, recommendation rules) should be inspectable and explainable, not black boxes, especially where a customer is relying on the output.
  • Separation of inputs, configuration, calculations, and outputs. Keeping these layers distinct — in a spreadsheet, an app, or any other product form — makes products easier to test, debug, and extend.
  • Human review for high-risk claims. Legal, financial, health, nutrition, food-safety, privacy, and security-adjacent claims or calculations always get human review before shipping.
  • AI as a collaborator, not an unquestioned authority. AI tools (including coding agents working in this repository) may draft, analyze, test, and generate implementation artifacts, but do not get to approve policy, invent evidence, or have their output treated as ground truth without review. See docs/company/responsible-ai-principles.md.

Naming: avoid "operating system" language

Do not describe products as "operating systems," even loosely or metaphorically (e.g., "the operating system for your pantry"). This phrase overstates scope, invites unfounded comparison to actual platform software, and tends to encourage feature sprawl to justify the label.

Preferred descriptive terms, chosen for what the product actually is:

  • product
  • application (or "app")
  • toolkit
  • planner
  • framework
  • workbook
  • suite
  • manager
  • studio
  • platform (only when a product genuinely hosts other extensible things — use sparingly)
  • development system (only for genuinely developer-facing tooling)

Pick the term that most accurately describes the product's actual shape and stop there.

Report an issue about this page