Validate a SaaS idea with a 20-minute card sort

The standard playbook for validating a SaaS idea: schedule 15 customer interviews, spend 3 weeks conducting them, then synthesize themes in a spreadsheet. By the time you have conviction, you've lost a month.

There's nothing wrong with interviews. But they answer "do people have this problem?" Card sorting answers a different question that interviews can't: "does my product structure make sense to the people who'd use it?"

If users can't naturally organize your features into groups that match your navigation, you have an information architecture problem. And IA problems kill SaaS products quietly — through low feature adoption, high support load, and churn that nobody attributes to "couldn't find what I needed."

You can surface this problem in 20 minutes for $0–$35. Here's how.

What a card sort tells you about your SaaS idea

A card sort doesn't validate demand. It validates comprehension. Specifically:

1. Do users understand your feature categories? If they can't group "automated workflows" and "trigger rules" together, your "Automation" section will confuse them.

2. Is your product scope coherent? If participants create wildly different category structures, your product might be trying to do too many things — a clear "feature bloat" signal.

3. Where should things live? Before you build a sidebar with 8 sections, find out whether users expect 3 sections or 12.

4. What language do users use? You call it "Pipelines." They might call it "Stages" or "Workflows" or "Process." Naming matters for SaaS — it's the interface between user intent and feature discovery.

The SaaS card sort framework

Here's a framework specifically designed for founders validating a SaaS product structure:

Phase 1: Extract your feature list (10 minutes)

Go through your product spec, Figma mockups, or pitch deck and extract every distinct feature or page:

Rules for SaaS feature cards:

• Write them as nouns or noun phrases: "Email Templates," not "Create and manage email templates"
• Include settings/admin features — they reveal where users expect configuration to live
• Include empty-state features you plan to build later — if users can't categorize them now, they'll be hard to discover later
• Don't include implementation details: "Webhooks" only if your users are developers, otherwise "Notifications" or "Integrations"

Example: A B2B invoicing SaaS

• Create Invoice
• Client List
• Payment Tracking
• Recurring Invoices
• Tax Settings
• Invoice Templates
• Payment Reminders
• Financial Reports
• Expense Tracking
• Team Members
• Integrations
• Billing & Plans
• Brand Settings
• Export Data
• Client Portal

15 cards. Each is a distinct feature or section.

Phase 2: Choose your sort type

For SaaS validation, you have two good options:

Open sort (recommended for early-stage ideas)

• Participants create their own categories
• Reveals how users mentally model your product
• Shows you the natural grouping structure
• Best when you haven't committed to a navigation yet

Closed sort (recommended for redesigns or tier restructuring)

• You define the categories (e.g., your planned sidebar sections)
• Participants place features into your categories
• Reveals where your structure breaks
• Best when you're validating an existing design

For a new SaaS idea, run an open sort first. You'll learn more.

Phase 3: Set up and recruit (10 minutes)

1. Create the study on ValidateThat (free)
2. Add your cards
3. Write a short welcome message: "I'm building [type of product]. Help me organize its features into groups that make sense to you."
4. Share with 10–15 people from your target market

Critical: Don't recruit other founders or product people. Recruit your actual target users. If you're building invoicing software for freelancers, recruit freelancers — not SaaS founders who happen to invoice clients.

Phase 4: Interpret for product decisions

After 10 responses, you'll have data. Here's what SaaS-specific patterns mean:

Five signals card sorting reveals about your SaaS idea

Signal 1: Natural product boundaries

If most participants create 3–5 groups with clear themes, your product has coherent boundaries. If they create 7–10 overlapping groups, your product scope is too broad — users are struggling to see the organizing principle.

What to do: If groups exceed 5, consider whether you're building one product or two. The groups users create often map to natural product tiers or standalone tools.

Signal 2: The "core vs auxiliary" split

Participants will almost always create one large group (the "core" of your product) and several smaller groups (secondary features). The items in the large group are your product's atomic value proposition — the features that define what it is.

What to do: Your homepage, onboarding, and free tier should center on this core group. Everything else is a layer on top.

Signal 3: Feature orphans (validation failures)

Cards that participants can't consistently place — showing up in different groups across participants — are features that don't fit users' mental models. This is a validation signal.

Common causes:

• The feature concept isn't clear from the label
• The feature doesn't naturally belong in this product
• Users don't understand why they'd need it

What to do: Question whether orphan features should exist in v1. They're the features most likely to be built, shipped, and ignored.

Signal 4: Naming mismatches

When participants name their groups, compare their words to yours:

What to do: Use participants' language in your interface. If 8/10 people call it "Reports," don't call it "Analytics Dashboard."

Signal 5: The pricing tier structure

If you plan to gate features behind tiers (free/pro/enterprise), a card sort reveals whether your tier boundaries make sense to users. Features that users consistently group together should probably live in the same tier — splitting them across tiers creates frustration.

What to do: If users group "Email Templates" and "Brand Settings" together (because both are about customizing how things look), putting templates in Free and branding in Pro will feel arbitrary to users. Respect the mental model.

A real example: the project management SaaS

One founder ran a card sort for a project management tool with these cards:

• Task List, Kanban Board, Gantt Chart, Calendar View, Time Tracking, Team Chat, File Storage, Client Portal, Reports, Billing, Integrations, Templates, Automations, Permissions, Activity Feed

What participants revealed:

• "Tasks" was the universal core: Task List, Kanban, Gantt, and Calendar always grouped together. That's the product's home screen.
• Time Tracking split evenly between "Tasks" and "Billing" — it belongs in both places (or needs a top-level position).
• Client Portal was an orphan — half the participants didn't understand what it was. It needed a better name or shouldn't be in v1.
• "Automations" consistently grouped with "Integrations" — users see both as "connecting things."

Total time: 20 minutes setup, $35 on Prolific, results in 3 hours. That's one afternoon of work that prevented months of navigation confusion.

When card sorting isn't enough

Card sorting validates structure. It doesn't validate:

• Demand — whether people want your product at all (use surveys, landing page tests, or a done-for-you validation report)
• Usability — whether people can complete tasks in your interface (use tree testing after your card sort to verify)
• Pricing — whether people will pay (use pricing page tests or Van Westendorp surveys)
• Messaging — whether your value prop resonates (use A/B tested landing pages)

The smart play: card sort your features first, then validate demand for the product structure that emerges. You'll pitch a product that's both desirable and navigable — most competitors manage only one.

Get started

1. Create a free card sort →
2. List your SaaS features (12–20 cards)
3. Recruit 10–15 target users
4. Read the results in 24 hours

Or if you want the full validation — demand, comprehension, pricing signal, and a recommendation — get a done-for-you validation report with 30 participants for $99. I'll pick the right method for your specific idea.

Further reading: How to analyze card sort results • Card sorting before you build • Our benchmark data from 491 studies