Data for Business Builders -- Core Patterns

Original thinking from a 2020 Notion doc titled "Ultimate Guide to Data for Business Builders." The premise: at a certain point in a company's growth, the founder's job shifts from building the product to building the business -- and the data challenges that come with that shift are predictable and solvable.

Pattern 1: Operational vs. Reported Numbers (Snapshots)

The core tension: front-line operational numbers and "reported" numbers diverge over time. You weren't crazy when you reported the numbers the first time -- the underlying data changed after the fact (late-arriving events, retroactive corrections, backfills).

Solution: Snapshots. Capture the state of key metrics at the time they were reported, so you can compare "what we said then" to "what the data says now."

Key fields for snapshots:

• The metric value at snapshot time
• A reported_at timestamp
• Handling for hard deletes (deleted records that disappear from current state but existed at report time)

This connects directly to [[analytics-engineering]] and the concept of [[incremental-models]] -- snapshots are the mechanism that lets you have both a current-state view and a historical-state view.

Pattern 2: Version Control for Business Definitions

Business definitions change as the company evolves. The problem isn't changing definitions -- it's changing them without showing stakeholders the impact.

Solution: Environments. Build the new definition in an isolated environment without touching production. Show the old and new side-by-side. If stakeholders reject it, scrap the environment. If they approve, promote it and tag the change.

This is the same mental model as [[dbt]] environments and git branching applied to business logic. The key insight: showing people how the data will look under a new definition is far more effective than talking about it hypothetically.

Pattern 3: Walking Back to Source

When inheriting or auditing an existing data setup:

• Trace stored procedures, queries, and ETL jobs back to their source systems
• Create a denormalized data model from existing Excel spreadsheets or reports (reverse-engineering the implicit model)

This is the "transition guide" pattern -- meeting a business where they are and building a bridge to a proper [[analytics-engineering]] setup.

Why This Matters

These three patterns (snapshots, definition versioning, source tracing) are the recurring problems every growing company hits. They're the building blocks of a [[data-infrastructure-buy-in]] conversation: here's what breaks, here's the predictable fix.