What It Is

The Skateboard to Car Progression is a mental model for product development and problem-solving that prioritizes immediate utility over eventual perfection. In the "State Change" philosophy, we aren’t interested in building components in isolation; we are interested in moving the needle for the user as quickly as possible.

Think about the goal of building a car. If your development plan is to build a wheel, then an axle, then a chassis, and finally a car, you have failed the user until the very last stage. For weeks or months, the user has nothing but a pile of parts. They are still walking to work.

The Skateboard to Car model flips this. Instead of starting with a part of a car, you start with a skateboard. A skateboard is not a car, but it solves the same core problem: it gets you from point A to point B faster than walking. Once the user is rolling, you iterate. You add a handle to make it a scooter (steering). You add bigger wheels and pedals to make it a bicycle (efficiency). You add a motor and a frame to make it a car (scale and comfort). At every single stage, the user has a functional tool that provides value.

Why It Matters

The primary problem this model solves is the "Delivery Gap"—the period of time where money and effort are being spent, but no value is being realized. In a traditional "Big Bang" development cycle, the risk is at its highest right before launch. You might spend six months building a car, only to find out the user actually needed to cross a river, not a road.

Without this model, you fall into the trap of building "useless increments." A steering wheel is a masterpiece of engineering, but it’s a paperweight if it’s not attached to a drivetrain. When you build the "parts" of a car first, you are operating on assumptions for the entire duration of the build.

With the Skateboard to Car progression, you de-risk the project immediately. You prove the concept with the skateboard. If the user likes the speed but hates the balance, you learn that before you’ve spent $50,000 on a windshield. It turns development from a high-stakes gamble into a series of small, validated experiments. It creates a feedback loop that informs the next stage of the build, ensuring that the "car" you eventually deliver is actually the vehicle the user wants.

How It Works

The mechanism is built on the distinction between a component and a solution.

1. Identify the "Core Job": Before you build anything, you have to know the fundamental job the user is trying to do. In the analogy, the job isn't "to have a car"; the job is "to get to the destination faster."
2. Build the "Skateboard" (The Functional Minimum): Your first version must be "simple but useful." It shouldn’t have a radio, and it doesn't need a paint job. It just needs to roll. In software terms, this might be a single-page form that replaces a messy email chain. It’s not a full CRM, but it solves the immediate pain of lost data.
3. Validate and Iterate: Once the skateboard is in the user's hands, you watch. Do they use it? Where do they fall off? This informs the next version. You don't move to the "car" until you've mastered the "bicycle."
4. The Rule of Completeness: Every stage of the progression must be a "complete" experience. A cupcake is a "skateboard" version of a wedding cake. It has cake, frosting, and flavor. A bowl of flour is not a cupcake; it’s an ingredient. Never ship ingredients; ship cupcakes.

The progression follows a specific path: Utility -> Reliability -> Usability -> Efficiency -> Scale. You don't get to move to scale (the car) until you've proven utility (the skateboard).

When to Apply

This model is most valuable in high-uncertainty environments. If you are building a product that has never existed before, or if you are working with a new client whose needs are poorly defined, you must start with the skateboard.

It is also the go-to strategy for resource-constrained projects. If you don't have the budget or the time to build the "car" today, you have to ask: "What is the skateboard version of this feature?" This allows you to ship something that helps the user now, rather than promising them a "car" next year that might never get funded.

Specifically, use this when:

• You are building a custom internal tool (e.g., in a State Change/no-code context).
• You are testing a new business hypothesis.
• You are migrating from a manual process to an automated one.

Common Traps

The most frequent mistake is building "Non-Functional Increments." This is when a developer says, "I'm following the model," but they hand the user a wheel. A wheel is not a skateboard. If the user can't use it to achieve their goal, you aren't iterating; you're just doing traditional waterfall development in disguise.

Another trap is "The Eternal Skateboard." This happens when a team gets comfortable with the simple version and stops iterating. They deliver the skateboard, the user is "fine enough," and the project stalls. The model is a progression. If you need a car to cross the country, a skateboard isn't a success; it's just the start. You must have the discipline to keep moving toward the car.

Finally, there is the "Over-Engineered Skateboard." This is where you try to put a GPS on a skateboard. It makes the skateboard too heavy to carry and too expensive to build. The point of the skateboard is simplicity. If it's taking you three months to build your "simple" version, it's not a skateboard—it's a car without doors.

How It Connections

The Skateboard to Car progression is the tactical execution of the Minimum Viable Product (MVP) concept. While "MVP" is often used as a buzzword for "cheap version," this model provides the visual framework for what an MVP actually is: a functional, if primitive, tool.

It also connects deeply to the concept of Feedback Loops. By shipping the skateboard, you trigger a feedback loop earlier than any other methodology allows. This fits into the broader State Change principle of "Building in Public" or "Continuous Delivery," where the gap between an idea and a user’s interaction with that idea is kept to an absolute minimum.

Evidence from Sources

Starting Simple

"Follow the 'skateboard to car' progression - start simple but useful" — SC Mental Model Talk 1 6/2023

The Goal of Iteration

"This practice suggests starting with a simple, functional solution (the skateboard) and iteratively improving it until it becomes a more complete solution (the car)." — SC Mental Model Talk 1 6/2023

Early Value Delivery

"It emphasizes delivering value early and often, rather than waiting for a perfect final product." — SC Mental Model Talk 1 6/2023

Functional vs. Non-Functional

"...starting with a simple, functional solution..." [Note: The emphasis here is on 'functional'] — SC Mental Model Talk 1 6/2023

In Practice

Scenario 1: The Automated Reporting System

A client wants a complex dashboard that pulls data from five different APIs, performs AI-driven sentiment analysis, and sends automated PDF reports to the executive team.

• The "Car" Approach: Spend three months building the API integrations and the AI engine. The client sees nothing until month four.
• The "Skateboard" Approach: Week 1, create a manual Google Sheet where the client can paste their data, and a single script that formats it into a basic table. It’s "simple but useful." It saves them one hour of formatting work. Now they are "rolling." Week 3, you automate one API. Now it’s a "scooter." By month three, you have the "car," but the client has been getting value since week one.

Scenario 2: The Customer Portal

An organization needs a portal where customers can log in, view their history, change their billing, and chat with support.

• The "Skateboard": A simple, password-protected page with a list of historical invoices and a "Contact Us" button that links to their existing email. It provides "utility" immediately.
• The "Bicycle": Add the ability to update a credit card on file.
• The "Car": Integrate the full live-chat system and real-time shipping tracking.

Scenario 3: Internal Process Improvement

A team is struggling to manage project tasks in a chaotic Slack channel.

• The "Skateboard": A shared Trello board with three columns: To Do, Doing, Done. No automations, no fancy plugins. Just a "simple but useful" way to see who is doing what.
• The Progression: Once the team actually uses the board, you notice they struggle with dead-ends. You add a "Blocked" column (the Scooter). Then you add an automation that alerts the manager when a task stays in "Doing" for too long (the Bike). You don't build the automation until you know the "Blocked" column is actually where the friction lies.