Skateboards, Cars, and the Return of Code-First Discovery

There’s a certain type of meme, often called “how to create a minimal viable product”, that’s been making the rounds in the product web for years. I must have seen at least 5 original versions and they all disagree with each other. 

Not very originally, I felt that they all missed the mark and decided to create my own version with the help of OpenAI’s powerful image generator. 

Rows 1 and 2 show two common “wrong” versions. In row 3 I tried to illustrate product discovery: a series of validation steps — customer interviews, fake door test, early-adopter/alpha — to test the key assumptions in the idea before launching it in full. Naturally this is a massive oversimplification for a complex product like a car, but all these memes are not really about cars — they’re about software.

Content with my contribution to product meme culture I posted the illustration on my LinkedIn feed and mostly forgot about it. The post got a bunch of thumbs up and smiley faces, but there was also a subgroup of people who clearly were not amused (if LinkedIn had a dislike button I’m pretty sure they would violently press it). Some took the time to explain in the comments that I missed the point of the middle option completely.It turns out that the scooter-to-car version comes from Henrik Kniberg, a famous and respected voice in the Agile Dev sphere. You may know Kniberg for popularizing the so-called Spotify Model (if you have squads, tribes, or guilds in your company you have him to thank), but he also made other important contributions. Kniberg started the MVP meme chain with this sketch that quickly went viral and even appeared in some books.

At first glance the concept doesn’t make sense — why would you give a prospective car buyer a skateboard? The commenters pointed me towards this 2016 article in which Kniberg explains the illustration. The allegorical story is about helping a user satisfy a need: get from point A to point B. Instead of launching a car project, we ask the user to try out various commute alternatives, starting with the quickest and easiest — a scooter and a bus ticket — and progressing to more complex alternatives. Based on the user reaction we learn what works and iterate towards a solution that truly satisfies the user. In the article (which is well worth reading) Kniberg gives a few examples of the concept taken from Spotify, Minecraft, the Swedish Police, and Lego. 

There’s much to like about Kniberg’s approach: it’s customer-focused, iterative, and encourages learning rather than just delivery. Now that I understand it better, I regret the dismissive title “another wrong way to develop a viable product”. 

And yet, I still have to tick off the agile aficionados who disliked my meme, and leave Kniberg’s option as “not recommended”. I consider it a rather outdated interpretation of product discovery — I explain why below. 

But there’s more to this than the Agile Dev vs. Design Thinking vs. Lean Startup culture wars of the past decade. The Agile approach to product discovery is suddenly making a comeback, so it’s worth talking about where it comes short. 

Product Discovery > Testing with Code

So what’s wrong with the agile interpretation of product discovery? It’s all based on producing working code, what Kniberg calls “releases”, to be tested with users.

This is very much in line with the principles of the Agile manifesto:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Working software is the primary measure of progress.

The manifesto was written in 2001 based on work done in the 1990s. Back then user research was not yet widely practiced, usage data were rarely collected, and product discovery, lean startup, or growth hacking were not invented yet. The pioneers of Agile assume that all testing must involve working code. 

Today, however, we have many ways to validate ideas that do not require coding: business modeling, data analysis, interviews, surveys, and more. We also have a class of fake-it-before-you-make-it user tests: fake door, concierge, wizard of Oz and usability tests. Eric Ries, the creator of the Lean Startup, called those MVPs too, and they can often be done without coding. I created the AFTER model shown below and explained in my book to demonstrate this gamut of validation techniques.

The best practice is to start from the left. Validate your ideas using these cheaper no-code techniques (you don’t have to use all of course) and park or pivot the ones that don’t seem to hit the mark. Proceed to testing with code only with those ideas that show supporting evidence. This way you run through many more ideas while conserving those scarce development resources (here’s a full example). 

Marty Cagan made the same point back in 2018:

“It’s not that we couldn’t use the engineers to create the learning iterations like Henrik is describing, it’s just that it would take dramatically longer (in my experience, at least an order of magnitude) and yield substantially more waste.” — Skateboards vs. Cars Revisited / SVPG. 

Over time more and more companies realized they don’t need to produce a “code MVP” to start testing their assumptions. These companies were able to learn and iterate at a much faster rate, which translated into better product launches that produced more business and user value. 

Sadly this trend seems to be coming to a screeching halt. The reason will not shock you. 

AI Has Entered the Chat

Coding has become the killer application of gen-AI, and there are early signs of product/market fit. This is a very positive development, however hyperbolic claims of “10x speed” and “zero cost” are driving the tech industry into a coding frenzy. AI usage mandates, token leaderboards, and PMs that must use Claude Code, are some of the signs of rampant output-focus. Some managers again believe that working code is the true measure of progress just as if we’re back in 2001. 

This change is hurting true product discovery:

• People reach for Claude Code or Figma Make as the first step — why spend time pouring over data or surveying uses when we can just build a working prototype in a day? Surely we should just skip ahead and test the code with users. This is essentially the Agile approach all over again. 
• Some people argue that the entire concept of product discovery is now unnecessary. If coding is 10x fast and dirt cheap, launch-and-iterate makes more sense, they argue. Here we’re basically going to option 1 in both Hendrik’s and my illustration — launch and pray. 

There are multiple good reasons to try to fight these lines of thinking. 

Testing with users is slower and more expensive than we tend to think

In any test where users are involved you need to:

• Identify the type of user you need 
• Recruit or target them
• Develop protocol for communication and for data collect — for example a usability test script, or A/B test instrumentation
• Design and develop the software to use — this is where AI coding definitely accelerates things
• Get the users to engage with the test — get participants to show up to the usability test, get the early-adopter to install the software and use it, etc
• Run the test — this usually takes in the order of days to weeks. in some large B2B cases it can take months
• Collect data and analyze it

AI can help with all of these, but it cannot expedite the most time-intensive part — running the test itself (testing with synthetic AI users is not considered a viable alternative by experts). 

We tend to fall in love with our babies

Once you’ve created a polished prototype and shown it to your team, managers., and stakeholders, it’s easy to forget that this is just a throwaway testing tool. Escalation of commitment is a real bias, and you may find it hard to park this idea even if it tests poorly. 

Acting before thinking

As product people, and as humans, our natural inclination is to do rather than to think (especially the heavyweight system-2 type of thinking). But there’s massive value in taking the time to evaluate an idea along the axes of impact, effort, and confidence, doing a back-of-the-envelope estimate, or conducting a competitive analysis. We can improve our idea just by doing these things, or maybe even realize that it’s not worth doing compared to other ideas. 

The Perils of Easy Output

In a sense my own meme that started this article illustrates these points. A quick Google search would have led me to Kniberg’s article, and I could have created a better-informed illustration. But AI makes it so easy to create a polished diagram that I just was pleased with myself and posted it. I skipped the thinking and moved directly to doing. 

I’m a massive fan of testing with code. I’m also not in favor of taking forever to analyze and debate every idea. AI coding is a great tool and we should use it. Still, the temptation to start with code has very serious consequences on our ability to learn and iterate fast. If we want to do the right things for our users and businesses we should use the full gamut of validation techniques despite corporate mandates and easy prototypes.

Upcoming Workshops

Practice hands-on the modern methods of product management, product discovery, and product strategy.  

Secure your ticket for the next public workshop
or book a private workshop or keynote for your team or company.