This document was written on the occasion of 10X's May 2019 announcement, which introduced the online grocery ordering feature in Tabery (our recipe app) and announced our fundraise. The ideas here represent our philosophy of product development — how we think about building products, analyzing behavior, reaching users, and building teams.

Understand

Dig into the problem

  • A product that doesn't solve a real problem cannot create value. Always start from user problems.
  • "User problems" means the gap between the current state a user experiences and the state they want to be in. The wider this gap, the stronger the motivation to use a product that bridges it.
  • The problems worth solving fall into two categories: existing problems the user is already aware of, and latent problems the user hasn't yet articulated. Both are valid, but each requires different discovery approaches.
  • Focusing on niche problems at first is fine. Start with problems that are deeply felt by a specific group, then expand.

Love the problem, not the solution

  • Product development has a natural pull toward solutions. Builders love building. But attachment to a specific solution is dangerous — it makes you blind to feedback that contradicts it.
  • The job is to solve the user's problem in the best possible way. If a better solution exists, pursue it even if it means abandoning work you've done.
  • A product that solves a real problem in an okay way will often beat a product that solves a fake problem in a brilliant way. Love the problem.

Observe users

  • Surveys and interviews are not sufficient. Watch users actually use the product. The gap between what people say they do and what they actually do is consistently large.
  • Set up regular observation sessions. Take notes. Don't filter what you're seeing through your existing assumptions.
  • Resist the urge to explain or defend during observation. You're there to understand, not to convince.

Interview users well

  • One-on-one interviews are invaluable for understanding motivation, context, and emotion — things you can't get from data alone.
  • Ask about behavior, not hypotheticals. "What did you do last time you tried to solve this?" is better than "Would you use a feature that did X?"
  • The goal of an interview is not to validate your ideas but to update your understanding of the user's world.

Understand with data

  • At scale, qualitative understanding needs quantitative support. Data tells you what is happening at volume; qualitative research tells you why.
  • Neither alone is sufficient. Combine them.

Build

Define and share the mission

  • Products are built by teams. Teams need a shared sense of direction. Without a clear, shared mission, individual contributors optimize for different things and the product fragments.
  • The mission should be specific enough to guide real decisions. "Make users happy" is not a mission. "Make it effortless for busy families to plan and shop for groceries" is closer.
  • The mission should be written down and referred to often. It's easy for the team to drift from it under the pressure of day-to-day execution.

Think in user stories

  • A user story is a description of what a user wants to do and why. Keeping the user's goal central in how requirements are written ensures you don't lose sight of who you're building for.
  • "As a [type of user], I want to [do something], so that [I can achieve some outcome]." This format forces you to think about user motivation, not just functionality.

Release minimally

  • Release only what you're confident provides real value. Premature releases create technical debt, support burden, and set user expectations you may not be able to maintain.
  • Once a feature is released, removing it is hard. A feature used by even a small number of users has someone who depends on it.
  • If you haven't released it, you can delete the code without consequences. The bar for shipping should be high.

Don't get in users' way

  • Push notifications, email campaigns, and other interruptions should be reserved for genuinely important information — things users would want to know even if they didn't initiate the contact.
  • Sending unnecessary notifications trains users to ignore you. When you have something important to say, they won't hear it.
  • The goal is to be the product users reach for when they have a specific need, not the product that reaches for them.

Release selectively

  • "Long-term benefit to users" should be the filter for every release decision. If you can't clearly articulate how a feature helps users over the long run, don't ship it.
  • An incomplete release creates more cost than no release. Half-built features generate support tickets, confuse users, and complicate future development.
  • Don't let sunk cost drive release decisions. If a feature isn't right, the best move is often to delete it and move on.

Keep it simple

  • Simplicity is about focus — keeping the product aligned with what users need and what you're trying to achieve.
  • Simple products are easier to build, easier to use, and easier to improve. Complexity compounds.
  • When a product gets complex, return to the core value proposition and ruthlessly cut anything that doesn't serve it.

Analyze

Analytics is a shared language

  • Data analysis exists to make visible whether users are behaving as intended and whether they're satisfied. It informs decisions.
  • Think of analytics as creating a shared language for the team — a way of talking about the product that's grounded in evidence rather than opinion.

Start with words, not numbers

  • Before you can measure something, you need to describe it clearly in natural language. What does "engaged user" mean for your product, specifically?
  • Vague definitions produce misleading metrics. Precise language produces precise measurement.
  • A good analyst is less someone who is good at arithmetic than someone who can think with precision and communicate clearly.

From forest to trees

Issue analysis diagram

  • Work from big questions to small ones. Understanding the overall health of a product before drilling into component metrics prevents the trap of optimizing something that doesn't matter.
  • Issue Analysis — a hierarchical decomposition of the questions you need to answer — is the foundation of good analysis.

Gather data in one place

  • Centralizing data dramatically reduces the overhead of analysis. When data is scattered across systems, every analysis session starts with a treasure hunt.
  • A single data warehouse that contains all behavioral and operational data enables faster, more confident analysis.

Match indicators to phase

Product phase diagram

  • The right metric depends on where you are. Retention rates aren't meaningful for a product that just launched with 50 users. Funnel conversion is.
  • As the product matures and segments become distinct, more granular, segment-specific metrics become appropriate.
  • Using the wrong metric for your phase leads to wrong conclusions and wasted effort.

Read charts correctly

  • Looking at a single KPI gives you almost no information about why something is happening.
  • Always look at distribution, not just averages. The same average can arise from very different distributions, and the distributions tell you things the average hides.
  • Understand what's driving a number before drawing conclusions from it.

Look at distributions

  • Most important metrics are expressed as rates, but averages hide the distribution underneath.
  • A 2% CVR from 1,000 users can come from a bell curve, from a bimodal distribution, or from a long tail. The shape of the distribution determines what you should do.
  • Segmenting users correctly requires understanding the distribution first.

Build dashboards that communicate

  • The goal of a dashboard isn't to display data — it's to enable everyone on the team to reach the same conclusion from looking at it.
  • A great dashboard, combined with documentation and an open culture, can multiply team productivity.

Deliver

Understand the market

  • Market = [number of users doing a specific economic activity] × [frequency of that activity].
  • You need to understand not just the size of your market but its composition. Who are the different segments? What context created the market? Why do people behave the way they do in it?
  • Don't project your own experience onto the market. You are not the user.

Everything starts with awareness

  • Before anyone can use your product, they have to know it exists.
  • All future users begin in a state of zero awareness. Moving them from awareness → understanding → interest → trial → retention → advocacy is the user journey.
  • Sending coupons to people who have never heard of your product is noise. Address users at the right stage of their journey.

Time scaling correctly

  • Scaling before product-market fit is one of the most common ways startups fail. Fix the leaky bucket before you turn on the faucet.
  • Until you have users who return reliably and are satisfied, growth investment is waste.
  • When you do scale, move fast.

Word of mouth is the brand

  • In an environment of information overload, the most credible signal is a recommendation from someone you trust.
  • Build a product people are genuinely excited to tell others about. That organic advocacy is the brand.
  • Track and optimize for word-of-mouth generation as a first-class KPI.

Measure everything

  • Online advertising has three components you can optimize: targeting (are you reaching the right people?), creative (are you saying the right things?), and placement (are you in the right channels?).
  • If you can't measure and attribute across all three, you can't improve. Invest in measurement infrastructure before you scale spending.

Invent one channel

  • Most user acquisition comes from a small number of channels. Don't diversify prematurely.
  • Go deep on one channel, reach critical density, and let network effects build. Portfolio diversification can come later.

Know your competitive stance

  • Competition can't be cleanly defined. First-mover competition, attention competition, income competition, and talent competition all pull from different pools.
  • Early on, focusing on delivering 10X value to any user at all matters more than competitive strategy.
  • When competition becomes a real strategic question, ask: which competition, and by when do we want to be #1 in it?

The Double Jeopardy Law

  • In mature markets, market share drives loyalty and usage frequency — not the other way around.
  • Start small and dominate a narrow segment before expanding. This concentrates your user base in a way that maximizes retention and word-of-mouth.

Reference: How Brands Grow by Byron Sharp

Avoid weak alliances

  • Any partnership where both parties would describe the benefit as "somewhat helpful" is probably not worth doing.
  • Good partnerships should allow both sides to achieve a major goal or dramatically shorten the distance to one.
  • Alliance work — aligning interests, understanding context, navigating governance — is some of the hardest work in business. Do it only when the stakes are worth it.

Build the team

Why teams exist

  • In an era when individuals can build simple products alone, the reason to build a team is to tackle problems that are too hard for any individual.
  • The constraint on individual output is time. Teams exist to compress time — to work on multiple hard problems in parallel.

The difference is in who

  • The most important decision you make as a founder is who you build your team with.
  • Seek what Google calls "learning animals" — people who can define their own problems, learn what they need to learn, and solve those problems with minimal direction.
  • The gap between a team of learning animals and a team of people still figuring out how to learn is not 10x. It's much larger.

Back to back

  • The ideal team dynamic: everyone is working on different hard problems simultaneously, but facing the same direction. Brief, dense communication, pulling on each other's knowledge, then back to focused work.
  • Individual contribution and creativity matter. Maximize those, and team throughput follows.

The team is the product

  • The team is a product. It can be designed, iterated on, and improved.
  • The HR and operations functions are in the business of making the team excellent. Think of the Head of People as the product manager for the team.

Values are set early

  • The values of a team crystallize around the values of the first few people on it.
  • Values cannot be imposed from above after the fact. They must be lived by the founders and earliest members.
  • This is the deepest reason why early hiring decisions are so consequential.

Optimize for throughput, not headcount

  • More people does not automatically mean more output. Hiring great people who work together well increases throughput. Hiring mediocre people in volume can actually decrease it.
  • Speed is a function of efficiency, not team size. Who you put on the boat matters more than how many people are on it.

Align incentives

  • The ideal state is one where every stakeholder in the team has their incentives aligned with the team's success.
  • Incentives should tie back to the value the team creates. When the team generates more return, everyone benefits proportionally.

Pursue genuine openness

  • Openness means: anyone on the team can access any piece of information at any time; it's clear where information lives; and informal communication is easy.
  • Learning animals, given shared information and shared principles, will make approximately the same decisions. Openness multiplies throughput.

Related post: What true openness means

Build to last

  • Hard problems take time. Build a team designed to fight for years, not months.
  • Maintain cash flow that preserves optionality. Build team structures that prevent people problems from accumulating.

Manage cash flow

  • Without cash flow, no team survives. Operating cash flow from the product should compound over time.
  • Use financing cash flow to bridge the gap during long-horizon investment periods.

Keep the business model simple

  • There is no such thing as a novel business model. Buy low, sell high — the rest is complexity layered on top.
  • Simple business models are easier for customers to understand and easier for partners to engage with.
  • Focus on making a simple business strong rather than making a complex business slightly more interesting.

On writing this document

On May 14, 2019, we announced two things at 10X: the launch of the grocery ordering feature in Tabery (our recipe app), and the completion of our fundraise.

Tabery was our attempt to solve a problem I personally know well as a parent of two young children: planning meals and doing grocery runs with kids in tow is genuinely hard. With this update, we've created the beginning of a complete mobile solution for the full loop — plan what to cook, decide what to buy, and order it.

The launch marks the beginning, not a destination. What I'm most grateful for is the team — the people who've been building this alongside me with complete seriousness and intention. This document is a reflection of what we believe, as a team, about what it takes to build something that matters.