Skip to main content
Margin Levers
MethodologyPricingFree ToolsAgents & API
Analyze Your Customers FreeSign In

See the profit drag hiding in your customer data

Upload your customer data and get a profitability analysis in 5 minutes — built on profit curve methodology used by top SaaS founders.

Try it free — no credit card

Product

  • Pricing
  • Open Source Program
  • Methodology
  • Integrations
  • Blog
  • Help & Support
  • Changelog
  • vs. DIY AI
  • Pricing
  • Open Source Program
  • Methodology
  • Integrations
  • Blog
  • Help & Support
  • Changelog
  • vs. DIY AI

Free Tools

  • Analyze Your Customers Free
  • Profit Drag Calculator
  • Cost Calculator
  • Profit Drag Checklist
  • Email Templates
  • Board Template
  • Profit Drag ROI Calculator
  • Industry Benchmarks
  • SaaS Unit Economics
  • Churn Impact Calculator
  • Gross Margin Quiz
  • Analyze Your Customers Free
  • Profit Drag Calculator
  • Cost Calculator
  • Profit Drag Checklist
  • Email Templates
  • Board Template
  • Profit Drag ROI Calculator
  • Industry Benchmarks
  • SaaS Unit Economics
  • Churn Impact Calculator
  • Gross Margin Quiz

Legal

  • Privacy
  • Terms
  • Your data stays yours →
  • What We Will Never Do
  • Verify Privacy
  • About

© 2026 Margin Levers. All rights reserved.

* Profit Curve methodology pioneered by Jason Cohen at WP Engine. Learn more →

v3.118.0.0 · Beta

Analyze Your Customers FreeSign In
Back to Blog

What Would 100x Your SaaS? How to Use Claude for First-Principles Feature Brainstorming

By Vince Fulco·April 7, 2026·7 min read
AI toolsproduct developmentB2B SaaSbuild in public

What Would 100x Your SaaS?

TL;DR: Two questions — asked to Claude — consistently surface better feature ideas than roadmap grooming sessions. The first is a jobs-to-be-done probe. The second is a first-principles 100x frame borrowed from Book of Elon by Eric Jorgenson. Together they break you out of incremental thinking and into category-level insights.

Most B2B SaaS roadmaps are built from three sources: support tickets, competitor feature lists, and whatever the loudest customer said on the last call.

None of those sources are wrong. But all three share the same blind spot: they're anchored to what exists today. They optimize the current product rather than reimagining it.

The best product ideas don't come from polishing what you have. They come from stepping back and asking what the product should be — for the person it's supposed to serve.

The Book of Elon Frame

Eric Jorgenson's Book of Elon distills a pattern Musk applies repeatedly across Tesla, SpaceX, and Neuralink: return to first principles, strip away assumptions, and ask what the thing would look like if you built it from scratch for the outcome you actually want.

It's a technique most founders know about and almost none consistently apply. The reason: it's uncomfortable. First-principles thinking surfaces how much of your product is legacy decision-making dressed up as features.

AI changes the calculus. You no longer have to sit alone with a blank page. You can spar with a model that has no attachment to your existing architecture, your current pricing, or your last sprint.

Two Questions That Change the Conversation

I've been running this with Claude and the outputs have been consistently surprising. The framework is two questions, used in sequence.

Question 1 — The JTBD Probe:

"What would theoretically make this application a perfect tool for someone with this specific job-to-be-done?"

This forces you to name the real job. Not "they want to upload a CSV" but "they need to know which customers are secretly destroying their margins before their next board meeting." The specificity unlocks different ideas.

Question 2 — The 100x Frame:

"What would 100x this application's value in the marketplace?"

This is where it gets interesting. The question is deliberately extreme. You cannot 10x a feature. You cannot 100x an export screen. The math forces you out of the UI layer and into the model layer — the pricing model, the data model, the workflow model.

The 100x answers tend to be about compounding rather than features. Things like: cross-customer benchmarks that get more accurate with every new dataset. Automated action triggers that fire when the analysis detects a threshold breach. A methodology so embedded in how founders think about their business that switching to a different tool means unlearning a framework, not just migrating data.

What I've Learned Running This Framework

A few patterns emerge consistently:

Your support tickets are a goldmine — but in disguise. Customers describe the pain, not the solution. They say "I can't figure out which customers to prioritize" — not "I want a sortable column with a profitability score." The JTBD probe helps you translate symptom language into outcome language, which is where the leverage is.

The 100x frame breaks roadmap incrementalism. "Better export formatting" is a v2 feature. "Export a prioritized action list with pre-written outreach copy for each segment" is closer to a 100x lever — because it collapses the gap between analysis and action. One is a UI improvement. The other is a category expansion.

Claude will surface combinations you wouldn't connect alone. Pricing models × workflow triggers × data integrations. The model has no attachment to your current implementation, so it recombines freely. Some outputs are impractical. A few are genuinely category-defining.

The best ideas are often half-right. The 100x answer Claude gives you isn't the feature — it's the direction. You still have to do the synthesis and the taste-editing. But it's faster and more generative than a blank whiteboard.

How to Run This in Practice

Here's the actual prompt structure I use in Claude:

Context: I'm building [product name] for [ICP — be specific: "B2B SaaS founders at $1-15M ARR"].
Their primary job-to-be-done: [one sentence, outcome-focused].
Current key features: [3-5 bullets, honest].

Question 1: What would theoretically make this a perfect tool for someone with this exact job-to-be-done? Be specific and honest about gaps.

Question 2: What would 100x the value of this application in the marketplace? Ignore current constraints — think first principles.

Run both in a single message. Don't split them across sessions — the context from the JTBD answer sharpens the 100x answer.

Then do something counterintuitive: ask Claude to argue against each idea it generated. This surfaces the hidden assumptions in the 100x suggestions before you fall in love with them.

Why This Beats a Roadmap Session

Traditional roadmap grooming has a structural problem: it's a negotiation. Between what customers asked for, what engineering estimated, what sales promised, and what the founder wants to build. The loudest voice wins.

The two-question Claude framework has no politics. It's a brainstorming partner with no ego and no attachment to the current sprint. It will tell you that your most-requested feature is a distraction from a deeper lever if the first principles suggest it.

That's uncomfortable. It's also exactly what you need to hear before you commit six engineering weeks to the wrong thing.

The Source of the Best Ideas

Sometimes the best ideas come from clients who feel the pain directly — they're living in the problem every day and they'll describe it with a precision no amount of user research can replicate.

Sometimes they come from this kind of forced first-principles thinking — stripping away what you've built and asking what you should build for the outcome that actually matters.

Both sources are valuable. The mistake is treating your support queue as your product strategy. Your support queue tells you what's broken. First-principles brainstorming tells you what's possible.

Run both. Reconcile them. That's where the roadmap lives.


Frequently Asked Questions

What is first-principles thinking in product development?

First-principles thinking means stripping away assumptions and reasoning from the ground up — asking what a product would look like if you built it from scratch for the outcome you want, rather than iterating on what already exists. In product development, it means questioning whether existing features actually serve the core job-to-be-done, or whether they're legacy decisions dressed up as roadmap items.

What is a jobs-to-be-done framework?

Jobs-to-be-done (JTBD) is a product strategy framework that focuses on the outcome a customer is trying to achieve — the "job" — rather than the demographic profile of the customer or the features of the product. A customer doesn't want a CSV export; they want to walk into their board meeting with a clear answer to "which customers should we double down on and which are destroying our margins?" Feature decisions look different when you start from that outcome.

How do I use Claude for product brainstorming?

Provide specific context: your ICP (be precise — "B2B SaaS founders at $1-15M ARR" not "small businesses"), the primary job-to-be-done in outcome language, and your current key features honestly. Then ask the two questions in sequence: the JTBD probe and the 100x frame. After getting answers, ask Claude to argue against each idea it generated — this surfaces hidden assumptions before you commit to a direction.

What is the 100x question for SaaS feature development?

"What would 100x this application's value in the marketplace?" The question is intentionally extreme. The 10x version still lets you optimize existing features. The 100x version forces you to reason about compounding mechanisms — cross-customer data effects, workflow automation, methodology lock-in — that can't be achieved by adding a column to a table or improving an export screen.


If you're building B2B SaaS and want to see this framework applied to customer profitability — which 100x levers look like: automated re-pricing triggers, segment-level expansion plays, and action lists that write themselves — try Margin Levers free. No signup. No email. Results in 5 minutes.

Continue Learning

Profit Curve Methodology

How customer profitability analysis works

Learning Center

Guides, strategies, and deep-dives

SaaS Benchmarks

Industry profitability comparisons