This post was originally published as the 26 Mental Models to Build Better Products in 2026 in my VSL Substack publication.
Two weeks of coding magic, one flawless launch and one very sad-looking usage chart. That’s what usually hits you when you build before you validate.
It feels great to create until you realize you built the wrong thing beautifully.
AI makes it dangerously easy to build everything, but it won't tap you on the shoulder when you're building the wrong thing.
The mental models I’m about to share are the thinking patterns that prevent this. They're quiet questions you should ask yourself before touching code.
So get ready because this is going to be a long one. I’ve put together 26 frameworks to help you decide what to build before you build it.
You can bookmark this and come back to it when you're stuck between options or unsure if an idea is worth your time.
WHY This Matters
When you skip product thinking you end up building features nobody asked for. You solve problems that don't exist and waste weeks on code that, in the end, gets deleted.
The pattern is predictable. You prompt AI to build a feature and deploy it perfectly, only to watch users ignore it while you wonder why flawless code didn't lead to adoption.
Unfortunately, the problem was your judgment and not the execution.
Maybe you didn't validate if the feature mattered and ended up building something users don't need. Or you didn't check if users would understand it and ended up creating confusion instead of clarity.
And if there was something I would’ve paid to be told last year was that product mistakes compound quickly.
That unused feature sits in your repo needing maintenance and ends up complicating your codebase for months. It confuses new users and ends up wasting debugging time that should have gone toward features people actually use.
The real price you pay is opportunity cost. Features that would have mattered don't exist because you spent your energy building the ones that didn't.
And that’s why you must start with product thinking before writing a single prompt.
What’s A Mental Model About
Mental models are reusable thinking patterns that help you make better decisions faster.
Experienced product builders use these instinctively. Before writing any code, they ask specific questions:
Who's this for?
What problem does this solve?
How will people discover this?
What's the simplest version that works?
What breaks if we get this wrong?
These frameworks are not random questions. The same pattern you use to evaluate a new feature also applies to pricing changes, onboarding flows, and API design. Learn the model once, use it everywhere.
Three core principles
Decision frameworks beat implementation details. Mental models help you evaluate options before you start building. They won't tell you how to code something, but they will tell you if you should code it at all.
Pattern recognition works across contexts. The "build vs. buy" model works for authentication just as well as it does for analytics. The "jobs to be done" model applies to landing pages just as well as feature prioritization. You are building a toolkit that works across every decision you face.
Prevention always beats fixing. You catch product mistakes in your head when changes cost nothing instead of catching them in production when they cost everything.
Think of these models as a senior product manager reviewing your ideas before you build.
They ask the hard questions early to force you to check if you validated demand, or if users truly understand the value.
But the real difference between a person and these models is speed.
A senior PM takes days to give feedback while these models take just five minutes.
Needless to say that if you can afford a senior PM you should definitely run things by them.
The 26 Mental Models Framework
Product Validation Models
These cover what to build and when
1. The Mom Test
Decides: Whether your product idea solves a real problem
When to use: Before building anything, especially when validating with friends/family
Your mom will tell you your app idea is great because she loves you. Friends will say "I'd totally use that!" because they don't want to hurt your feelings.
The model works like this: Ask people about their current behavior instead of asking then if they would use your solution.
"Would you pay for a tool that organizes your bookmarks?" is worthless.
"Tell me about the last time you couldn't find a bookmark you saved" reveals whether this problem actually exists in their life.
Key questions: What did you do the last time you faced this problem? How much time/money did it cost you? What solutions have you tried? How much would it be worth to solve this?
What makes it different: Forces conversations about past behavior and real pain, not hypothetical interest and polite encouragement.
2. The Ramen Profitable Filter
Decides: If this feature/product can generate enough revenue to sustain you
When to use: When choosing between multiple product ideas or features
You need to build something that makes enough money to keep you building rather than a unicorn.
The filter asks: Can I get to 10-50 paying customers with this specific solution? It's a mistake to start with "will this scale to millions?" Just "can I find my first 50 people who will pay?"
Example: You're choosing between building AI-powered resume optimization (massive market, huge competition) or a niche tool for freelance podcast editors to manage client revisions.
The resume tool might scale bigger. The podcast tool can get to 50 customers in communities you already know, like Substack, Reddit, Facebook groups or Discord servers where editors hang out.
Key questions: Who are the first 10 customers by name or community? What's the specific painful problem they have right now? What's a reasonable price they'd pay monthly? Does 10-50 customers at that price cover your living costs?
3. The Hair-On-Fire Problem
Decides: Whether the problem is urgent enough that people will switch to your solution
When to use: Validating problem severity before building
Problems come in two categories: hair-on-fire urgent and "yeah, that's annoying." Only the first category makes people switch tools.
If someone's hair is on fire, they don't politely research solutions. They grab whatever's closest. That's the urgency level you need.
Example: Losing customer data because your backup system failed? That’s the Hair-on-fire scenario which forces you to buy a solution today. Manually copying data between two tools that takes 10 minutes weekly? Annoying, but you'll keep doing it for months before switching.
Key questions: Are users actively searching for solutions right now? Have they tried multiple existing solutions? Would they pay to solve this today or "eventually"? What's their current painful workaround?
What makes it different: Separates "nice to have" features that never gain traction from "must have" solutions people adopt immediately.
4. The Unfair Advantage Test
Decides: Why you can build this better than anyone else
When to use: Before committing to a product direction in a competitive space
Every idea sounds good until someone with more resources copies it in two weeks.
Your unfair advantage is something that can't be easily replicated: unique data access, specialized expertise, an existing audience, proprietary technology, or deep domain knowledge.
Example: Building a generic project management tool? No unfair advantage because Notion, ClickUp, and fifty others already exist. Building a project management tool specifically for film production crews using terminology and workflows you learned from 10 years in the industry? That's an unfair advantage competitors can't copy without living your experience.
Key questions: What do I have that competitors would need years to build? Can this be copied with money alone? Does this advantage matter to customers?
5. The MVP Scope Guillotine
Decides: What's actually essential for the first version
When to use: When scoping your first version or any major feature
The guillotine is brutal: If users can accomplish their core goal without this feature, it doesn't make V1.
Here's how to use it: State the core user goal in one sentence. Then evaluate each planned feature: "Can users accomplish [core goal] without this?" If yes, cut it.
Example: Core goal: "Help freelancers send professional invoices and get paid."
Features you're considering:
- Create invoice with line items → Essential (can't invoice without this)
- Send invoice via email → Essential (can't get paid if client doesn't receive it)
- Accept credit card payments → Essential (need a way to get paid)
- Recurring invoices → Cut it (they can manually create monthly invoices)
- Expense tracking → Cut it (doesn't help them invoice clients)
- Client portal → Cut it (email works fine for V1)
- Multi-currency → Cut it (start with one market)
What makes it different: Most builders include features that feel important but aren't necessary. This model forces you to be honest about what's truly essential.
User Experience Models
Decide what users are going to use and what they won’t
6. The Jobs-To-Be-Done Lens
Decides: What outcome users are hiring your product to deliver
When to use: Designing features, writing copy, planning onboarding
Users actually hire products to get a job done. Nobody wants a drill. They want a hole in the wall so they can hang a picture so their living room feels complete. The same applies to a piece of software
This lens shifts your focus from features to outcomes.
Example: You're building a time-tracking app.
Feature-focused thinking: "Users need start/stop timers and project categories."
Jobs-focused thinking: "Users need to bill clients accurately without manually reconstructing what they worked on."
That insight changes everything. In this case the job is generating accurate invoices rather than just tracking time. So maybe the solution is not manual timers but automatic time detection.
Key questions: What's the user trying to accomplish? What's their life like before and after using this feature? What alternatives are they using now? What job is that alternative really doing?
7. The Empty State Problem
Decides: How to design the experience when users have no data yet
When to use: Every time you build a dashboard, list view, or data display
Most builders design for the full state. During development you use dummy data so your dashboard is populated with numbers, graphs, and activity. But every user starts with nothing. Empty states either guide users to success or lose them immediately.
Example of empty state failure: User signs up for your analytics tool. They land on a dashboard showing... blank graphs and "No data available." They don't know what to do next. They close the tab.
Example of empty state success: Same dashboard, but empty state shows: "Connect your first data source to see insights" with a big button labeled "Connect Google Analytics." Below: "This takes 2 minutes and you'll see your first dashboard immediately." ***Clear next action.*
Key questions: What does a first-time user see? Is the next action obvious? Does the empty state feel broken or intentionally helpful? Can they reach a "success" state in their first session?
8. The Error Message Principle
Decides: How to communicate what went wrong and what to do next
When to use: Writing any error, warning, or validation message
"Invalid input" is useless. "Email addresses can't contain spaces. Please remove any spaces and try again" tells users exactly how to fix it.
The principle has three parts: (1) What went wrong, (2) Why it's wrong, (3) How to fix it.
Bad error message: "Authentication failed"
Good error message: "Wrong password. Check your caps lock and try again. [Reset password]"
Bad error message: "File upload error"
Good error message: "This file is 12MB but our limit is 10MB. Try compressing it or splitting into smaller files."
Key questions: Does this message explain what specifically went wrong? Does it tell users how to fix it? Would someone non-technical understand this?
9. The Progressive Disclosure Pattern
Decides: How much information to show at once
When to use: Designing complex interfaces, multi-step processes, settings pages
Showing everything at once overwhelms users. Progressive disclosure reveals information in layers starting with basics and only showing advanced options when needed.
Example: Settings page with 40 options all visible at once? Overwhelming. Settings page organized into "General" (5 basics visible) with "Advanced Settings" collapsed below? Manageable.
The pattern works in onboarding too: Don't explain every feature on day one. Show the core workflow first. Introduce advanced features when users are ready.
Key questions: What does every user need to see immediately? What can wait until they ask for it? Can beginners accomplish their goal without seeing advanced options?
10. The Feedback Loop Check
Decides: Whether users understand that their action worked
When to use: Any user action including buttons, forms, saves, deletions
Users click "Save." The button does nothing visible. Did it work? They click again. And again. Now they've created three duplicate entries because there was no feedback.
Every user action needs a closed feedback loop: Loading state (processing), success state (it worked), or error state (it failed).
Examples:
- Button click → Button shows spinner → Success message appears → Button returns to normal
- Form submission → "Saving..." indicator → "Saved successfully" with checkmark → Form clears or navigates
- File upload → Progress bar → "Upload complete" → File appears in list
Key questions: After clicking/submitting, does the user know immediately that something is happening? Do they know when it's complete? If it fails, do they know what went wrong?
Technical Decision Models
Decide if that feature is worth your time and effort
11. The Build vs. Buy Scorecard
Decides: Whether to code it yourself or use a third-party service
When to use: Evaluating authentication, payments, email, analytics, search
Use a scoring system with three questions, each rated 0-10:
- Is this core to my product's unique value? (0 = commodity, 10 = your secret sauce)
- Is there a battle-tested solution I can buy? (0 = I'd need to build it, 10 = Stripe/Auth0 level quality exists)
- Will building this take more than one week? (0 = few hours, 10 = months of work)
If questions 2 and 3 score high (15+ combined), buy it. If question 1 scores high (8+), consider building.
Example: Authentication for your SaaS
- Core to your value? 2/10 (everyone needs auth, it's not your differentiator)
- Battle-tested solution exists? 10/10 (Clerk, Supabase Auth, Auth0, dozens of options)
- Takes more than a week? 9/10 (OAuth, password reset, session management, security is complex)
Score: Buy it. You'd spend weeks building something that Clerk gives you in 30 minutes.
Counterexample: Your AI-powered keyword research algorithm
- Core to your value? 10/10 (this IS your product)
- Battle-tested solution exists? 3/10 (generic SEO tools exist but not your specific approach)
- Takes more than a week? 8/10 (yes, it's complex)
Score: Build it. This is your unfair advantage.
12. The Complexity Budget
Decides: Whether this solution is too complicated for the problem
When to use: Choosing between simple and sophisticated solutions
Every abstraction, pattern, library, and framework you add is debt. You maintain it forever, debug it, explain it to AI, and work around its limitations. You have a limited complexity budget so you must spend it wisely.
Example: You need to store user preferences (theme, language, timezone).
Complex solution: Set up Redis for caching, create a separate microservice for preferences, implement pub/sub for real-time updates across sessions, add GraphQL subscriptions.
Simple solution: Add three columns to your users table. Read them on login. Update them on save.
The complex solution might be "better" architecturally. But is it worth the complexity for a feature that reads three values on login? That's the budget question.
Key questions: What's the simplest solution that works? What complexity am I adding and why? Will I still understand this code in six months? Am I solving today's problem or a hypothetical future problem?
13. The Data Architecture Question
Decides: How to structure your database and relationships
When to use: Planning database schema for a new feature
Design your database for the queries you'll run most often, not for theoretical elegance.
Example: Building a blog platform. Each post has an author, tags, and comments.
Read patterns you'll have:
- Show all posts (with author name and tag names) → Happens constantly
- Show one post with all comments → Happens constantly
- Show all posts by one author → Occasional
- Show all posts with a specific tag → Occasional
This tells you: Denormalize author name and tag names onto posts table for fast listing. It's okay to repeat data if it makes your common queries fast. The "perfectly normalized" approach requires joins on every page load.
Key questions: What data will I fetch on every page load? What queries will users run most often? Is it okay to duplicate some data for speed? Can I add an index to make this fast?
14. The Good Enough Threshold
Decides: When to ship vs. keep refining
When to use: Before every deployment when you're tempted to add "just one more thing"
Perfectionism kills momentum. Ship when it solves the core problem, even if it's not polished because you can always iterate.
Example: You built a contact form. Current state:
- ✅ Users can enter name, email, message
- ✅ Validation works
- ✅ Submissions save to database
- ✅ You get notified
- ❌ No auto-reply confirmation email
- ❌ No fancy animations
- ❌ No file attachments
- ❌ No CAPTCHA
Key questions: Does the "happy path" work reliably from start to finish? Is this missing feature a functional blocker, or just embarrassing to my ego? Will the user fail to achieve their primary goal without this? Can I manually handle the edge cases for the first 10 users?
15. The Third-Party Risk Assessment
Decides: Whether to depend on an external service
When to use: Integrating any API, library, or platform
Every external dependency creates a blast radius where their failure, pricing changes, or disappearance becomes your emergency.
Risk tiers:
Acceptable risk: Stripe for payments. If Stripe fails, payments fail, but that's true for everyone. Stripe is battle-tested and reliable. The alternative is building your own payment processor, which is insane.
Moderate risk: Segment for analytics. If it fails, you lose tracking data, but your app still works. The alternative is sending events directly to multiple analytics tools, which is annoying but manageable.
Dangerous risk: Your entire app depends on one founder's side project API that could shut down tomorrow. If it fails, your app fails. No fallback exists. This is unacceptable risk.
Key questions: What breaks if this service fails? How likely is failure? How hard is it to switch to an alternative? Is this service core infrastructure or a nice-to-have feature?
AI-Assisted Building Models
Decide when the AI is right and when it is wrong
16. The AI Review Checklist
Decides: Whether AI-generated code is production-ready
When to use: After AI generates any code before you commit it
AI models default to the "happy path," writing code for a perfect world where inputs are valid, APIs never fail, and bad actors don't exist.
AI has five predictable blind spots. Check these every time:
✅ Validation: Does it validate user input on both frontend and backend?
✅ Error handling: What happens when API calls fail, files are missing, or data is malformed?
✅ Edge cases: What if the user uploads a 500MB file? Enters emoji? Submits the form twice?
✅ Security: Does it sanitize inputs? Check permissions? Prevent injection attacks?
✅ Performance: Will this work with 1,000 records? What about 100,000?
Example: AI generates a file upload function.
What AI probably included: Basic upload logic, saving to storage, returning success.
What AI probably missed:
- File size limits (user uploads 2GB video, server crashes)
- File type validation (user uploads .exe file, security risk)
- Error handling if storage is full
- What happens if upload is interrupted
- Duplicate filename handling
Run through the checklist. Add what's missing.
17. The Feature Architecture Sketch
Decides: How to structure a feature before prompting AI
When to use: Before building any non-trivial feature
Five-minute sketch saves hours of AI going in circles. Map the data flow: User action → Frontend → Backend → Database → Response
Example: Building a "save for later" feature for articles.
Quick architecture sketch:
1. User clicks "Save" button on article
2. Frontend: Disable button, show spinner
3. Frontend: Send POST to /api/saves with article_id
4. Backend: Check if user is authenticated
5. Backend: Check if article exists
6. Backend: Check if already saved (prevent duplicates)
7. Backend: Insert into saves table with user_id + article_id + timestamp
8. Backend: Return success with saved article data
9. Frontend: Update UI to show "Saved" state, enable button
10. Handle errors: Not authenticated, article not found, database error
Now when you prompt AI, you give it this sketch. AI knows exactly what to build. Without the sketch, AI makes assumptions and you spend an hour iterating.
Key questions: What triggers this feature? What data moves where? What can go wrong at each step? What does success look like? What does failure look like?
18. The Context Window Strategy
Decides: What information to include in your AI prompts
When to use: Starting any new feature or debugging complex issues
Strategic context makes AI 10x more useful. Random context makes it confused.
What to include:
- Database schema (relevant tables only)
- Existing code patterns from your project
- Error messages (full stack trace)
- Specific requirements and edge cases
What to skip:
- Implementation history ("I tried X then Y")
- Vague goals ("make it better")
- Unrelated code
- Your entire codebase
Example of a good prompt:
I need to add email validation to my signup form.
Current schema:
users table: id, email, password_hash, created_at
Current pattern (from login.ts):
We use Zod for validation
We return errors as {field: string, message: string}
We validate on both frontend and backend
Requirements:
Check for valid email format
Check if email already exists (return friendly error)
Case-insensitive email check
Trim whitespace before validating
Generate the validation function for backend.
This prompt includes schema, existing patterns, and specific requirements so AI can generate exactly what you need.
19. The Iteration Pattern
Decides: How to improve AI output without starting over
When to use: When AI code almost works but has issues
Iterate surgically. Point to the specific problem and requested change.
The pattern: (1) Identify the specific line or section, (2) Explain what's wrong, (3) State exactly what you want instead.
Bad iteration: "This doesn't work. Make it better."
Good iteration: "The form submits successfully but doesn't show a success message. Add a toast notification after line 47 that says 'Settings saved' and clears after 3 seconds."
Bad iteration: "Add error handling."
Good iteration: "Add a try-catch around the API call on line 23. If it fails, set error state to 'Unable to load data. Please try again.' and show it in a red alert box."
20. The AI Blind Spot Map
Decides: What categories of problems to always check manually
When to use: Any AI-generated feature touching real users
AI writes code for a single user in a perfect vacuum, consistently missing the "invisible" systemic chaos.
AI has predictable blind spots across five categories:
1. Race conditions: Two users click at the same time—does data get corrupted?
2. Proper validation: Frontend validation exists, but does backend validate too?
3. Edge case handling: Empty arrays, null values, missing data
4. Security: Authentication checks, permission verification, input sanitization
5. Async logic: Promises, error handling in async operations, loading states
Build a habit of checking this manually as from experience I can tell you that AI misses these categories almost every time…
Example: AI builds a "delete account" feature. Check the blind spots:
- Race condition: Can user trigger delete twice? Add request debouncing
- Validation: Does it check if user is deleting their own account? Add permission check
- Edge cases: What if user has active subscriptions? Add validation before delete
- Security: Does it require password confirmation? Add confirmation step
- Async: Does it handle database errors? Add error handling and rollback
Without this checklist, you ship code with security holes and broken edge cases.
Product Growth Models
Decide how to expand your product offering and what to charge for it
21. The Pricing Validation Test
Decides: Whether your pricing makes sense to buyers
When to use: Setting initial pricing or considering changes
Show your pricing tiers to 10 target users. If they can't choose a tier in 30 seconds, your pricing is broken.
The test reveals:
- Can users self-identify which tier fits them?
- Do they understand the value difference between tiers?
- Are tier names clear (not cute)?
- Do limits make sense?
Example of bad pricing:
- Starter: $19/mo - "For individuals"
- Growth: $49/mo - "For growing teams"
- Pro: $99/mo - "For professionals"
User confusion: "I'm an individual but also professional. I'm not growing but I have a team of 2. Which tier?"
Example of good pricing:
- Solo: $19/mo - Up to 5 projects, 1 user
- Team: $49/mo - Up to 25 projects, up to 5 users
- Business: $99/mo - Unlimited projects, unlimited users
User clarity: "I have 3 projects and work alone. Solo plan." Decision made in 10 seconds.
Key questions: Can users identify their tier based on concrete limits? Do tier names describe who it's for or how much they can do? Would you be able to choose if you were seeing this for the first time?
22. The Impact vs. Effort Matrix
Decides: Which features to build next
When to use: Feature prioritization and roadmap planning
True velocity is about aggressively filtering out "Low Impact, High Effort" traps that feel productive to build but deliver nothing to the user.
Plot every potential feature on two axes: User impact (low to high) and Development effort (low to high).
Four quadrants:
- High impact, low effort: Build these first (quick wins)
- High impact, high effort: Build these next (major features)
- Low impact, low effort: Build if you have spare time (nice-to-haves)
- Low impact, high effort: Never build these (time sinks)
Features under consideration example:
High impact, low effort:
- Add password reset link to login page (1 hour, prevents 20% of support tickets)
High impact, high effort:
- Build API for integrations (2 weeks, enables enterprise customers)
Low impact, low effort:
- Add dark mode (3 hours, some users will appreciate it)
Low impact, high effort:
- Build custom analytics dashboard (3 weeks, competitors exist, users won't switch for this)
Build in this order: password reset → API → dark mode when slow → skip custom analytics.
Key questions: Is this feature actually valuable or just fun to build? Can we get 80% of the impact with 20% of the effort? If we don't build this, will users actually leave?
23. The Five-User Interview Pattern
Decides: What users actually need vs. what they say they want
When to use: Planning new features or understanding why adoption is slow
Just five conversations focused on past behavior can reveal more actionable data than 1,000 surveys asking about future wishes.
The pattern:
- How do you currently solve [problem]? (Reveals workarounds)
- Walk me through the last time you did [task]. (Actual behavior)
- What's frustrating about how you do it now? (Real pain points)
- What have you tried to fix this? (Shows urgency)
- If we solved this, what would you do differently? (Validates impact)
What you're listening for: Patterns across multiple users. If 4 out of 5 mention the same workaround, that's your feature opportunity.
Example: You're building a content calendar tool. User interviews reveal:
- 5/5 users currently use Google Sheets
- 4/5 users manually check LinkedIn/Twitter to see what competitors posted
- 5/5 users forget to repurpose content across platforms
- 2/5 users want AI writing assistance (not a pattern yet)
Result: Build competitive content tracking and cross-platform reminders. Leave AI writing for later because there isn't enough demand signal.
Key questions: Did they complain about a problem, or did they prove they are trying to solve it? Am I listening to the loudest user or the recurring pattern? Did I ask "would you use this" (bad) or "how do you do this now" (good)?
24. The One Metric Focus
Decides: What success metric this feature moves
When to use: Before building any feature intended to improve the product
Shipping code without a defined success metric is just recreational engineering.
Every feature needs one primary metric that defines success.
Shift from "Building" to "Solving":
- Bad planning: "We're building a referral program because it would be cool."
- Good planning: "We're building a referral program to increase new user signups by 20%. Success = 1 in 5 users refers someone."
More examples:
- "Add onboarding tutorial" → Metric: Increase activation rate (users who complete first task) from 40% to 60%
- "Build API documentation" → Metric: Reduce API-related support tickets by 50%
- "Add social proof to landing page" → Metric: Increase conversion rate from 2% to 3%
Key questions: What specific metric will move if this works? How will we measure it? Do we have a baseline for that number right now? If the metric doesn't move, will we kill the feature or iterate on it?
25. The Pivot vs. Persist Framework
Decides: When to change direction vs. keep iterating
When to use: When growth stalls or user feedback is consistently negative
Abandoning a good idea because of bad execution is a tragedy, but polishing a product nobody wants it’s the fastest way to bankruptcy.
Pivot when:
- ❌ Users consistently say "I don't have this problem" (Problem validation failed).
- ❌ Free users like it but nobody will pay (Value proposition broken).
- ❌ Churn is high because the product doesn't solve a core need.
- ❌ You repeatedly hear "I'd use this if it did X instead" (Wrong solution).
Persist when:
- ✅ Users confirm the problem is real and painful.
- ✅ Some users are willing to pay but pricing/packaging needs work.
- ✅ Churn happens because of execution issues (bugs, missing features).
- ✅ You hear "I love this but wish it had Y feature" (Right direction, needs iteration).
Example: You built a project management tool for freelancers.
- Pivot Signal: After 6 months, users say, "I don't actually need project management—I just work on one project at a time. I need invoicing." → Problem validation failure. Pivot to invoicing.
- Persist Signal: Users say, "I love this but it's missing recurring tasks and a mobile app." → Execution issue. Persist and build the missing features.
Key questions: Are users complaining about bugs (fix it) or the concept (kill it)? Do they wish it worked better, or do they wish it was something else entirely? Is the refusal to pay about the price or the value?
26. The Feature Kill Switch
Decides: When to remove features that aren't working
When to use: Regular product audits and when considering feature expansion
Every unused feature is a permanent tax on your codebase that slows down every future deployment.
"Zombie" Feature Tax:
- Maintenance Burden: You still have to debug, explain, and test code that nobody uses.
- Interface Clutter: More buttons mean more confusion for new users trying to find the core value.
- False Confidence: Usage metrics look healthy overall, but the engagement is diluted across 20 mediocre features instead of 3 great ones.
Kill Switch Process:
- Identify: Flag features used by < 5% of users in the past 30 days.
- Investigate: Is it broken, hidden, or just useless?
- Announce: Give users 30 days notice to save their data.
- Delete: Remove the code entirely.
- Listen: If nobody complains, you just made your product better.
Example: Monthly Feature Audit
- Core workflow: 100% usage
- Export to CSV: 65% usage
- Custom templates: 45% usage
- Bulk actions: 25% usage
- Custom emoji reactions: 3% usage → Kill this
- Calendar view: 2% usage → Kill this
Key questions: Does this feature pay rent? If we deleted this tomorrow, would our support inbox actually notice? Are we keeping this because it adds value, or just because we already wrote the code?
This is a lot. You don't need to memorize all 26 models right now.
Think of this as your 2026 reference guide. Bookmark it and come back when you're facing a specific decision, like: should I build this feature, how do I price this, is this AI code production-ready, which feature matters most?
The mental models you use most often will become instinctive.
The Gold Nugget 💡
Here's how to actually use these mental models: use the 5-Minute Product Think framework.
Before you prompt AI or write any code, spend five minutes asking which mental models apply. Write out 3-5 questions based on those models. Use the answers to guide what you build.
Copy-paste ready template:
text
Before I build [FEATURE]:
1. Product Validation: Is this a hair-on-fire problem or nice-to-have?
2. User Experience: What does the empty state show and what action should users take?
3. Technical Decision: Is this core to my value or should I use a third-party service?
4. What could go wrong: What edge cases will break this in production?
5. Success looks like: What metric moves if this feature works?
Adapt the questions based on which models fit your situation.
Building a new feature? Use product validation and UX models.
Reviewing AI code? Use the AI review checklist and good enough threshold.
Choosing your tech stack? Use build vs. buy and complexity budget.
This framework works because it forces product thinking before code thinking. It catches misaligned expectations when changes cost nothing and gives AI better context for what you actually need.
Let me show you this in action with a real scenario:
You're thinking of adding social sharing to your app. Five-minute product think:
- Hair-on-fire problem (Model #3): Are users actively asking to share? Check support tickets and interviews. Result: Nobody mentioned sharing in the last 50 conversations. Not urgent.
- Jobs-to-be-done (Model #6): What job would sharing solve? Maybe: "Get my teammates to sign up." But is that really how B2B tools spread? Result: Direct invites probably work better than social sharing.
- Build vs. buy (Model #11): If we build this, use a library or write custom? Result: Social sharing libraries exist, but...
- Impact vs. effort (Model #22): High or low impact? Low (nobody's asking). High or low effort? Medium (2-3 days with testing). Result: Low impact, medium effort = don't build.
- One metric (Model #24): What metric would this move? Signups? But we get 90% of signups from SEO and direct outreach, not social sharing. Result: Won't move our key metrics.
Decision after 5 minutes: Skip social sharing. Build the team invitation feature instead (users actually asked for this).
See how the models work together? You prevented wasting 3 days building something nobody needs.
When to skip this: Quick experiments, throwaway prototypes, learning exercises, anything that won't touch real users.
When it's essential: Features that real users will interact with, technical decisions that affect your architecture o product changes that impact revenue.
The five minutes you spend thinking through mental models saves hours of building the wrong thing. And hours of debugging the right thing built wrong.
Let's Connect
Which of these 26 mental models do you wish you'd known about six months ago?
Or what product decision are you facing right now that could use a mental model? Reply and tell me. I read every response and often turn common questions into future articles.
Build With Better Judgment
Bookmark this page. Use it all year. Come back when you're facing a decision and not sure how to think it through.
You'll still build fast with AI but now you'll just build the right things.
Mental models are how experienced builders think. Now they're how you think too.
This post was originally published as the 26 Mental Models to Build Better Products in 2026 in my VSL Substack publication.
Top comments (0)