Principles

Make it valuable, usable, and feasible

Every product decision sits at the intersection of three questions:

• Is it valuable? Do people actually want this, will they pay for it, will it change their behavior?
• Is it usable? Can people figure it out without a manual, without hand-holding, without calling support?
• Is it feasible? Can the team actually build it, with the technology, time, and resources available?

Most failed products nail one or two but miss the third. A product that's valuable and feasible but unusable becomes shelfware, powerful software nobody can figure out. A product that's usable and feasible but not valuable is a beautifully designed toy nobody needs. A product that's valuable and usable but not feasible is a pitch deck.

Marty Cagan frames this as the PM's core job: your engineers own feasibility, your designers own usability, and you own value. But the real work happens at the edges where these three overlap. The best product decisions satisfy all three simultaneously. When they conflict, you negotiate, not surrender. "We can't build that in time" doesn't kill the idea. It reshapes it into something the team can ship that still delivers the value and remains easy to use.

This isn't a framework you apply once during planning. It's a filter that runs constantly. Every feature request, every scope decision, every pivot should pass through all three lenses. If you can't articulate how something is valuable, usable, and feasible, you're not ready to build it.

In practice: The original iPhone couldn't copy and paste. Apple shipped it anyway because the core value (a real internet browser + phone + iPod in your pocket) was massive, the usability (multi-touch, no stylus) was revolutionary, and the feasibility constraints meant something had to give. They chose to ship without copy-paste rather than delay the entire product or compromise the touch interface. The trifecta wasn't about perfection. It was about making the right tradeoffs across all three dimensions.

Limit the details, perfect the details

Jack Dorsey described the entire discipline of product in one sentence: "Limit the number of details and get the details perfect."

The job reduces to two questions:

• What problem should we solve? The first is about ruthless prioritization, saying no to a hundred good ideas so you can fully commit to three great ones.
• How do we solve it in the most effective and elegant way? The second is about execution excellence, getting those chosen details genuinely right.

It's tempting to spread across too many problems and ship mediocre solutions to all of them.

This principle sounds simple but it's operationally brutal. It means choosing three problems instead of ten. It means telling customers you won't build their request. It means killing features that took months to build because they dilute the experience. The reward is a product with an identity, not a feature warehouse.

In practice: When Stripe launched, accepting payments online took weeks of integration work. Stripe reduced it to seven lines of code. The complexity didn't disappear. Stripe absorbed it so the developer didn't have to. That's what "perfect the details" means: simplicity as the output of deeply considered engineering, not the absence of engineering.

Maximum value in minimum seconds

A great product delivers the maximum amount of value in the minimum amount of seconds. Not minutes. Seconds. Time-to-value is the most important metric, and it separates the products people love from the ones they tolerate.

Think about the products you reach for without thinking. Slack: you type a message, someone replies. The value is immediate. Instagram in 2010: you take a photo, apply a filter, and it looks beautiful. Three taps. Stripe: a developer copies seven lines of code and can accept payments. Each product compressed what used to take hours or weeks into seconds. That compression is the product.

This isn't about removing features. It's about removing the distance between opening the product and feeling the benefit. Every screen, every loading state, every configuration step, every "getting started" wizard is friction standing between your user and the moment they say "this is worth it." On top of sign-ups, monthly active users, and feature adoption, measure the gap between the first click and the first moment of value, the "aha" moment, then ruthlessly shrink it.

The trap is thinking time-to-value only matters for onboarding. It matters for every interaction. Every time a user opens your product, they're asking the same question: was this worth my time? The answer needs to come fast:

• A dashboard that takes ten seconds to load teaches users to check it less often
• A search that returns results in 200ms keeps people in flow
• A report that requires three clicks will be generated less than one that requires one

In practice: When Superhuman launched, they obsessed over making every interaction feel instantaneous. Email loads in under 100ms. Every action has a keyboard shortcut. The entire experience was designed so that the value (getting through email faster) was felt within the first thirty seconds of use. Users didn't need to be told Superhuman was fast. They felt it. That feeling, the gap between expectation and experience, is what turns users into evangelists.

Every yes is a no to something else

Features have hidden costs that never show up in the estimate. Every feature you add increases:

• Cognitive load for users (more choices, more confusion)
• Maintenance burden for engineers (forever)
• Support tickets for the team
• Opportunity cost for the roadmap (hours not spent on what matters)

The compound effect of undisciplined yes-saying is a product that does many things poorly and nothing brilliantly.

The instinct is to say yes because each individual feature seems harmless. But products die from a thousand small yeses, not one big mistake. Instagram started as Burbn with fourteen features: check-ins, plans, points, photo sharing, and more. It only took off when Kevin Systrom and Mike Krieger cut everything except photos and filters, a 60% feature reduction. They launched October 6, 2010. Twenty-five thousand users signed up on day one. One million in two months.

The discipline of no isn't about being negative. It's about understanding that focus compounds. A product that does three things exceptionally well beats a product that does twelve things adequately. Basecamp has been profitable for over twenty years by saying no to most feature requests, including the ones from their biggest customers. They don't offer Gantt charts, time tracking, or resource allocation, all table-stakes features in their category. Their product is better because of what it refuses to be.

In practice: When Sony built the Walkman, the team wanted to add a record button. Cost: 50 cents. Akio Morita refused. Not because it was expensive, but because it would confuse the product's identity. The Walkman was for listening. One purpose, executed perfectly. That clarity is what made it iconic.

Test the riskiest thing first

Google X has an internal innovation principle: if you're training a monkey to recite Shakespeare on a pedestal, start with the monkey. The pedestal is just engineering, you know how to build it. The monkey is the unknown. If the monkey can't learn Shakespeare, the pedestal is wasted effort.

It is tempting for anyone to do the opposite. Build the pedestal first because it feels productive. Admin dashboards, infrastructure, beautiful UI, all before validating whether anyone wants what they're building. A typical bad prioritization sequence: build the admin dashboard, polish the UI, add analytics, then test whether anyone actually has the problem. A good one: test demand first, build a minimal version, validate usage, then polish. The pedestal is comfortable. The monkey is scary. But the monkey is the only thing that matters.

This applies at every scale:

• In a startup, the monkey is whether anyone cares about your problem
• In a feature, the monkey is whether the core interaction works
• In an experiment, the monkey is the assumption most likely to kill the idea

Identify it. Test it. If it fails, you've saved weeks or months of wasted pedestal-building.

In practice: Before building Zappos, Nick Swinmurn posted photos of shoes from local stores online. When someone ordered, he bought the shoes at the store and shipped them himself. Terrible unit economics. But it answered the riskiest question, will people buy shoes online without trying them on?, for nearly zero cost.

People tell you what you want to hear

Every customer conversation is contaminated by politeness. Your mom would tell you your idea is great even if it's terrible, because she loves you. Most people behave like your mom. They say "that's awesome, I'd totally use that" because it costs nothing and avoids awkwardness. This means the default mode of customer research, pitching your idea and asking for reactions, produces noise that feels like signal.

The fix isn't finding more honest people. It's asking questions so well that even your mom can't lie to you. Three rules from Rob Fitzpatrick's The Mom Test:

• Talk about their life, not your idea
• Ask about the past, not the future
• Shut up and listen

"Would you use this?" is the most dangerous question in product because the answer is always yes and it means nothing. "Walk me through the last time you dealt with this" is one of the most valuable because it forces specifics that can't be faked.

The signal you're looking for isn't enthusiasm. It's commitment. Did they give you:

• Time — a follow-up meeting
• Reputation — an introduction to their boss
• Money — a deposit, LOI, or budget allocation

Compliments are free. Commitments cost something. If every conversation ends with "that sounds great, keep me posted," you've collected compliments, not evidence. And if your conversations feel good, you're probably failing. Good discovery conversations are slightly uncomfortable because you're learning things you didn't want to hear.

In practice: Dropbox's Drew Houston spent months talking to people who said "yes, I'd definitely use that" about his file-syncing idea. But he only got real signal when he posted a three-minute demo video to Hacker News. The waitlist jumped from 5,000 to 75,000 overnight, not because of polite encouragement, but because people actually signed up. That commitment (giving an email, joining a waitlist) was the signal that conversations alone never provided.

Fall in love with the problem, not your solution

The best product managers switch solutions without emotional cost. They're attached to the outcome, not the artifact. When a feature fails, they don't mourn it. They ask what the failure taught them about the problem and try something different.

This sounds obvious but it's psychologically brutal. You spent three months building a feature. The team pulled late nights. The design is elegant. And the metrics say nobody cares. The human instinct is to find reasons the metrics are wrong, to wait another month for the data to "mature," to tweak the onboarding so people "discover" the feature. The disciplined response is to kill it and reallocate those resources to something that moves the needle.

Uri Levine, founder of Waze, puts it directly: "Fall in love with the problem, not the solution." The problem is durable. The solution is disposable. If your solution doesn't work, the problem still exists and still needs solving. Your attachment to a particular solution is the thing standing between you and the right answer.

Teresa Torres operationalizes this: for every customer problem, generate at least three different solution ideas before committing to one. If you only have one idea, you're not doing discovery, you're doing rationalization.

In practice: Slack started as an internal communication tool built for a gaming company called Tiny Speck. The game (Glitch) failed. But Stewart Butterfield noticed the team was obsessed with their internal chat tool. He fell in love with the problem (team communication is broken) and abandoned the solution he'd raised millions for (the game). Slack is now worth billions. The game is a footnote.

Charge more than feels comfortable

Underpricing is the default mistake for first-time product builders. The logic sounds generous: "Let's make it affordable so more people can use it." But low prices don't attract more customers. They attract the wrong customers and signal that the product isn't valuable.

Price is information. When a product costs $10/month, buyers assume it does $10/month worth of work. When it costs $500/month, they assume it solves a $500/month problem. Patrick Campbell's research at ProfitWell showed that SaaS companies who raised prices saw higher conversion rates, not lower ones. The price anchored the perceived value higher.

The test is simple: if nobody pushes back on your price, it's too low. You want roughly 20% of prospects to say "that's expensive." If zero prospects flinch, you're leaving money on the table and attracting users who don't value what you've built. The ceiling is almost always higher than founders think.

There's a deeper reason this matters beyond revenue. Higher prices attract customers who are serious about solving the problem:

• They show up and implement properly
• They give real feedback because they're invested
• They renew because the problem is real to them
• They become advocates because they have skin in the game

Low-price customers churn faster, need more support, and never become advocates. Your pricing determines the quality of your customer base as much as your marketing does.

In practice: Superhuman launched at $30/month for email, a category where every competitor was free. People told them nobody would pay for email. Their early users were the most engaged, most vocal advocates the company had. The price filtered for people who genuinely valued speed, and those people evangelized the product to their networks. The premium price wasn't a barrier to growth. It was the growth strategy.

You're not the CEO of anything

The "PM as CEO of the product" framing is everywhere and it's mostly harmful. It encourages command-and-control behavior in a role that has no direct authority. Ken Norton, who spent years as a PM at Google and later as a partner at GV, reframed it: PMs are servant leaders. His shorthand is "bring the donuts." The best PMs deflect praise to the team, absorb blame when things go wrong, and do whatever unglamorous work needs doing, whether that's cleaning the bug queue, replying to a support email, or organizing a document repository. No job should be beneath a product manager. The moment you start thinking of yourself as the person who decides, instead of the person who serves, you've lost the team's trust.

In practice:

• Involve engineers early, never commit to scope without them
• Always explain the reasons behind your decisions
• Respect their time by being specific

These aren't soft skills. They're the operating system for a role that runs on influence, not authority. If your engineers don't trust you, your roadmap is fiction.

Do things that don't scale

Before building systems, do the work manually. Before automating, concierge. Before scaling, serve ten users by hand. This feels inefficient. It's the opposite: it's the fastest way to learn what to build, because you experience every friction, every edge case, and every moment of value delivery firsthand.

Paul Graham's essay on this principle is required reading at YC. The counterintuitive insight: startups fail more often from premature scaling than from not scaling. Building microservices for twelve users isn't engineering, it's procrastination disguised as architecture. The founders who win do things that horrify engineers. They manually onboard every user. They respond to support tickets personally. They hand-deliver the product. And in doing so, they learn things that no dashboard or analytics tool could tell them.

The transition from manual to automated should happen when the manual process is so well understood that you know exactly what to automate. Not before. If you automate a process you don't fully understand, you automate the wrong thing.

In practice: Airbnb's founders went door-to-door in New York photographing apartments for their hosts. It didn't scale. But it dramatically improved listing quality, which improved conversion, which grew the supply side. They did it manually until they understood exactly what "good listing photography" meant, then built tools to help hosts do it themselves. The manual phase wasn't a workaround. It was the strategy.

Written with ❤️ by a human (still)