Why Building Games and Building Apps Require Opposite Instincts

The Question Nobody Asks

If you've spent time in both game studios and SaaS companies, you've probably noticed something odd: the same product management advice that works brilliantly in one environment fails spectacularly in the other.

"Talk to your users." "Find the pain point." "Validate before you build." This is gospel in SaaS. And it should be — these principles have helped build some of the most successful software companies in history. But walk into a game studio and try to run product discovery the same way, and you'll get blank stares. Not because game developers are less rigorous, but because the fundamental nature of what they're building is different.

Apps and web services are demand-driven. They exist because users have a problem, and the product solves it. Games are supply-driven. They exist because a creator imagined an experience, built it, and put it in front of people to see if it resonates.

This isn't just a philosophical distinction. It changes everything — how you discover what to build, how you measure success, how you iterate, and how you decide when something is done.

graph LR
    subgraph "Demand-Driven (Apps/SaaS)"
        A["User Has Problem"] --> B["Research & Validate"]
        B --> C["Build Solution"]
        C --> D["Measure Adoption"]
        D -->|"Feedback Loop"| B
    end
    subgraph "Supply-Driven (Games)"
        E["Creator Has Vision"] --> F["Prototype & Playtest"]
        F --> G["Ship Experience"]
        G --> H["Market Reacts"]
        H -->|"Creative Iteration"| F
    end

Demand-Driven: Building What People Need

The modern SaaS playbook is essentially a formalized answer to one question: What problem does the user have, and how can we solve it better than the alternatives?

The process is well-documented. You start with user research. You identify pain points. You validate that the pain is real and frequent enough to justify a product. You build a minimum viable product, measure adoption, iterate based on feedback, and optimize for retention. The entire pipeline — from problem-solution fit through product-market fit to growth — is driven by observable demand.

This works because utilitarian products serve functional goals. A project management tool saves time. An accounting app prevents errors. A communication platform reduces friction. Users can articulate what they need because they experience the absence of the solution as a concrete problem. "I waste two hours a week on status updates" is a pain point you can build against.

The metrics follow naturally. NPS measures satisfaction. Annual churn hovers around 3-5% for healthy B2B SaaS, with net revenue retention above 110% for top performers. Activation rate measures whether new users find the value. Customer health scores predict renewals. Everything operates on monthly or annual cycles, and every metric traces back to: is this product solving the problem it promised to solve?

Product-led growth (PLG) is the logical endpoint of demand-driven thinking. If the product genuinely solves a problem, users will adopt it, invite colleagues, and expand usage — all without a sales team pushing them. The product itself is the growth engine because the demand already exists.

Supply-Driven: Building What People Didn't Know They Wanted

Games don't work this way. Nobody wakes up thinking "I have a problem that can only be solved by a platformer where an Italian plumber jumps on mushrooms." There is no pre-existing demand for Super Mario Bros. The demand was created by the experience itself.

Sid Meier famously defined games as "a series of interesting decisions." Not a series of solved problems. Not a series of validated pain points. Decisions — meaning moments of agency, tension, and consequence that produce an emotional response. The product discovery process for games isn't "find the problem" — it's "find the fun." Studios prototype rapidly, playtest obsessively, and iterate until the core mechanic feels right. This is fundamentally divergent thinking (exploring creative space) rather than convergent thinking (narrowing to a solution).

Shigeru Miyamoto, Nintendo's legendary designer, has been transparent about his process: he tries to make games that he himself would want to play, trusting that if he finds it fun, others will too. His design canvas isn't the screen — it's the player's interactive experience, the feeling of picking up a controller and exploring something that feels right. As he once put it: "Game designers have to have a creative mind and also be able to stand up against the marketing people — otherwise they cannot be creative." This is not demand discovery. This is creative vision, tested against reality.

Steve Jobs articulated the same philosophy from the other side of the tech industry: "A lot of times, people don't know what they want until you show it to them." He wasn't dismissing market research — he was pointing out that for certain categories of products, the traditional demand-driven approach has a ceiling. You can't survey your way to the iPhone because customers will describe a better BlackBerry, not a touchscreen computer in their pocket.

The game industry's version of this insight is even more stark. In games user research, the researcher's job isn't to ask players what they want — it's to observe whether players' emotional responses match the designer's intent. If the horror game isn't making playtesters feel scared, that's a design problem. But the decision to make a horror game in the first place? That came from creative vision, not user demand.

Nintendo's Blue Ocean Strategy with the Wii is the canonical example. Rather than competing with Sony and Microsoft on processing power — the demand that existing gamers articulated — Nintendo asked a different question entirely: What if we made a console for people who don't play games? No amount of user research with existing gamers would have surfaced this direction. The Wii created demand by offering an experience that didn't exist yet: motion-controlled gaming that grandparents and children could enjoy together.

And the metrics reflect this entirely different world. Where SaaS measures on monthly and annual cycles, games measure on daily ones. Day-1 retention averages 26-28%. By Day 7 it drops to around 8%. By Day 30, you're often below 3%. Revenue is tracked as ARPDAU (average revenue per daily active user), not MRR. The time horizons, revenue models, and success signals are structurally incompatible with SaaS frameworks — not because one is better, but because the underlying relationship between product and user is fundamentally different.

Where the Frameworks Break

The problem isn't that demand-driven or supply-driven approaches are wrong. The problem is applying the wrong one to the wrong product.

When SaaS Thinking Invades Game Development

When game studios over-index on data-driven methodologies borrowed from SaaS, the results are predictable: homogenization. Every mobile game gets a battle pass. Every live-service game gets daily quests optimized for retention. Every design decision runs through an A/B test. The games become technically optimized but creatively hollow.

As one industry analysis put it, the proliferation of battle passes, daily quests, and relentless player retention mechanics stems from data-driven obsession — engaging in the short term but producing a homogenized gaming landscape. The metrics improve while the soul disappears.

This is what happens when you treat a supply-driven product as demand-driven. You optimize for measurable engagement at the cost of the unmeasurable thing that made people care in the first place. Artistic direction, tone, narrative themes, and core creative vision aren't captured by analytics. Data can tell you that players drop off at level 3, but it can't tell you whether your game should be funny or serious, stylized or realistic, accessible or hardcore.

The contrast is clearest in how ongoing operations work.

graph TD
    subgraph "SaaS Product Manager"
        A1["User Feedback"] --> A2["Prioritize Problems"]
        A2 --> A3["Ship Features / Fixes"]
        A3 --> A4["Measure Impact"]
        A4 -->|"Converge"| A1
    end
    subgraph "Game LiveOps Manager"
        B1["Creative Vision"] --> B2["Design Events / Seasons"]
        B2 --> B3["Ship Content / Experiences"]
        B3 --> B4["Observe Player Response"]
        B4 -->|"Diverge"| B1
    end

A SaaS product manager asks "What problem should we solve next?" and ships functional updates — features, integrations, bug fixes. A game LiveOps manager asks "What experience should we create next?" and ships experiential updates — events, seasons, content drops, battle passes. Same cadence, opposite orientation. The SaaS PM converges on user needs. The LiveOps manager diverges into creative possibilities.

The recommended industry approach is to be data-informed, not data-driven — using analytics to validate ideas and identify problems while maintaining creative vision. But that distinction only makes sense if you accept the premise that the creative vision comes first and data serves it, rather than the other way around.

When Game Thinking Invades SaaS

The inverse failure is rarer but equally destructive. A SaaS founder with a "visionary" product idea who refuses to validate it against real user needs is the stereotype of the failed startup. "Build it and they will come" is a viable strategy for entertainment products where the experience itself creates demand. For a B2B workflow tool, it's a recipe for burning $2 million on something nobody asked for.

The statistics are brutal: a significant portion of SaaS products fail not because of poor execution but because they're built without truly understanding the user's problem. Founders fall in love with their idea instead of the customer's problem. In a demand-driven context, this is fatal. The demand has to exist first.

The Spectrum: It's Not Binary

Of course, real products don't always fall neatly into one category.

Social media sits in the middle. Facebook started demand-driven (college students wanted a directory). But engagement and growth were driven by supply-driven mechanics — the News Feed, algorithmic discovery, features nobody asked for but couldn't stop using. TikTok is almost purely supply-driven: nobody asked for short-form vertical video, but the experience was so compelling that it created its own demand.

Creative tools lean demand-driven (designers need to design) but their best features are often supply-driven. Nobody asked Adobe for generative fill. Figma's multiplayer cursor wasn't solving an articulated problem. These features created new workflows that users didn't know they wanted.

Gamified apps like Duolingo deliberately blend both approaches. The core product is demand-driven (people want to learn languages). But retention and engagement are driven by supply-driven game mechanics — streaks, leaderboards, character narratives — that are designed, not demanded.

graph LR
    A["🔧 Pure Utility"] --- B["Accounting\nSaaS"]
    B --- C["Figma\nNotion"]
    C --- D["Duolingo\nTikTok"]
    D --- E["Mobile\nF2P Games"]
    E --- F["🎮 Pure Entertainment"]

    style A fill:#3b82f6,color:#fff
    style B fill:#60a5fa,color:#fff
    style C fill:#a78bfa,color:#fff
    style D fill:#c084fc,color:#fff
    style E fill:#f472b6,color:#fff
    style F fill:#ef4444,color:#fff

The key insight is knowing where your product sits on this spectrum and adjusting your approach accordingly.

Practical Implications for Builders

If you're building products, here's what this distinction means in practice:

For Demand-Driven Products (Apps, SaaS, Tools)

• Start with the problem, not the solution. User research isn't optional — it's the foundation.
• Validate before building. If users can't articulate the pain, the demand might not exist.
• Measure what matters. NPS, churn, activation, and retention map directly to problem-solution fit.
• Iterate based on feedback. Users know what's wrong because they experience the problem daily.
• Be suspicious of creative vision. Your clever idea matters less than whether it solves a real problem better than alternatives.

For Supply-Driven Products (Games, Entertainment, Creative Experiences)

• Start with the experience, not the market. What feeling or moment are you trying to create?
• Prototype the core experience early. Fun-finding — the process of iterating until the core mechanic feels right — is your equivalent of problem-solution fit.
• Use data to refine, not to decide. Analytics should tell you if players are having the experience you intended, not what experience to create.
• Protect creative vision. The thing that makes your product special is probably the thing that can't be measured.
• Accept higher variance. Supply-driven products have bigger hits and bigger misses. That's the nature of creative risk.

For Products in Between

• Know which parts are demand-driven and which are supply-driven. A SaaS product's core value proposition should be demand-validated. Its engagement mechanics can be designed creatively.
• Don't let one approach colonize the other. Your gamification layer shouldn't override core utility. Your user research shouldn't kill creative features.

Why This Matters Now

This distinction is becoming more important, not less. As AI tools lower the cost of building both apps and games, the barrier to entry drops across the board. When anyone can ship a product quickly, the question of what to build becomes more important than how to build it.

For utilitarian products, AI-assisted development means faster validation cycles. You can prototype and test against real user needs in days instead of months. The demand-driven playbook gets faster, not different.

For creative products, AI changes the economics of content production but not the fundamental challenge: someone still has to have the creative vision. AI can help execute, but it can't tell you what experience is worth creating. If anything, the flood of AI-generated content makes strong creative direction more valuable, not less.

The builders who understand which game they're playing — demand-driven or supply-driven — will build better products. The ones who blindly apply the wrong playbook will keep wondering why the "best practices" aren't working.

The Uncomfortable Truth

Here's what nobody in product management wants to admit: there is no universal framework for building great products. The demand-driven playbook and the supply-driven playbook aren't just different strategies — they reflect fundamentally different relationships between creators and users.

In demand-driven products, the user is the authority. They have the problem. You find the solution. Humility before user needs is the cardinal virtue.

In supply-driven products, the creator is the authority. They have the vision. The user discovers whether it resonates. Creative conviction is the cardinal virtue.

Trying to be humble and visionary at the same time isn't enlightened — it's confused. Know which one your product requires, and commit to it. The worst products are the ones that can't decide.