They think the misunderstanding is technical. Like: “people don’t get how the model works,” or “they overestimate hallucinations,” or “they don’t know the difference between Sol and Terra” or whatever. That’s not the core misunderstanding. The core misunderstanding is economic.

Not macroeconomic. Not “the job market.” I mean the economics you can’t avoid if you’re building anything: opportunity cost, risk/reward, and the weird units where software actually becomes valuable—scale, repetition, leverage.

AI has made it dramatically easier to produce software. And somehow people jumped from “I can produce software” to “I can create value.” Those two are not the same thing. They were never the same thing. We just got away with conflating them because producing software used to be expensive enough that it filtered who could play the game.

Now the filter is gone.

So you get a wave of builders shipping things that work, that look fine, that have authentication, pricing pages, onboarding flows, and a bunch of features that compile. And then the builders say, with a straight face: “Marketing is hard.” or “We have a marketing problem.”

No. What you have is a value problem. And value is harder than software.

Here’s the uncomfortable claim: most of this AI-written software will be garbage. Not because the code is wrong. Not because the UI is ugly. Not because the product is “bad.” Garbage because it will absorb time and attention and money and produce nothing on the other side. No value out. Not even learning out.

And that’s a particularly deceptive kind of waste, because it feels like progress. It feels like creation. You get the dopamine hit of shipping. You get the illusion of momentum. You can point to a URL.

But nobody uses it. Or ten people use it. Or a few people try it once and leave. Or worse: some people do use it, and now you’ve bought yourself the privilege of running a system you didn’t really want to run. You wanted to build. You didn’t want to operate.

The bottleneck was never just the software.

That’s the part that’s hard for people to accept, because for a long time the bottleneck really did feel like software. If you were a non-technical founder, you had to find an engineer. If you were a junior engineer, you had to level up. If you were a small team, you had to spend months building the first version before you could even show it to anyone. “Shipping” was the hard part.

So the story became: once we can ship faster, we’ll win more.

But the startup story, the thing people romanticize, has always had two giant components. One is making something. The other is getting it into the world, watching how it behaves, listening to people, adjusting, fixing, supporting, deciding what not to do, handling failures, and doing that over and over. The second part is not a “marketing add-on.” It’s the business. It’s the operation.

And now that the first part is cheaper, the second part becomes brutally obvious.

Think like a CEO for a second. I once heard a line that stuck with me: the job of a CEO is to reduce risk. That’s it. Not to write code, not to craft pixels, not to ship features. Reduce risk.

If you take that seriously, building with AI becomes way clearer.

With AI, you’re placing bets. You can place more bets per week than you could before. You can prototype faster. You can get to a working demo faster. You can generate “a product” faster. That’s real. That’s not hype. It’s a big deal.

But placing bets faster doesn’t reduce risk. In fact it can increase risk, because you can now generate an infinite amount of surface area—features, code paths, integrations, promises—without having earned the right to maintain them.

If you’re not consciously reducing risk while you ship, you’re just manufacturing liabilities at higher throughput.

But those liabilities arrive later, while the reward of building is immediate.

This is why the “vibe coding” wave is so appealing. It feels like pure creative expression. Software has always been kind of magical: you can encode rules into a screen and it reacts. It’s interactive. It’s like writing a living thing into existence. And for the first time, people who couldn’t code are now shipping real software. They’re building authentication systems, connecting payments, creating dashboards, generating landing pages, setting up pricing.

I’m not here to sneer at that. It’s genuinely impressive. It’s also genuinely fun.

But fun is not value.

And this is the part people keep missing: AI makes the building cheap. It does not make getting anyone to care cheap.

You can ship an app in a weekend. You can ship five apps this week. You can ship a dozen “products” before you’ve had a single uncomfortable conversation with reality. Before you’ve had to earn attention. Before you’ve had to be chosen over doing nothing. Before you’ve had to find out if anyone comes back.

That’s the trap. AI is like a machine that turns imagination into artifacts. And artifacts are seductive, because they look like progress. But the world doesn’t reward artifacts. The world rewards things that people actually use, repeatedly, in a way that changes their behavior.

So when people say “we have a marketing problem,” what they often mean is: “we built something and reality isn’t cooperating.”

That’s not a marketing problem. That’s the actual problem.

It’s not that distribution is irrelevant. It’s that distribution is not a sticker you slap on top of value. Distribution is where you discover whether value exists at all. It’s where your neat business model in your head collides with what people actually do.

And that collision is exactly what a lot of builders are trying to avoid.

If reality rejects the product, you have to reconsider it. If reality accepts it, you have to operate it. Either way, shipping is only the beginning.

A lot of builders are going to learn the hard way that the bottleneck was never the software. The bottleneck was always: can you get someone to care, repeatedly, and can you keep the thing running while they do?

That’s operations.

Operations is not a department you hire later when you “scale.” Operations is the ongoing activity of making a promise and paying the cost of keeping that promise. It’s answering complaints. It’s handling refunds. It’s reading confused emails. It’s figuring out why your system ran out of memory at 3 AM. It’s fixing broken flows. It’s noticing that people churn in onboarding and actually doing something about it. It’s deciding what not to build. It’s monitoring. It’s support. It’s reliability. It’s the emotional labor of caring about users when you’re tired and the product isn’t glamorous anymore.

Marketing is where that promise first meets the people who can accept or reject it.

This is why the “marketing is hard” complaint is such a tell.

When someone says “marketing is hard,” what they often mean is: “I don’t want to do the part where reality gets a vote.”

Marketing, in the broad sense, is just getting your product into the hands of the people it’s for. That includes distribution, yes. It includes messaging, yes. But it also includes understanding what those people value, what alternatives they have, what pain they’re actually trying to solve, and why they would pick you over doing nothing.

If your product doesn’t fit into someone else’s life as a clear win, no amount of “marketing” saves it. If you can’t position it cleanly in their mind, if they can’t immediately understand what it’s for and why it’s for them, your software being beautifully engineered is irrelevant. You’re building a thing that doesn’t have a home in the world.

And AI doesn’t solve that. AI can brainstorm with you. It can generate copy. It can produce variations. It can role-play. But it cannot do the one thing that matters here: decide what is valuable for your users in the context of their lives and then build a system that reliably delivers it.

That’s your job.

Because value is determined in the user’s life, not inside the software, “it works” is a weak argument.

People keep defending their AI-built apps like: “but it works.” Okay. A lot of garbage works. Working is table stakes. Working is not value.

Value is created relative to other people. Not your internal model of the world. Your internal model is a starting point, sure. But value is something you negotiate with reality. With markets. With segments. With communities. With people who recommend things to each other and who have their own definitions of quality and their own alternatives and their own constraints.

This is messy. It’s not deterministic. You don’t get to just build in a vacuum and then declare value. You have to bring the model in your head into contact with the world as other people experience it. You have to discover where the bottleneck is for them, not for you.

And here’s the kicker: even if you find something people like, that’s still not the end. Now you have to run it.

We look at software companies and we see the facade. We see the app. We see the interface. We see the flow. We see the product screenshots. We see the “ship.”

We don’t see the machinery behind it.

Take a company like Airbnb. People call it an “app” because that’s the part you can screenshot. But the real thing is an operation: trust, disputes, support, edge cases, fraud, user behavior, and all the messy human things that don’t fit neatly into a product demo.

That’s not a dunk on Airbnb. That’s the point. The value is not “the app.” The value is the machine behind it. The part that keeps working when humans behave like humans.

If you think the app is the business, generating the app can look like generating the business. It isn’t.

This is why the fantasy of “I’ll just automate everything” is so misleading.

Yes, you can automate more things now. You can generate code that does real work. You can build internal tools, scripts, integrations, workflows. You can build an MVP in a weekend. Great.

But the real businesses—the ones that actually create and capture significant value—have a huge operation behind them. That operation doesn’t magically appear because you used an LLM to write your backend.

And if you’re solo, or a tiny team, you can’t escape that. You can pretend you can. You can build ten apps at once and tell yourself you’re building a portfolio of bets. But when one of them actually starts to grow, you’ll discover a constraint that is not a matter of willpower.

When you’re actively maintaining a growing piece of software, you can only do one. Maybe not literally one, but effectively one. Because growth creates demands: more users, more support, more bugs, more requests, more infrastructure load, more edge cases, more expectations. The moment people depend on your thing, the cost of caring rises.

And that cost doesn’t scale down just because you can generate code faster.

This is the part vibe coders are mostly not pricing into their behavior. They’re building nonstop. Many projects at the same time. Sometimes chasing unverified features.

But seriousness isn’t measured by how much you build. It’s whether you’re willing to run the system.

And the reason most of this will be garbage is not that the builders are incompetent. It’s that they’re optimizing for the part that feels creative and controllable, and avoiding the part that feels slow and social and uncertain.

It’s not easy to listen to users. It’s not easy to constantly re-prioritize. It’s not easy to do customer support when you’d rather ship new features. It’s not easy to go to market. It’s not easy to handle the reality that users don’t care about your cleverness. It’s not easy to accept that sometimes the most rational move is to kill the thing you just spent two weeks building.

So instead, people keep building. Because building feels like progress. And AI makes building feel like flying.

There’s another misunderstanding hiding here, and it shows up a lot among engineers.

We grew up with deterministic software. By definition, software was logic. If this, then that. You can prove things. You can test. You can be confident. A lot of engineering education is built on this worldview: precision, guaranteed outcomes, repeatability.

Now we have a new kind of software that is probabilistic. Agents. LLM-driven systems. Outputs that vary. Behavior that is shaped by prompts and context. People call it “unreliable” because it can hallucinate.

And some experienced engineers reject it instinctively. They say: if it can be wrong, it’s unusable. And they’re not completely wrong.

But humans are probabilistic too. If you hire an employee, you don’t get a mathematical proof they’ll do the right thing. You get guardrails: culture, incentives, expectations, laws, accountability. You build systems around humans because humans are not deterministic machines.

So the real skill with AI isn’t pretending it’s deterministic. The skill is learning how to constrain it, shape it, and govern it.

Once execution becomes cheap and probabilistic, the scarce skill moves upstream: deciding what matters, defining acceptable behavior, and taking responsibility for the result.

That’s management.

Building with AI is not “tell the model to do it and then cash the value.” It’s: define what matters, choose the lane, constrain the output, review it, fix it, integrate it, test it, and then keep doing that while the world changes.

If you’re reading this as a PM or founder or CTO, here’s the part I actually want you to feel in your gut:

The relevant measure of speed is not how much software you produce. It’s how quickly that software reduces uncertainty.

If you are shipping faster and learning the same amount, you’re not accelerating. You’re just wasting time at higher throughput.

Because early on, before anything has pull, the job isn’t “ship more.” The job is to reduce uncertainty. To find out what people do when you put your thing in front of them. To find out what they ignore. What they misunderstand. What they come back for. What they’d pay for—or what they’d only use if it were free. To find out whether your product is actually a product, or just a demo you like.

You can build a prototype faster than ever. That should change how you prototype. It can even change the order of prototyping. It used to be that software was the most expensive, highest-fidelity step. You’d sketch. You’d storyboard. You’d do low-fi mockups. Then maybe you’d build.

Now you can build first. That’s wild. It can be faster and better to produce an interactive prototype than to draw a napkin sketch.

But this creates a new trap: because you can produce high-fidelity experiences immediately, you start putting fidelity where you haven’t earned it yet. You build the full thing. You polish it. You add features. You lock in design decisions. You spend your time making it feel real.

And then when you show it to users, they judge it by the wrong things. They comment on the color. They comment on the look. They get distracted by the surface. Or you get emotionally attached, because it’s not a sketch anymore—it’s a product. You’ve already invested.

High fidelity doesn’t merely cost more. It changes the experiment: users become more likely to evaluate the surface, and builders become less willing to revise the premise.

Prototyping used to be staged for a reason. It’s not because we lacked imagination. It’s because staged fidelity helps you learn the right things in the right order.

AI can compress time-to-prototype. It doesn’t remove the need for learning stages.

If anything, it makes discipline more important, because the temptation to skip the learning loop is stronger than ever.

And this is where I think the “CEO reduces risk” lens becomes the only sane way to build with AI.

If you’re placing bets, the goal is not to place the maximum number of bets. The goal is to reduce risk per unit time. That means your process needs to constantly ask: what’s the biggest uncertainty here? Where is the bottleneck? What would make this real?

Sometimes the bottleneck is technical. Fine. Use AI to crush it.

But most of the time, at the stage where people are vibe coding, the bottleneck is not technical. The bottleneck is: do people want this? Will they switch? Will they pay? Will they trust it? Will they keep using it? Can you deliver the promise reliably? Can you handle complaints? Can you keep it alive when it breaks? Can you operate it when it grows?

Those are risks. And they don’t go away because you can generate code.

In fact, the ability to generate code faster can hide those risks. It can let you avoid them longer. It can let you build a more elaborate castle before you discover nobody wants to live in it.

That’s how you end up with “garbage”: lots of time in, no value out, not even learning.

And when I say learning, I mean learning about the business. Navigating the idea maze. Reducing uncertainty with contact, not with imagination.

Yes, sometimes when startups fail, people say “at least you learned something.” And that can be true in a personal sense: you did a bunch of things, you got sharper, you built skills. That matters.

But the specific poison of LLM slop is that it can produce neither: no real progress through the idea maze, and no meaningful sharpening either. Just output. It looks like building. It feels like motion. But it doesn’t buy you truth.

Shipping without learning is just output. It’s content production.

And content production is not what most people think they’re doing when they say they’re “building a startup.”

That doesn’t mean AI lacks leverage. It means the leverage appears after you have found something worth multiplying.

Once the machine works, using AI is much simpler. If you already have a system with pull—users, demand, a product that survives reality—then AI is an incredible optimizer. You can look for bottlenecks and opportunities. You can automate pieces. You can speed up delivery. You can reduce costs. You can do what a good consultant does: find the constraint, remove the constraint, repeat.

That’s not trivial, but it’s legible. It’s operating on an existing truth.

What’s much harder is creating value out of nowhere. The part where your neat subscription model in your head collides with the fact that customers don’t care, don’t trust, don’t switch, don’t pay, or don’t even understand what you built.

That’s the part where shipping is cheap and learning is expensive. And where a lot of people choose cheap shipping over expensive learning, because it feels better.

I’m not saying you shouldn’t build. Build. Building is powerful. Prototyping is powerful. One-off software is powerful. The fact that someone can now create a tool for their own life that used to be too expensive to justify is genuinely a new kind of freedom.

But don’t confuse that freedom with leverage.

Lowering the cost of creation expands what is personally worth making. Leverage requires something more: repeated value for other people.

The promise of software, the reason software is such an insane economic instrument, is leverage: you can serve massive scale with the same code. That’s the dream people are chasing when they sign up for expensive model subscriptions and build three apps a week.

If nobody uses your code, you have no leverage. You have an artifact.

If ten people use your code, you might have a nice toy. You might have a useful internal tool. You might have something that makes your own life better. That has value. But it’s not a value engine in the way people mean when they say “I’m building a business.”

If people use your code and depend on it, then the work begins. Because now you owe them something. Now you’re in operations. Now you’re in the business of keeping a promise.

And that is where most AI-built products will die—not because they couldn’t be built, but because nobody wanted to pay the cost of caring.

So here’s the distinction I want to leave you with, sharpened, not motivational, not a lesson, just a hard line you can use to judge your own work:

Producing software is when you can point to a working thing and say, “It runs.”

Creating value is when other people rearrange their behavior around your thing—when there’s pull, when it survives reality—and you can keep the promise you made to them tomorrow, and the next day, and the next.

AI makes it easy to produce software.

It does not make it easy to create value.

If your week ends with a working product and zero new information about what people will actually do with it, you didn’t build a business asset. You produced a convincingly engineered form of waste.

Credits

• Image by Patrickamackie2 (Patrick A. Mackie), CC BY-SA 4.0, via Wikimedia Commons

• Speech-to-text with Handy and Whisper Large v3.

• Composition, styling, and editing with Notion and ChatGPT.

In this post, I’ll show how I implemented a real-world feature for a new project I’ve been working on, and why I think the act of coding has now reached a very reliable abstraction: natural language. I’ve been working with AI tools to improve my development speed since the AI wave started, and the last few weeks have changed how I build.

I started with GitHub Copilot, which was already a game changer for editing (auto-complete) and local changes. My speed multiplied. Then I coded by asking questions on ChatGPT.com while editing with GitHub Copilot in VS Code. When GitHub Copilot announced Chat inside VS Code with code context, I tried it a bit but wasn’t impressed, so I didn’t use it much. Later, Google announced Stitch for building UI. I used it to scaffold something, then had to take it from there as a human “editor” (with Copilot’s help, still working in-editor).

Coding IDEs started popping up and I didn’t try them. I’ve been an early OpenAI user, I like and trust them, and I wasn’t ready to invest time learning new tools. I figured I’d let them evolve before jumping in. Also, I’ve customized VS Code enough that switching feels painful. I don’t like that VS Code has nano-lag compared to editors outside a web view, but I still use it because it’s so customizable, has a large plugin ecosystem (it’s become a standard), and just works most of the time.

When OpenAI announced codex-cli I was curious, without realizing how powerful it would become. One day I decided to try it. As a bootstrapper, I’m usually short on time to even read the full instructions. I worried about it messing up my repo, so I started a new project and decided to use only codex-cli to feel safe and get familiar. I built my first app prototype entirely with it, and it worked! But after a certain point the code became spaghetti 🍝 full of monkey patches—unmaintainable. I realized that unlike my usual process, where a prototype evolves into production through iteration, this prototype could not be salvaged. I’d have to start over.

Before rewriting the project to give it the structure it deserved (not just “vibe code it” but actually monitor every change—especially at the structure level), I did some customer validation. A few potential users were excited. So I disposed of the throwaway prototype and decided to build it well.

What I did next was serious planning with ChatGPT.com’s help: understanding the theory, different approaches, potential trade-offs, and researching tools. When I was ready to build, I went back to codex-cli. Because the project was new, I made sure everything was saved in the remote repository (just in case), passed the flags so it could do what it needed (even go outside the shell, which was causing slowdowns), and let it tell me when it was ready. It would sometimes fail and sometimes get it right. It was very useful, but it still needed supervision and guidance—like an intern.

I would step back, undo, course-correct, and continue. I made sure the project used the right tools in the right way, with the right separation and structure. It took time, but it was worth it. I was already building much faster, and I got really excited about codex-cli. I started reporting issues and talking with the team behind it.

Around the same time, other CLIs started popping up—most notably Google’s Gemini and Claude. I tried Google Gemini. It takes one bad “shot” to reduce trust; when you’re sitting and waiting for minutes, if the agent does the wrong thing and messes up the codebase, it’s annoying even once. On some hard problems I had, codex performed better than Gemini (that was my impression), so I stuck with codex. I didn’t really try Claude since codex was already very good, though I read in the Pragmatic Engineer newsletter that many developers liked Claude Code.

Then something magical happened a few weeks ago. OpenAI announced ChatGPT 5. Buried in the announcement was a note that ChatGPT 5 was optimized for code writing, so I tried it. I updated codex-cli and found that many of the issues I’d reported were fixed and the default model was now GPT-5.

To my surprise, GPT-5 was optimized for exactly this kind of work: reasoning about technical goals, proposing good approaches, calling tools, and making things happen. It’s a default-reasoning model, meaning it does a “thinking” step behind the scenes before responding—which reminds me of how my first serious programming professor taught us to “think before you code.” It feels like working with a smarter person. Instead of an intern, it’s like having a senior developer who’s actually much smarter than you, ready to ship. You just say what you want in plain language and they’ll get it done. Once I started coding with codex-cli and GPT-5, I realized product development had changed. We can now build features in minutes rather than hours, hours rather than weeks, and weeks rather than months. The old assumption that developer speed only varied by 2–4x has been inverted. I was mind-blown: when I thought I’d get a complex feature done by day’s end, it was done in 30–60 minutes (this was already true with codex-cli and GPT-4).

I don’t know how others are using AI coding tools, but it’s worth sharing how I’m building. The insight I’ve had is that I rarely need to look at the code. Sometimes I do—and it’s important—but most often it just works, and I can verify it with as much depth and rigor as I need.

I think the act of coding has reached a very reliable abstraction: natural language. Some of us developers are wondering whether our hard‑earned skills will become obsolete. Tech executives claim most developers will become unnecessary. Apps like lovable.dev position themselves as replacements for developers. I find it somewhat sad that there is a startup with superstar engineers and Math Olympiads, that is openly on a mission to get rid of developers like themselves.

I don’t think that’s what will happen. Code is useless without its users, and complex projects serve diverse audiences, including internal stakeholders. We’ll still need people who can talk to the AI and specify, in sophisticated technical language, exactly what they want—often the product of thoughtful trade-offs with no single “right answer” in a complex problem space. Say someone asks an AI to “build a pong game.” It will likely produce a working version, and you can iterate. But if an expert talks to an AI step by step, as they would with a coworker, they’ll likely produce a better product—and, crucially, one they can trust, because they can inspect the critical parts and understand how it works. That’s how you offer quality and reliability guarantees to users. We may need fewer developers, but we’ll still need people who understand how systems work behind the scenes. For complex apps (the ten we use 80% of the time), we’ll still need those experts to both build and iterate—in natural language.

For demonstration—because they say “you don’t know what you don’t know”—I’m sharing how I built a feature this way for my new project, Shape It. I did have to step in and use VS Code Copilot Chat once when parentheses weren’t matching (Copilot is good at this because it has access to the IDE’s errors). The interesting part is that I built the entire feature using natural language only. I’m not sure this should be called vibe coding, which is often associated with people who don’t know how to code (and that’s great—but limited). In this new kind of agentic coding, you do need to “speak” code in natural language to get it right and reliable.

Make it work, make it pretty, make it fast still applies. The difference now is that you can think before you code in natural language, and a capable agent will do the heavy lifting. You supervise, you specify, you verify—and you ship.

I’m sharing here’s my entire conversation with codex-cli, for your inspiration:

progressive-disclosure.txt

It took half an hour to make it work (tech speak), around two hours of “design talk” to make it pretty, and it’s already fast enough.

In the only thing that matters, Andreesen emphasizes that product-market fit (PMF) is the most critical factor to startup success. When starting a new project, builders and people who are drawn to great products, are naturally inclined to focus on what the the solution will look like (or do) “the product”, making it easy and natural to lose track or underestimate the other, and equally important part of the PMF puzzle, “the market”.

But, even when we are market-aware, as product managers, whether by training, or because of an external push such as a friend, investor, coach, or stakeholder who asks “how are you going to make money?” followed by “who is going to pay for that and why?”, we are inclined to have an expansive view and look for a good reason to say “as many people as possible”, and if we’re not wary of our innate push towards motivated reasoning, we may be fast and certain to make up and conclude that our target market are large “potential” audiences, akin to starting at the top of the total addressable market (TAM).

My point is—when looking to innovate, rather than thinking of addressable markets, no matter if it’s TAM, SAM, or SOM, we should instead look into the first 2.5% of people who will use your product according to the innovation diffusion theory as the early answer to “who is this product for?”. These people are the “innovators” also known as super fans by Amy Jo Kim and as high-expectaction customers (HXC) by Julie Supan.

While your super fans will probably not help you make money, and they will certainly not be the target audience that will make your business model work, technically speaking, for simplicity, early on, you should think of them as your target audience, specially for design purposes. I will talk about the importance of audiences in design more in depth in another post, but the point I want to make here is that we should always be building for someone, and that someone, before product-market fit, should be your super fans. Everyone across the organization should be aligned on who these super fans are and you should try to bring them in close to the product early and often, until further on when people are asking for your product (eg. having a market pull).

When creating something that doesn’t exist, it’s often hard enough to find one person who cares about it and genuinely wants to “hire” your product. Considering how many assumptions you’re probably basing your reasoning on, and how complex your product is; saying who your larger audience is, and designing your product around how you think they think (meta guessing), is non-sense. But we do it either way, because we need a good answer to the question “who is your customer?”. We have to start somewhere, and we’d all like to start somewhere good, when possible.

Instead, start with a few assumptions that answer “who cares a lot and why?”. These assumptions, if framed correctly, should point you towards your super fans. Start with your super fans and try to make them …super… happy, they are well positioned to teach you the most about your product at this stage. Before product-market fit, you’d rather have a few super-happy super-fans, than an imaginary slice of a super valuable market.

When you find them, if they really are your super fans—meaning that they absolutely love your product and would be very disappointed if it didn’t exist—they will be so excited about the problem you are solving that they will be willing to help you build the solution. They will be as interested and as personally invested as you in having the solution materialize, so you should bring them in as partners in your design process, they will be happy to partake.

There are many ways to do this, but to keep things simple, I suggest first screening them with Amy Jo Kim’s super-fan 5 discovery questions (adapt as needed), and then embedding them into your product development cycle. For example, you could show the new iterations to them every 2-3 week sprint and use their feedback to inform your next build cycle.

I would say that with five (real) super fans who share the same traits in relation to the problem you’re solving, you can already build enough momentum to reach your early adopters, who may already be willing to pay for a solution. You early adopters are your super fans + more people who also care but need a more polished product before adopting it. Every case is different but your project may be able to survive at this point, and that’s usually what you’ve been aiming for since the beginning.

There are many methods to conduct user research professionally, but if you are short on resources, you can go a long way in learning about the problem/solution by just being humble and using your intuition. With those things in mind, just continually keep trying to make them happier and you’ll be on track to solving the right set of sub problems of the PMF puzzle early on, hopefully giving both the same relevance:

• Who is the market? → Who cares and why? → Start with your super fans (Minimum Viable Audience).

• What is the product? → What should I build? → Start with an idea. (Minimum Viable Product).

Personally, as an indie hacker, I made the mistake of showing my prototypes to anyone who would listen, because I was often forced into scrappiness due to lack of resources, and although that helped with improving the usability of the product, it just made things worse in terms of understanding the market and their needs, often leading to Frankenstein-like products that made no one happy in an effort to make everyone happy. In other words, showing prototypes to non-fans helped me make the solution better in some way, but it made things worse in understanding the problem space.

Before you have product market fit, most of the value generation comes from having a deep and comprehensive understanding of the problem. “The search” is more about the underlying problem than about any specific solution. Problems are often more complex than they first seem once you start breaking them apart.

To find your super fans, who will help you understand the problem you need to start somewhere, so make a set of hypotheses, rank them, and try to prove them or disprove them.

Here’s how I formulated these hypotheses for a new project:

1. Write down a one sentence short and simple explanation of your value proposition. In my case, I wrote “Fast access to summarized high-quality content about anything”. It simply captures what this is and what makes it special. Note that this doesn’t include the “who” part.

2. Then try to come up with a few outcomes, think social, emotional, and functional that happen when someone “hires” your “what”? For example, I wrote, people may discover new ideas (functional), impress their friends (social), and feel smart (emotional), but I wrote a few more.

3. Then write “who cares most” and make a list of audiences that could potentially care about your “what”. Try to separate this buckets of people based on demographics and/or behaviors. For example, I wrote busy growth-minded people, DIY fans, people who listen to podcasts frequently, and self-taught modern polymaths, among others.

4. Lastly, look at everything you wrote, and use your sense making and intuition. Then choose one or two audiences, if you have a team, make the guess democratic. You’re trying to find who your super fans are by guessing who cares about what you do based on the outcomes they get.

5. Iterate, improve, and evolve both your product and your market.
   Note: It can happen that some day your product changes so much that your super fans no longer like it, and that’s ok. I’ve observed this phenomena with fresh and cool niche music that follows the MAYA principle when the band grows into the mainstream.

I suggest you write down what you’re going to do in a notebook and you make the habit of coming back to it regularly, this way you’ll help yourself re-focus on what matters and re-evaluate your approach and your progress. I had to learn this the hard way myself when I was working on solo projects.

Looking for your super fans, hypothesizing and iterating about who they are (systematically), giving them the importance they deserve, denoting them as your target audience company-wide, brining them in regularly and repeatedly, showing them your prototypes, and learning from them are underrated and often ignored activities that can help entrepreneurs navigate the problem space and help their ventures thrive and survive by creating valuable products that matter to someone somewhere.