📖 Book
✓ Link checked
Paid
Beginner
Why we picked it
The single best thing ever written on customer conversations. It teaches you to ask about the customer's life and past behaviour, not your idea, so you can't be lied to. If a founder reads one thing before talking to a single customer, it's this.
From
momtestbook.com
by Rob Fitzpatrick
~130 pages
- Talk about their life, not your idea.
- Ask about specifics in the past, not opinions about the future.
- 'That's so cool, I'd totally buy it' is a compliment, not data, dig for commitment and evidence.
Open
momtestbook.com →
✍️ Essay
✓ Link checked
Free
Intermediate
Why we picked it
This gives you the actual checklist a request has to clear before it earns a yes, starting with whether it fits the vision and the customers you are building for. It names how products rot one lazy yes at a time, which is the cost you are protecting against. Read it when you want a repeatable filter instead of deciding each request on gut feel.
From
Intercom (Des Traynor)
by Des Traynor
10 min read
- A new feature should pass a fixed set of questions before you commit to it
- Your vision matters more than any single request, metric, or sales target
- Bloat is invisible in the moment and only obvious in the rear view mirror
Open
intercom.com →
📄 Article
✓ Link checked
Free
Beginner
Why we picked it
This is the piece about the conversation itself, so the customer feels heard even when the answer is no. It walks through questioning the request, understanding the goal behind it, and closing the loop honestly rather than going silent. Use it for the exact wording that keeps the relationship intact.
From
Intercom
by Paulina Welnic
8 min read
- Acknowledge and question the request before you judge it
- Uncover the goal the customer is chasing, not just the feature they named
- Always close the loop, since silence is what actually loses customers
Open
intercom.com →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
Des Traynor makes the case that "no" is the product strategy, and that adding a feature for one loud customer quietly costs every other user. It gives you language to defend a tight v1 against constant requests. Short, sharp, and directly about the discipline of cutting.
From
Intercom (Des Traynor)
by Des Traynor
~8 min read
- A cohesive product with clear boundaries beats a pile of tangential features.
- Every feature you add has an ongoing cost, not just a one-time build cost.
- No single customer request is worth more than a coherent product.
Open
intercom.com →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
The original, primary source where the RICE framework was introduced, cite this, not the SEO reposts. The clearest way to compare hard-to-compare feature ideas.
From
Intercom Blog
by Sean McBride
~12 min read
- Score = (Reach x Impact x Confidence) / Effort.
- Forces you to quantify confidence and expose low-confidence pet projects.
- Comparable scores let you rank features objectively.
Open
intercom.com →
✍️ Essay
✓ Link checked
Free
Advanced
Why we picked it
Cagan argues your job is to deliver outcomes, not to maintain a prioritized list of everyone's requests. That is the backbone of anchoring a no to the outcome you are chasing rather than to who shouted loudest. Read it to stop treating your roadmap as a request queue.
From
Silicon Valley Product Group (Marty Cagan)
by Marty Cagan
10 min read
- Commit to problems and outcomes, not a fixed list of features
- A request spreadsheet quietly pushes in things users do not actually need
- Frame the roadmap around the outcome so a no has a reason behind it
Open
svpg.com →
✍️ Essay
✓ Link checked
Free
Intermediate
Why we picked it
This names the failure mode you are trying to avoid: shipping feature after feature and mistaking motion for progress. Perri shifts the question from what did you deliver to what did you learn about the customer, which is the test a request should pass. Short and sharp, good for a gut check before you say yes to keep someone happy.
From
Melissa Perri
by Melissa Perri
6 min read
- Shipping features is easy, deciding what to build is the hard part
- Measure outcomes and learning, not the count of features shipped
- More features do not automatically make a product more valuable
Open
melissaperri.com →
📖 Book
✓ Link checked
Paid
Intermediate
Why we picked it
The full book behind the essay, for when you want the system and not just the idea. It gives you the language of outcomes over outputs so you can defend a no to your team and your customers with something concrete. Worth it if requests are piling up faster than you can reason about them.
From
Melissa Perri (O'Reilly)
by Melissa Perri
200 pages
- Tie every build decision to a measurable customer or business outcome
- Say no to work that only adds output without moving an outcome
- Set up the org so outcomes, not feature counts, decide priority
Open
amazon.com →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
Turns the vague feeling of product-market fit into a number you can move. Ask users how they would feel if they could no longer use the product, then track the share who say 'very disappointed'. Under 40 percent means keep working. A test you can run on an idea long before you scale it.
From
First Round Review
by Rahul Vohra
~20 min read
- The 40 percent 'very disappointed' benchmark for product-market fit.
- Segment to your high-expectation customers and build for them.
- Make the fit score a metric you improve quarter by quarter.
Open
review.firstround.com →
📖 Book
✓ Link checked
Paid
Beginner
Why we picked it
A punchy, contrarian classic on building a lean, sane, profitable company from the founders of Basecamp. It's the antidote to hustle-culture folklore about how startups must operate.
From
37signals
by Jason Fried & David Heinemeier Hansson
~288 pages
- Small teams, less process, and shipping beat planning theatre
- Say no to most things and protect focus
- You can build a great company without following the standard playbook
Open
amazon.com →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
To say no to the right requests you need feedback you can trust, and this shows how to get it by watching customers rather than just taking their asks. It reinforces that observing the struggle tells you more than the feature name they hand you. Practical field technique for separating a stated want from a real need.
From
First Round Review
by Michael Sippey
12 min read
- Watch what customers do, not only what they ask for
- Get close to the actual struggle to find the real problem
- Stated requests are a starting point for questions, not a spec
Open
review.firstround.com →
📄 Article
✓ Link checked
Free
Beginner
Why we picked it
This is the principle behind the first half of your answer: a request is a proposed solution, so back up to the problem before you accept or reject it. It shows how starting from the problem often reveals a better fix than the exact feature asked for. Handy for reframing a no as a redirect to the real need.
From
Intercom
by Stephen Forbes
8 min read
- Every feature request is a solution, so find the problem behind it
- Starting from the problem often beats the exact feature requested
- A no lands better when paired with the real problem you heard
Open
intercom.com →
📄 Article
✓ Link checked
Free
Beginner
Why we picked it
A practical, scripts-included guide aimed squarely at saying no without burning the relationship. It covers acknowledging the request, explaining the reasoning, offering a workaround, and framing no as not now, which is the customer-facing craft your answer needs. Reach for it when you have the decision made and just need to phrase it well.
From
Canny
by Jenna Potter
9 min read
- Explain the reasoning so the no feels deliberate, not dismissive
- Offer a workaround or a not now instead of a flat door slam
- Transparency about why can strengthen the relationship, not weaken it
Open
canny.io →
