Lesson 1: Project Scope, Audience, and Success Metric

You can save weeks of rework by deciding three things now: what you are building, who it is for, and how you will measure whether it works.

Lesson Objective

Create a one-page project brief that defines:

Scope boundaries
Target audience
Success metrics for production and launch

Why This Matters

Most failed indie projects do not fail because of coding skill. They fail because scope expands faster than execution. This lesson sets your guardrails before production starts.

Step-by-Step

Step 1: Define Your Core Promise

Write one sentence in this format:

This game helps <player type> experience <core fantasy> in <session length>.

Example: This game helps cozy-strategy players build and defend a tiny floating village in 10-15 minute sessions.

Step 2: Set Scope Boundaries

Create two short lists:

In scope for v1
- One core loop
- One playable level set
- One progression system
Out of scope for v1
- Online multiplayer
- Full mod support
- Multiple game modes

This gives you permission to say no without second-guessing later.

Step 3: Identify Primary Audience

Document:

Skill level (beginner, mid-core, hardcore)
Preferred platform (PC, mobile, console)
Expected session length
Similar games they already enjoy

Use this to guide mechanics, controls, and tutorial depth.

Step 4: Define Three Success Metrics

Pick measurable metrics you can verify:

Production metric: playable vertical slice by date
Quality metric: average bug severity under a target threshold
Launch metric: wishlist, retention, or conversion target

Example targets:

Vertical slice complete by week 4
No critical blocker bugs at release candidate
500 wishlists pre-launch

Step 5: Create the One-Page Brief

Your brief should include:

Core promise
Scope in/out
Audience profile
Success metrics
Top 3 project risks

Save it in your project docs folder and link it in your task board.

Mini Challenge

Publish your one-page brief to your project repository and ask one teammate or friend to review:

What seems too big?
What is unclear?
Which metric feels unrealistic?

Refine the brief using their feedback before Lesson 2.

Pro Tips

Keep v1 smaller than your instinct says.
If a feature does not support the core promise, defer it.
Metrics should be binary enough to avoid debate.

Common Mistakes

Defining audience as "everyone"
Confusing feature count with player value
Using vague goals like "make it fun" without measurable checks

Troubleshooting

"I cannot decide the scope."

Start with one loop and one level. If you can finish that well, you can expand later.

"I have no launch data yet."

Set proxy metrics first (wishlist target, playtest retention, crash-free sessions), then refine after playtests.

"My team keeps adding features."

Treat the scope brief as a contract. New ideas go into a post-launch backlog.

Recap

In this lesson you defined the project brief that controls scope, aligns decisions, and keeps progress measurable.

Next Lesson Teaser

Next, you will set up Unity project structure, repository conventions, and task board workflow so the team can ship consistently.