You’ve definitely heard that one: Investors back the jockey, not the horse. Get VCs to choose between the product and the key people behind it. They will predominantly stress how much they bet on the founding team. Check prevalent advice on pitching. The team slide will almost always emerge as a pivotal part.

I just got back from Bits and Pretzels, a major European startup event. The story? All the same. Team over a product. I heard it from the main stage. I picked it up from roundtable discussions. It got repeated over and over and over again in hallway conversations.

I call bullshit.

What people say they do is different from what they actually do.

Subscribe now

Listen to Pitching

Throughout the two days of Bits and Pretzels, the pitching stage was open almost the whole time. I tuned into a few dozen pitches across a few sessions. The quality, expectedly, varied. However, what interested me more than pitches were the judges’ questions.

If a team is important, there should obviously be a lot of inquiry about it. It doesn’t matter whether the judges were genuinely interested in exploring the idea or merely sharing feedback about the pitch itself. The founder questions should emerge.

Across all the pitches I saw, there were easily way more than a hundred questions in total. How many of them were about the founding team?

One.

About the product? A lot. Traction and revenues? Even more. The proverbial jockey? One.

And it’s not like the presentations lacked variety. You could hear anyone from founders looking for the first users to those ready to grow a validated idea. The industries ranged from the future of work to robotics, from sales to entertainment, from finance to health.

Even when a founder literally started their pitch by introducing themselves as a serial entrepreneur, no interest followed. Or at least it wasn’t signified by any question whatsoever. It felt like a direct prompt: “Ask me about this!” To no avail.

Challenge the Investors

“But Pawel, there’s a world of difference between a pitching contest and actual investing!”

There sure is. So let’s talk to the investors. I asked several of them how important the team is. Very. One of them went as far as to suggest it’s 80% of their decision input. So far, so good.

Let’s challenge that, shall we?

I followed up asking investors whether they would invest in a startup perfectly aligned with their agenda but not promising hefty ROI multipliers. Nope, can’t do. “We don’t invest below $1M ARR, sorry. My hands are tied.” was a typical answer.

Change $1M ARR to whatever arbitrary financial or traction metrics any given fund has set for themselves, and you could basically quote the answers. Pre-seed stage? “What’s the customer base, Customer Acquisition Cost, churn? What’s the traction?”

Hold on a second. What about the founding team role you were telling me so much about? Seems it doesn’t matter unless all the numbers pass the test. Yup, “My hands are tied.”

It makes sense. Ultimately, no matter how aspirational the agenda, the fund is there to generate profit. The discussions will boil down to the strongest indicators of future ROI. Which, quite coincidentally, are revenue- or traction-related. That’s risk management basics, really.

Should we then really expect General Partners to ignore that and prioritize stories of the founding team?

Availability Bias

Yet, somehow, when we think about how investors make decisions, it’s natural to stress the role of founders. Hell, if we inquire investors about that directly, they concur. Why?

It’s the stories we share. Ask random people in the startup ecosystem for a success story, and they will come up with the best-known ones. If not Googles and Facebooks of this world, then at least Airbnb, or Shopify, or Zappos, or Mailchimp.

All these stories have a hero at the helm. Brian Chesky, Tobi Lütke, Tony Hsieh, Ben Chestnut & Dan Kurzius. The visionary leaders. People you’d invest in without as much as a second thought.

Save for the fact that Brian Chesky didn’t look like a sure bet in the first place. Not to the investors he approached initially, at least. Oh, and Mailchimp never needed a round.

It’s a classic case of availability bias. We can readily recall these stories precisely because they are the most notable. We may thus consider them the norm, even if they’re anything but. It’s a trap. When all the available samples are edge cases, founders may as well trick themselves into believing they’re building the next Airbnb. Surprisingly many of them do, actually. I mean, believe, not build.

Reality, though, is largely built of failed startups run by unremarkable founders. These are product companies that get funded, if at all, because they can prove the business is promising enough. Except no one writes home about them. We can’t cite their brands, let alone their founders’ names.

Count the deals, and it’s those anonymous startups that make up the bulk of all investments. Do a simple test: how many recent funding stories can you bring up? Now, there were tens of thousands of startups funded last year. And the year before as well. Oh, and two-thirds of them ain’t gonna raise another round anytime soon. Or, like, ever.

Even for an insider, it’s impossible to know more than a sliver of these cases. A layperson will default to the same few, most notable ones. That’s a perfect Petri dish for availability bias.

Hindsight Bias

A good companion to availability bias is hindsight bias. When we look at all these success stories, we see the founders as if they had it all written in the cards.

Consider the details, though, and the arc breaks. Why was Shopify a snowboard shop? Why did Flickr start as a failed online game? Oh, and when we’re at it, how about Slack? Same co-founder, same story. It’s as if Stewart Butterfield believed he needed to start with a failed game to build a successful business. Or, more likely, he had no idea. In hindsight, we consider those pivots almost inevitable. If they were indeed that obvious, why take the long path?

Or maybe, just maybe, there wasn’t anything certain about these calls. Maybe all these stunning successes with charismatic founders were one unlucky turn away from going bust?

Think of Steve Jobs in 1997, when Microsoft’s investment saved Apple from a sad end, way before the iPod or iPhone. One has to wonder what story we would be telling about Jobs if Bill Gates didn’t come to the rescue.

Probably something like the one about Fab.com and their failed pivot to Hem.com. Or, if they were a tad luckier, something like Groupon’s neverending pivot story. Funny thing, these never come up when I ask about startup stories.

In hindsight, all celebrity CEOs look invincible. In reality, the perception stems from their success. Which was anything but certain.

What People Say They Do Is Different from What They Actually Do

“We invest in a founder, not a product” is a convenient story. It’s easy to convince ourselves that it’s what we do. That is, unless we examine the actual behaviors.

Then, the story breaks. It’s more along the lines of “The founders are the decisive factor once everything else fits the expectations.” Guess what. Once everything else is OK, there’s no choice to be made. An investor has one startup to choose from. If they’re lucky. More likely, they disqualified everyone.

That’s, by the way, another common theme from my discussions with investors at Bits and Pretzels. “We can’t deploy all funds.” I heard that theme from General Partners from funds big and small, focused and broad.

Would they invest in a founder who literally wants to advance the fund’s agenda? Nope. Not if ARR, CAC to CLTV, churn rate (pick any) are not what they’re supposed to be.

So much for betting on the jockey, not the horse. It’s largely paying lip service, nothing more. If you want to know how any given fund makes decisions, ignore what they say they do. Look at what they actually do.

Not AI-generated. Seriously. 웃 https://okhuman.com/JTMv0A

Minimum Viable Product (MVP) is, hands down, the most successful term to come out of Lean Startup. Eric Ries didn’t coin it, though. Frank Robinson beat him to it by almost a decade.

Ries didn’t just make MVP a celebrity. He transformed the meaning of “viable,” too. While Robinson focused on ROI and risk, Ries redefined it as a vehicle for validated learning.

Funny thing. When people say “MVP,” they mean neither of these.

Subscribe now

Minimum Viable Product

In Eric Ries’ world, we build an MVP to optimize the Build-Measure-Learn cycle. We want to build as little as possible to be able to measure the outcome and, ultimately, generate new insight.

That’s how Ries described “his” MVP from the very outset.

“What we should have done, and what we did for a lot of features thereafter, is started with a landing page that promised people that product. Then we should have taken out the AdWords we were planning to take out, drive traffic to that landing page, and offer people to buy the experience that we are talking about.”

In that story, MVP is not a product. Not even a product scaffold. It’s a promise that a product might exist. A fake promise, no less. That’s basically what an empty landing page is.

Yet it’s enough to measure traffic (pageviews, clicks) and interest (email signups). It’s enough to learn. That’s what “viable” was meant to mean.

Everyone Builds MVP

At Lunar Logic, we helped develop some 200 products. Mostly early-stage. In many cases, we were there from the first line of code. Sometimes even earlier, from the ideation phase.

For each gig we landed, we talked with at least a few founders who didn’t end up working with us. If we include these chats, then the counter is long past 1,000.

One of my (many) roles at Lunar is handling these conversations. Yes, that means I easily explored more than a thousand product pitches. And not “let’s pitch to see if it even has legs” ones, but a “I really want to build the thing” kind. It’s a front-row seat to observe how founders talk about their product ideas.

MVP is the cornerstone of all of these stories. If we trust what people say, then everyone is building a Minimum Viable Product. It’s a Lean Startup heaven.

Except for the part where what we say we do is different from what we actually do.

Always a Product

At the risk of stating the obvious, the “product” part of MVP always delivers. Ask any founder about their idea. They’ll talk as much as you let them about how they are solving a problem (whether existent or not). All these narratives are about products, services, and offerings.

It sounds obvious. If a business is to make money, it has to sell something. Remove the offering, and you don’t have a business. No business, no founder, and no one to talk to about product development.

A side note: The existence of a product sounds obvious, but it shouldn’t be a given. A sensible discovery process should revolve around problem exploration before we even consider any solution. Figuring out what a product might be should happen only down the line. But that’s a different discussion.

Either way, a product is always there.

Sometimes Viable

Whether said product is viable is a whole ‘nother beast. At Lunar, we have a category for product ideas that blatantly don’t make sense. We call them “Facebook for cats,” which is a sentimental trip to the early 2010s, when we were literally asked to estimate such projects.

I didn’t gather data, but over the years, the percentage of such thoughtless ideas shrank. Yes, there was a wave of “blockchain for cats,” but it died rather quickly. Yet, if we count our experience as a temperature reading, the overall quality of product ideas has improved.

Which isn’t to say that they are viable. In any sense of the word.

We can consider viability in the literal meaning, as a product capable of working, succeeding, and/or growing. An appalling startup success rate suggests that maybe 1 in 10 product ideas are viable. At best. And that number refuses to budge for decades.

We can refer back to Lean Startup, too. In this case, viability is about how much learning we are able to extract from the product to iterate on it. Ultimately, the goal is the same. Some definition of success.

From either vantage point, viability is only an occasional feature of an MVP. An average product is not viable. Not even remotely close.

That’s why our goal to ”fail” at least half of our discovery phases is a modest one.

Never Minimum

I could complain about product ideas’ lack of viability all day long, but that’s hardly my main problem with how we use the glorified abbreviation. The biggest lie in Minimum Viable Product is the “minimum” part.

Across more than a thousand product pitches I heard, there wasn’t one that I’d consider minimal. Not. A. Single. One. And by a wide margin. Typically, it’s easy to remove two-thirds of the scope, and we still look at a product idea that potentially delivers value to the ideal customer profile.

And I’m using here a generous definition of viability—one where the offering genuinely aspires to solve a problem for customers, not one where we optimize for the learning cycle.

Even if I set the bar low and assume an MVP means actual product development, I am yet to see what I would consider a Minimum Viable Product. So far, no luck.

That’s why, when someone says MVP, I resolve it to Always a Product, Sometimes Viable, Never Minimum.

(Largely) Meaningless Labels

In a way, it was inevitable. Just about any term that becomes widely popular stops bearing any meaning. Take Agile. Once it got mainstream, suddenly everyone wanted to do Agile (or be Agile or whatever). What follows, everyone did (or was or whatever), whether that meant doing half-assed Scrum or building a culture that actually is responsive to change. Mostly the former kind, though.

Soon, when someone said Agile, it communicated nothing. You’d have to ask what they meant exactly to have any clue which definition of the word they had in mind.

Don’t get me wrong. I don’t criticize. Even for teams doing a half-hearted effort, it was likely still better than what they’d done before.

The same goes for MVP. It’s become an umbrella term for whatever a startup believes should be the first version of their product.

And it’s not like we lost all meaning. The vast majority of founders are genuinely trying to cut down the scope of their “MVPs.” They know an MVP should be small. They just don’t know how small small should be.

It’s an Experiment

Given that MVP has evolved to mean “the first version,” let’s just leave it as it is. I don’t mind. Yet we still need lingo to communicate these minimal increments we use to generate insight. If only we had a word for that.

Like, I don’t know, an experiment, maybe?

I know, I know. It doesn’t have a fancy three-letter abbreviation, and it’s impossible to get credit for coining the term. Still, an experiment means trying something, measuring the outcome, and ideally learning something new. It might mean generating new insight, confirming or disproving a hypothesis, etc. Doesn’t it sound awfully like the Build-Measure-Learn cycle?

In fact, a well-designed experiment should have an uncertain outcome. If we expect something to fail and it does, we learn little. And vice versa, if the odds of success are high and the thing flies, we don’t get much fresh insight.

In other words, simplifying a bit (I assume the payoff function is linear), the ideal experiment has a coin-flip chance of landing either way.

Had all those product ideas been pitched as experiments, well, probably most founders would have given up before we had a chance to talk. Framed like that, they’d have realized what they had wasn’t a smart experiment but a reckless, costly bet. They’d have either abandoned the idea or gone back to the drawing board.

Experiment Eats MVP for Breakfast

Language shapes our cognition. So how does using a largely meaningless TLA affect our thinking? Probably not much.

I know, MVP was meant to mean something. Yet, if we judge by our actions, then it’s lost its original meaning.

Now, MVP means: always a Product, sometimes Viable, never Minimum.

It can be a workable, albeit not ideal, frame for a product's first version. It’s not remotely as useful for the earliest stages of product development. So pardon me if I explicitly resolve MVP like that. Before we start working together, I’d rather be on the same page, and this particular acronym is less than useful for getting us there.

If, however, we want to talk about product discovery, let’s talk about experiments instead.

Written by an actual human. 웃 https://okhuman.com/VSay0g

We’re hiring. But it’s not gonna be a job advert, fear not. If anything, it’s a reflection on how the definition of a good developer in a startup has evolved.

Since we work with early-stage startups extensively, the skill set we’re looking for matches that of our clients near-perfectly. It’s a combination of (enough) tech capabilities, understanding of the value the offering delivers, some product-management-fu, a “whatever it takes” attitude, strong communication and collaboration skills, etc. Oh, and AI. AI too. In short, flexibility and breadth over narrow focus and depth.

And no, it’s not going to be an “AI has broken hiring” rant (even if it, in fact, did). For that one, go here.

In a way, it’s a message to developers. Yet, you can easily read it as a how-to-hire guide, too.

Subscribe now

You Are Full-Stack

If I got a beer each time someone threw a full-stack horse at me, I could throw a couple of parties right away. The argument goes that you can’t be good at the entire tech stack.

I get it. For years it paid better to be narrowly specialized, so we built this convenient illusion that it was impossible to do everything well enough.

Except, if you roll back some 25 years, we didn’t have a word for a full-stack developer, because everyone was full-stack. It was possible then. It is possible now. Especially with the new tooling.

AI can get you an aesthetic and functional UI even if you’ve never been a designer. Ditto the basic infrastructure setup, even if you’ve never been a devops engineer. Oh, and those fixes in, heavens forbid, a PHP codebase? Sure, can do, even if you’ve never touched PHP, not even with a ten-foot pole.

You are a full-stack developer now. Get used to it.

You’re Not Doing Rocket Science

Save for a small fraction of products where deep knowledge mattered, we largely used specialization as an efficiency vehicle. It was faster to have one person do back-end while the other did front-end (given that both knew their shit).

Guess what. In terms of code output, they now both lose to Claude hands down.

So deep knowledge matters where it’s actually needed. Which is not that often. An average developer is not doing rocket science. Unless they’re literally doing rocket science, that is.

Most software development means doing an unoriginal mobile or web app. It’s likely yet another solution to a first-world problem that no one asked for. And it’s going to be dead by the time it turns 5.

We don’t need fancy skills for that. We need just enough. In this case, “just enough” is distributed horizontally, not vertically.

We like to fool ourselves we’re that team from JFK’s “going to the moon not because it was easy, but because it was hard.” In reality, we’re that team from our internal joke at Lunar Logic: “It’s not like we’re sending a man to the moon, or something.”

You Are a Product Person

So, you’re not that much of an expert, and you need to pick up CSS, no matter how much it sucks. What else? You better learn how to manage product.

One of the most common reasons why developers fail recruitment at Lunar is how they think about why they do what they do. Why is that product being built in the first place? Why is this feature specced like that? Why would anyone even use it? Why? Why? Why?

Yes, I know. In 2020, these were all product questions. And product questions went to product people, who considered them and promptly delivered specifications that had all the answers.

That was then. This is now. Now, we want it or not, product specifications get AI-generated too. Developers, increasingly, are the ones who reconcile what makes sense from a product perspective.

The reason is simple. They are still responsible for turning English into code, whether they do it by hand or with an AI agent. And somehow, we still don’t trust non-engineers to prompt their way to products. For good reasons, let me add.

Still, the side effect is that more and more product responsibilities will naturally bubble down to engineering. You better know how to deal with that.

Oh, And You Are an Architect, Too

There’s been a ton of coverage on how junior jobs are gonna disappear in tech. Dario said it. Sam said it. Elon said it, too. Suddenly, the job market wants only experienced developers. One has to wonder where they would come from.

Still, we could rephrase the “we only want seniors” message. It’s just that we now expect more architectural decisions from every developer.

Five years back, a back-end developer might have had a database expert buddy to decide on data structures, and a front-end colleague who’d take care of anything on top of API endpoints. Today? That’s likely one job. Which you can outsource to Claude, easy enough. Yet, if you want at least a half-decent outcome, you’d better understand what you’re doing. Otherwise, you’ll end up with an unmanageable big ball of mud.

There’s a silver lining to this cloud, though. This architecture thing? It’s not necessarily what it used to be—a fancy title for the most experienced engineers who refused to get promoted to management. Remember? You don’t do rocket science. It’s enough architecture, and you’re good.

Interestingly, this means that you still need to know what good code and good software design look like. That thing? Never gonna get old, I guess.

T-Shaped Skill Set

A neat metaphor for exploring depth versus breadth of skills was that of a T-shaped person. Such a person has a relatively broad set of abilities and specializes in one of them. This means they can act as an expert in one context while still being useful in many others.

It’s that developer we all know. “I will do anything back-end. I can do front-end. If I have to. And if I’m allowed to complain about it. Loud. Infrastructure is fine too. Be warned, though: it will take time. A. Hell. Lot. Of. Time. Oh, you want me to make UX improvements? Will do. I just hope you’re not that attached to the idea that improvements must be better, are you?”

Jokes aside, I always appreciated people who were open to jumping in wherever the product needed. I call this a “whatever it takes” attitude. The gold was always the attitude, not the skills.

With all the changes in flight, the willingness to engage with many different things becomes even more crucial. You see, the ideal skill set is still shaped like a T. It’s just the font has changed.

As long as we used skill depth to carry the workload, which was most of the time, the expertise doesn’t matter as much anymore. We’ve gotten these fancy tools to do boring heavy lifting, remember? Meanwhile, we redefine what breadth means. Toe-deep might have been good so far. No longer.

Toe-deep means an AI agent goes largely on its own intuition. Which works great. Until it fails catastrophically. We need enough of these side skills to apply our own judgment.

The new T-shape is styled after Danny DeVito—short and fat. That’s how broad judgment looks in a picture.

Jack of All Trades

If this sounds like an ode to jack of all trades and a paean to flexibility, it’s because it is. Again, I don’t dismiss the need for deep expertise in some contexts. There’s a reason why top AI engineers command 7-figure salaries.

Statistically speaking, though, it’s not what the software development industry is all about. Once again, we’re not sending a man to the moon. We’re building glorified digital marketplaces, productivity apps, entertainment widgets, and whatnot.

That’s the jack-of-all-trades territory.

It’s almost funny. At Lunar, we’ve been hiring like that since the early 2010s. It felt like an uphill battle. And now, suddenly, the job market is all like, “You know what? You were right all along.”

Looking at our hiring processes this year, we keep rejecting people not because their T has not enough of a stem. Rather, its arms are not bulky enough.

One of our recruitment exercises is exploring (poorly written) product specs. We want to see how candidates think about non-technical aspects of product development. And we get a person who’d be all about database performance and SEO optimization. Or another who’d make sure to jump on Retrieval-Augmented Generation as soon as humanly possible.

Hold your horses, people! There’s no product just yet. Nothing to optimize. Nothing to be AIed. Let’s talk about whether the idea makes sense and why it most likely does not.

If you want a damn good product developer, don’t look at the one thing they can do best. Consider how many different things they can do well enough.

So yeah, it’s jack of all trades, master of none. But good enough at many.

Share

Written by an actual human being. Seriously, I have proof. 웃 https://okhuman.com/EKR7gw

Can you vibe-code a product?
TL;DR: No.

I wrote Vibe-Coded Product Success Stories Ain’t What They Look Like more than a year ago. In all honesty, upon writing the piece, I knew it might not age great.

I was wrong. It fared well.

A year down the line, and we still lack the actual success stories of vibe-coded products. If there’s anyone who would be all over the place with how you can prompt your way to a unicorn—or any remotely successful product, really—it’s Lovable. So let’s look at some of their publicity.

• Lumoo reported €700k ARR after 9 months of operations. It targeted €1M by the end of 2025.

• Plinq reported $450k ARR in 3 months.

• Quicktables reported €90k ARR in 2 months.

All that done with pure vibe-coding, Lovable-fueled superpower. Looks exciting at best, appealing even at worst.

Subscribe now

Growth Is Not Growthin’

Considering the numbers above in isolation, I should concede. I mean, they clearly show you can Lovable your way to decent revenues.

Yup, looks great. That is, unless you wait a while to see whether it’s an accidental shiny moment or it is really sustainable.

Out of the three, Quicktables seems to be done. It’s been sold with no fanfare. Which likely means there was nothing to fanfare about in the first place. If anything, it might be a tale about salvaging whatever there was to be salvaged from a failed startup. A telling story, but on a different topic.

Of the remaining two, Lumoo went surprisingly silent about their €1M ARR goal. In such a case, nothing speaks “we haven’t made it” louder than silence.

Plinq, on the other hand, mentions lower revenues in later sources than in the original Lovable story. It’s a total of R$500k in six months, equivalent to some $100k. Even assuming healthy traction, it’s a far cry from the $450k a year reported a quarter before.

Not only is the growth not growthin’. It’s shrinkagin’.

ARR Is BS

In all honesty, Plinq’s numbers didn’t necessarily shrink. Most likely, the original report just heavily overinflated them. Then reality—as it usually does—just didn’t live up to hyped expectations.

When Lovable covered Plinq, they used ARR (Annual Recurring Revenue) to paint a rosy picture. Except that using ARR for a 3-month-old startup is blatant manipulation.

These days, Annual Recurring Revenue is like the Holy Roman Empire. Neither holy nor Roman, not even an empire.

After 3 months, you don’t have annual revenue, and you know close to nothing about how recurring it is. Any traction you might already have is not remotely enough to predict its sustainability. After all, it’s easy to show 100% growth if you have just a handful of users. Most of all, in the AI era, revenues don’t serve as nearly as good a proxy for business potential as they did in the SaaS era.

By now, we've made ARR a vanity metric.

There’s a reason why some organizations started spelling out ARR as Annualized Run Rate, which means taking the best recent monthly revenue, multiplying it by 12, and pretending it’s the actual ARR. It’s like saying, “Hey, we’re bullshitting you here, wink, wink, but at least we admit it, so it’s all good, ain’t it?”

Small wonder that ARR numbers from Lovable reports age like milk.

They Still Raised Money, Didn’t They?

Here’s the best part. Save for now-deceased Quicktables, the other two startups raised money. Plinq raised $250k, while Lumoo got more than $600k in a seed round.

Sure, not really landing a whale, but still quite decent. Especially if you could cut down the development costs to a minimum, which is precisely the vibe-coding promise.

If I were feeling snarky, I’d question the need to raise an equivalent of 3 quarters of revenue in a seed round. But we already established that those ARR numbers were largely pulled from thin air.

Still, a startup raising a few hundred thousand in the first year of operations is in the top 5% or 10% of the class. In my book, that’s a strong start.

In the end, I have proven myself wrong, haven’t I?

Follow the Money

I could—and I will—defend my “you can’t vibe-code a product” position with a claim that a “strong start” is not a “success” just yet. The make-or-break thing for a startup is not initial usage. It’s sustainability.

In the cases we analyzed, we have no signal that sustainability is anywhere close. Heck, a few quarters down the line, and we get no updates on the ambitious revenue targets they shared initially. It may mean stagnation. It may mean decline. Either way, that’s not a sign of break-even waiting around the corner.

There’s a better “not even remotely close to a success yet” argument, though. Let’s follow the money. In both the Lumoo and Plinq cases, the prominent investor was one Anton Osika.

Yes, the same Anton Osika who happens to be Lovable’s CEO. The very same person who has a vested interest in success stories of Lovable-generated products. Ain’t it a convenient coincidence?

If Anthropic can spend close to $10M on a Super Bowl ad, and OpenAI may acquire a YouTube talk show for north of $100M, why wouldn’t Lovable spend a small fraction of that for strong PR? Such an investment is a direct equivalent of AI behemoths’ marketing extravaganza (adjusted for the scale of operations).

In that light, the “vibe-coding success stories” look kinda different.

There’s No Shortage of Trying

Meanwhile, Lovable itself moves like a juggernaut. While they may be short of their superambitious revenue targets shared last year ($1B ARR mid-2026), their growth stays impressive.

A year ago, I would have bet against Lovable passing the $500M ARR mark (even the bullshitty kind). I would have lost.

If anything, it means plenty of people are generating stuff with Lovable. There’s no denying that. And somehow, despite all the effort, we don’t see a tsunami of vibe-coded products. Hardly a ripple.

So more and more are trying, but barely anyone succeeds. Curious, isn’t it?

That is, unless “trying” means something entirely different here. Like, I don’t know, prototyping maybe?

“Thanks to Lovable’s rapid prototyping and real-time collaboration capabilities, we’ve dramatically streamlined our product development process. What once took six weeks — from idea to working prototype — now takes just three hours.”

This is Jorge Luthe from Zendesk, through Lovable’s own PR. It kinda makes sense. The money is not in the consumer market (wannabe product founders without enough funds to pay for development), but in the corporate world (established product companies optimizing their processes).

The only tricky part is that prototyping won’t yield a vibe-coding success story. PR and finance are at odds here. Oh, well...

The Actual Lovable-Powered Success Story

I admit, researching stories for this piece was a rabbit hole. The more I looked, the more data points emerged. Each with its own flaws. So let me share the closest to the actual vibe-coding success story I could find.

Brickwise was accepted into the YC F25 program. It means raising $500k from YC, which (obviously) isn’t connected in any way with Lovable.

“Checkmate, Pawel. Admit you were wrong.”

Yeah. Sorta. I mean, I admit you can bullshit YC to land in a cohort of some 200 companies that get through twice a year. I might be genuinely excited, if not for some dubious stuff.

Like, would you publish the grand news about being accepted to YC with this image?

Full disclosure, AI-generated graphics are my pet peeve. But this one? It’s cringy as hell.

Less than a year down the line, the signals you can pick up about Brickwise are anything but appealing. Again, the silence about traction speaks volumes about lack thereof. A blog that’s riddled with SEO bait smells of desperation.

If that’s the hero of the movie about vibe-coded product successes, then, I’m afraid, we really had to scrape the bottom of the barrel.

In the end, there’s not much success in that success story. And I doubt any more awaits in the future.

Coding Was Not a Bottleneck

A lot has changed in the year that has passed since my previous post on the topic. Most importantly, AI got way better at coding. Way better. It was not an incremental improvement. Released at the end of 2025, Opus 4.5 was a pivotal change. And we’ve gotten even better models since. Claude Design followed in April this year, so we don’t have to agree on functional-but-ugly.

If the technology was the problem, we should have seen significant progress by now. And we haven’t. One idea that made it past the YC filter on the top of the AI hype wave is nothing to write home about.

We learned to believe that development was the crucial part, because it used to take a lot of time and money. Guess what. That was a misconception altogether.

A startup is not a product. A product is not code.

And yet we keep pumping the bubble of vibe-coded products. We didn’t solve the problem of finding problem-solution fit or product-market fit. We did solve the problem of more efficient coding.

If the only tool we have is a hammer, all problems look like a nail. If the only tool we have is vibe-coding...

Share

Written (and typed) by an actual human. 웃 https://okhuman.com/5eoHxw

The last piece on user interviews triggered a disproportionately large amount of follow-up discussions in different places. If you don’t want to read the whole article, it boils down to a few bits of advice:

• Never treat an interviewee as a user

• Always have two people run the interview

• Don’t use an AI notetaker

• Don’t outsource a synthesis to AI or otherwise

• There are no silver bullet questions

• Assume the confirmation signal is weaker than it looks

Most importantly, though, tread carefully. When mishandled, user interviews create a false signal of confirmation. That’s much worse than just wasting some time on an activity. It’s as if you pointed yourself toward a dead end, patted yourself on the back, and cheered “Go attaboy!”

Subscribe now

Storytelling Is a User Interview

These days, I spend a good part of my week on recruitment. Among “my” parts of the process is what we call storytelling. I ask candidates to tell me stories about their best teams, worst teams, conflicts, etc.

My goal is to build a picture of a person as a teammate. My building blocks are the bits and pieces that they share, largely in between the lines.

We were discussing user interviews at the office when my colleague said: “Hey, storytelling is literally a user interview!” Only then did I realize how many similarities a good user interview and a good storytelling exercise share.

• I don’t ask a candidate to describe what kind of teammate they are. I go looking for what’s important to them in a team setup. It’s their story, not mine.

• Whenever I have a buddy interviewer with me (and I increasingly try to), I am often surprised by how differently we see things.

• I don’t use an AI notetaker (duh!), which makes me double-focused on the stories. Also, these things happen face-to-face, so AI notetaking would be kinda disrespectful.

• I most definitely do not outsource synthesis to AI. Just no. Period.

• I rely on the same set of starter questions (best team, worst team, etc.), but most commonly the magic happens when I go with the follow-up ones. “What did happen next?” “How did that person feel?”

• After running hundreds of those, I learned (by making mistakes) to be careful with formulating the conclusions. I mean, I really expect strong signal to vouch for a candidate. Otherwise, it’s a “meh” from me.

Hell, I would even add that there are some similarities in conversation dynamics. As product people, we want potential customers to confirm we’re on a good track. As a hiring manager, I want a candidate to succeed. In both cases, we’d hear stuff we want to hear. Confirmation bias is a bitch.

What We Say We Do Is Different From What We Actually Do

The reason why I picked up storytelling as a recruitment technique is simple. There’s a difference between what we claim we do and what we actually do. If you want to build a picture of someone’s behaviors in a given context, it’s better to ask them what they did in a specific situation, rather than throw a made-up scenario at them.

The same goes for learning whether someone is your potential customer or what they would need from a future product. Ask about what they have been doing, rather than what they would do.

“Have done” is signal. “Would do” is noise.

Same for hiring. Same for user interviews.

Note: I don’t assume that an interviewee, in either context, wants to trick the interviewers. Well, fine, some job candidates would. A bad idea if you ask me. During a user interview, though, there’s no incentive whatsoever to entertain such shenanigans.

Still, our brains mislead us. We continuously build a picture of ourselves that’s different from our true selves.

Storytelling to the Rescue

“Tell me a story about…” is a neat trick. It does three things concurrently.

1. It goes back to things that actually happened. That’s historical data.

2. It’s naturally all about them, and not your product/your job offer. They are the narrator.

3. It’s a highway to side inquiry. The actual insight is on the fringes.

Take “Tell me a story about the last time you watched something on streaming.” as an example. There’s no way this question keeps the limelight on your product idea. Not unless you interject and intercept the story.

By the same token, my “Tell me a story about the best team you’ve been a part of” allows the candidate to set the stage entirely. And the way they do it—which story they choose, who is in there, how all the people interact—tells way more about the candidate’s understanding of good teamwork than any direct answers would.

Even better, the story necessarily is “there and then,” while your product or your job is “here and now.” The context naturally pulls interviewers away from pushing their thing down the interviewee’s throat.

Oh, and humans are storytellers by nature. That’s how we communicated for millennia.

There’s literally no downside to this line of inquiry.

Not All Stories Are Made Equal

OK, there is a downside. While we may be genetically primed for storytelling, talent is not distributed equally. When I ask candidates, my storytelling recruitment exercise regularly ranks as either the easiest or the hardest task of the process.

Some folks struggle to come up with stories. And when they finally figure something out, they lack the skill to tell anything but the most rudimentary details. Sometimes, follow-up questions help. Often they do not.

That’s fine. Not every interview must be a success. Not every recruitment ends up with a hire. Not every user interview ends with valuable product insight.

On such occasions, wrap it up and move on. No need to extend the agony. The statistic is on your side. There are enough people who are good storytellers. You don’t need to squeeze every ounce of value from each story.

“Have Done” Is Not Speculation

If there’s one overarching reason for running user interviews, it is to address speculation. In product development work, we have no shortage of opinions and beliefs. Almost every product out there—successful or not—is based on a belief. Founders are universally among the most opinionated people I know. That is, as long as we talk about their product ideas. Which happens to be my job at Lunar.

In product development, belief is just a nice word for speculation.

User interviews are supposed to (in)validate the beliefs and assumptions. To that extent, there’s hardly a better tactic than relying on stories.

When someone tells their story, one-upping them with your product idea sounds awkward at best, rude at worst. When you shut the fuck up and listen, any signal you get is unprompted. Unprompted here means stronger. As a bonus, you improve the odds of serendipitous findings.

The best part, though, is that storytelling naturally anchors the conversation around what has actually happened. It’s about “have dones,” not “would dos.”

Remember? “Have done” is signal. “Would do” is noise.

Here’s some more reading on product discovery tools:

Share

Written by an actual human. No kidding. 웃 https://okhuman.com/WbfMrw

In a short brainstorming session, we exchanged ideas for the most effective product discovery tools. Sure, the right tool is not right, period. It’s right only in the right context. No silver bullets here, sorry. Still, some evergreens emerge almost every time.

Assumption mapping is one. I personally like user journey mapping, too. However, there’s one thing that we don’t often consider a proper discovery technique, yet it should be a staple. User interviews.

User interviews definitely make it to my top 3. Yet, as with everything, there’s a caveat here.

Subscribe now

The Mom Test

Before we jump to the actual analysis, I wholeheartedly recommend reading Rob Fitzpatrick’s The Mom Test. It’s short. It’s well-written. It tackles just one idea and does it superbly. Heck, it’s fun. Rarely is there a business book that crosses all the t’s and dots all the i’s. This one does.

Do yourself a favor and get a copy. Better yet, listen to the audiobook. The author does fabulous work turning it into something like an informal chat, rather than a professional yet dry-as-hell narration that’s the baseline for business literature. It feels almost like you got a chance to invite Rob Fitzpatrick for a few hours over coffees or beers. Which I would totally do, if I had a chance.

User Interviews 101

If you want to skip the reading (don’t), and user interviews are a new concept (they shouldn’t be), here’s the gist of it.

You talk with an existing user of your product (if you have some), or a potential one (if you don’t yet have any), for 30-60 minutes to get valuable insight into your plans. The plans may mean changing UX, adding a new feature, or building an entirely new product.

The tricky part: asking direct, closed questions along the lines of “Do you think this is a good idea?” or “Would you use it if we built it?” is the worst—and utterly useless—way to run user interviews. Also, it’s the most intuitive way, which makes the whole activity tricky.

By contrast, good questions revolve around interviewees’ needs and problems, and how they solve them now. In a way, it’s an exercise in beating around the bush to extract valuable insight that will validate (or, more likely, invalidate) the product assumptions you might have.

The Curse of Knowing Too Much

When we run engineering internships, we often ask the interns to build an MVP of a simple product. On more than a few occasions, we developed a thing for which we had potential customers inside Lunar. An obvious move was to interview these hypothetical future users.

So there I was, being user-interviewed by two interns. People with relatively limited engineering skills and no experience building products whatsoever. The only preparation they got was some advice from our product folks.

It was one of the best user interviews I’ve ever seen.

I got zero questions leading me to the idea that they might be working on a product. It was all about my problems and how I was handling them. We spent some 45 minutes chatting, and no products, features, or users were ever mentioned.

Lack of experience didn’t hold them back. In fact, it might have helped them. We prompted the interns to explore the problem, and that’s what they did. Founders, on the other hand, tend to be overly focused on their idea, which makes it so much harder to avoid treating their interlocutor as a potential user.

Now that I look back, I think that was the key part. It didn’t feel like I was a user in that interview.

They Shouldn’t Know It’s a “User” Interview

OK, the name of the technique doesn’t do it many favors. It’s called a user interview. It should be something something interview. I don’t know. A problem interview. A need interview. Yeah, I know. You don’t interview a problem.

Anyway. Revolving around the idea of a user tricks us into asking the wrong questions.

Review your questions. If any of them might make an interviewee feel like they are a product user, throw it out and never look back.

Of course, in some contexts it would be blatantly obvious to an interviewee that they are, in fact, a user. It’s fine. Just make sure none of the questions suggest it. In any way.

Two Is Ten Times One

Our interns run their interview in a pair. In a new environment, trying to prove themselves, most would choose such a setup. It’s less stressful when you’re in it together. You can support each other. It’s a safe play.

Yet, once you get familiar with the task and the environment, it would be tempting to skip the pairing part. In this case, though, it’s so much better to run it as a duo. In this case, 2 * 1 = 10. User interviews are binary, it seems.

In theory, the interviewer(s) would come with a list of questions, and they’d go through it one by one. In practice, conversation dynamics vary a lot. Some people need but the tiniest hook, and they’ll respond with a lore drop, crossing a third of the questions out of the list instantly. Others need continuous inquiry to give you anything.

The magic, as usual, happens in between the lines. So when one person (Batman) is all focused on navigating the conversation, the other (Robin) should be on the lookout for those hidden gems barely mentioned in passing. In my experience, expecting one person to handle both is too much.

As a bonus, Robin can (should?) be the one to play the “hold your horses” card. When Batman gets carried away, assumes they talk with a user, and starts asking product questions (which will inevitably happen), the other person is in the best position to notice. And react.

AI Notetakers Do More Harm Than Good

In the past, one reason to have another interviewer when talking to a potential customer was to have a note taker. There probably are people on this planet who can actively guide the conversation while taking notes. All three of them still make their interlocutor lose focus when they switch between the tasks.

“But wait! We have AI! AI can generate the transcription and the summary of an interview perfectly, no sweat!”

Yes. And no. Yes, AI can generate the transcription well enough. So what? Do you have product people in your team who will be reading these transcripts? I mean, seriously, do you?

The time needed to read and understand the transcript is comparable to how much it took to chat. So you might as well do the thing as it is happening.

Also, don’t expect AI to extract genuinely original insight. Novel observations happen at the intersection of the thoughts and experiences of the interviewee and the interviewers. Claude has access to neither.

Trying to work with an AI notetaker is a direct equivalent of telling AI to generate a dozen pages of slop based on some sources. We’d rather see the prompt, not the prompt output.

A competent human will intuitively understand which parts of the conversation are valuable and which are not. LLMs, by definition, do not have “intuitive understanding.”

Don’t Outsource the Synthesis

Let me redefine what a user interview is. It’s spending 45-60 minutes, talking to a person who might never even be interested in your product, to harvest between 0 and 3 short insights. It doesn’t sound like an effective use of time.

That is, unless one of these insights is valuable enough to justify investment. And it just so happens that every now and then, they are. Even if none of them are on their own, if you gather enough data points, you’ll start seeing patterns. That’s value, too.

So you either have enough reflex to see those on the spot, or you rely on synthesizing the interviews afterwards.

That’s, in fact, my old pet peeve with AI creativity. AI models will get only as creative as we make them. And we need expert knowledge to make it happen. Put differently (in Teresa Torres’ words):

“I can’t say AI is great at synthesis. AI is great at synthesis if you’re great at synthesis and you know how to teach AI how to be good at synthesis.”

The reason, again, following Teresa Torres, is that “there are lots of ways to synthesize an interview.” Claude or NotebookLM can’t know on its own what’s contextually the most valuable vantage point. It can’t pull ad hoc all the experience and intuition of a product person.

Ultimately, synthesizing insight is the most valuable part of a user interview. In general, we don’t outsource the core of our businesses. Why should we do it for the discovery process, then?

There Is No Silver Bullet Question

A frequent bit of advice for user interviews is to finish by asking: “What question should I have asked but didn’t?”

Don’t overestimate it.

In theory, it does the trick. It’s an open-ended question that probes the territory you didn’t explore. In practice, it suffers from the very same pattern that plagues the “Would you use my product?” inquiry.

Rob Fitzpatrick frames it as a fatal mistake (emphasis mine):

“Most of your meetings will end with a compliment. It feels good. They said they liked it! Unfortunately, they’re almost certainly lying. Not necessarily intentionally.”

By the same token, when asked the “ultimate” question, we will invent stuff the interviewer wants to hear. “What question should I have asked but didn’t?” Wait, there is supposed to be something more? Let me make something up.

No specific script will land you good insight. It’s all about navigating the conversation ad hoc, depending on what you’re getting thus far. Ignore that, and the answer to the “silver bullet” question may be either golden or completely misleading. Or anything in between.

You Will Be Biased

Finally, no matter how you try, there’s no way to avoid bias. I mean, we go in there with a hypothesis and a hope. It’s not like we’re neutral. “I’m indifferent to whether this idea is good or bad,” said no founder ever.

No wonder. The list of biases we need to overcome in this situation is impressive:

• Confirmation bias makes us ignore counterevidence to the hypothesis.

• Survivorship bias makes us overly optimistic about the odds.

• Social desirability bias makes interviewees say things we’d like to hear.

• Self-selection bias makes the pool of people we talk to more likely to be interested in the thing.

• Say-do gap makes people state intentions they wouldn’t eventually act on.

• Overconfidence bias makes us overestimate the weight of our own interpretations.

• Observer-expectancy effect makes us directly influence the answers we get.

• Illusion of validity makes us overestimate our ability to predict outcomes based on data.

Should I go further?

No matter how aware we are of biases, it’s of little help. We believe knowing of a bias helps, but it does not. And yes, there is a bias for that, too. It’s called bias blind spot.

In Thinking, Fast and Slow, Daniel Kahneman argues for setting verifiable criteria beforehand and sticking to them, and them only. In the context of qualitative techniques, such as user interviews, it will prove challenging.

Still, it’s a safe bet to assume the positive signal is always weaker than it looks, while the negative is always stronger.

User Interviews: Handle With Care

When I started writing this article, I was like, “Hey, let’s write a short, lightweight piece on some user interview caveats.” Some 2000 words later, it feels like I could keep going.

Yeah, Rob Fitzpatrick took well over 30k words to write The Mom Test, which is short and lightweight. And it covers the same narrow topic. What have I been thinking?

Looking back at it, though, I’m like “Scratch that. If there’s only one thing I’d like you to remember, it’s none of the above.”

As innocent as user interviews look, it’s so damn easy to hurt yourself running them. If you take assumption mapping or user journey mapping and do them wrong, the worst thing that can happen is you waste some time. The outcome will be meh, but it will hardly push you in the wrong direction.

If you do user interviews wrong, they’ll absolutely push you in the wrong direction. It’s a “great if done well, harmful if not” kind of technique.

More posts on product discovery techniques:

Share

I’m typing these things by hand. Like an animal. 웃 https://okhuman.com/jcttRg

At Lunar, we’ve helped build some 200 digital products. None was a slam dunk. There was no “we shipped it, and it went wild.” Hell, I’d have settled for “it performed as intended.”

Nope. Not one.

There’s a neat explanation coming from a recent podcast with Eric Ries of Lean Startup fame. Aside from some promotion of his new book, which I guess was the point of the interview, he got asked how Lean Startup fares in the AI era.

The centerpiece of his answer is something that I think still few companies claiming to be lean startups (or Lean Startups) get.

Learning is where the value is. Not the artifact.

In other words, the point of building an MVP is not the MVP. It’s everything we learn on the way.

Subscribe now

Building a Product Is Never a Home Run

As in the Anna Karenina principle (”All happy families are alike”), all the products we helped build that eventually succeeded share the path. It was a long haul of changes, adjustments, discovery, and exploration to eventually find the right ingredients that clicked. And after that whole effort, “clicked” still doesn’t mean getting to millions in Annual Recurring Revenue (or whatever placeholder we now use instead) in months.

If we boiled it down to one meta pattern, it was optimizing for learning. My old mantra all over again:

Try stuff. See what works. Stick with what does. Drop what does not.

We don’t know up front what might work. We can’t know it. It’s unknown and—more importantly—unknowable. If the odds of a home run are but a fraction of a percentage point, what actually constitutes an MVP doesn’t matter at all. What matters is whether we improve our understanding of our surroundings and set ourselves in a better position for another swing.

Learning. Again.

In the Complex Domain Recipes Don’t Work

Cynefin offers a neat explanation why there are no home runs in the startup world. Here’s one of the filters that helps to figure out whether we’re in a complicated or complex domain.

If good solutions to a problem exist and we can scrutinize the problem enough to pick the right one, we are in the complicated domain. We can analyze our way through the issue.

If, on the other hand, we can’t possibly know the course of action unless we start probing the environment around us, we are in the complex domain. We can only play the sense-and-respond game here as we learn the novel environment. There are no recipes that can reliably work in this land.

So where do early-stage startups live? It’s the complex domain all the way. If they were complicated, we would be able to devise a path to success up front. Somehow, I’m not seeing these bulletproof plans turning into anything but a pipe dream. And, believe me, I’ve seen a lot of ‘em plans.

Again, we can’t know what to build from the outset. It’s not building pace that is the constraint. It’s the learning pace.

More Swings, More Hits, Right?

“But Pawel, we build 10x faster now. That’s 10x the attempts and 10x the learning!”

Um, it’s not 10x. Faros crunched the numbers, and the productivity gain is way below 2x. Packaged with deteriorating quality. If there is a more impressive change somewhere, it’s the size of a task. I looked at Lunar data, and the average PR might be more than 3x as big as it used to be. Packaged with deteriorating quality. Different data. Different metric. Same outcome. Coincidence?

Coding musings aside, we talk about two fundamentally different activities. Think of it as a difference between shooting as fast as you possibly can versus practicing to improve your technique. It’s not the attempts that count. It’s whether you score. And you don’t see teams trying to shoot the second they get the ball. One has to wonder why. They’d literally 10x their volume, wouldn’t they?

By the same token, getting another MVP or feature out the door at breakneck speed does virtually nothing to improve a startup’s odds.

Fine, say you can 2x the build speed. You can’t double the traffic by sheer willpower, though. You can’t summon twice as many customers willing to run interviews. Most importantly, you can’t extend anyone’s attention limit. It is the hard constraint.

But you sure can overwhelm said attention with the new feature overload. Break a leg.

The Learning Cycles

One of the useful things introduced by Lean Startup is the Build-Measure-Learn cycle. The gist of it is that you go in rounds. First, you build something. Then, you measure its impact against the expected results. Finally, you draw conclusions that inform the next iteration. Repeat. Over and over and over again.

While Eric Ries explicitly labels one part “learning,” the meta concept is anything but new. In the 70s, John Boyd introduced the Observe-Orient-Decide-Act loop, drawing on experiences from multiple dogfights. Before that came W. Edwards Deming’s Plan-Do-Study-Act method, which in turn built on Walter Shewhart’s Specification-Production-Inspection cycle. That was the 1930s already. Like, when dinosaurs roamed the Earth.

David Campey has another version of it. Idea-Struggle-It Works! It works just as well for kids as for grown-ups when they aspire to learn something. And he calls it the joy cycle. I used Discovery-Development-Validation in the product development context.

While each of these models tackles the issue from a slightly different perspective, the common parts are evident. The cyclic nature. Continuous validation. New insight at the very core. Past outcomes informing new decisions/actions.

These are all learning cycles. Not build cycles.

Do We Optimize for Learning?

Isn’t it curious how consistent the pattern is? Across the century, from Bell Labs (Shewhart), through Toyota (Deming, Ohno), the Air Force (Boyd), to the modern startup landscape (Ries), it’s the same message all along. It’s learning where the value is. Not the artifact.

If we want to optimize for the effectiveness of this process, the crucial skill is validation, or whatever you want to call it. Remove that, and you don’t have a cycle. You just have a Gantt chart of activities, which you can execute one after another. Or all at once.

If the latter was the case, with all the AI capabilities, we’d be golden. We’d just orchestrate a swarm of agents and call it a day. Alas, the problem is not complicated. It’s complex. We need that learning cycle.

And it’s just so easy to get AI to dismantle it.

“People’s ability to evaluate the quality of their own work becomes impaired by using [AI].”

That’s Eric Ries again. The more of the learning cycle we outsource to the tools, the less insight we extract. Hell, it’s detrimental to our learning muscle. It harms us short and long term.

We start with generating code. Soon, there’s too much of it to keep up with the reviews. Not long after, the product work follows suit. By the point where AI writes specs, the game is already lost. It’s a feature factory, not a product startup. We act as if we knew where we were heading when, in fact, we don’t.

We optimize for building rather than learning. We make the wrong trade-off altogether.

The Build-Learn Trade-off

I ain’t a luddite. I don’t argue for AI-free product development. I am genuinely impressed by how much we can achieve with coding agents. There’s no going back to 2020. It’s just that I am painfully aware that code is not a product, and product is not a startup.

If building was all there was, I’d be all like “Outsource the shit out of that to coding agents and call it a day.” But it’s not a Build-Build-Build cycle. It’s Build-Measure-Learn.

We need to rebalance the priorities. It’s like youth team sports. The best teams are not those that win petty games when kids are 10 or 12 years old. The best ones are those that develop these kids into successful professional athletes (and decent human beings, let me add). These goals are at odds with each other.

Winning when you’re 10 means you get the biggest and strongest and let them muscle their way over less physical teams. A couple of years later, these lads and lasses are nowhere near their counterparts who focused on understanding the game, learning the technique, and getting used to the teamplay.

The former is the equivalent of build focus. We muscle our way with increasingly powerful AI capabilities. The latter is learn focus. We don’t take shortcuts in the short term. In the long run, we beat the crap out of the brute-forcers, no sweat.

And those 10-year-olds with an overambitious coach aren’t even winning anything that matters. Save for the coach’s ego boost. Which isn’t something you’d put into your resume ten years down the line.

It’s the ultimate build-versus-learn trade-off. For an early-stage startup, it’s no contest. Learn. Duh!

How to Optimize for Learning?

The big question, then, is what can we do to preserve the learning component of the cycle? Better still, how can we enhance it?

Here’s Eric Ries one last time (I promise).

“The major antidote to this is to be getting real-world feedback.”

Yup, it’s as simple as getting feedback from actual customers and/or users. And no, now that you asked, synthetic personas for running user interviews are not a suitable substitute. You can’t cheat your way to real-world feedback without real-world activities. Bummer, I know.

Again, it’s the same intuitive frame. We put a different label on it, but it’s the same thing. Eric Ries packages it as real-world feedback. Teresa Torres might call it continuous discovery. Johanna Rothman would go with frequent customer interaction. I’d be all about validating relentlessly.

Essentially, figure out how to learn. Build only as much as you need to facilitate that. If you optimize building, the learning will come too little, too late.

Pick your side.

Some sources in this post come from fellow companies operating in the same niche.

The joy cycle comes from David Campey, who runs Afrolabs, which is very much Lunar’s African “brother from another mother.”

The podcast with Eric Ries was run by Kuba Filipowski from Netguru, which might now be in a very different place than Lunar, but we grew from the same root (and collaborated on a couple of projects years back).

If you ever consider Lunar as your product development partner, do consider them as well.

Share

We just went over the metrics dashboard with our client. They predominantly focus on the acquisition funnel, which matters for the product now, but we read the temperature for conversion and retention, too. Finally, we have a compound metric, a.k.a. the North Star metric, that covers a range of customer behaviors.

Then, we have a whole list of product experiments queued up.

The most obvious path forward is to prioritize those experiments, try the simplest prototypes, and see how they affect the metrics. If readings go up, we double down on the idea. If they’re meh or go south, we roll back and pick another thing from the list.

Except it’s not that simple.

Subscribe now

The Metric Liquidity

In finance, we talk about market liquidity. If the market is liquid, it means we can easily buy and sell the asset. What follows, the prices of these transactions are frequently and continuously updated to reflect how the “market” values the asset.

In a similar manner, we can consider metric liquidity. When Amazon deploys a feature to production, they know almost instantly whether it helps or harms their KPIs. Their metrics are liquid.

With our client, it’s not the case. Mere weeks after the initial release, the traction is, well, I’d love to use the word “modest,” but it’s not even that. Week-to-week readings may bounce up or down by as much as 100%. And it’s not because something significant has changed about the product. It’s because of how few data points we’re dealing with.

To stick with the financial market analogy, it’s as if transactions were few and far between. In such a case, the market is not liquid, and we can’t infer much from the most recent price. It might have been a one-off thing. Or it happened too long ago to tell much about the current status of the asset.

By the same token, metrics that are not liquid enough will tell us little about how well a product is doing. Add a game-changing feature, and if there isn’t anyone to notice, the metrics won’t budge.

Timelines of Validation

Fundamentally, the more liquid a metric is, the faster the lead time for experiment validation. Amazon can automatically roll back underperforming features and keep those that positively impact their KPIs. Anthropic can embrace the spaghetti strategy to see what sticks with their users. Netflix famously A/B tests the shit out of everything before settling on what’s the new norm.

For contrast, imagine a fledgling startup with a handful of early users. Unless the idea under scrutiny truly blows up, which happens but is extremely rare, it’s gonna be a long wait till the metrics show traction.

Those 3 new users who used the product a week after we released a new feature may suggest a 38% engagement increase thanks to the new idea. Or it can be a natural fluctuation that tells literally nothing. How do we know? We wait. If the change is real, the traction growth over time will compound and outweigh the natural engagement flux. We will know. Eventually.

Metric liquidity defines validation timelines and available strategies. As much as we’d always like to have short experiment feedback lead times, without enough data liquidity, it’s not an option.

Why Long Validation Lead Times Suck

There’s an important reason to push for short feedback loops whenever we experiment. OK, there are many. Like the fact that humans don’t like uncertainty. We don’t like it all. We actually prefer the certainty of receiving an electric shock to a 50/50 chance of getting away without the painful experience. Curious creatures we are, indeed.

Electric shocks aside, long validation lead times suck in product development because they serve as a pace-maker. We either wait for the outcomes of one experiment before trying another, or we risk the outcomes of different attempts interfering with each other. In the latter case, odds are we’ll have the right change and never know it, buried under lots of other, not necessarily helpful, stuff.

Even more crucially, the outcomes of earlier experiments inform later decisions. It’s the old Build-Measure-Learn cycle from Lean Startup. Skip the “learn” part, and you drive in the fog. You can make one turn or another, but it’s mostly guesswork. Good luck trying to navigate like that, I guess.

When you run a startup, you’re playing against the odds already. No need to make your situation even more miserable by making your experiments random. So yes, long validation lead times suck big time (to use a technical term).

“We Wait” Should Be a Default Strategy at the Earliest Stage

Unless we subscribe to the notion that building a successful startup can be predesigned (which I called the destination hypothesis in the past), the metaphor we operate under is exploration.

We try things, stick with what works, drop what does not. In product development, we learn which is which thanks to validation.

Put differently, validation timelines are really what define how fast we can go at a startup. Those timelines, in turn, are constrained by the traction.

At the earliest stage, we have little-to-no traction, and that’s precisely when we need the most rapid validation cycle. Except that’s not an option. Let me rephrase. It sucks to be an early-stage startup.

We can reverse the picture, though. If the only available tactic for experiment validation is “we wait,” then faster development doesn’t do much for us anyway. We arrive at the same conclusion: development speed is not a bottleneck.

It is not today, when we can generate a ton of code with AI. It wasn’t so in the past either. Even if we acted as if it was.

The Guessing Game

Imagine a game. You’re supposed to guess a 4-digit number. You pay $4 for each try. If you win, you get $5,000.

Alternatively, you can play the same game, but you “buy” each digit separately for $1 each. So you start by trying to guess the thousands digit for a buck. You know whether you guessed correctly before you decide whether you want to “buy” the guess on the hundreds digit. And so on.

Which version would you play?

Obviously, the latter. Duh! It splits one big decision into four separate small calls, where each informs the following ones. If we miss the first guess, which is likely, we save ourselves $3 and stop trying.

We play the same game with our product experiments. That is, save for the fact that most companies claim to choose the second variant, and then don’t wait to learn how the small bet went and commit to the following ones right away.

The rationale is along the lines of “we have developers, and we need to keep them busy.” It’s like betting again before we even know how the last one landed. That’s a compulsive behavior of people with a gambling problem.

Also, a default in the startup world.

Validation Has Been a Bottleneck All the Way

When we consider the relationship between metric liquidity and validation lead times, it is clear that the effort required to build an experiment doesn’t materially affect the picture.

We should, in fact, subordinate development effort to the pace of experiment validation, and not vice versa.

Interestingly, our client, who I mentioned earlier, has done precisely that. Once the MVP went live, instead of speeding up, we slowed down.

We could now be adding stuff like there’s no tomorrow. After all, there’s no shortage of ideas. But it’s not a casino, and we don’t try to lose our life savings. Our context is way less movie-worthy product development. And we understand that it’s not building that’s a bottleneck. It’s validation.

It has always been so.

Share

I admit, I was surprised by how popular my recent post on assumption mapping got. In the spirit of experimentation, let’s check whether it was the assumption mapping itself that got the attention or product discovery tools in general.

Another useful one from our exploration toolbox is a user journey map. This one tries to emulate the end-to-end customer experience with the product. Let’s dissect it, then.

Subscribe now

User Journey Map: The Basics

Typically, we enter user journey mapping with a persona in mind—a very specific functional character who might have used the product. The whole journey is supposed to be theirs.

Then, we start mapping. It usually follows a similar pattern:

• First, there is a need the persona is trying to fulfill

• Second, they look for and discover solutions that can respond to that need somehow

• Third, they have the first interactions with these products

• Then, they actually use one of the solutions to satisfy the need

• Finally, they might become repeat customers, and that might unveil new ways of interacting

• Optionally, they might even refer the solution to others

Note: depending on a product, the stages of the journey may differ. The important part is that it’s not just a one-time interaction with the app, but a broad context. Think of it like, “From realizing a need to telling your friend about this new product you’ve been using recently.”

For each of the stages, we analyze how it is handled right now. Considering the alternatives we know of, how does our persona solve their problem? How do they discover available options? How do they use these products? How well do said solutions respond to the needs? Etc.

We answer these by defining interactions between the persona and the solutions they currently use. Once we have that, we assess the persona’s experience. Is it good? Bad? Are they frustrated? Would they come back?

The experience quality is the vertical axis. The better the customer is served by existing options right now, the higher up the relevant interaction goes.

Key Insight: The Shitty Outliers

The insight we generate during the exercise is at the intersection of generating observations (here: user interactions) and assessing them (here: experience quality).

As usual, most of the landscape is not very interesting.

With user journeys, the key part is the bottom. Whatever is a crap experience for the persona right now is a potential differentiator for the new offering.

In fact, it’s worth double-checking anything that ends up here. Same as with assumption mapping, the question is: What evidence do we have?

Note: It is counterintuitive. We want to confirm people have a problem and are actively solving it with a product. This suggests there might be problem-solution fit. We want to confirm that they’re satisfied with the existing products enough to pay for them. This hints that product-market fit is not off the table. And yet, we want a part of that experience to be shit. Otherwise we may not have a shot at the market. It’s not unusual for us to contradict ourselves during the exercise.

The outcome—the shitty outliers—is what we zero in on. Typically, we’d design experiments to confirm or refute our assumptions that they are, in fact, sources of frustration.

Once we have strong supporting evidence, the shitty outliers direct the early development process. We want to build the experience with the new offering around one of them.

User Journey Mapping Example

Do you remember our product idea for a recruitment marketplace that attempts to circumvent AI slop in hiring? Let’s simulate a user journey for it.

Our persona might have been Jeanette. She’s 26, has less than two years of experience as a developer in a second-tier tech company, which she didn’t like, and has just been laid off.

1. Jeanette’s problem is straightforward. She needs a job. Preferably less toxic than the last one.

2. She checks LinkedIn and job portals, like Indeed, Glassdoor, or Dice, to find relevant openings. Glassdoor may be preferable given its history of reviews that touch culture, which seems important to Jeanette. All of these are known options, and even if not, a simple search would yield the comprehensive list.

3. Not all these places offer the actual “first interaction” to Jeanette, but there’s always registration, resume upload, available positions search, and what have you. Boring. That’s neither new nor surprising by any means.

4. The big issue for Jeanette is not finding a job listing, though. It’s finding a job. Save for some fringe matching features, job portals largely serve as a bulletin board. And however they streamline application process, a candidate will still land in the AI filter of hiring companies. Given the discrimination against women applying for junior tech positions, Jeanette is up against long odds. Heck, even when she finds a few openings where she feels she really fits, there’s zero way to let the recruiters know about that.

5. Ironically, Jeanette is a recurring customer, as she struggles to land a role she expects. She’d very much like not to come back. At least for the next couple of years.

6. The only reasons to prefer one solution over another—and thus recommend it—would be better eventual chances of landing a decent job. Right now, the closest proxy is the number of relevant job openings each portal offers, but that’s a weak signal, given how often applications are outright ignored.

Depending on which service we consider, specific stages may shine more (Glassdoor for employer reviews, LinkedIn for the largest network of job listings). In practice, Jeanette will likely use several alternatives concurrently, so we can average it out.

The journey clearly identifies the low point. All the platforms are doing OK with listing the job openings, but they fall short when the measuring stick is whether a candidate lands a job. That’s, by the way, why we start with the problem definition. Jeanette doesn’t want to read job ads. She wants a job.

When we look at things with that in mind, the shitty outlier is painfully obvious.

The Weak Point

So far, so good. The user journey pointed us the right direction. The problem, though? Shaky foundations. As popular as they are, I’m not a raving fan of personas. They create a fake sense of specificity. I mean, how many Jeanettes, age 26, looking for a job after a layoff, do you actually know?

Choosing Jeanette over Karl, age 35, aiming for another career upgrade, was an arbitrary decision. Same for ignoring Jordan, age 22, hoping to land the very first job.

Still, the actual speculative nature of the exercise lies in how we assess each interaction. We know some things. Early-career workers face an increasingly challenging job market. The experience of applying for a job evolves into a fire-and-forget activity—we don’t count on any answer whatsoever .

Jeanette’s frustration, though? Is it real at a scale, or just anecdotal? Do we label someone else’s experiences as crappy only because we disliked our own? Would Jeanette be perfectly fine once the job market improves and there are some more relevant openings?

We Know a Lot (Also, Not Enough)

A go-to answer to the emerging questions should direct us toward finding evidence. How do we know that? How can we support the claim with the data?

Unfortunately, we’ll find evidence to, well, pretty much prove whatever we want.

“Taylor said, he has applied for 5,762 tech jobs. His diligence has resulted in 13 job interviews but no full-time job offers.”

Oof, that’s tough.

“Got a lot of responses from cold applications for AI roles, and ended up with two offers at AI infra companies. I ended up getting a significant pay bump beyond what Apple offers for the same level!”

Wait, wasn’t it tough?

“Mark Zuckerberg reportedly offered Andrew Tulloch, an AI researcher and co-founder of Thinking Machines Lab, a compensation package worth as much as $1.5 billion over at least six years. Tulloch turned down the offer, but plenty of others have taken the money and joined Zuckerberg’s tech giant.”

Oh well…

So, the job market is either shit, or fine, or booming, depending on which story you pull.

And that’s all just “adjacent” data. We can infer some things about the job-seeking experience (it sucked for Taylor, it was a breeze for Tulloch), but how far can we generalize these stories? We sure are inclined to consider the data point that supports our belief and discard the other. But that’s just our confirmation bias speaking.

It’s All Opinions Anyway

Aside from the overabundance of data points, the challenge in assessing an imagined persona’s interactions with products is twofold. First, we try to measure experience. It’s much more intangible than reseatching how many people seek jobs these days. We often end up relying on anecdotal evidence here.

Second, the information that would actually be valuable is hoarded by product companies. I mean, LinkedIn has a ton of data on how job seekers use their app. They can infer at least some things about the experiences. But forget about them sharing it with the world. That data is one of the sources of their competitive advantage.

That is why the assessment phase of user journey mapping will often boil down to exchanging opinions. The persona was speculative in the first place, and now we speculate how they would act.

There are two tricks you can use to limit the negative impact, though.

1. Agree on what counts as evidence before researching it. For example: “We don’t count stories as a valid data point, since frustration will clearly be overrepresented. We rely on quantitative sources only.” While it will improve the outcome of the activity, it would also make it significantly longer.

2. Alternatively, accept the biases and go with intuitions. Especially if there is some alignment among people doing the exercise. It is discovery, after all, not an exact science. We don’t try to commit to a multi-year development effort yet; we just plan a few-week-long product experiment.

Also, after helping with more than a hundred startups, my experience suggests that it takes more than pulling research data to discourage a founder from trying out their product idea. No matter how much we try to “fail” at every other discovery, we will likely end up building something anyway.

User Journey Mapping: The Focusing Exercise

So is it useless, then? Hardly. User story mapping shines when we seek focus and alignment.

We predominantly use it as a convergence tool when we’re still in the problem domain of the double diamond. By this point, we know who (the persona) needs what (the problem), and try to find the best leverage point (the shitty outlier) to focus on one thing at a time.

The neat trick we play with the user journey map is the “there be dragons” part, which is everything we don’t need to care for right now.

While we spend much discussion time on a couple of candidates for shitty outliers, the important part is what we leave out. That’s the whole point of user journey mapping: knowing what to ignore.

More on product discovery tools:

Share

When you read about early-stage product development and product ideation, there are two main approaches. The boomer camp is still strong. They’d keep repeating the old agenda: do your discovery first, validate before you build, all that Lean Startup stuff, yadda, yadda, yadda.

That makes me a boomer, I guess. Oh well...

The other path is all about “building is cheap now,” so it’s an entirely new game. Working software is but a few prompts (and a boatload of tokens) away, so let’s turn all the ideas into products and see what works. We might have been doing this whole exploration and discovery thing only because development was expensive, but guess what: it’s not anymore.

Coming from the boomer camp and bringing way more than a decade of experience in product development, I may have a strong conviction about which one is better. Yet it doesn’t stop us from experimenting with both paths. In fact, that’s what we do for a living at Lunar.

So maybe it is the moment when we change our ways or go extinct?

Subscribe now

The Spaghetti Strategy

Amazon has been known for decades for encouraging experiments in production. Engineers could try an idea, see how it affects the KPIs, and if it worked, it would stay in production.

That’s spaghetti strategy. Throw spaghetti at the wall and see what sticks. These days, Anthropic—and the Claude Code team especially—exemplifies that culture. They build a ton of stuff, put it out there for people to see, and learn what works. Keep what does, revert or fix what does not.

No matter what anyone thinks about Anthropic’s financials in general, it would be absurd to deny that Claude is a wildly successful product. So is Amazon’s storefront. It’s no wonder the spaghetti strategy finds followers now, since one can try it without literal billions in one’s coffers.

Better still, we have an entire cohort of AI startups whose ambition is to streamline that kind of work. Lovable, Replit, Bolt, and the like.

The Build Economy

The reality Lovables of this world want to create is called the build economy. As the story goes, now anyone can build a product. You don’t even need tech skills. Plain English and a Lovable subscription are enough. The rest will be magically taken care of by AI.

Of course, to eventually make a product successful, one needs to build many of them. The promise is there, though.

A side note: It’s actually in Lovable’s interest to land a working product in the latest possible attempt, i.e., the very last before someone finally gives up. After all, they get their revenues when people keep trying, not when they make it.

Wicked incentives aside, Lovable et al are on a mission to enable everyone—especially non-technical people—to build their products. If we trust their numbers, they’re damn successful so far. That would mean that the build economy is the future.

But is it?

The Story Lovable’s Numbers Tell Us

When we look at the self-reported numbers from Lovable’s build economy report, the interesting part goes beyond “annualized ARR” (which is the 2026 version of rose-tinted glasses).

According to their own claims, Lovable sees 720 million monthly visits across all the projects created by their tools. Color me impressed.

I mean, unless we account for the fact that it’s spread over some 50 million apps. That’s like a single, lone visit every other day per app on average. Sure, it’s better than the 3 pageviews per app they reported last year. Still, how many online businesses can survive with just a handful of visits a month?

I speculate that using an average doesn’t tell even half of the story. It would be interesting to know how many monthly visits a median Lovable site gets. And how many of them can you expect if you’re, say, in the 90th percentile?

For all we know, we should expect the averages to be heavily inflated by a small number of popular apps. If so, it makes the long tail really long (and really sad). Put bluntly, there are tens of millions of Lovable apps no one uses.

The Products No One Needs

OK, I know, the Lovable visit distribution chart I drew above is entirely speculative. Yet, it’s not like I pulled it out of thin air. We see the same pattern everywhere we look.

A recent paper from the National Bureau of Economic Research mirrors this dynamic. We release more applications, but the total number of reviews and downloads is either stale or declining. Do the math.

Steam data paints a painfully similar picture for game dev. About half of the games receive fewer than 10 reviews. If you’re a developer, that’s like not even friends and family caring about your game.

The sad long tail becomes longer. And sadder.

These are products (apps, games, websites, SaaS, etc.) that no one needs or cares about. Yes, we can build them—and we do—but is there really a point?

Wasn’t Spaghetti Strategy a Good Thing, Though?

“Make up your mind, Pawel. First, you tell us how the spaghetti strategy is fabulous for Amazon and Anthropic. Then you go all doom and gloom, no one will use our products, and stuff like that. So which one is it?”

Both actually. Spaghetti is, indeed, a smart move. That is, as long as you already have a ton of active users who can tell what sticks and what doesn’t. Remove the traffic, and you remove any meaningful signal.

And no traffic is precisely where all these vibe-coded products are. They threw their spaghetti on the wall, but it’s a pitch-black night, and the power is off. Even if something indeed stuck, there’s no way of telling. And all they can hear is to keep tossing. It’s how “build economy” works.

As much as Lovable would want us to believe otherwise, it’s not the Mom and Pop SaaS era. Those few success stories that will inevitably emerge are just a hook. It’s the story about your neighbor winning a lottery. It’s uplifting and all, but it doesn’t make playing the lottery a smartass move.

Build It and They Will (Not) Come

The lottery-winning dream is an iteration of the old ”build it and they’ll come” approach. Except this time, it’s on damn steroids.

In the 2000s, when you had built it, and they did not come, it was a gut punch. You would take a break after a major failed effort. Like one big night in Vegas—all in, nothing to show for it. You don’t become a repeat customer.

Today, it’s like slot machines. It’s easy. It’s cheap. Except the game is as rigged as before. You spin the reels. Nothing comes out. So you do it again. And again. And again. Having a product “out there” was never a winning tactic. Having a product that a slot machine next door can deliver just as fine is even less of a home run.

That is, unless it’s you who builds slot machines.

Build Economy Works Fine, Just Not For You

Statistically speaking, any product started today has lower chances of succeeding than its counterpart from the 2000s. We reiterate the same broken patterns, but since we removed the entry barriers, more people are trying their luck.

Again, we have more apps, but the overall usage metrics are stale. Math is not mathing here. And it’s no wonder. It’s the customers’ attention pool that is the hard limit of this game. We won’t have more hours in a day to spend on new things. We won’t have billions of new people getting their internet-connected devices. For something to get in, something else has to go out.

Yet, there are players for whom the build economy works brilliantly—the slot machine operators. If the message that everyone’s now a builder catches, and if said builders try over and over and over again, the revenues keep flowing. The fact that the game is rigged against the builders makes it even better. Who wouldn’t want a repeat customer?

In that sense, Lovable et al are very much like Uber. Not in the sense that huge investments and a very long time to profit will finally pay off. They're similar because what they promise and what you actually get are two different things. Also, their incentives are the exact opposites of those they serve.

The gig economy didn’t make it any good for the gig workers. The build economy won’t do any better for the builders.

Share

At Lunar Logic, we often start working with founders who are still at the pre-development stage. We typically get them through the discovery phase before we commit to building anything. Every other time, it ends with abandoning the development.

One pivotal part of any discovery workshop we run is assumption mapping. It’s also my favorite part. The reason is simple. No matter how much the founders claim they verified their idea, we always uncover new, interesting stuff. “Interesting,” as in: if not true, then the whole business doesn’t make sense, and we can find evidence whether it’s true or not.

Subscribe now

Assumption Mapping: The Basics

Assumption mapping originates from Lean UX and was popularized by David Bland. It starts with considering the idea from three aspects: desirability, viability, and feasibility. Each answers a different question.

• Desirability covers whether people want a specific solution. It is front and center when we consider problem-solution fit.

• Viability answers whether we can build a sustainable business around the idea. It is a focal point when we search for product-market fit.

• Feasibility is all about whether we can technically build the thing. Depending on the idea, it may be the critical or largely ignored part. Or anything in between.

For each of the trio, we brainstorm statements following the pattern: “We believe that...” For desirability, it would be variations of saying that we believe people would want the thing. For viability, different ways of stating that people would pay for it. Etc.

These are our assumptions. Note, they should be specific and narrower than “we believe that people will want our thing and will pay for it.” Also, brainstorming means generating ideas beyond the usual suspects. Finding non-obvious beliefs is the whole point of the activity.

“What gets us into trouble is not what we don’t know. It’s what we know for sure that just ain’t so.”
Mark Twain

The biggest risks for a startup are not the things that instantly come up when a founder is asked about them. It’s what’s below the radar. Stuff that we subconsciously assume must work, while reality might have other plans for us.

That’s where the last part of assumption mapping kicks in. We sort the ideas using a two-dimensional space. One axis is evidence. If we already have a lot of data that backs up the belief, the item goes one way. If we don’t have the data, it goes the other. I like to frame it as the uncertainty axis.

The second dimension is importance understood as “How fucked up would we be if this thing ain’t true?” The axis goes from “whatever” to “we’re toast.” Think of it as Mark-Twain-o-Meter.

Once you’re done sorting, you’re looking at the priorities for your exploration. Whichever items end high on both the uncertainty scale (no data to support the assumption) and Twain-o-Meter (we’re toast if it ain’t true) are the first to be validated.

Hiring Is Broken or a Practical Example of Assumption Mapping

Let’s take one idea that we’ve recently worked with. The underlying observation is simple. Hiring is broken. AI has removed the remaining ways to convey care between a candidate and a hiring company, or vice versa. It’s increasingly a game between one AI agent (mass-sending generated resumes) and another (filtering out 95% of applications before any human can even see it). Can we create an experience for both candidates and hiring companies that would sidestep this reality altogether?

It would be a service where a candidate can send a “I genuinely care about this particular job” signal. A hiring company, in turn, would be inclined to get such an application directly to a human recruiter, bypassing the AI filtering plumbing. In other words, if there was such a marketplace, both parties would (hypothetically) benefit.

So let’s look at some examples of assumptions behind this idea.

Desirability

Desirability considers whether people want a specific product, solution, or offering. Again, think in terms of problem-solution fit. Sample beliefs will thus be as follows:

• We believe that job seekers genuinely care about some jobs much more than others.

• We believe that job seekers would attach a “token of care” to an application for a job they care about, given the chance.

• We believe that hiring companies would prioritize applications from candidates who care about the job over an average submission.

• We believe that, in the current hiring landscape, candidates have lost an opportunity to convey information that they care about a particular job.

• Etc.

Viability

Viability, in turn, considers whether we can build a business around the idea. Think: product-market fit. We could generate the following assumptions:

• We believe that candidates would be willing to pay a modest amount to show care about particular jobs if that circumvents the standard filtering process.

• We believe that hiring companies would see value in information about candidates’ care, and thus would pay extra attention to such applications (e.g., routing them directly to a human reviewer, providing feedback, etc.).

• We believe that there is enough traffic in recruitment that a service relevant only when someone seeks a job would sustain itself.

• Etc.

Feasibility

Finally, feasibility considers whether we can reasonably build a solution. In this case, it’s yet another marketplace. Nothing super-fancy. But let’s give it a go:

• We believe that we are able to build “yet another marketplace.” Duh!

• We believe that we are able to integrate with many existing systems to reduce the hassle for interested hiring companies.

• We believe that we will be able to handle the law specifics in all the markets we want to operate in.

• Etc.

Where Uncertainty Meets Twain-o-Meter

If you consider the assumptions above, some of them strike you as obvious. I mean, we definitely can build another marketplace (1). We’ve built like a couple dozen of these in the past two decades. We have the track record. It definitely scores low on the uncertainty scale.

The opposite example may be the belief that the candidates have lost an option to convey a signal of care (2). In the past, they could do something extra with their resume, and it would grab a recruiter’s attention. I still remember one of the candidates drawing a comic as her application (and yes, she got the job). By the way, cheers, Olga, if you are reading this.

Anyway, what if the assumption ain’t true? What if candidates still have ways to send a token of care to companies that offer jobs they particularly well fit? Are we toast? Not if the new solution offers them a convenient way to send a signal of care (which also, conveniently, doesn’t require anyone to draw a comic). Twain-o-Meter doesn’t go red here.

But what about candidates willing to chip in a modest sum to send these tokens of care (3)? If they don’t want to pay, we might have a solution, but we don’t have business. Mark Twain says “trouble.” And since such behavior is definitely not the norm on the job market now, there is little, if any, evidence that it’s an acceptable idea. Uncertainty is very high, too.

Same with hiring companies being open to circumvent their newly acquired tools that filter out 19 out of 20 incoming job applications (4). It’s too early to have significant data samples of the usage of these tools (high uncertainty/little evidence). And if it ain’t true, we don’t have much of an offering to job seekers (Twain-o-Meter goes high, as well).

Whatever gets highlighted on both accounts is a sure-shot candidate for further exploration.

We Know More Than We Think

One of my favorite quotes comes from Douglas Hubbard’s How to Measure Anything.

“You have more data than you think. You need less data than you think.”
Douglas Hubbard

I often misquote him by saying, “You know more than you think you do, and you need to know less than you think you do.” Either one should be a motto of the part that follows assumption mapping.

During assumption mapping, we’ve just identified the beliefs that:
a) Will kill the product idea if they’re not true.
b) And we don’t have much evidence whether they actually are so.

The most sensible course of action is to find a way to get the data and either prove or disprove the underlying assumption.

In Douglas Hubbard’s spirit, there’s a lot of data that’s accessible. Even if it’s not readily known, it’s knowable upon research. Then, there are user interviews. I mean, who hasn’t looked for work at least once? We definitely know people who are looking for one right now. Hell, we are a hiring company, too. There’s a ton of knowledge readily available, given some effort to tap into it.

A side note: for assumption validation, you don’t want to have an AI persona for a user interview. A chatbot, even with the best of prompts, will unlikely be accurate when hypothesizing about actual future customer behaviors.

Finally, there are plenty of low-cost experiments you can run, ranging from landing pages to clickable prototypes. That’s where AI capabilities—and vibe coding specifically—absolutely shine.

We know more than we think. And even when we don’t, it’s easier to know than we think.

Assumption Mapping 101

If you want a cheat sheet, assumption mapping is three things.

First, we consider three aspects of a product idea:

• Desirability. It answers: Will people want it?

• Viability. It answers: Can you make money with it?

• Feasibility. It answers: Can you deliver it?

Second, for each of those, we brainstorm assumptions. All sorts of things we believe are true and that are critical to product success. Note how the vantage point changes what assumptions we generate.

Third, we position each assumption in a two-dimensional space.

• Uncertainty indicates how much evidence we can instantly produce to prove an item at hand is actually true.

• Twain-o-Meter tells us how fucked up we are when the thing we believe is true ain’t so.

Whatever lands high on both axes is a candidate for further exploration. This is input for the validation effort. Or, more likely, the invalidation effort. Everything else is largely uninteresting. At least for the time being.

No magic here. And yet it’s one of the most insight-generating activities you can run at the exploration stage of any product.

If I were a VC partner, I would literally expect a quick assumption map walkthrough as a part of any pitch.

More on product discovery tools:

Share

The default startup dream is to hack an idea, get some early interest, secure funding (preferably a fat round), and grow like hell till you become a unicorn while seeing the VC money pouring in.

That’s the dream the VC fueled for decades. That’s also what most startup success stories are. No wonder so many founders default to such aspirations.

AI, if anything, made the whole cycle shorter and growth even more rapid. Last year, we were following Lovable’s race to become the fastest-growing startup ever. We’ve seen obscene seed rounds given to AI celebrities. Everything has become even more reckless.

The basic pattern has remained the same, though. Grow fast. Secure a ton of money. Do and say anything to make the previous two possible.

Subscribe now

A Warning Tale of Icon

I first became aware of Icon, the ad-making company, early in 2025. It was at the top of the wave of founders one-upping each other on who expects a longer workweek from their employees.

Kennan Frost (then using the name Kennan Davison) outbid everyone, saying that ”996 (working 12 hours, 6 days a week) results in defeat. Why do 6 when you can do 7.”

That couldn’t have possibly worked. TL;DR: It didn’t.

I could argue that the reason was the plain toxicity of the work environment Frost created. I bet it played a role. Yet the pivotal thing was the product that was all hype and little value.

The Rise and Fall of the Hype Cycle

It took one viral video to trigger some early traction. Once you have that, sprinkle AI all over the place, and you’re the next nugget. The hype wave lifts you instantly.

I have zero reasons to believe Kennan Frost’s numbers (he claimed $5M ARR in the first month; see above). Yet even if they were roughly correct, they would translate to around 400 early sign-ups. Definitely a success, but far from proof that you’d make a hundred million a year in record time.

Especially when you can’t deliver the value you promise. And the promise was huge. It was literally creating multiple high-quality ads from a prompt. I doubt Anthropic would have been able to deliver on that promise a year ago. Hell, I doubt they’d be able to do it today.

The value-promise gap will bring the hype wave down as rapidly as it rose in the first place. No amount of borrowed Peter Thiel’s authority, ego projection (I really regret that I didn’t save this creepy video with competitors bowing before Icon), retweet counts, or made-up numbers will create tens of millions of dollars in revenue.

And the value wasn’t there. The videos looked robotic. Copy was bland. The outcome missed the human touch. Not to mention that OpenAI shutting Sora down would likely be a grave blow, even if everything else worked fine.

Validation Doesn’t End with the First Hundred Customers

Once the initial “AI admaker” business turned out to be way beyond Icon’s reach, they pivoted. And the pivot is actually the most hilarious thing in this story.

With their 2025 ride, Icon learned enough about their domain to change the plan and become the very thing they wanted to disrupt—a human admaker. You have to pardon me for the Star Wars reference here.

I guess the new business doesn’t require developers working around the clock, 7 days a week. It won’t make hypergrowth possible. Most of all, a $12M domain bill now looks way more than extravaganza. It looks dumb.

Oh, and I don’t think this pivot will survive either.

Sustainability Is the Game

As comical as it is to watch these overhyped startups kick the bucket, there is always a lesson to be learned. In Icon’s case, at no point in their story was there any sign of sustainability.

• The first few hundred customers do not guarantee more will come.

• The first months of subscriptions do not guarantee it will be recurring.

• The first round of funding does not guarantee any further investments.

• The first wave of hype/virality does not guarantee regular followers.

Yes, we see companies rise at an unprecedented pace (Lovable, anyone?). But these are outliers. And even then, I’d default to betting against them, since everything they share is about growth, not sustainability.

A smart startup would first track sustainability metrics:

• Churn rate

• Customer lifetime value to customer acquisition cost

• Time to profit

• Future plateau

• Runway length

If they show red and the trend line does not show a path to green, no amount of hype and early growth will fix it.

And yes, I know that it’s not advice you’d hear from a VC. They care about growth dynamics, and annual recurring revenue (ARR) is their psalm. In case you asked, they also want your startup dead. Statistically speaking, that is.

In an early-stage startup, you can hardly do wrong optimizing for sustainability metrics. It’s what guides a founder from default dead to default alive.

Don’t Be Kennan Frost

I don’t have any doubts—Kennan Frost will have a soft landing. Yet, his third startup (after a successful exit with Skio and the Icon disaster) will not have an easy path to securing funding. Not on pure charisma. That is, given that he starts another company.

A funny thing is that, with the $9M+ he raised for Icon, he could still be working to make the company a survivor. Success even. He would have needed to navigate primarily with a sustainability metric, rather than an ego and hypergrowth illusions.

So don’t be Kennan Frost. Care for the sustainability of your startup. In the long run, your ego will thank you for that.

A side note: that viral video that has been proven bogus is but the remaining bit of the original Kennan Frost’s content that’s still online. I guess the ego doesn’t give up that easily.

Share

Written by an actual human. This one with a lot of rework.
웃 https://okhuman.com/tbfMEA

I stumbled upon this neat idea: Mom-and-Pop SaaS. Since AI allows everyone to build a digital product, we will increasingly see non-technical people launching SaaS solutions in their respective niches.

“Get ready to start seeing (and hopefully building) more and more products from unexpected places. This will be software built by local experts with limited technical experience, but way more experience in everything else.
I call this Mom-and-Pop SaaS!”

Elena Verna coins the term in her recent article. It may not be surprising at all that she serves as (Head of?) Growth at Lovable. Everyone building their own app is precisely what Lovable would love to achieve.

The picture she paints, though, is vastly oversimplified.

Subscribe now

Generating a SaaS Is Not as Easy as It Sounds

For the sake of this argument, I’d be happy to assume that Lovable’s promise—that we can perfectly vibe-code a production-ready solution—is true. I haven’t checked their capabilities recently, but surely the models behind have become more capable. Also, they work hard on improving the abstraction layer they deliver.

Yet, as I said multiple times, code is not a product, and a product is not a startup.

A good question is what “product” a non-technical person will prompt. I’ve spent more than a quarter of a century in the software industry, and one pattern does not change. Customers primarily think in terms of function.

They want features. They envision what software will do and... well, that’s it. OK, those with their careers in creative industries may also be overly picky about some design aspects (typically the wrong ones). The vast majority of insight and concern goes purely to function alone. And it ends like this ↓↓↓

The website above served its function to the best of the business owners’ understanding of tech (none, in fact). Obviously, we could beautify it or make it look modern, and it still wouldn’t do any better.

Successful software is way more than pure function.

Some of Them Will Get It Right

The further argument is that of the numbers. Get enough people flailing around with their ideas for digital products, and some of them will get it right.

Meccha Chameleon was built by 2 developers in a couple of months. The game took Steam by storm. It has sold more than 7 million copies in two weeks. Everyone’s in awe. It’s possible! If it was a SaaS instead of a computer game, it would be a poster child of Mom-and-Pop SaaS.

No one mentions more than 20,000 games released each year on Steam. Half of them get fewer than 10 reviews. That’s literally no one caring beyond developers and their families (and not even the whole families). The message is “You can do it! You should try!”

“[Opportunity to build a SaaS] literally didn’t exist for most people, a few years ago. Devs could do this as a side hustle (and a lot of them made bank doing exactly that), but now’s the first time that all of the millions of people like you and me can realistically turn their expertise into products.”

That’s Elena Verna again (emphasis mine). “You can do it! You should try!” Indeed, if “all of the millions of people like you and me” try to build a SaaS with Lovable, a few of us will succeed. By the same token, if we all play the lottery, someone will hit the jackpot.

A side note: “a lot of developers” hitting a jackpot by building a startup as a side hustle is an outright lie. Many could have tried. And largely they failed. Stories such as Mailchimp’s are few and far between. Startups that do survive are predominantly those where founders have only one gig, and it is the startup.

Is Vibe-Coding Sustainable?

My argument against the Mom-and-Pop SaaS considers the long game. Any developer would tell you that getting the first version out is the easy part. No customers, no expectations, no ongoing commitments, no submitted issues to fix, no feature requests, no nothing. When you break something, no one cares. When you remove something, no one complains. Simply, there is no one to care or complain just yet.

Once you get the first revenues, the game changes. It is a commitment. If adding a thing breaks an existing feature, it’s suddenly a problem. If people stumble upon a bug, it’s a problem. Heck, if you don’t add things customers want, that’s a problem, too.

Even when everything works fine, software requires maintenance. Tech stacks evolve, and old versions are discontinued. Security patches are a thing (and an important one). Every now and then, APIs and integrations need attention. Backward compatibility is (sadly) a 20th-century thing.

Only a month ago, one of our clients came back with some bug fix requests for their old product. The main issue? The whole thing didn’t build anymore. It run a tech stack so old that Apple stopped supporting it. A simple bug fix turned into a big technology update.

Long story short, software will break. And it will require attention. From a non-technical Mom or Pop, no less, who happens to have no idea what’s happening and why. Oh, and all that at a moment when they’re 100% focused on running their small business. It’s the “oven breaking in the middle of baking a pie” kind of experience. Except it’s not a pie at stake but someone’s business.

We won’t be seeing loads of new products taking over businesses from incumbents, even if it was possible to generate them. We will go back to the existing proven solutions (and subscriptions) simply because it’s someone else’s business to keep the lights on. Mom-and-Pop’s small business doesn’t need its own SaaS. They need the lights on.

Lovable Is Not Shopify

To argue for the “small SaaS” revolution, Elena Verna points to a recurring pattern. In the past, the emerging tools helped to create new waves of businesses. Shopify streamlined e-commerce. YouTube made independent video publishing accessible. Airbnb enabled people to rent their properties.

All true. Yet, in all these cases, the responsibility for tech was elsewhere, i.e., it wasn’t on Mom and Pop's plate. Airbnb cares for its platform to work, and for your listing to be up. Shopify’s business depends on its clients not having their e-commerce randomly break. Etc.

Lovable? It takes zero responsibility for your vibe-coded SaaS to work. It rents you code-generation infrastructure for the time you need to generate code. It doesn’t offer ongoing maintenance services for whatever you created with it. That’s fundamentally different.

If Mom-and-Pop’s listing at Airbnb breaks out of the blue, it’s Airbnb’s problem. If a Lovable-generated Mom-and-Pop SaaS breaks, it’s Mom and Pop’s problem.

Thanks to AI, There Are New Viable Business Scenarios

Now, I don’t want it all to sound overly critical. There are scenarios where AI software generation capabilities make the impossible possible. One of my business acquaintances used to say that if you don’t have $100k-$200k, then don’t even dream of starting a SaaS.

I would challenge these numbers today. Early prototyping has become so much easier. My friend, who has spent his whole career in product management, argues that we should now build ideas before we evaluate them (he calls it option storming). Bootstrapping has become more viable.

So yes, a business idea that requires software has become more affordable, at least at the early stages. Which means that we can explore less lucrative, niche scenarios. Curiously, as Elena Verna notices, that’s not our standard startup dream.

“The whole VC-industrial complex trained all of us to believe that every software company should pursue literally world-changing outcomes and 10-figure exits.”

Spot on. VC is broken, indeed. It has always been so. I genuinely believe we’d be better off abandoning the VC path as a default one for startups. That, however, would also mean abandoning the aspiration to “strike it rich” as the primary goal. The hypergrowth aspiration, after all, is all fueled by VC greed. Luckily, that was never Mom-and-Pop’s agenda.

Still, if we consider small businesses, they will be served by niche product developers who understand Mom-and-Pop’s landscape and will be happy to take end-to-end responsibility for keeping the lights on for such a small product.

That is, unless said product developers dream about hitting the jackpot. The dream that we were fed for decades. I guess we shall see soon.

Share

I write these myself. Seriously. 웃 https://okhuman.com/60N9vw

Some half a year ago, I wrote that 2026 would be a year of scarce startup financing. The piece was based on a few simple arguments.

• VC fundraising slowed down

• Average deal value went up

• Whatever funds were left in the system got cannibalized by the insatiable hunger of the major AI labs

What follows, everyone else had to be starved for money. Yes, that’s an average Joe’s startup. Read the whole argument here.

I just got to see the other aspect of this situation. One not based on the statistics, but an individual story. Your “average Joe’s” story. A startup we work with has just closed the first round of financing. I should probably say “pre-seed round,” but these terms become increasingly blurry.

They secured around $1.5M. Quite good for a pre-seed round, I should say. So maybe my predictions were all wrong?

Subscribe now

Things Take Longer Than You Think

If there was a theme in this story about the startup securing funding, it would be the old observation that things take longer than we expect.

• It was around 9 months from the start to the first round

• The pre-pre-seed phase cost more than twice the planned amount

• The capability to shoulder the extended runway was the make-or-break

Sure, if I gave you the full story, there would be standard bits about unexpected issues emerging everywhere else but the development, pivots (but only after building too much), and falling in love with one’s ideas. These are all the usual suspects. We have accounted for these and tried to prepare the founder as well.

Still, the fundraising was a pain. It was so, even though the founder is well-connected. And they checked almost all the checkboxes on the list. The product is AI-native. The market is established. The business case is sound.

If I looked for downsides, there are just a couple of things. It’s not a billion-dollar idea. Or a trillion-dollar idea, I should say. The founder is not an AI celebrity either.

Realities of 99% of Startups

The thing is, such stories will not get you TechCrunch coverage. The media will focus on Anthropic’s next mega-round or a billion-dollar seed round for another AI startup. Except that’s not the world the vast majority of startups live in.

Most of us live realities with three zeros fewer in any number that gets exchanged. And no press coverage whatsoever. Few people care about whatever we’re doing, and even fewer would consider throwing any money at it. Well, welcome to the startup world. It’s anything but what the ads said.

In our world, we hope for hundreds of thousands in a pre-seed round, not hundreds of millions. Even if it is less than pocket money for VC funds, it is increasingly harder to secure, as it’s “safer” to bet on another mega-round of AI colossi (whether it actually is safer is yet to be seen, but perceptions are all that counts on this front).

The bottom line is that we need to plan for longer funding timelines. Which translates to securing longer pre-pre-seed runways.

Longer Runway (Still) Costs More

A decade back, it was obvious that the longer the runway we needed, the more money we had to muster before we started. Then AI came along and offered us a plethora of shortcuts. We can generate prototypes on a whim. We can run user interviews with AI personas. Heck, let’s use AI to do the creative process for us. “What took weeks now takes minutes or hours.” We’ve all heard the promise.

We could then assume we had the same time and money but do so much more within the same constraints, right? Put differently, we could do the same activities we did in the past but on a shorter runway.

Thus, building a startup should have become cheaper.

If that is the case, we literally see zero signals confirming such an assertion. Average funding rounds have swelled. If anything, it suggests that building a startup is more expensive, not cheaper. So maybe everyone is bootstrapping these days, and that’s why we don’t see a change in deal data? Nope, we don’t see the DIY wave either. The stories of bootstrapped companies are still few and far between.

Building a Startup Has Never Been about Development

One explanation is something I keep repeating on this substack over and over again. Code is not a product. And a product is not a startup.

Between here and success, there are so many activities. Building a product, which historically took up the bulk of the effort, was neither the only nor the most important part.

Remove discovery, and you ignore the very assumptions that will render the whole thing an utter failure. Remove continuous validation, and you can build all you want, but customers won’t want it. Remove the go-to-market strategy, and you can even have the right solution, but you won’t build a business out of it.

While we get tremendous help from AI with coding (especially early prototyping), it helps with everything else only marginally. The path is almost as long and hard as it was.

Development was never a critical path. The sheer effort we invested in it suggested otherwise, but it just covered the actual product dynamics. It was always validation (early) and sales (later) all the way.

Expectations Have Risen

There is another factor why AI didn’t change the playing field as much as we’d guess. We simply expect more. In the 2021 heyday, with a stroke of luck, a founder might have been able to secure a pre-seed round with as little as a pitch deck. But even in more normal periods, a working prototype would be something to show off. It communicated the effort invested and the skill set behind the core team.

Now? A working prototype is the new pitch deck. Lovable can make it for you with just a few prompts. Everybody has one. It’s a table stake.

A side note: Even if the code is crap, investors won’t notice. They won’t consider whether your prototype is well-crafted and can serve as a foundation for an eventual product or if it’s just a barely functional demo that would stink if you looked under the hood. They’ve never done that part. Why should they start now?

So when some things became simple, the attention moved to other things. Like whether the business has its legs. And you can’t fake this part with AI just as easily.

The expectations did go up. What used to be the hard part may now be the easy part, but it’s also the shrugged-upon part.

The New Trajectory Is Not That Different

Consider it a trajectory. Initially, we invest in the cheapest activities. Historically, it was a pitch deck, market research, and a landing page. By the point we were prototyping, we needed (expensive) technical skills, and we had to put in the effort.

With each further step requiring development, total costs would go up. First, an MVP, then something that allows us to validate problem-solution fit, and eventually product-market fit. The effort piled up as we kept invalidating many of the initial assumptions. We slowly (and at significant cost) iterated our way to eventual success.

Enter AI. Timelines and budgets for development shrink. We can generate a prototype right away. With modest effort, we can push out an MVP. Heck, we can fake some tech skills, reducing the need (and the associated costs) to bring in technical help.

It’s a different game altogether. Or is it?

By the point we try to validate problem-solution fit, the focus shifts away from building. Sure, development might have been slowing us down in the past, but it only gave us more time to figure out our idea’s viability.

The cost efficiency gains we have from AI in the early stages are there, sure enough. But they’re short-lived. AI shines in some parts of product validation. It doesn’t do much for others.

Whatever money we save at the beginning is “compensated” by increased expectations (from both customers and investors) and greater competition. By the time we’re trying to figure out product-market fit, the startup has likely cost at least as much as it used to. Or more.

Code Is Not a Product and Product Is Not a Startup

If you look at the broader context, it’s no wonder that we don’t see a plethora of “I bootstrapped my startups for $50k” stories. It may be possible to create code for as little as that. Code is not a product, though. And a product is not a startup.

Yet we mostly see the improvements at the code level and pretend that it’s all there is to succeed with a startup.

I would argue that, in the AI era, the odds of success went down, not up. We face more competition, disappearing moats, and more noise. And it’s not like customers have 10x as much attention to consume—and pay for—an order of magnitude more products.

For something to get into our attention schedule, something else has to go.

Getting into attention schedules, if anything, has become more difficult and more expensive. So has building a startup.

Share

Not AI-generated. 웃 https://okhuman.com/BuMxNA

We failed. We released an MVP, and it was a flop. Tough luck, you think, and you’re right. Product development is notoriously an uphill battle. No wonder that a product idea didn’t fly.

The reason we failed, however, is not about how unsuccessful the product release was. It’s about the process. We doomed the idea to fail.

If there’s a consistent message throughout this substack, it’s along the lines of “build less, validate more.” And yet, we’ve overdone discovery and validation.

Subscribe now

The Failure

Together with our partner, we worked on a vertical weather app. The key differentiator was its focus on the frost season.

Here’s a thing. Interesting things happen when the temperature drops below zero. Water freezes. Construction companies use specific add-ons to make sure concrete sets properly. Farmers take precautions to prevent sensitive crops from freezing. Etc.

Now, that’s interesting only in geographies with actual winter and actual frost season. Luckily, we have plenty of historical data to know where and when such periods happen—when it’s already spring but frost can strike back. Miss that time of year, and you missed your opportunity window.

And yes, we missed it. Despite having months in advance. The fact that the weather played a trick and brought the frost season early is not an excuse. There’s little point in a frost-focused solution when the next time anyone will have that problem is 11 months from now.

Product Discovery the Way We Always Wanted

We engaged in the product discovery process with plenty of time to spare. In fact, it was one of those rare occasions when time-sensitivity worked in our favor. We did the research. We run user interviews. We validated the findings. Eventually, we got a clear idea of the target customers’ needs.

The discovery phase was not just something small crammed at the beginning “because Lunar Logic insisted.” We did it the way we wanted. Sure, given all the exploration, we might have spent a better part of the available timeline, but we had really good insight. The building part was supposed to be a piece of cake. It wasn’t, but still we delivered a prototype early.

Only to learn that it’s the wrong solution altogether. The validation round for a working MVP was brutal. The onboarding process, intended to simplify the presentation of crucial data, was confusing. Our understanding of expectations was challenged.

We got down to redoing the MVP to address new feedback. The app got better. But then tech issues kicked in. When we thought we would make it, Mother Nature changed her timeline, leaving us with virtually zero time for go-to-market activities.

Game over.

Reverse Engineering the Failure

One interesting technique for exploring potential futures is to reverse-engineer a specific state. In our case, we knew time sensitivity was critical. So, at the very beginning, we could have easily played a game of: “Assume we already built it but were late. What went wrong?”

The process might have gone like this:

• We don’t control nature. The cold wave might have come early this year.

• Before that, we needed some time for marketing.

• Even earlier, we needed a buffer for technical fuck-ups.

• By the time we had a final MVP, we should have planned to redo things based on validation outcomes.

• Thus, the first working prototype had to arrive even earlier than that.

• We should have added a sensible amount of time to hack it together, and we’d have a reasonable finish line for discovery.

That finish line would be way earlier than what we actually did. 4-6 weeks earlier. OK, I’m speculating now, but it would be a super-insightful discussion once we reached that line and still weren’t ready with all the exploration activities we wanted to perform. Should we cut the discovery short? Or maybe we should rescale development to fit the shrinking timelines?

Either way, we’d explicitly accept the risks down the line in one scenario or another.

Trade-off Game

Ultimately, the balance between exploration and building is a trade-off. Either one without the other doesn’t add much value. You either build useless stuff or learn what’s valuable but never deliver.

The game is about switching tactics at the right moment. Think of it as a series of activities, each following a curve of diminishing results.

What’s important is that the shape of each curve depends on where it starts. Skip ideation and validation, focus all your efforts on building from the outset, and you will flatten the delivery curve.

Sure, you’ll deliver a lot, but how much of it will add value? It’s like making decisions uninformed. We wouldn’t necessarily expect impressive outcomes.

Validate, Validate, Validate

I keep repeating the “validate, validate, validate” mantra as a response to “build, build, build” message, which is the default mode of operation for startups. Admittedly, my line packs both exploration and validation into one box. However, once we pass the inflection point, insisting on either of these two is no longer an optimal strategy.

You can stick to the early research, but beyond some point it doesn’t bring you closer to success.

The reason for my strong insistence on validation is simple. We’re universally far off in one direction (build focus). Correcting the course to the opposite one (exploration/validation focus) is then sound advice. Even if—in theory—you can overdo it. Which, incidentally, we did.

Overcompensation Effect

I think of it as an overcompensation. At Lunar, our bread and butter is an uphill battle to get barely enough exploration, discovery, ideation, and validation. When we had an opportunity to do things our way, we overemphasized those.

Did we fail? Sure. On this account, a “better” reason for failure doesn’t count for anything. Yet, it is a better reason, indeed. It’s simply easier to fix the issue of too much exploration. We don’t have to reset the process. We simply switch tactics late. That is, unless the idea is time-sensitive.

Also, when almost everyone is making one type of mistake, erring on the opposite side of the spectrum is advantageous. You gain experience from both “wrong” scenarios, so it’s easier to strike the right balance with the next attempt. Think of it as a calibration strategy.

A side note: these curves are relatively flat-shaped. It means we don’t need to be precise about when we switch the main tactic. Most competitors will miss the mark by miles anyway.

An Oversimplified Model

One final thought: The model is oversimplified. One might infer from it that we stop ideating once we start early validation, or that validation is done once we shift to delivery.

It should be a continuous process going in loops. After all, if we successfully delivered an MVP, nothing guarantees that whatever we ideate for the next batch of features will work just as well.

And vice versa, the fact that an MVP was a flop doesn’t doom the whole effort. It just loops us back to one of the earlier stages (in the case of our weather app, all the way back to ideation).

Also, I used ideation (research), early validation (with a working prototype), and delivery (the actual MVP) as a sample process here. Depending on the context, marketing, or legal, or compliance steps might fall here as well.

The important part is this:

• There are distinct phases evolving from “theoretical” research to “practical” building.

• There is a balance in how we transition between them.

• Most startups are heavy on the latter part.

• Don’t be like most startups.

If you have a choice, make a mistake different than everyone else. You will learn more that way.

Share

Not generated by AI. 웃 https://okhuman.com/XGEnnQ

“You don’t have a product trio, so you don’t have a product development culture.” I’ve heard that remark recently and, unsurprisingly, it triggered my bullshit detector.

Product trio is an idea popularized by Teresa Torres in her Continuous Discovery Habits. The gist of it is that you want a product person, a design/UX person, and an engineering person to form a trio that makes all important product decisions.

It serves as much as an advisory board covering all the facets of product development as an atomic body that’s competent to make just about any call. The trio members also act as advocates for other roles when they talk with their respective teams. After all, a developer from the trio will be the best person to sell a non-obvious decision to other engineers.

It’s one of those down-to-earth ideas rooted in practice that we naturally can align with. Especially if we’re a product organization. So what’s the connection between the trio and product development culture?

Subscribe now

Product Development Culture

Let’s start with the culture. There’s no precise definition of product development culture. I mean, we know what an organizational culture is (by Wikipedia, emphasis mine).

Organizational culture is the set of shared norms, values, and behaviors in organizations that reflect an organization’s core values and strategic direction.

But what kind of culture is a product management culture? If we follow Wikipedia’s “norms, values, and behaviors,” it would be one in which people’s actions result in building successful products. We would naturally see all sorts of product-focused processes and practices that foster this kind of work.

We would see product trios, right? Well, we might. Or we might not. I would even go as far as to say that it’s unlikely.

Practices Don’t Define Culture

There’s a famous story of the leaders of American car manufacturers from the 80s. Back then, they had their butts kicked by the Japanese automotive industry. Looking for inspiration, they went on a field trip to visit Japanese factories. To their surprise, the hosts were extremely open and didn’t try to hide any secrets.

Upon coming back home, American managers promptly copied the practices they had observed. None of it made their factories better. Some of it made them worse.

The Japanese very well knew that practices are built on top of principles and values—the building blocks of culture. Remove that foundation, and practices alone are close to useless. Sometimes, indeed, harmful. Small wonder that they didn’t hide much from the Americans. Culture is not as easily copyable.

Think of it as an iceberg. Observable parts (the practices) may look impressive, but only because the underwater part—organizational principles and shared values—provides a stable foundation. Remove what’s hidden under the waterline, and the results have to be lackluster.

The trap here is that we copy what’s easy to see (practices) rather than the important part (culture). We are proverbial guys who are looking for lost keys under a lamppost “because the light’s better.”

Product Trio Is (Just) a Practice

Product trio, as a specific practice, serves as a poor measuring stick of a culture.

In the late 80s, an automotive factory in either Japan or the US could have, say, an Andon cord (which would stop the entire manufacturing line). In both cases, it would be the same practice, same solution. Yet in the former, Andon will be routinely used to stop the line when there’s an issue (and thus an improvement opportunity). In the latter, the first worker to use it was punished, and no one ever tried it again.

What would these observations tell you about continuous improvement in these two environments? The practice might have been the same, but the cultures were vastly different.

It’s the same thing with the product trio all the way. You can have one great product development company that uses the technique. You can have another crappy one that does the thing, as well. Sure, in the second case, it would largely be theater. But you won’t see the difference unless you look at the details: how the trio collaborates, who calls the shots, how much autonomy they have, etc.

Even more interestingly, the lack of product trios says nothing about the culture either. The practice serves specific goals:

• Effective communication between product, design, and engineering

• Early involvement of all the roles in decision-making

• Efficient execution within a given role (e.g., engineering)

A product trio is not the only way of achieving the above. Personally, I’m no fan of Apple, and yet it’s one of the go-to companies when we want to praise someone for product development. Their processes don’t resemble the product trio at all. And yet, it’s hard to argue that Apple has been a paragon of product development culture.

Again, measuring a culture by the presence of a specific practice (or lack thereof) confuses correlation with causation.

Single Person Product Trio

The most appealing argument that a product trio does not define culture may be the most recent AI solopreneurship trend. “I’m no designer, but Claude Design will have that role in my team. I’ve never done engineering, but here’s Claude Code to fill the spot. Add my product insight, and we will rock it! Well, I will rock it!”

It’s funny how people would still call that a product trio. I guess we are attached to labels. However, with the solo setup, we remove one critical aspect of the original idea: independent minds. AI agents, by definition, will be biased by what we feed them, and in the “solo trio” case, all strings lead to one person. One brain.

It is not to argue that a solo setup can’t work. As much as it has its challenges (one brain), it does have its advantages (lean setup, bootstrapping potential). The emergence of such an approach shows that there are different paths to building a product development culture.

Product trio, after all, is just a convenient model, not a universal truth.

Product Duos at Lunar Logic

Interestingly, the discussion about product trios happened partially in the context of Lunar Logic. We don’t do product trios. In our product development work, however, we use an underlying desirability-viability-feasibility framework a lot.

It would be relatively easy for us to add another “people” layer to this, and suddenly we would have neat product trios. And yet, I would be surprised if that’s what we end up with in the future.

Being a relatively small collective (anything between 15 and 35 over the last two decades), we always encouraged people to wear more than one hat. For an engineer, this would often mean getting into product stuff. So, a typical engineer at Lunar covers more than just engineering.

The same would be true for any other role. We don’t have “pure” product people or designers/UXers. They always dig into adjacent domains. As a result, for the most part, our product trio is a product duo.

The goal, after all, is not to follow the process rigidly, but to figure out what’s needed and respond to that. If we need to cover all the bases, we do. If we need to have distinct perspectives to create friction, we do. Does it matter whether we follow the original idea to the letter?

Cross-Skilling as an Alternative

A product duo doesn’t say anything more about product development culture than a product trio. However, the way engineers act in everyday situations, when working on our clients’ products, speaks volumes.

A broader insight enables better decisions and creates avenues for suggesting ideas/solutions beyond the traditional role distinctions. Over time, all these small contributions stack up to the point where they may be the difference between a successful product and a failed one. And you, well, our clients, get that as a standard part of the package.

It’s only possible because of the underlying culture. It’s all about how we think about our work, how we develop people, what we believe is important, etc. It has roots in recruitment, management & leadership, and shared values. Product trio is just a practice that fits such a culture or not. If it doesn’t, we likely have an alternative technique that addresses the same product challenges.

The culture shapes practices. Not vice versa.

Share

Written by a human being. 웃 https://okhuman.com/BGmXpA

I stumbled upon yet another “Agile is dead” kind of post. This time, it targeted Scrum. By now, I’m mostly like “add it to the list and let’s move on.” One passage caught my attention, though (emphasis mine).

“Then there’s Shape Up, which is gaining serious momentum. Companies are adopting its six-week cycles and hill charts because they solve real problems that Scrum doesn’t address.”

For those who are not familiar, Shape Up is an approach (framework? method?) proposed by 37 Signals/Basecamp as an alternative to Scrum for product development teams. In short, they found Scrum lacking in several places and figured they could do better.

Thus, Shape Up took, well, shape.

Subscribe now

Scrum for Product Teams?

Now, 37 Signals’ main business is running a product, Basecamp. We might reasonably expect that they’d be a good candidate to spot places where Scrum is overly rigid in the modern product development context. After all, it wasn’t native landscape for Scrum in its formative years.

On the most generic level, I agree with the diagnosis. Scrum is too rigid. Always has been. It’s just two decades ago that rigidness was a viable way to get rid of the old, unhelpful habits. In my first product company at the dusk of the 20th century, we had a half-year release cycle. Any Agile approach would trump that, hands down.

But we’re not living in the Internet bubble era anymore. Those unhelpful habits? They are just ramblings of the old folks (and yeah, I increasingly feel like one). The trade doesn’t make sense.

So, isn’t Shape Up just Scrum for product teams adjusted to the 2020s?

• It comes from a product company.

• It has a product development context painted all over the place.

• It’s been formed around modern engineering practices.

• It adopts some contexts that arrived later than Agile (e.g., Lean Startup).

Not a bad foundation, if you ask me.

Let’s Talk Iterations

The good impression disappears as soon as you get into the details, though. So, in short, in the Shape Up world, Scrum’s typical two-week iterations were bad. So let’s switch to 6 weeks, shall we?

Oh boy, where do I start? Scrum folks will be quick to comment that the method didn’t explicitly prescribe 2-week iterations (even though they’re by far the most common). If you use “rules as written,” you could be perfectly fine with month-long cycles. Extending that to 6 weeks doesn’t feel all that iconoclastic to me.

What’s funnier, we exchange a fixed iteration length, which we could control to a degree, for another, fixed and absolutely arbitrary one. It’s 6 weeks. Because 37 Signals said so.

In fact, most mature teams were cutting the iteration rhythm to shorter and shorter because it meant better flow and more effective work. Whatever. Let’s go the other direction. If experience teaches us anything, we’ll end up with:

• More work in progress.

• Longer feedback loops.

• Bigger commitments.

The theory of work suggests that all these are moves toward worse effectiveness. It’s not without a reason that no one misses those old half-year-long release cycles. But hey, let’s move a few steps back down that direction, shall we?

The Curse of Cadence

My biggest complaint, however, is valid for both Scrum and Shape Up alike. Both methods artifically glued together cadences of planning, release, and improvement.

An iteration is precisely that: an ideally uninterrupted period when a team can work on a planned batch of work. That implies the work has been prepared earlier. It is delivered no later than at the end of the cycle. Also, the “uninterrupted” part suggests that planning and improvement happen outside of the sprint/iteration.

In my experience, optimal cadences for planning, release, and improvement do not happen at the same rhythm. In the absence of more context, I would default to:

• Coarse-grained planning done in a few-week-long cycles, optimized for the availability of a broad circle of stakeholders.

• Fine-grained planning done ad-hoc, as soon as we are close to depleting the ongoing commitment/batch of work.

• Delivery done as frequently as reasonably possible, ideally daily.

• Improvement done ad-hoc, just-in-time, with a fallback to biweekly/monthly retrospective (depending on the team’s maturity) if nothing has emerged.

That would be a very different set of cadences.

Scrum did us a disservice by artificially throttling the naturally messy process of product development. Shape Up correctly identifies the iteration constraint as an issue and then doubles down on the approach that was at the eye of the storm. It’s just with a different shape of a cage, I mean, iteration length.

Product Management Sprinkles

Admittedly, 37 Signals did a good job sprinkling a lot of modern product management jargon all over the place. We have appetites, and bets, and prototyping (breadboarding, actually; in case you missed esoteric lingo), and what have you.

The thing is, renaming things doesn’t do much on its own. “Bets, no Backlogs” sounds radical enough. Unless you find yourself with a huge, unmanageable backlog of bets (pun intended), and the new ones keep coming. The problem with backlog overwhelm was never about the idea of backlog itself, but about how we used it.

Rename “features” to “bets” (which is a good idea, by the way), and you end up in the same sorry place unless you manage the granularity of the incoming work and say no to stuff frequently.

I suggested using the idea of “the fold,” taken from design, as a guiding principle for planning the work. Now, if you actively keep your backlog (or betlog) reliably short, it doesn’t matter how you call your “to-do things.” The list will suddenly become manageable.

The best part? You don’t need no fancy lingo to make that happen. It will work just as well with Scrum as with Shape Up, and any other method, really. Product management sprinkles don’t do much if you don’t get your fundamentals in place.

Renaming things the fancy way may bring you PR, fame, and an ego boost, sure enough, but unless you change the actual building blocks, don’t expect vastly different outcomes.

A side note: my favorite example of the observation above is Spotify repackaging a matrix organization into the Spotify Model. There are very interesting consequences for their product. Which could have been easily foreseen.

Shape Up in the LLM Era

Ironically, Shape Up was released in 2019, just a few years before the rise of AI in software development. The broad effect of AI adoption in product development—for better or worse—was shrinking timelines. We want more, and we want it faster.

Thus, changing the default from a 2-week cycle to a 6-week cycle seems like swimming against the tide. Don’t get me wrong. I’m a contrarian. I appreciate going against the grain. When it makes sense, that is.

Lengthening iterations has never made sense. Over the last three decades, we have continuously evolved toward smaller batches of work, shorter cycles, and less work in progress.

Interestingly, AI pulls us in both directions. We may have faster cycles (good), but we respond by trying to do more work at the same time (bad). We can shorten validation loops (good), but instead we try to pack bigger batches of work (bad).

The iteration length may be one safety valve to tweak the balance one way or the other. A short release cadence would naturally push toward the upside of AI capabilities. A longer one would pile up the overhead. So, why 6 weeks, again?

Is Shape Up a Good Choice for a Product Team?

“Any headline that ends in a question mark can be answered by the word no.”
Betteridge’s law of headlines

As Betteridge’s law of headlines suggests, I wouldn’t recommend Shape Up as a good way to go for a product development team/organization. I mean, if an alternative is chaos, you’re better off using something. And Shape Up is as good as Scrum in bringing some order.

Basecamp got some things right with their jab at the old champion. Some others? Not so much. As funny as it is, Shape Up is more prescriptive than Scrum. It has “We did a thing. It worked for us. Thou shalt do the same.” vibe painted all over it. If you ask me, that’s one of the universal no-go signals for any advice you get.

For a typical product organization, I would default to a flow-based approach with a robust way to limit work in progress (a 2-week-long iteration doesn’t serve this purpose in the AI coding era). Personal Kanban is a great starting point (don’t be fooled by “personal” in the name). But if you need to bring some order to your product development effort, and you don’t have the time/knowledge/experience to figure out the principles, either Scrum or Shape Up would be an improvement, too. Just make sure you don’t stick with the book for too long.

When Something Is Difficult, Do More of It

One final thought. I still remember ’s session about continuous integration from like 2010. He shared the story of how we evolved from once-a-year releases to Amazon’s thousands-a-day deployments. He stressed how each leap required reinventing practices that held us up.

The underlying message was dead simple.

“When something is difficult, do more of it.”
Kent Beck

Once-a-year release is difficult? Do once-a-quarter. You’ll find some things (like a 3-month-long stabilization period) that may be feasible once a year but not 4 times as often. So you’ll fix them. Then, you make another leap.

It’s the same basic advice I’d give to those facing friction in their product development processes. A standard two-week-long iteration proves difficult? Do more of it. Switch to one-week-long. See where things break. Redesign them. Repeat.

It may mean doing some things more frequently as well as doing others less often. A retrospective every week probably feels like too often. A production deploy at the same frequency may be too slow.

So it doesn’t matter which method you start with. You can start with Scrum, or Shape Up, or whatever. Just keep experimenting. When something is hard, do more of it. If your product development team follows that bit of advice, you’ll quickly evolve away from the least helpful bits of any method. What remains will likely be useful.

Share

I like going against the grain. I still type those. 웃 https://okhuman.com/12EPjQ

One of the neat ideas popularized in product development by the Lean Startup body of knowledge is the Wizard of Oz MVP. The concept is simple. You build barely enough of the front-end to make it look as if there was a full-blown digital product, yet you have a person manually do the actual work behind the scenes.

The goal was twofold. First, it limited the investment in building something before the idea is even validated. Second, it was a source of learning. Having a human in the loop allowed for gathering insights and contextually reacting to unexpected needs or requests.

Enter AI. You don’t have to cut the development effort, as AI tools will build an MVP for you right away. Heck, you can get them to gather usage data just as easily. The Wizard of Oz seems to be going right to the “Killed by AI” pile.

I beg to differ.

Subscribe now

”Just Build It”

One of our clients is a case in point. Despite their initial intention to “just build it,” we convinced them to take a step back and work together through the discovery process.

The exploration went well. The product idea was sound. There were similar solutions on the market. The founder had a potential unique value proposition (UVP). The runway seemed limited but secure.

And yet, we suggested the good old Wizard of Oz MVP. Let’s do the minimum. Let’s have humans handle the rest behind the scenes. Let’s learn and validate.

“But the business model is validated! The UVP is there! Sure, it’s not bulletproof, but we don’t need to check whether that’s a sound idea. Because it is. Let’s just build it!”

That’s what we ended up doing. The product didn’t fly. We got back to the drawing board. Eventually, we pivoted. The “validated business model” was, indeed, validated. In a somewhat different niche. In a somewhat different geography. In a somewhat different scenario.

In other words, it wasn’t validated at all.

The Wizard of Oz Is Much More Than a Build Hack

The key part of doing things manually within the Wizard of Oz experiment is not cheating on the effort required to build the thing. It’s the learning.

Pattern spotting

Humans are pattern-spotting machines. We see patterns everywhere. We connect the dots at ease, even when there was no connection to start with. Heck, we see faces in, well, everything.

So when we have our Wizard of Oz helping customers with different requests, it’s a given that the wizard will quickly spot the patterns in behaviors and needs. In a startup, that translates to actual opportunities. Validated ones, let me add.

Ingenious solutions

Once customers depart from the pre-designed script—and believe me, they will—the Wizard of Oz has all the freedom to follow suit. A full-blown product is algorithmic. It does things the way it was designed.

The wizard, though? The wizard can suggest an ad-hoc solution, get instant feedback on whether it worked, and then iterate further. Ditching the script does two things here. It’s an investment in customer satisfaction and enables the exploration of new opportunities.

Opportunity exploration

Talking about opportunity exploration, the wizard comes with that option built in. Whenever an interaction goes astray, it’s just a fresh discovery. It may prove useful or useless, but we’ll know only after we’re through.

Even better, it’s not a hypothetical discovery, which is what we do during the discovery phase. We base it on someone’s actual need. Sure, it’s a whole another discussion whether we want to include that scenario in a product. But that’s precisely where pattern spotting will be of use (see above).

Scaling optimization

The wizard’s time and effort constraints will tell us where we should focus our efforts. Think of it like this: we want to automate the parts that would free us the most of the wizard’s time. Whatever feels more like a one-off, we can ignore for now.

Sure, with the power of AI, we could automate everything, but prioritization actually matters here. Things that are repeatable and homogeneous should be made invisible. Those that happen only occasionally suggest optionality. You don’t want to automate optionality, as putting it within algorithmic guardrails removes value rather than adding it.

The wizard is there to know which is which.

Serendipity and Judgment are Not AI’s Strong Suit

I could argue that there’s more to it, like the fact that customers increasingly appreciate human support. Funny, ain’t it? The less of that we have, the more we value it. Is there a pattern to explore here, perchance?

Anyway, if you go through the list above, it boils down to two things: serendipitous exploration and judgment. Neither of which AI is any good at.

Sure, you can get an AI agent to go “explore.” That is, wherever you tell it to. That, in turn, means that you explore areas known to you. By the way, that’s precisely what we do during a discovery phase. We explore what’s phatomable, what we can already think of. It’s not how we learn entirely new things.

But we can tell AI to wander into the unknown, right? Yes. Kinda. Not really. In return, we will get the most likely answers. Something that a local expert would respond to with a “duh!”

To make AI venture forth into the unknown, we need expert knowledge to manage context. It won’t stumble upon a fresh thought by accident or by observing a single customer’s behavior. In that sense, AI is not creative at all.

As much as you can’t expect serendipity from AI, you shouldn’t count on its judgment, for it has none. Curiously, you get plenty of both from the Wizard of Oz.

Product Does Not Equal Code

If all there was to succeed with a product was building it, you could ignore all the above. Also, we wouldn’t have a startup community at all, as incumbents with their infinite coffers would outperform any fledgling startup, like, every single time. Alas, product development does not work like that.

• Flickr emerged from a tool intended to boost engagement in a (failed) video game.

• Slack was an internal collaboration tool for a team building another game.

• Mailchimp got inspired by a failed greeting card business.

• Shopify was just a way to improve sales of snowboarding equipment.

We could go on and on.

Product development is the story of serendipitous exploration and judgment (and luck, but neither a good product manager nor AI will give you that). Code is needed to have a product, but code is not the product.

The Wizard of Oz may make much less sense now from the perspective of optimizing the coding. If that was the only thing you’ve been using the concept for, then sure, the wizard is dead.

Yet the technique is just as valuable for exploration and insight generation as it was. Maybe even more so, given how often we fall for the build, build, build mindset. Long live the wizard, then!

Subscribe now

No AI was hurt in the process of creating this essay. 웃 https://okhuman.com/2AIBag

Some six months ago, I wrote a piece on business sustainability and time to profit. Long story short, I argued that what we see with the most prominent AI startups is an aberration, and just about any startup should follow a different path.

Optimizing for time to profitability and business sustainability may lack glamour, but it’s, by far, the most reliable business strategy for a startup.

Read the whole piece here:

Now, it’s funny how some things become outdated so quickly. The data I used in that post of mine? Already changed.

Subscribe now

The 2020s Startup Landscape

My main reference point was that the combination of long timelines to break even and a gigantic appetite for funding makes the most prominent AI companies outliers. Also, given that OpenAIs and Anthropics of this world are not yet profitable, the gap is bound to grow.

The AI labs will go up and to the right, which, on this chart, is nothing to brag about. An interesting part of this view is that the larger the operating losses, the more capital a company needs to raise. So the dimensions are correlated to a degree.

Also, note, we don’t look at return on investment here. The charts tell nothing about whether and how much investors will get back. We only look at the break-even point.

One way to look at the pictures is to consider how the startup landscape evolves. We used to have shorter timelines in the 2000s. Because of shorter investment periods, product companies wouldn’t burn nearly as much money. Then, as timelines in the 2010s expanded, funding necessarily had to increase.

With everyone seeing AI as the next big thing, it was only natural that the combination of hype and spending needs would create another bubble. So maybe it’s just evolution?

OpenAI and Anthropic Have Changed the Game

The charts were up to date as of November 2025. By now, they’re already different. And not because OpenAI has further shifted their profitability projections. That is, as long as you believe a person dubbed ”unconstrained by truth.”

If that was the only adjustment, the trajectories would become somewhat more horizontal. Less optimistic, but still manageable. Instead, they literally went through the roof.

Just consider it visually. It’s not an iterative change. It’s not an evolution from the previous wave of record-breaking startups such as Tesla, Uber, SpaceX, or Airbnb. It’s already a different order of magnitude in funding and nowhere close to break-even. And all we hear is that they’ll need more money still.

While OpenAI and Anthropic are, obviously, the most vivid examples, surely, there are followers. My favorite, Thinking Machines Labs, considers itself worth $50B-$60B, so I’m guessing they want to raise ~$10B. Others will follow to exploit favorable conditions.

Looking just at the scale of the change, it’s a tectonic shift, not an incremental adjustment.

Does It Matter to an Average Startup?

There are only that many most prominent AI startups, though. An aspiring founder would be right to ask whether it even matters for them.

The answer is yes. But not for the obvious reasons.

Consider a typical startup, be it AI-native or not. It’s not like the founder is the next Ilya Sutskever, or Mira Murati, or Yann LeCun. No one would throw hundreds of millions at an anonymous person. That startup plays a game that hasn’t changed all that much. They’re in for a 5-digit friends-and-family round and, with a bit of luck, a low-6-digit seed round. And then, they’d better have something to show for it.

For all that matters, what is happening with OpenAI could have been happening on another planet. Save for one thing. Funding.

The force that pushes major AI labs through the roof on the charts above—along with a flock of big-name-led smaller followers—does not act in isolation. The money, after all, comes from one pool. And it’s either directed to fund the next gargantuan OpenAI round or toward other startups. Like, a hundred thousand of them.

Now, an average Jane’s startup is within that hundred thousand. The bad news is that VCs have already made their decisions, and it all goes to the OpenAIs of this world. Sorry, aspiring founders. You didn’t have a shot in this game.

The reason to consider absurd rounds going to major AI labs is that they suck up everyone else’s air. And it’s bad, not good news.

Realities of Startups and Major AI Firms Are Increasingly Disconnected

I’m not fooling myself. Whatever Sam Altman or Dario Amodei says will make the news. Yet, for the rest of us, they could as well live in a different universe. Your average startup faces a world where:

• Common perceptions (extended timelines, higher rounds) hold true only for a marginal fraction of startups.

• Funding is increasingly hard to secure.

• Small bets are increasingly uninteresting.

• The landscape for more obvious solutions is increasingly more crowded.

Luckily—and ironically—there are no signs that the product success rate has gone up. In fact, if you account for all those vibe-coded attempts, it had to go down. In the wave of AI-powered startups, survival is an increasingly rare trait.

Sadly, survival is not something investors want from a startup. Yet, in this rapidly changing environment, there’s hardly a better tactic than pursuing early sustainability. That means playing the exact opposite of what the news and the investors suggest:

• Break-even over revenue.

• Sustainability over growth.

• Bootstrapping over external investment.

You know, as in the good old example: “While there is value in the items on the right, we value the items on the left more.”

And if you want just one universal guideline: time to profit is a neat compound metric that will help you there.

Written by hand. 웃 https://okhuman.com/TPRdQg

It’s an interesting time at Lunar. As usual, we’re involved in building a few different products. However, right now, we are working on a portfolio that ranges from super-heavy AI reliance to a rather conservative approach, which wouldn’t feel off if it were 2022. That gives us plenty of data to consider and compare.

My favorite sandboxes are gigs where we use AI most intensively. After all, that’s where the most unknowns are, thus that’s where we learn the most.

That’s also where making predictions is most fun. So, when we started one of those AI-intensive efforts, I suggested that:

• We’d be able to go super-fast initially.

• Yet, eventually, the technical debt will take over, and code maintainability (or lack thereof) will hit us hard.

• Thus, the pace would slow down rapidly.

Long story short, I was wrong. If you want to dig deeper, in the first part of this miniseries, I explore the technical considerations of a prototype evolving into a product.

Subscribe now

Disposability As Differentiator

In the first part, I suggest a key difference between what we still consider a prototype and what is already a product: disposability.

You can dispose of a prototype, and nothing bad happens. Conversely, you can’t throw out a product without bearing the cost (forgoing revenues, pissing off customers, etc.).

It affects product management just as much as engineering. The moment we feel responsible for serving customers, we can’t randomly push bugs to production and expect all to be fine.

By the same token, we can’t change or remove features on a whim and pretend it’s normal. People are using that stuff. And paying us for that. We want it or not, it’s a commitment.

If we can freely throw a thing out, it’s a prototype. If you can’t, it’s a product. Disposability makes all the difference.

High-Pace Product Management

The most interesting part, as always, is a moment of transition. Here, from a prototype, which we can freely discard, to a product that we promise to maintain and develop.

AI gave us perfect tools for rapid prototyping. We can move fast, sidestepping the past pace-vs-quality trade-offs. With a bit of luck, we get early validation and start the transition. Now, from an engineering perspective, we have every incentive to stick with an AI-intensive approach.

That creates pressure on product management. You want a feature? Bam! It’s ready. What’s next? The perception that we always have time in product management because coding will take time is gone.

Not to mention that, these days, every product manager should adopt AI tools to push product specifications way further than they did in the past. Or so the common advice goes. That, by the way, is in line with the high-pace product management expectations we face. Everyone has to up their game to stay in the race.

A side comment: these perceptions, if taken in isolation, are oversimplified. We lose critical aspects of discovery and validation that can’t be automated away. And no, talking to AI is not a substitute for talking to actual users.

Managing Product Context

At the risk of oversimplifying, I would define product management as managing product context. It’s juggling all the perspectives:

• What’s already in the product?

• How are the customers using it?

• What more do they want?

• How do we grow the user base?

• What product issues do we face now?

A product owner needs to know equally well “what is” (what’s in the product and how it is used) and “what might be” (what should be added and how it will be used).

Except, suddenly, everything moves so much faster, we need to feed the engineering team more input, and everyone’s talking about disappearing moats. Everyone wants more.

AI to the Rescue

The old game—translating insight to specs by hand—is unsustainable. But hey, writing PRDs is so 2025. These days, you just feed your AI tooling with your thoughts and let it generate the output.

Even better. Claude Code can do more for you than you could ever handle yourself. It can use the codebase as the context, so it works with a better understanding of the actual landscape. It’s not only what you see in the product from a functional perspective. It’s just as much about what technically is there.

And you can generate the feature description in whatever form you want. Be it a detailed specification, PRD, designs, or a working prototype. Even better, hand it over to developers, and their coding agents have a way more detailed prompt to work on from the outset.

We sped up the whole cycle. Or have we?

Broken Human-to-Human Communication Loop

Historically, the scenario relied on human-to-human communication:

• PM would turn their insight into specs.

• The specs would likely not be overly detailed, as no one fancied writing pages upon pages of those.

• Whatever wasn’t clear was discussed between the engineers and the PM.

There’s nothing in an AI-heavy product management process that would make the above impossible. Yet the incentives are different. Once we start generating specs (again, in whatever form) instead of creating them, we change the cognitive process.

I mean, would a PM check that a 4-pager describing the latest feature is really what they intended? Let’s assume they would. And it was. And the next time it was so again. Would they keep reading and carefully analyzing these specs every time?

And what about developers? Once they realize the specs are not human-reviewed anymore, would they care to do it themselves? For how long?

By the time they stop, we have completely shattered the human-to-human communication loop. And added at least two layers of AI interpretation, each of which potentially creates misunderstandings.

Case In Point

Dev: The last feature is on staging.
PM [checks it out]: It doesn’t work as specified! Here’s what should be different.
Dev [checks the code, checks the specs]: Well, actually, it works as specified. Here are the specific parts that prove my point.
PM: Oh, my Claude must have hallucinated that part.

Yes, that’s an actual exchange. By that point, the developers would be all like, “Why should I care to read that stuff if the folks who send these over can’t be bothered?”

Sure, you can argue it is a dysfunction, and it is. It’s just that we now incentivize such behaviors. That part is new.

To add insult to injury, each time we make that slip, we create product management debt. And it doesn’t matter whether the specs were correct (they often are), or they weren’t but no one caught the difference, or the discrepancies didn’t matter in the grand scheme of things. What matters is that we gradually lose detailed product comprehension.

It is very much like what happens with the code as we stop reviewing it. Except this time, we don’t understand specific details about product behavior.

Product Management Cliff

This product management debt may not seem like much initially. Yet, it stacks up. Also, remember, we are transitioning from a disposable prototype to a product. Customers expect the product to keep behaving the way it did.

Gradually, a PM will understand the product less, and the stakes will be higher. Similarly to coding, AI will take care of that. It can analyze the code to understand what is really going on.

Everything will be OK. Until it won’t.

At some point of complexity, the regression problem will kick in. Changing one scenario will break others in unexpected ways. Normally, we’d rely on humans to apply judgment. After all, product owners consciously decide to break some features all the time. However, we gave up understanding when we broke the communication loop. We sacrificed it at the altar of efficiency. This time, it’s no longer a conscious decision. It will just happen.

Product Management Cliff Is Closer Than Quality Cliff

At the beginning, I mentioned that in one AI-intensive project we work on, I expected the code quality cliff to emerge and slow us down. I was wrong. AI tools are extending the maintainability line farther than I thought.

I was surprised, though, how fast the product management issues emerged.

Product managers maintain the high-level product context just fine—the why of the product, if you will. However, it’s different with the how and, especially, the what of the product. In discussions between themselves, as with developers, product people increasingly rely on the AI output. Once a feature description becomes a literal 4-pager, the cognitive load of carefully reviewing it becomes a challengeable investment.

To make things worse, AI output sounds coherent. LLMs are good at producing content that looks sensible. Catching inconsistencies thus requires more effort and is more difficult. It’s not much of an incentive to keep doing that.

Once we choose the easy path, things go downhill quickly. Engineering will keep up the pace. Except they’ll build the wrong things. We realize it only afterward, so we trigger rework. That, in turn, increases complicatedness (both technical- and product-level) and raises the chances of similar issues emerging in the future. The loop closes. We incur more product debt faster. The pace slows down, the pressure goes up.

And then we fall off the cliff.

The first part of this miniseries focuses on the technical aspects.

Written by a human. 웃 https://okhuman.com/3BiZ7Q