The Intersection: Where Successful Products Are Born
Successful digital products happen at the intersection of three distinct skill sets: subject matter expertise, product development, and technology/code.
Vibe coding as a label made the meteoric rise. It was invented just 3 months ago, and now it seems everyone who's even remotely dealing with software knows what that is.
AI companies showcase how you can generate the whole application with their newest model. The startup ecosystem encourages the vision of non-technical founders doing it all by themselves. And it's not just words. During my recent trip to eMerge Americas, I talked with people trying to vibe code their MVP.
As things stand right now, they'll be up for a rude awakening.
Lean Startup Is Not Dead
I was recently amused by another "[something] is dead" kind of post. This time, the deceased was the Lean Startup.
The gist of the argument is that Lean Startup was useful when software development was expensive. That's why we focused on discovery, validation, experimentation, and all that jazz.
But now, to quote the article (emphasis theirs):
writing code is no longer the bottleneck for building a product. In fact, it’s headed towards becoming one of the easiest parts of product development.
In other words, in the AI era, coding is cheap. Just get whichever model performs best in benchmarking tests and get it to generate your app. Instead of meticulous discovery, just build it and put it in front of people. You'll see whether it works or not.
The thing is that Lean Startup was never about circumventing expensive development. It was always about finding the right product and the right niche for it. Continuous discovery is a process of, well, discovering that sweet spot (or, more frequently, not).
We always wanted to run cheap experiments to learn, validate (or rather invalidate) our business hypotheses, and iterate our way to something that may fly.
Only one thing changed. Right now, we have tools enabling different experiments that still fall into a "cheap" bucket. A few years back, we might have discarded building a proof of concept as the effort and price were prohibitive. Today, it may well be a viable option.
The goal, though, hasn't changed. We're not building a product yet. We are running an experiment to learn about our potential customers, their needs, problems, and behaviors.
The Lean Startup is as alive as ever. If anything, we got ourselves new tooling to make even more use of it.
What's Wrong With Vibe Coding?
OK, but who cares about Lean Startup? The whole discussion doesn't affect the rise of vibe coding as a new way of building products. I just mentioned that it, in fact, adds another option, so we're all good here, right?
Yes. Maybe. Well, not really, no.
The starting point matters. If we start with the assumption that we can vibe code a product, we're fooling ourselves. We can vibe code something. This something may even do a thing or two. But it's not a product.
Not in a real sense. It's not something that delivers enough long-term value to gather a pool of paying clients and sustain the business behind it.
A side note: I know claims of 1-person businesses with millions in revenues. Let’s wait to see their sustainability and how they will change over time. Also, they don’t contradict the argument below. Finally, 1-person businesses making millions is not an AI-era invention. Just consider influencers.
Coming back to vibe coding, look at how people typically demo the AI product development capabilities. It's mostly a super simple, just-for-fun kind of app. And the prompts still show quite some tech experience from behind the scenes.
If you've ever been a part of any serious product development effort, I bet you instantly understand this is not how the realities of building a product look.
Once you know precisely what to build, developing it is not that much of a challenge. The hard part? Knowing what to build.
After building dozens of products from scratch and contributing to building dozens more, we established the saying that, in essence, guides us to validate anything and everything our clients tell us to develop.
As you may guess, this process is heavily collaborative.
Software Developers For Free!
Imagine having access to a team of, say, 20 developers. They will work for you for free. They will unquestionably do whatever you tell them to, no questions asked. They will always work to the best of their knowledge. Would you like that team to turn your idea into a product?
Let me rephrase the setup.
They will never ask a question.
They. Will. Never. Ask. A. Single. Goddamn. Question.
It's not that they will not think about the broader business context, which is, sadly, still a default for many software developers. They won't clarify the requirements. They won't suggest edge cases. They won't consider trade-offs when goals are mutually exclusive. Heck, they will not even let you know when the solution doesn't actually work. They'll just hack some code and pretend that's precisely what you wanted.
Would you like that team to build your product?
Remember, they come for free. The value for money ratio is perfect.
Or is it?
You can navigate around all the shortcomings of your 20 free-of-charge developers. You can test whatever they deliver, point them to the issues, check the fixes, and so on. You can add more and more context—business and technical—so whatever they produce responds to your needs better.
It takes (your) effort and time. So is it really free?
Subject Matter Expertise
Successful digital product development happens at the intersection of at least three domains:
Subject matter expertise
Product management (including UX)
Technology/code
The first one is the least problematic. After all, a product idea always starts with some insight into a specific domain. Sure, later on, it may prove too shallow, overly optimistic, or flawed altogether. Still, if there's a safe starting point for an aspiring vibe-coder, it's probably subject matter expertise.
Product Management
Then we have product management. By the term, I mean understanding what it takes to build a sustainable digital product, how to drive its development, and what the many pitfalls are that will render the effect useless.
My "build less" mantra is in that group. The discovery process, assumption validation, and the experiments that guide development decisions all fall into that bucket.
Based on two decades of experience, there's one universal truth here. If we get subject matter experts (the dreamers) to make unbounded decisions on this front, we'll end up chasing a killer feature. It's not because they're ill-willed. It's because they don't know any better.
They know their domain. That's where they are the experts. They don't know the domain of product development. And that's a domain, too. That's where we come up with our expertise.
It’s where our mantra kicks back, once again.
Our clients always know what they want. Until they get it. Then, they know they wanted something different.
Following the dreamers blindly always ends up with a ton of rework. We learned it the hard way (doing the rework). Some of our clients learned it the expensive way (paying for the rework).
And that still was the optimistic outcome. It assumes that there was business to scavenge. The pessimistic outcome is that flailing with the product back and forth never reached a point where it could sustain the business.
Technology
Finally, the fun part. The technology. That's where AI models are supposed to show their prowess. And they do. I mean, I am impressed both at what code LLMs can generate and at the rate of improvement.
And it's not nearly enough. The game we play on the technology front is not about whether we can generate code, what it does, and how it fits the rest of the code base.
It's primarily how the code gradually turns changing business requirements into a working product over time. There are a few keywords here. "Gradually," "changing," and "over time."
Things will be changing. Whatever is the best technical solution for today, it will not be so tomorrow. What's more, over time, we gather baggage of all sorts of specific use cases. It's impossible to collect them all in a complete system requirements that AI can consider.
It necessarily means that continuous vibe development will be breaking things. Not even because an LLM will hallucinate (and it will), but because it can't possibly have the whole context.
In a product development team, we generate such insight through the collaboration of people in different roles, intuition, and expertise in the technical domain. An experienced developer who knows the code base would intuit potential issues by looking at the code, even if not written by themselves, e.g., during code review.
That's something that an LLM is fundamentally incapable of.
The Intersection
The successful product development stories address all three domains. Without subject matter expertise, the product will be an artificial attempt and ultimately result in something no one needs (1).
Without product management skills, we won't be able to turn a good idea into a sustainable product. Whatever we started with will turn into a Frankenstein of gradually more desperate attempts to make it work somehow (2). Which would only make things even worse, by the way.
If we remove tech-savvy, we may be off to a decent start. However, our attempt will quickly crumble under inconsistencies (technical and business alike). Growing technical debt will soon render any progress unachievable, as fixing one thing will break another (3).
We need to be at the intersection of all three skill sets to make a product work. Vibe coding promises to remove the need for one domain (technical) entirely and reduce another (product management) to the minimum.
And that is a lie.
Public Transport Fare App
I'm using public transport to get to my office. To pay the fare, I use an app. Right now, it's a fourth one. Every single one of them has some issues that eventually frustrate me enough to try yet another alternative. Sure, they're usable. Usable as in, I can pay the fare. But I could complain *a lot* about their UX and functionality.
Whenever (once again) something doesn't go smoothly with the fare purchase, we chat about it with my partner.
- They shouldn't ask me about that bit of data. They should fill it in by themselves. It's just bad UX.
- Yeah, but they probably don't have that in an API endpoint.
- And they'd also need UI that allows for updates whenever they substitute a vehicle.
- But they do have that data somewhere for tracking purposes.
- They might probably use GPS data, too.
Yes, that's a conversation about the (far-from-perfect) UX of a mobile app that does something as simple as purchasing a public transport fare.
We consider all three domains: technical limitations, product management with its tactics and constraints, and a little bit of domain knowledge. It may sound a bit weird as we dive deep into one domain for a second to jump back and start exploring another one.
That's precisely how we use the intertwined experience from all the contexts when building products. There's no clear cut. There's no clear specification we could feed as the context. We pull useful bits of knowledge as we sit fit and as a response to another person making their comments or asking questions.
That's anything but a "conversation" we might have with an AI model.
Understand the Process
None of this is rocket science. Save for deep technical knowledge (without which you can probably do the prototyping/MVP anyway), anyone can self-learn all that.
Just be prepared that learning is a long process, and you set yourself to make many mistakes. I often say that everything we do in the context of product development is covered in several books.
The hard part is not reading them. It's sorting the good bits from not-that-useful ones. And then learning how to apply the advice in practice. You want to make it on your own? Go ahead, break a leg! I'll hold your beer.
A similar advice goes for the technical part. Generating the first batch of code has never been that much of a problem. Granted, it was more expensive than today. But then, you can expect developers to use AI models extensively these days. They just don't let it run on autopilot.
The key advice here is really this: understand the process.
The tools we use when building digital products have changed. The principles have not.
In the past, we were forced to understand more of all the involved domains. Since people explicitly fulfilled technical and product management roles, we could at least expect that they knew what they were doing. Not that it was always (or even often) true. But still.
Today, we can explicitly say, "I don't need to learn any of that. I'll just have AI do that for me."
That's the equivalent of having blind monkeys throw darts. Once in thousands of times, it will strike a bullseye. The question is: Do you want to be a dart-throwing monkey?