📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
A grounded take on the real risk sitting under your question: when one customer is half your revenue, losing them can halve the company. Lemkin is honest that concentration is dangerous but survivable, using examples like Twilio and Palantir's top-heavy revenue. Read it to size the stakes calmly instead of either panicking or ignoring them.
From
SaaStr (Jason Lemkin)
by Jason Lemkin
7 min read
- Investors get nervous once a single account passes roughly 10 to 20 percent of revenue.
- Concentration is a risk you manage, not always a reason to walk away from the deal.
- Ten happy big customers reads very differently from one, so widen the base while the whale funds you.
Open
saastr.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 →
✍️ 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 →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
The practical companion piece: what to actually show and say when your largest account asks where their features sit on the plan. It helps you stay transparent without handing over control of what gets built next. Handy for the recurring meetings where a whale customer pushes for commitments.
From
Aha!
by Brian de Haaff
6 min read
- Share direction and themes, not dated promises you will be held to.
- A customer facing roadmap is a communication tool, not a contract.
- You can acknowledge a request honestly while keeping the decision about priority.
Open
aha.io →
📖 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 →
📄 Article
✓ Link checked
Free
Advanced
Why we picked it
Shows the healthy version of working closely with big customers: a deliberate design partner program where a handful of accounts shape the product without any single one owning it. It gives you a structure so custom collaboration feeds the roadmap instead of hijacking it. Useful if you want to keep the big customer close but on your terms.
From
First Round Review
15 min read
- Work with a small deliberate set of partners, not one account, so no single voice dominates.
- Treat partner agreements like real paid contracts with skin in the game on both sides.
- Orient around what several partners need in common, which is the roadmap signal you want.
Open
review.firstround.com →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
Design partners are how B2B founders validate with depth, and this gives you a practical way to pick the right ones. The urgency, capability, and representativeness test helps you avoid partners who love you but never buy, or who move too slowly to teach you anything. It also makes the point that good design partners should convert into your first paying customers.
From
Andreessen Horowitz (a16z)
by Seema Amble and Jennifer Li (a16z)
12 min read
- Score potential partners on urgency, capability, and how representative they are
- The best design partners become your first real customers
- A few deeply engaged partners beat many shallow ones
Open
a16z.com →
📄 Article
✓ Link checked
Freemium
Intermediate
Why we picked it
Practical scripts for turning down or deferring a request without blowing up the relationship, which is the skill you need when the person asking pays half your bills. The reframe of answering yes, and here is what we would drop to make room is directly usable. Read it for the words to say in the actual conversation.
From
Lenny's Newsletter (Lenny Rachitsky)
by Lenny Rachitsky
10 min read
- Never answer a request with a flat yes or no, answer with the trade-off it forces.
- Ask what problem the customer is really seeing before you scope a feature.
- Saying no is easier when you show what the yes would cost the rest of the plan.
Open
lennysnewsletter.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 →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
Deals with the specific pressure of a request that arrives wrapped in a deal, where sales and a big customer both want a yes now. It gives you a 2x2 to separate a genuine market need from a single deal's demand. Useful because your custom asks often come attached to revenue you do not want to lose.
From
Saeed Khan (On Product Management)
by Saeed Khan
9 min read
- Ask whether the feature closes only this deal or many future ones.
- A request tied to revenue still needs to clear the same market test.
- Charge for or defer the truly one-off asks instead of absorbing them into the core.
Open
swkhan.medium.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 →
✍️ Essay
Free
Intermediate
Why we picked it
Before you say yes to the custom features nobody else wants, this essay makes you sit with the real risk: one account that pays a lot can quietly take over your roadmap and turn you into its in-house vendor. McAfee tells the story of a company that let one customer reach 80 percent of revenue, bent the product to that customer's demands, and collapsed when the customer's funding dried up. It is a starting point for weighing when a big customer's asks are worth it and when they are a trap dressed as a win.
From
Startup Patterns (Medium)
by Sam McAfee
- A single dominant customer can mask the fact that you do not yet have real product-market fit, so the revenue feels like validation when it is actually dependence.
- Every custom request pulls capacity away from the product you meant to build; if you lose that one customer, you lose the revenue and the roadmap you traded away for it.
- Keep some engineering capacity reserved for work that serves the whole market, not just your biggest account, and be wary of open-ended custom scopes.
Open
medium.com →
✍️ Essay
Free
Intermediate
Why we picked it
A practical piece on the exact failure mode where each big customer gets their own custom feature and the product fragments into a pile of one-offs nobody else uses. It gives you a way to think about the lifetime cost of a demanding account, not just its contract value. Useful when you are staring at a request that only this one customer will ever touch.
From
The Startup (Kit Merker)
by Kit Merker
8 min read
- A customer who asks for many small custom things will rarely be satisfied by the core product.
- Weigh the ongoing maintenance cost of a custom feature, not just the deal it unlocks.
- Custom work for one account creates drag on every future release for everyone else.
Open
medium.com →
Why we picked it
The permission slip to recruit users by hand, do things manually, and deliver 'insanely great' experiences to your first few customers. The cheapest, most honest way to validate demand is to go get it one person at a time.
From
paulgraham.com
by Paul Graham
~15 min read
- Recruit your first users manually, don't wait for them to come.
- A tiny group of users who love you beats a big group who like you.
- Manual, unscalable effort early is a feature, not a failure.
Open
paulgraham.com →
