What Entrepreneurs Can Learn from Data and Goliath
Mara's fitness-app startup had just cleared ten thousand signups when her cofounder proposed folding location history and contact list access into a single "accept all" onboarding screen, since the analytics dashboard looked richer with them. Mara paused. She liked knowing where users worked out, but she had also just deleted three loyalty apps from her own phone after noticing how much they tracked between visits. She asked her team to mock up two onboarding versions, one minimal and one expansive, and to actually read what each permission enabled before either shipped. The question wasn't whether more data would help the business; it probably would. The question was what she was comfortable asking for, and what users would agree to if the request were stated plainly instead of buried in a scroll of legal text.
The whole book, compressed
This edition works through 4 core lessons — take them one at a time, not all at once.
What's different for your conditions
Tap whichever ones sound like you. Nothing here is sent or saved — it's just for your own noticing.
0 of 5 selected
The core lessons, applied to you
How much your product actually gathers
Most founders underestimate how much data a modern app accumulates simply by functioning normally. Login timestamps, device identifiers, crash logs, in-app navigation paths, and third-party analytics SDKs all generate records, often before anyone on the team has explicitly decided to "collect" anything. Schneier's broader point applies at startup scale too: the volume of incidental data can rival or exceed the data you deliberately ask users for.
Teams add analytics or ad SDKs for convenience and never audit what those tools transmit afterward.
Once a quarter, list every SDK and data field your product touches and ask whether each one still earns its place.
The tradeoff between growth and exposure
Rich user data fuels personalization, retention modeling, and pitch decks investors love. But every field collected is also a future liability, a support burden, and a reason users might hesitate before trusting you with their next purchase. The tradeoff is real and worth making with eyes open rather than defaulting to "collect everything, decide later."
Growth targets push teams to collect first and justify it later, after the data is already sitting in a database.
Before adding a new data field, write one sentence describing the specific feature it enables, and skip the field if you can't.
Reducing exposure without slowing the business
You do not need to become a privacy specialist to run a leaner data operation. Setting retention limits, anonymizing analytics where possible, and giving users a real way to see and delete their data are achievable steps for small teams, and they reduce both risk and the cost of eventually complying with regulation.
"we'll build the privacy dashboard after we hit product-market fit" often means never.
Build a basic data export and deletion flow into your product roadmap before your first big marketing push, not after.
Your business inside a larger data economy
Startups do not operate outside the data economy Schneier describes; they are often small nodes feeding larger data brokers and ad networks through the SDKs they install. Recognizing that your company's practices connect to a broader debate about corporate and government data use helps you make choices that hold up as both your company and the regulatory landscape around it grow.
A founder chasing growth may want maximum data collection, while the same founder building long-term trust wants restraint, and these pulls rarely resolve cleanly in one meeting. Investors sometimes reward growth metrics built on broader collection, even when it strains user trust. The practical move is treating data minimization as a product decision with real tradeoffs, not a compliance afterthought. Founders who wait until a legal review forces the question usually pay more, in engineering time and user goodwill, than those who build the habit early.
Name one thing, honestly
- Which fields in your signup flow are there because a user needs them, versus because they might be useful someday? - If a user asked exactly what your product knows about them, could your team answer in under a minute? - Would your current data practices survive being described plainly on your own homepage?
Good. Now look back at the "Try this" line under whichever lesson feels most connected to what you just wrote, and treat that as this week's actual assignment — not all 4 at once.
The practices from this edition
0 of 3 selected
Run this for seven days
Build a basic data export and deletion flow into your product roadmap before your first big marketing push, not after.