Data Model as Product Strategy

The Support Question Behind the Schema

The client-digest MVP from the previous chapter can now be deployed, observed, and recovered. Before inviting the first three agencies, the founder rehearses one support request:

We hired a second account manager. Can she see the Acme digest, who changed it yesterday, and whether it was actually sent?

The prototype has a users table, an uploads table, and a field called report_status. It cannot answer cleanly. The upload belongs to the person who created it, although the agency believes it owns the work. “Acme” is text copied into several records. The status says complete, which might mean generated, reviewed, or delivered. A founder can inspect the database and guess, but the product itself does not know.

This is not a database inconvenience. It is a disagreement between the product and the customer’s world.

A data model names what the product believes exists, who owns it, how it changes, and which facts deserve a history. If those choices match the valuable part of the customer’s workflow, the product becomes easier to use, support, measure, and change. If they do not, every feature builds on a quiet misunderstanding.

The first model should therefore be narrow, but not casual: model the value moment precisely, establish the current trust boundary, and leave the imagined platform outside it.

Begin with the Promise

A generic SaaS model usually begins with users, accounts, subscriptions, and whatever happens to appear on the first screens. A useful product model begins with a sentence about value.

For the agency product, that sentence is not “a user uploads a CSV.” Uploading is an input. Generating a digest is closer, but a draft the account manager does not trust has not fulfilled the promise either. The value moment is:

An account manager sends a trustworthy explanation of weekly ad-account changes to a client without spending an hour assembling it.

That sentence already makes several modeling decisions visible. The product serves an agency, not only a login. Work is performed for a client. A source export becomes a digest. Someone reviews the digest before it leaves the agency. Delivery is consequential enough to remember.

The founder can now ask the question that governs the first schema:

What must the product remember for this promise to happen, be trusted, be supported, and happen again?

The answer is not every noun heard in discovery. It is the smallest connected world that can carry the promise.

Ownership Comes Before Collaboration Features

The prototype’s first mistake was making each record belong directly to one user. That was convenient while the founder demonstrated the product alone. It became false as soon as an agency expected its work to survive a staff change.

The founder separates three actors:

• The agency_account owns settings, billing, users, clients, and work created for those clients.
• The account_user is a person who signs in and performs traceable actions on behalf of the agency.
• The client is the external business for whom a digest is prepared. The client receives value but does not yet need a login.

This is enough to answer who owns the work and who acted. It does not require a general team system, nested workspaces, or a customer portal. If several agency employees join, membership can connect users to the account. If they initially have the same powers, a single member role may be honest. Separate roles become necessary when real people need different approval, administration, export, or billing authority.

Names matter because they keep unlike concepts unlike. A login is not automatically the customer. The buyer is not always the daily user. The owner of a record is not always the person who created it. The recipient of value may never enter the product.

The same reasoning transfers beyond agencies. A developer tool may need organization, project, environment, and API key. A marketplace may need buyer, seller, listing, order, and payout. A bookkeeping tool may need firm, client, and close period. Choose the distinctions that prevent a real ownership, trust, billing, support, or measurement error; do not collect domain nouns for completeness.

Follow the Work, Not the Screens

The interface contains an upload form, editor, and dashboard. None is the core object. Screens will change as the founder learns. The customer’s work must remain intelligible through those changes.

For the digest product, the useful chain is:

agency_account → client → source_export → change_digest → delivery

The source_export preserves what entered the system and whether it parsed successfully. The change_digest is the value-carrying object: it holds the generated explanation and the human revision that makes it safe to send. The delivery records an attempt to send a particular version to a particular recipient through a particular channel.

This separation resists a tempting shortcut. If the founder stores only a mutable report, a later edit can erase what the client actually received. If “sent” is merely a Boolean on the digest, a retry or provider failure has nowhere honest to live. Separate objects earn their place when they preserve a fact the customer or founder will need after the happy path has passed.

Other products will need different carriers: a project and task, a request and approval, a transaction and settlement, a document and signature, a message and response, or a job and generated file. The core object is usually the noun that appears in a serious support question: “Which invoice was paid twice?”, “Who approved this change?”, or “Why can this key reach production?”

State Should Tell a True Story

The field report_status = complete hides the most important part of the workflow. Complete in whose eyes?

The founder gives the digest a small lifecycle: draft, ready_for_review, approved, and archived. Delivery has its own result: queued, accepted, delivered, failed, or unknown, depending on what the delivery provider can truthfully report. A digest is not marked delivered merely because the product asked another system to send it.

Each state must change something. It may allow review, prevent editing, enable delivery, invite a retry, or make a support failure visible. If two labels permit the same actions and answer no different product question, the distinction may be decorative. If one label collapses several materially different situations, it is too vague.

For every important transition, the founder should be able to say:

• who or what may cause it;
• what becomes allowed or forbidden;
• whether the previous value must be retained;
• which failure or support question it helps explain.

Events in the next chapter will record behavior around these objects. The model comes first: an event such as digest_sent means little if “digest,” “sent,” and the responsible account are still ambiguous.

Draw the Trust Boundary While It Is Small

Permissions feel like a later concern only while the founder is the sole user. The second agency employee turns ownership into product behavior.

The first rule can remain simple: an account user may reach only clients, exports, digests, and deliveries owned by that user’s agency account. Within the account, all members may draft and review during the pilot, while only an account owner may invite members or change billing. The founder records administrative corrections separately rather than making invisible production edits.

That rule should be enforced through relationships in the model, not inferred from a page URL or a client name. Every access path—including exports, background jobs, file downloads, support tools, and integration callbacks—must arrive at the same account boundary.

Deletion and sharing need equally plain answers. Removing a user should not erase agency-owned work. Deleting a source file may leave a digest that must retain provenance. Sending a digest outside the account is an intentional release, not ordinary internal viewing. Billing belongs to the account even if one person initiated checkout. External provider identifiers belong beside product-owned state so a failed payment or delivery can be reconciled without surrendering the product’s own account of what happened.

This is not an argument for enterprise authorization machinery. It is an argument for being able to finish the sentence “this person can do this to that object because…” without improvising.

Put the Imagined Platform Outside the Line

Once the object map begins to make sense, it invites expansion. The founder can already imagine team hierarchies, custom roles, reusable templates, comments, tags, dashboards, integrations, white-label portals, and arbitrary workflows.

Most should remain outside the first boundary. The map can name them along with the evidence that would bring them in:

• Add distinct roles when two real participants need materially different powers.
• Add workspaces when one account needs durable internal separation that clients alone do not provide.
• Add templates when repeated manual reuse causes observable friction.
• Add an integration when manual import blocks activation or repeat use for the target agencies.
• Add a fuller audit log when approvals, regulation, buyer expectations, or recurring support questions require a reliable history beyond the few consequential actions already preserved.
• Add richer billing records when payment state changes access, renewal, support, or account ownership in ways the provider reference alone cannot explain.

“Later” is a design decision, not neglect. It keeps speculative abstractions from dictating the product before customers have supplied the distinctions. The exception is a risk already present: account isolation, confidential files, money movement, and externally delivered work do not become optional merely because the product is young.

Let Learning Change the Model Safely

The first schema will be wrong. A useful pre-PMF product discovers better nouns, different boundaries, and workflow states nobody predicted. The goal is not to avoid migration. It is to make revision possible without treating customer work as disposable.

Prefer additive moves while meaning is uncertain: introduce a new relationship, backfill it from known evidence, verify the result, then retire the old representation deliberately. Keep stable identifiers when URLs, exports, integrations, support conversations, or customer habits depend on them. Test transformations against realistic data, not only an empty local database. Back up before a risky change and rehearse the route back. Record automated changes that alter customer-visible state.

Suppose discovery shows that a client can have several ad accounts, each with its own export and reporting cadence. Adding an ad_account between client and source export is a healthy correction. Silently reinterpreting every existing client as an ad account is not. The migration must preserve which agency owns the records, which digest came from which source, and what recipients previously received.

Migration discipline is product discipline because the data is not residue from the product. It is customer work entrusted to it.

Draw the Core Object Map

The founder’s artifact is one page, not a universal schema. Put the value moment in the center and arrange the current model around it:

• Promise: an account manager sends a reviewed weekly change digest to a client.
• Actors and ownership: agency account, account user, client, and the relationships that establish ownership.
• Value-carrying work: source export, change digest, its review history or version, and delivery.
• States: only the transitions that change what can happen or explain why it did not.
• Permissions: who can view, change, approve, send, export, delete, invite, administer, and pay.
• Evidence anchors: the objects and identifiers to which activation, value, return use, failure, support, and billing events will attach.
• Outside the boundary: team hierarchy, custom roles, workspace, template, portal, generalized integrations, comments, labels, and any other unproved object.
• Migration risks: names, ownership relationships, identifiers, and histories that will become expensive to split, merge, or reinterpret.

Then trace one real digest from import through review and delivery. Trace the support request in the opposite direction: recipient to delivery, delivery to digest version, digest to source export, and every object back to the agency that owns it. If the line breaks, the model is missing something. If the page becomes a wall, remove everything that does not carry today’s promise, trust boundary, or learning.

Finally, ask the questions that exposed the prototype: Who can see this? Why is it stuck? What changed yesterday? What did the client receive? Did the workflow deliver value? A first data model is ready when it can answer those questions without pretending to describe the whole future business.