Sitemap

Startups Need Hypotheses

7 min readMay 24, 2025

--

Startup founders begin with a dream, but know very little about the path to success. Hypotheses thinking can help.

Here’s the story of how hypothesis thinking changed the course of my company. I hope this case study is useful for your journey.

This post was inspired by I Ask Every Founder These 5 Questions Before Taking Them On. In my post here, I’d like to answer the first of those 5 questions.

“What’s the last assumption you had about your business that turned out to be completely wrong?”

I’d like to rephrase the blog writer’s question to:

“What’s the last **hypothesis** you had about your business that turned out to be completely wrong?”

I believe that a founder should avoid assumptions. Instead, I try to develop hypotheses, then prove or disprove them. Hypotheses lead to learning and improvement. Assumptions can lead to costly mistakes or wasted time.

For Foodgraph:

The biggest hypothesis we made turned out to be completely wrong.

Our learnings changed the course of our company, resulting in a pivot from B2C to B2B.

Our venture started life as a B2C company to offer the great American food shopping app. We aimed to accurately and quickly help consumers learn whether a food product they’re considering fits their preferences and requirements.

Hundreds of these food shopping apps have been published and failed, but they did get hundreds of millions downloads.

Why has demand for food shopping apps been high, but retention low?
The apps have not solved the consumer need, in some unknown way.

Hypothesis #1:

The problem to solve was about UX or GTM.

Our hypothesis was that the primary issues causing low app retention were related to the user experience (UX) and the go-to-market approach (GTM). So we built a prototype, tested it, and got positive response and learnings. Here’s what we learned:

Hypothesis #1 debunked:

The problem to solve was **not** about UX or GTM.

It was about product data.

The biggest issue to solve? When the consumer scans a product barcode in the store, they expect that the product data will be found and displayed, with helpful information to make a more informed purchase decision.

In other words, avoid “Item Not Found”.

The big learning was that if the match rate for product lookups was not high — perhaps 90% or more — then the value of the UX is deeply-impaired, and the app will end up in the dustbin of other tried-and-failed apps.

This discovery led us to putting data acquisition as our top “must-do”, ahead of UX and GTM.

Hypothesis #2:

We could acquire all the product data we needed by combining existing paid and free sources.

The goal was to assemble a national catalog of grocery products, starting with packaged food.

In other words, could we get quality data and images for close to 100% of the products on the grocery shelf?

Our 1st approach: Free Sources

We found that free sources, like the government’s USDA Food Data Central and the crowd-sourced Open Food Facts, had many problems:

  • data and images were missing
  • data and images were for older product versions
  • data and images were wrong (mistyped or for a different product).
  • multiple, conflicting records for the same product
  • identifier values (UPCs) were wrong or did not follow the GS1 standard.
  • spotty product coverage

Our 2nd approach: Pay-As-You-Go Services

Then we tried a few usage-based services, such as Barcode Lookup. The problems were the same as the free sources above.

Our 3rd approach: Paid Subscriptions from Brand Syndicators

We decided to test the subscription services offered by data syndicators that represent different brands. We knew that these services are expensive and non-overlapping, so we mght have spend up to $1m.

We got proposals and data samples from some of the leading companies of that time (in 2020), such as Kwikee, Label Insight, NielsenIQ (Brandbank), Salsify, and Syndigo.

The good news?

  • Quality was high.
  • Strong coverage for products from large CPG companies, which accounted for about 60% of the store, but only if we stitched together the data from all of the services.

The bad news?

  • Poor coverage for products from small CPG companies, which accounted for about 20% of the store.
  • No coverage for private label products from retailers, which also accounted for about 20% of the store.

Hypothesis #2 debunked
We could only get product information for about 60% of the grocery shelf using traditional sources, e
ven if we spent a lot of money.

Now what??? We could:

  • quit now
  • build our own data.

We seriously considered ending the venture. But the problem seemed worth solving and maybe we were touching on something much bigger.

Hypothesis #3:
We could build our own data in 6–9 months.

We had to find a new way. The key questions we needed to answer:

  1. How do we get product data for:
    - large brand products?
    - AND small brand products?
    - AND private label products from retailers?
  2. How could we evaluate data quality?
  3. How could we combine data from multiple sources, especially for the same product and when conflicts exists?
  4. How could we keep the data fresh?
  5. How could we do this repeatably and scale?
  6. What will this cost to develop and maintain?

A pretty daunting list of problems to solve. We started working through a series of experiments in data acquisition, integration, use of AI (circa 2021), tests, fixes … and iteration after iteration.

Hypothesis #3 debunked:
We could **not** build our data in 6–9 months.

We gradually saw a path, but it would take much, much longer.

We reached the “now what?” moment again.

We could:
- quit now
- stay the course and still aim to build a B2C business
- pivot to a new business

This led us to explore a new hypothesis:

Hypothesis #4:
Lots of companies may be having the same problem.

If we can successfully build and maintain a U.S. catalog of grocery product data for ourselves, it may be valuable to others as a B2B service.

To test this hypothesis, we took a multi-track approach to directly address our business fundamentals:

  • Pivot
    Tighten our R&D to building a B2B data service.
    Let go of the B2C focus for the forseeable future.
  • Rearchitect & rebuild
    Reuse what we could, but be relentless in redesigning an approach that would result in an MVP for B2B.
  • Realign the team
    Let go of workers who don’t fit the new hypothesis / vision. (Very tough, but necessary). Hire workers who do.
  • Talk with potential buyers & those in-the-know.
    Do they experience the same problem?
    How have they addressed it?
    Are there chronic gaps?
    If yes, and we could solve these problems, what would they expect to pay for such a service?
  • Be patient.
    This is a hard problem. A U.S. catalog of grocery product data doesn’t exist. Find out why and solve for the core issues.
  • Manage the burn rate closely.
    Spending must align with the objectives above. We needed time and cash to solve tough problems until we could arrive at our B2B MVP.
  • Don’t try to raise venture capital yet.
    Until there’s traction, it’s not time. Tap other sources of capital.

We followed this path. We landed on these findings:

Hypothesis #4 proven:
B2B companies in grocery-related business have a core business need to access a U.S. catalog of product data.

And they have high-pain in doing so. Most are dissatisfied with their results.

They shared that they be willing to pay tens of thousands of $$$ for such as service, and sometimes more.

We got to work building this B2B data service. We had to innovate lots of things about a new data acquisition strategy, how to multi-source data, how to handle messy & unstructured data, how to recognize quality data, and more.

The pivot got us to a successful MVP.

Once were were ready, we went to market with our MVP. We successfully and quickly secured multiple, paid, beta customers at $10,000 each.

It took us 4 years from our first day as a company to securing the signed beta agreements. However, once the beta service was ready, getting these clients went fast. It took only 3 to 12 weeks from the first meetings to the executed agreements.

What are the problems we solved?

Our novel approach tackled the root causes of why a U.S. catalog of grocery product data never existed before:

  • Data sources are highly-fragmented.
  • Data is unstructured, messy, and differs for every source.
  • Data values change frequently.

From beta to commercial contracts

The betas were successful: We delivered value and we learned.

We were ready to start selling commercial contracts.

In our first quarter of commercial sales:

  • All of our first contracts are for 3-years terms.
  • All of our first contracts are 6-digits in value.

These early results were quite exciting, especially considering the youth of our company.

  • It’s clear that we are solving a real pain point.
  • It suggests that our service is likely to be renewed if we deliver.

Hypothesis #4 was **strongly** proven.

Make hypotheses. Validate or debunk. Repeat.

I’ve learned that:

If I’m not using “hypothesis thinking”, then I’m not learning … and I may be making costly mistakes.

These mistakes can even be fatal to the business.

Learning from hypothesis thinking can lead to growth.

Embrace the not-knowing. Then learn ... and change.

That’s it. Make educated guesses. Prove or disprove it. Make change.

Inspiration from Maya Angelou

I like this quotation from Maya Angelou about learning:

“Do the best you can until you know better. When you know better, do better.”

About Foodgraph

Foodgraph offers the Largest Data Catalog of U.S. Packaged Foods.
Check out our website.
Let us know how we can help.

--

--

David Goodtree
David Goodtree

Written by David Goodtree

Topics: Food, holidays, startup life

No responses yet