
Evaluating Trade Offs
Frame product and engineering choices with order-of-magnitude reasoning and thought experiments before burning build time on weak bets.
Overview
Evaluating Trade-offs is a journey-wide agent skill that surfaces Lenny podcast wisdom on deciding under uncertainty—usable whenever a solo builder needs to compare paths before committing resources.
Install
npx skills add https://github.com/refoundai/lenny-skills --skill evaluating-trade-offsWhat is this skill?
- Curated guest insights: 40 guests and 42 mentions on trade-offs
- Order-of-magnitude framing instead of false precision on uncertain forecasts
- Thought experiments to kill doomed ideas before engineering spend
- Tactical quotes from operators such as Alex Komoroske and Anuj Rathi
- Contrasts speed-vs-excellence and try-everything vs metathinking
Adoption & trust: 1.3k installs on skills.sh; 1k GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
You are torn between options and tempted to either fake precise ROI numbers or ship every half-baked experiment into code.
Who is it for?
Indie founders and one-person PM+eng roles who want a lightweight decision lens before writing plans or spawning parallel agent tasks.
Skip if: Teams that already have a signed spec, quantitative model with real data, or a formal stage-gate process that replaces qualitative trade-off review.
When should I use this skill?
You must choose between strategic options, experiments, or ship-quality bars and want qualitative guardrails before implementation.
What do I get? / Deliverables
You rank choices by magnitude and reasoning quality, drop likely failures early, and enter build with a clearer bet instead of analysis paralysis or random trials.
- Ranked options with magnitude-based rationale
- List of experiments or directions explicitly not worth building
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Compare two audience directions by magnitude of upside instead of debating point estimates in a blank spreadsheet.
Run a thought experiment on whether a feature experiment is doomed before asking your agent to prototype it.
Choose excellence on a flagship flow when the skill corpus argues mediocre speed wastes company time for a solo brand.
Cut nice-to-have launch items when magnitude favors a smaller noteworthy release.
Prioritize lifecycle bets that are orders of magnitude better than incremental tweaks.
How it compares
Use as curated decision philosophy alongside structured planning skills—not as a substitute for quantitative analytics when you actually have reliable metrics.
Common Questions / FAQ
Who is evaluating-trade-offs for?
Solo and small-team builders who make product calls daily and want podcast-grade framing on speed, quality, and uncertainty without hiring a strategy consultant.
When should I use evaluating-trade-offs?
At idea when comparing markets, at validate when scoping an MVP, at build when choosing what not to build, at ship when cutting scope, and at grow when prioritizing bets with limited bandwidth.
Is evaluating-trade-offs safe to install?
It is primarily reference text without install scripts in the excerpt; still review the Security Audits panel on this Prism page before adding any skill from the registry.
SKILL.md
READMESKILL.md - Evaluating Trade Offs
# Evaluating Trade-offs - All Guest Insights *40 guests, 42 mentions* --- ## Alex Komoroske *Alex Komoroske* > "Trying to ignore it by trying to pin it down with fake numbers that you just made up for yourself at great expense is a really bad idea... It doesn't really matter if it's 1,000 or 1,001, who cares? It orders a magnitude larger than the alternative, and so it is better." **Insight:** In highly uncertain environments, focus on order-of-magnitude differences rather than wasting effort on 'false precision.' **Tactical advice:** - Avoid over-analyzing minor numerical differences in long-term forecasts. - Prioritize directions that offer significantly higher potential returns (orders of magnitude) over those that are merely slightly better. *Timestamp: 01:12:56* ## Anuj Rathi *Anuj Rathi* > "In my opinion, when you have to make a choice, think more and ship better. Most experiments should be thought experiments. They should not even be tried out because they're obviously going to fail which is contrary to, 'Let's try it out, and then let's see.' I think that wastes a lot of company time." **Insight:** Prioritize excellence over speed by using rigorous 'thought experiments' to eliminate weak ideas before they reach the engineering stage. **Tactical advice:** - Use 'metathinking' to predict experiment failure and save company resources. - When forced to choose between shipping fast and shipping better, choose excellence to ensure the product is noteworthy. *Timestamp: 00:49:19* ## Annie Duke *Annie Duke* > "Waste is a prospective problem, not a retrospective one... if you wouldn't start this today, then that means that everything that you're putting into this going forward is the actual waste." **Insight:** To evaluate whether to continue a project, ignore sunk costs and ask if you would start the project today with the current information. **Tactical advice:** - Ask: 'If I weren't already in this project/relationship/job, would I start it today?' - Recognize that continuing a failing path is the true waste of future resources. *Timestamp: 01:13:35* ## Bob Baxley *Bob Baxley* > "Tenets are really decision-making tools and it's sort of like... A classic one is paper versus plastic. It's just too complicated to reconsider that every time you're at the grocery store. So you sort of make a rule for yourself and you're just a paper person or a plastic person, you move on from there." **Insight:** Effective tenets are 'this over that' choices that eliminate recurring debates by setting a permanent direction. **Tactical advice:** - Identify debates the team has repeatedly and create a tenet to decide the direction once and for all. - Ensure tenets are specific enough that someone could reasonably argue for the opposite (unlike platitudes like 'be simple'). *Timestamp: 00:38:20* ## Bret Taylor *Bret Taylor* > "If you're a great engineer, the answer to almost every problem in your business is engineering... you probably by default should question it." **Insight:** Avoid the bias of applying your primary skillset as the solution to every problem; the real solution may lie in a different discipline. **Tactical advice:** - Question solutions that fall too comfortably within your own area of expertise *Timestamp: 00:22:14* ## Dan Hockenmaier *Dan Hockenmaier* > "But then you have all these teams that are really managing some tension in the business, which is totally different than a funnel. So say if you have a marketplace quality team... if I let on a bunch of new supply to a marketplace, probably the first thing that happens is our GMV or our revenue goes up... but if those are on average lower quality, it's going to degrade the kind of customer experience and reduce retention over time. And so the model that they're trying to build is how to manage that tension." **Insight:** Certain teams must build models to manage inherent tensions (e.g., quality vs. quantity) rather than simple linear funnels.