What Product Assumptions Are You Making?

Teresa Torres argues that product teams routinely build on untested assumptions, treating hopes as facts, and that this risks building something nobody wants. Using an imagined Caltrain commuter app, she shows how to list the assumptions behind an idea as explicit, testable hypotheses. She then describes lightweight ways to test them before writing code, such as keyword research, splash pages with download buttons, and fake app experiences. The piece frames product development as an iterative loop of testing assumptions and solving real problems rather than defending an original vision.

01Key takeaways

• Write down the assumptions behind a product idea as explicit hypotheses before committing to build.
• Test whether people take the desired action, like searching or clicking download, before investing in the product.
• Use splash pages and waitlists to validate demand and build an early user list without a finished product.
• Simulate the solution with manual or low-effort alternatives like FAQs to learn how much product is really needed.
• Keep testing each new assumption as you build, since product development is iterative.
• Focus on solving the underlying problem and market need rather than defending the original product vision.

02Key sections

The hidden cost of unstated assumptions

Teams generate many hypotheses when planning a product, but often fail to notice them and proceed as though they were established facts. Since few early bets are right, skipping validation invites building something unwanted.

Turning an idea into explicit hypotheses

The author takes a Caltrain app idea and breaks it into three testable hypotheses about whether riders will download the app, remember to use it, and ride more often. She notes obstacles to each, like speed of driving being a bigger reason to avoid trains.

Testing the first assumption cheaply

Keyword research shows whether people seek the information, and a splash page with a download button tests real intent without an app existing. Collecting signups also builds an early user list before any development.

Simulating the product to test memory and behavior

Instead of a full app, early users can be given a bookmarked FAQ or a manual answer service to see whether they remember to seek help and whether their ridership grows over time. Results may show the problem is simpler to solve than expected.

Product development as iteration

Testing does not end once building starts, since each new feature adds new assumptions. Continuing to test keeps teams from overbuilding a product no one wants.

03From the post

“When a team sets out to develop a product, they generate a series of hypotheses. In my experience, good teams are explicit about these hypotheses and test them before they invest too much time into a particular product plan. However, more often than not, I see that development teams are”

04Frameworks mentioned

Summary and takeaways written by PM Atlas; quotes are short excerpts. © the original author.