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 start. 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

In the olden days, i.e., like 3 years ago, the early product development work was straightforward. Once the exploration was done, we’d get into engineering work, trying to balance craftsmanship with the pace of work.

Naturally, before anything has been validated, we chose speed over quality. Then, if we decided to keep going, we would gradually rebalance our decisions. As we saw an inflow of customers, reliability mattered more. We naturally prioritized craft more to make sure the product was technically sustainable in the long run.

Enter AI. The early prototyping has shrunk into intensive bursts of effort that can be contained within single weeks or days. Or, as some claim, hours. The pace spike doesn’t even come with that steep a price. With enough context-fu, the codebase quality will be more than decent for an early prototype.

Then, with a bit of luck, we see the early traction, and the momentum suggests we do more of what we did. I mean, with an AI prototype, we gamed the system. We ate the cake, and we still have it.

So, how does the prototype-to-product transition look in the AI era?

Subscribe now

The Difference Between a Product and a Prototype

When considering the transition from a prototype to a product, we could consider at least a few differentiating aspects. For this discussion, however, one is critical. 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.).

The line is blurry. It’s not like the first paying customer automatically turns a prototype into a product. It’s just that with each user, the costs of a hypothetical disposal of a quickly hacked solution mount to the point where we no longer consider discarding a viable option. We suddenly have a product. It is yet to be decided how successful it will be, or whether it will succeed at all. Yet product it is.

The Transition of Engineering Practice

The transition from a prototype to a product is an interesting period. In the past, engineering practice gradually evolved as we saw more and more evidence that the thing was working. There were underlying feedback loops that ensured it happened.

Once the first customers arrived, they stumbled upon issues that we passed to developers to fix, which, in turn, incentivized the engineering team to improve the codebase. More users meant more usage scenarios, more issues, and a stronger motivation to improve code quality.

The defect rate throttled the pace of progress. The crappier the initial code, the more issues we saw, and the slower we could add new features.

Think of it as a progression path. The more successful the product, the farther you get. Yet the trajectory has been preset.

Except that the trade-off that used to work no longer does.

AI Breaks the Trade-off Loops

With the help of increasingly better AI coding agents, we defer the emergence of the pace vs quality trade-off. First of all, we can get a disposable prototype super fast. And the code quality is passable or better.

More importantly, though, we can easily extend that way of working further. As we onboard customers and issues emerge, we can pass bug reports and improvement ideas to the agents and let them do the heavy lifting.

Sure, the pace will drop somewhat as we deal with an increasingly complex product. But we should still be better off than we would be in an “old-school” scenario.

Arguably, we don’t even need to care about the codebase quality. After all, as long as an AI agent can handle a fix, why would it matter whether code is SOLID or a big ball of mud?

In fact, we are incentivized not to look at the code at all. And when we do, it’s an entirely different level of cognitive challenge, so it’s unlikely we’d fundamentally influence the overall quality. The only sensible solution is to keep going, i.e., defer the responsibility for the code-level to AI entirely.

Which works perfectly. Until it doesn’t.

The Quality Cliff

In the past, save for relatively rare examples of products developed with reckless abandon, we didn’t hit the quality wall with product development. The reason was the self-balancing pace-versus-quality trade-off game we played.

However, we ditched the game altogether. AI does not have an incentive to suggest a better, more systemic solution to an issue to avoid future problems. It will do what it’s prompted to do—fix a bug. It does not try to avoid future effort (token spend) the same way as humans use their ingenuity to avoid repeating tedious tasks.

The quality of every code base, left unchecked, will deteriorate over time. The code base maintained by AI is left unchecked by design. It will get worse.

In fact, we know that AI agents do not do well when they try to maintain code unsupervised over the long term. The regression issues kick in hard. So it’s like whenever one problem is solved, another couple of them are created elsewhere.

It’s the quality cliff. For a time, things go fine as the system withstands the stress. But then, everything breaks suddenly. It’s like our blood pressure when we’re losing a lot of blood. Or our leisure approach to time-to-profitability for startups. It’s all fine. And then out of the blue, we fall off the cliff.

AI Prototype to Product: Long-Term Game

By this point, one argument should emerge. “But there are codebases developed in that manner, and they seem to be fine.” Boris Cherny is very open about how the Claude Code team doesn’t write code anymore. Philip Su suggests lights-out codebases, where there is no direct human review or intervention by design.

Two comments. One, in all these stories, there’s a fine print. So far, none of these come without thorough human review. Sure, in an interview, you’d have a 5-minute-long story on how AI agents plan, write, and review code. And only then, half of the sentence stating that “of course, at the end, a developer reviews the code, too.”

Two, these are all relatively fresh experiments. The fundamental shift in perceptions of the broader developer community came around the end of 2025, when Opus 4.5 was released. Even for those who jumped on that bandwagon early enough, we have only a few months’ worth of data. Let’s see how these codebases look in a few years.

Some predict it is actually a future, and that software will become a throwaway, i.e., it will have a shelf life of less than a year.

Either way, we should expect improvement in coding agents. They will be able to handle wider contexts, navigate more complicated architectures, etc. The big question is whether these improvements will outpace the generation of tech slop.

Looking at the pace at which we generate code, I remain skeptical.

Code Is Not the Only Game

Now, I’d love to be proven wrong. So far, humans have been surprisingly creative in solving the problems they created before the push came to shove. So maybe AI improvements will give us a “get out of jail free” card before the breakdown kicks us in the butt.

Was code quality the only game, I might have been optimistic. Interestingly, one project we run is a case in point of an AI prototype turning into a product. When we started, I said that if we kept going, we’d hit the quality cliff.

I was wrong. We didn’t. Before we even got there, we hit the product management cliff. But that’s a story for a follow-up article.

Written by a human. 웃 https://okhuman.com/l1owZA

Throughout more than two decades, we contributed to more than 200 different products. It was anything from adding developers to a team to speed things up to doing end-to-end product development with founders.

I don’t have the exact number, but the products that still exist are somewhere in the 10%-20% range. Yup, despite our bold claims that we help founders improve their chances of succeeding, the bottom line is not all that impressive.

Admittedly, part of the story is that a product might have been successful in 2007 and still be dead by 2017. So we still beat the odds.

Either way, with that much exposure to different product development efforts, we definitely see patterns. A lot of them. So let’s look at some of these stories and see what comes of it.

Subscribe now

The Community Portal

An idea to build a dedicated website that is a go-to place for the LGBTQ+ community may look like overkill in 2026. Some 20 years earlier in the pre-Facebook era, it was anything but.

From an engineering perspective, it wasn’t that much of a challenge. UX, admittedly, was nothing I’d be proud of. Yet still, it was the 2000s, not the shiniest era for UX.

The failure, though? If you build for a community, you need a community to be there. It’s not that much of a go-to place to meet other folks if they’re not there.

The founder was all about features, leaving little room for driving traffic. No wonder that customers saw little point in coming back. Nonetheless, we tried more features. Way more features. One of them had to be a killer one, right?

None was. The money ran out. End of story.

Reinventing Personal Fitness Training

What if you could have an experience of having a personal fitness trainer without hiring one? And a famous one, no less. Customers would have access to an instructor they couldn’t afford otherwise. The trainer would have a much broader audience. Everyone wins, right?

Guess what. Training with an app is not a direct equivalent to training with an actual human. People weren’t flocking to sign up to that, even if the app was smooth and easy to use.

Somehow, a piece of electronics with some digital content doesn’t offer the same value as some basic human attention. Even if, at the end of the day, we receive precisely the same information.

And yes, we tried the second version, too. Eventually, the founder gave up.

Bakery Management 2.0

One of the sure-shot business ideas is to take what already works and automate it or improve it significantly. That’s what one founder had in their hands. They had a legacy management software dedicated to a narrow niche—bakeries.

What might have been the state-of-the-art in the early 2000s was already way outdated by mid-teens. An old on-premises app begged to be migrated to a SaaS model.

Easy enough. Till the point when we needed customers. The founders were reluctant to cannibalize their existing business, so they tried to operate with new customers only. That meant very little initial traction and no ongoing validation.

They kept going for almost two full years, struggling to build any momentum. There was always another killer feature around the corner. No matter how many of those we had built already, just to learn that “Nope, not that.”

Eventually, they had their Kodak moment. No, not the one with a great memory. The one when you go out of business because you got stuck in the past for too long.

Social Gambling

What if you take a fun pub game that people love and turn it into a digital platform? People are going to fancy it just as much, right? And sure, you can build that one little experiment to check whether it’s true, but why not go with everything, all the bells and whistles blazing, and make it a full-blown platform?

I remember this one vividly, as we strongly advised the founder to go slow. Anyway, we did fast. So when they eventually stumbled upon the legal issues, the product development was almost done.

The full-blow version, that is.

You see, that version of social gambling was still considered actual gambling by law, against the initial assumptions. And you can’t just operate a gambling platform at your leisure with no strings attached.

So the founder had two choices, both bad. Either get a proper license, which would ruin the business model, or play with fake money, which, unsurprisingly, got a lackluster reception.

Cooking Together

How about the idea of facilitating dinners with strangers? One person buys groceries and cooks, the rest put their share into the (virtual) kitty. The platform makes sure that we end up with people who share interests, and handles the money.

What could possibly go wrong?

Well, it’s not something we do casually, so I’d expect trouble building up traffic. Which coincidentally happened. The answer? Yes, you guessed it. More features. The customers? Nope, they didn’t come.

Changing our behaviors (and at scale) requires more than just creating a platform that would facilitate the new pattern once it has emerged.

At least the founder was pretty conservative with spending, so we didn’t waste too much of the development work in this case. Still, more than we should have.

The Common Part

Now, I could go on and on with these. Really, I have no shortage of such stories. We can already see the interesting part, though.

In neither of these examples was software the cause of failure. Matter of fact, I try to think of a single story across all products we’ve been involved in, and there is...

Nothing.

I literally can’t come up with an example where more features, improved UX, better stability, etc., could have saved it. That’s from our experience, of course. I don’t say it’s impossible to find such an example. Granted, though, they will be few and far between.

And yet, that’s an obvious first response when a startup doesn’t fly from the outset. “Let’s build more.” As if it ever worked.

Survivorship Bias

I get it, when we look at the products that made it, inevitably, there is continuous product development work. There’s barely a month when popular apps don’t surprise you with cramming yet another feature to make their UX even more bloated.

By the way, are you a Spotify user, perchance? Then you know what I’m talking about.

Every successful product keeps building. What follows, if we want to succeed, we need to keep building as well, right?

Wrong. It’s a classic case of survivorship bias. Sure enough, Spotifys and Salesforces and what have you do keep building. All. The. Time. But so did all the forgotten failures. It is not a differentiator. So it can’t be the reason.

In the stories, the reasons for failure were different. From a weird idea to lackluster outreach to following Blockbuster steps to legal issues. ”All happy families are alike; each unhappy family is unhappy in its own way.” More features would not make these products “a happy family.”

Final (AI) Thoughts

There is an interesting follow-up to the above. If more features hadn’t saved these startups, neither would have the new AI development capabilities. Admittedly, all these stories are from before the Claude Code heyday. We wrote those products by hand.

If we could build these products faster and cheaper, it would change nothing. We’d probably end up adding even more features. Native mobile apps for the gaming platform. PoS integration for bakeries. Facebook clone for the community platform. It wouldn’t change the outcome.

And yet, now that we have all the code-generation tooling, we seem to believe we have the ultimate solution. As if “not enough development” was the reason for startup failures.

I’m afraid it’s the good old “If all you have is a hammer, everything looks like a nail.” All we have is Claude Code, so every problem looks like too few features. It didn’t work in the past; it won’t work now.

I don’t generate that stuff. I write it. 웃 https://okhuman.com/Eukv2A

A random mix of news that hit my inbox after a short break:

• Slack has released 30+ new features, which were developed at a faster pace thanks to AI.

• Meta has a leaderboard for token spending, and the metric goes to assessments.

• An internal discussion about the pace of development in one of our projects (it is faster) and feature lead times (uhm, not really).

These all paint a consistent picture of today’s product development realities. We build faster. We release more. And we incentivize doing even more of that.

It happens as much in big tech as in small-scale products (as our internal discussion proves). In fact, one story from the product development I mentioned above shows it vividly. Over the course of a quarter, we had a few instances in which we depleted the backlog. In other words, the engineering team was faster than the product team.

Now, that’s new.

Subscribe now

Building Is Faster; Product Work Not Necessarily So

There’s no denying that with AI tools, we get faster with coding. With the same engineering team, we can develop more features. However, think of it. With a couple of thousand developers or so working on Slack, delivering 30-odd features shouldn’t sound like a big deal. Even less so if you assume they’ve been riding Claude Code like there was no tomorrow.

And yet, we go “wow!” Why?

Anyone who’s done anything serious in product development understands how heavy the process gradually becomes as a product matures. The early days when they hacked what-was-to-become-Slack as an internal communication tool for a game dev team? Long gone.

Now, there’s a huge product team with multiple levels of people making decisions about what should be done and how, and then reviewing the outcome. The bigger the team, the more coordination required. And that takes time.

The outcome, inevitably, means change requests that go back to the engineering team. Which (ideally) can respond promptly, only to have the product organization repeat its thing and take even more time.

No wonder delivering something, anything really, takes so much time. No wonder that lead times (which measure the whole cycle from idea to delivery) don’t improve nearly as much as building.

We Can Optimize Product Decisions, Too

OK, but it’s just an inefficiency of product organization, right? Since it was never a bottleneck, we didn’t need to optimize it. Now that we can get engineering to work so much faster, the next sensible step is to get product people up their game, too, correct?

It depends.

Disclaimer: If you’re reading Pre-Pre-Seed, you know I’m a fan of Lean Startup. And if there’s one part of it that I’m disproportionately attached to, it’s validation. I’m all about “let’s check it” anytime we can.

Having said that, I acknowledge that product management is largely about exchanging opinions. And playing egos. And office politics. That too. Especially that. Should it be like that? No. Is it like that? Sadly, way too often, it is.

It is so in big organizations where hierarchy petrifies status. Whoever is higher in a pecking order has a right to be right. As much as I love the following quote, it captures both the importance of the data and the role of status and ego in organizations.

“If we have data, let’s look at data. If all we have are opinions, let’s go with mine.”
Jim Barksdale, Netscape CEO

The problem is not exclusive to big organizations, though. In early-stage startups, where the whole “product organization” means “a founder,” and there’s no hierarchy whatsoever, it would be just as pronounced. And I’m saying that after directly working with dozens of early-stage founders.

A conviction that they need to launch a startup makes them feel infallible. That’s the same game setup as in a big product organization. It ain’t easy to challenge a decision-maker who knows they’re right. Even if they aren’t.

Now, figure out how to optimize opinion exchange. It’s not as simple as generating more code.

”If We Have Data, Let’s Look at Data”

We can follow Jim Barksdale’s playbook and circumvent opinion exchange entirely by bringing in the data. In a healthy organization, it should be a trick that cuts the discussion short and points us in the right direction.

So how do we get the data? I’m glad that you asked.

We validate. We get something in front of customers, observe their behaviors, and learn. Ideally, it’s a small experiment, with a cheap, expendable prototype that we didn’t invest much in. The reason? 90% of the time, validation means, in fact, invalidation.

How quickly can you go through that loop? Now, we’re talking. Getting the actual human beings who are relevant to what you’re building and willing to spend some time talking about your half-assed idea for a feature is hard work. And it takes time.

Sure, we can optimize some parts of this process with AI. If we need outreach, there are ways to automate it. But the bulk of the work is driving and following a conversation. Without doing the legwork of talking with potential customers, you won’t have anyone to talk to.

I mean, good luck convincing me to have a conversation with an AI bot about your feature idea. If you can’t be bothered to talk about your product, why should I even care?

Can’t We Do With Synthetic Personas?

An alternative way to get the data would be to—yes, you’ve guessed it—generate it with AI. We could create synthetic users and interview them all we want.

Unfortunately, as useful and appealing as this tactic contextually is, synthetic user interviews are no substitute for talking to actual customers. You won’t learn how people behave when using the product, when they get lost, how their actions differ from their claims, etc.

It’s the difference between what’s most likely (which is what AI-generated output is) and the fringe needs, where the most interesting learning is. It’s the difference between speculated behavior and the actual one.

If you consider how much a synthetic user interview validates, it isn’t that much different from the opinion of a person in power. Oh, and if I were such a person these days, I’d make sure to back up my claims with some synthetic data. With LLM’s sycophancy, it would be a piece of cake. Suddenly, we’re playing the opinions game again.

Developers Are Now Outrunning Your Ability to Talk to Actual Humans

Validation is hard. It means challenging your own ideas. That’s never easy. Before that, you need people to do the validation with. It requires prep work. Oh, and even before that, you have to learn how to run the process well, so that your confirmation bias doesn’t take over.

And if all that wasn’t enough, it takes time. Here is a nice example from a company with tens of millions of users.

“The bottleneck of the team was waiting for statistical significance for most of our experiments, despite all the traffic we had. (...) If we changed a copy of our main website or most prominent tools, the experiments were statistically significant within hours. A more complex down the funnel change for higher value customers? Weeks, sometimes months. Ugh.”
Leah Tharin

Even in a setup where you can get willing customers on the spot, validation takes a hell lot of time.

Now, imagine you could cut the time to build the feature by a factor of 10. What used to take a week now can be done in hours. Yet you still wait “weeks, sometimes months” to learn whether it works at all. And if so, how it should be changed.

Sure, in the meantime, you can build a ton of other features. Which would be equally unvalidated as this one. It would only make it even harder to get any signal about whether they make sense.

If we look at the whole feedback loop, the lag is not in the building part. And optimizing development further won’t do as much as we expect. It means optimizing the part that is already short.

It seems a lot like searching for keys under a lamppost because “that’s where the light is.”

No AI was hurt in writing this article. 웃 https://okhuman.com/vms9oQ

Whenever I use an early-stage startup product and end up in contact with the authors, I volunteer to participate in a user interview. I do it without even being asked. Think of it as paying back to the community.

After all, our experience at Lunar is largely about helping the pre-pre-seeds—the earliest-stage founders—succeed with their products. We have a front-row seat to observe how crucial user interviews are and how challenging it can be to get people to participate.

That’s why I’m like “Take me! Let me help you!” Hell, I would even help product people to improve the interview as we go. After all, we’re doing it professionally, remember? It’s a freebie that lands on their laps.

Now, guess. How many times did they follow up to run an actual user interview with me?

Hint: it’s a round number. A very round one...

Subscribe now

Securing User Interviews in Startups

In Continuous Discovery Habits, Teresa Torres argues that we need to run user interviews continuously, i.e., weekly. It’s not a one-time thing that we do during ideation and call it a day.

The reason is simple. There’s no better way to learn whether what we want to build—or what we have built—has value to customers.

A good part of the difficulty in running user interviews continuously is developing a funnel of potential interviewees. We all live busy lives. Cramming an additional 30-60 minutes into our schedules to discuss a product I may or may not be using in a few weeks is not a slam-dunk proposal.

What’s more, in an early-stage startup, the effort we invest in finding these candidates is taken from elsewhere. We run user interviews instead of product development, sales & marketing, etc.

One would think that a free option to run an interview would be a godsend. So why a cold shoulder?

User Interviews Are Hard

I get it, it’s not easy to run a good interview. But if hard things discourage someone, why are they running a startup, again? By the way, when it comes to running good interviews, do yourself a favor and read The Mom Test if you haven’t yet. That’s your go-to starting point for anything-user-interviews. And it will make things easier.

Long story short, if we run an interview to get confirmation that what we’re doing is good, that’s precisely what we’re getting out of it. Then it’s easy to build a perception that talking to potential customers doesn’t do much. After all, we chatted with these people, they told us they’d use our app, and they don’t. Ergo, user interviews suck.

If that’s the problem, read The Mom Test. Seriously. Yes, I know I’ve just said it before.

There’s another challenge, too. If we’re running user interviews well, we should hear things we don’t want to hear. Like that, the idea we’re so in love with is not as good as we thought it was.

A strong conviction in the idea is a prerequisite to playing the game against the odds. And what is a startup if not the ultimate against-the-odds game? It’s our basic psychology (or a characteristic of Kahneman’s System 1) that we tend to avoid and ignore information that doesn’t suit our worldview.

So, if user interviews are going to tell us we’re wrong, we might as well save some time and cognitive dissonance by avoiding them altogether.

Social Anxiety Is a Major Factor

If all that wasn’t enough, there’s another force in play here. Once again, it’s our basic psychology. Reaching out to an unknown person and engaging in conversation is socially challenging for many.

Sure, it’s an individual trait, and there are folks out there for whom it’s like breathing. For many of us, me included, it’s a challenge, and a steep one. If I could get my answers without the need to overcome social anxiety, I’d be very, very happy.

I don’t want to overly stereotypize here (and I will definitely do so to a degree). Yet if we look at the pre-pre-seeds, there are only very few people involved. Also, this group tends to be skewed toward technical skills. After all, they’re building a startup. It’s pretty likely that whoever is wearing the product management hat at that stage is not concurrently a social butterfly. And at this stage, there’s no such thing yet as a bench you can use to get that specific skill set.

It’s easier to dodge the anxiety altogether and focus on one’s strengths (and keep building the damn thing). Hell, there’s a whole line in psychology that would tell you precisely that.

Except when doing that, in one swift move, an early-stage startup removes the key validation tactic. Also, what might work for personal development doesn’t translate one-to-one to building an organization.

Synthetic User Interviews

There is a savior, though. We could easily set up a context for an AI model to act as our ideal user. And then we can interview it till it yields. It’s as easy as giving a model a persona, which we already know. After all, we needed to create it to recruit interviewees in the first place.

Even better, we can tweak the context and interview as many different synthetic users as we want. And they’re available instantly. What’s not to like?

There’s one problem. Large language models are statistical machines with pattern recognition. They’d give you the most probable answer. They won’t give you fringe insight, even if they were trained with such data, because it’s unlikely.

You could get fringe insight if you designed the context to drive a model away from the most likely culprits. That, however, would require you to know “where” that fringe insight is. Which, unfortunately, you don’t, since you’re running goddamn user interviews to learn precisely that.

By the way, that’s why AI won’t create a novel product idea or, in a broader context, won’t get creative from an expert’s vantage point.

So a synthetic interviewee comes with a small print. It’s awesome if you want to explore a known domain that you’re unfamiliar with. Many of the desk research tasks we do during the discovery phase fall into this bucket. That’s where we should ride that wave like a pro.

However, if you operate in a context where you are an expert, you don’t look for the most likely. You know the most likely already. You seek non-obvious. And non-obvious emerges serendipitously.

That is not going to happen with a synthetic persona.

Confirmation Biases

LLMs have a strong tendency to confirm whatever their operators’ views or opinions are. We describe it as AI model sycophancy, and by now it’s a well-researched phenomenon.

That’s precisely the opposite of what we want to achieve in user interviews.

Of course, we can get just as bad results when asking humans the wrong questions, too. Yet, AI adds a whole new layer of confirmation bias. We wouldn’t expect a random user whom we have just met for the first time and will never see again to be sycophantic. We should expect that from an AI model.

Now, we can try to overcome it by carefully managing context. Yet, by narrowing the context, we further limit the odds of creative insight. It’s a costly trade-off, as the whole point of user interviews is to prioritize discoverability.

Interviewing Humans versus Interviewing Models

Looking at the arguments above, seems like a balancing act between higher-quality but more difficult and time-consuming human interviews and readily available but limited-impact AI/synthetic interviews. We should expect a healthy mixture of these. Probably with a bias toward the former, because of the quality.

Well, never underestimate the AI hype. David J. Bland has a nice meme to sum it up.

Talking to AI users is all over the place. That’s what competent folks see. That’s what the majority of discourse covers. Only occasionally, someone stops to ask “why?”

“There must be a reason that synthetic users are becoming more and more popular inside organizations but I can't quite put my finger on it...”
David J. Bland

So let’s do the executive summary, shall we?

Interviews with actual human beings:

• Provide better discoverability by enabling serendipity in exploration.

• Validate (or invalidate, which is equally good) actual behaviors, especially when you can get people to try to use something.

• Are challenging to organize and run.

• Require planning and effort up-front. Quite a lot of it.

• Trigger social anxiety.

• Can turn into a “feel-good” activity.

Interviews with synthetic users:

• Limit discoverability to the most probable scenarios and the prompted context.

• Do not ultimately validate behaviors, at least as long as we target humans with a product (I’d treat AI agents as customers as an exception here).

• Are quick and cheap to run.

• Can be done all the time, anytime.

• Allow dodging social anxiety altogether.

• Will likely turn into a “feel-good” activity.

We could sum up these lists by saying that AI user interviews sacrifice quality for convenience. Put this way, it’s no wonder that people choose AI over an old-school approach. We are creatures of convenience.

In Kahneman’s terms, our brain substitutes a more difficult question:

“What would my target customers actually do?”

with a much simpler one to respond:

“What does AI say that my target customers would do?”

Even if they sound similar, these are two vastly different questions. Yet we’d subconsciously answer the easier one and pretend it was the answer to the more difficult one.

User interviews with AI personas are no substitute for talking with humans. Synthetic user interviews have plenty of value, especially at the early stages of discovery, where we orient ourselves. But the closer we are to validation, the less value they provide.

As my friend said:

“A bad map that looks like a good map is worse than no map at all.”
Derek W. Wade

If you wondered, I do write those, like, you know, “in the olden days.”
웃 https://okhuman.com/VbNTPg

At Lunar, we primarily work on early-stage product development, both with startups and with established companies (so-called corporate Lean Startups). That puts us in an interesting spot. As the product development landscape evolves, we concurrently participate in its different segments.

We can consider AI adoption in product development from the perspective of the innovation adoption curve. Our clients would range from early adopters to late majority. We navigate the landscape where the same thing may be considered reckless in one context and overly conservative in another.

In the space where just about everyone is opinionated, such a diversity of perspectives is, by far, not given. So what patterns do I see as we exchange our experiences from these varied contexts and filter them through two decades of doing the thing?

Subscribe now

1. More Code Is Inevitable

I know, it’s “duh!” Bear with me, though. Yes, it is a central point of the change, but its implications are concurrently overstated and understated, depending on the angle.

Yes, the tools get better. The models that arrived at the end of 2025 and the beginning of 2026 have convinced many influential voices to change their perspectives and switch to code generation. The change doesn’t seem incremental. The new norm is getting to a whole another level of abstraction. We don’t talk code anymore. We talk features and specifications.

We could have gotten huge quantities of code generated earlier. That’s not new. What’s new is that people are starting to consider it for their daily professional jobs. The pace at which we create code, and its amount, goes up fast. And, we want it or not, it is there to stay.

What’s key here is the scale of the change. Again, it’s not incremental. I routinely use a range of 10x to 100x increase, and it seems to be in line with the predictions Simon Wardley recently made at ScanAgile26. Technically, we could have an infinite amount of code, but let’s stick with the assumption above.

2. More Code Review Is Impossible

Save for the expendable code, where we care little about the quality, one widespread go-to technique we rely on to sustain code quality is code review. It goes further than just quality. Thanks to code review, we learn craft, exchange contextual knowledge, discuss the architecture, etc.

The only issue is that code review requires focused attention. We can’t easily scale it up. Not by a factor of 5. Most definitely not 10, or 50, or 100 times.

OK, there’s another issue with code review. It requires judgment, too.

Now, juxtapose these with the first point. We’ll have plenty more code. But we won’t be able to have plenty more code review. What’s the endgame? We won’t be doing code reviews because it would be unsustainable.

We won’t be able to outsource code review to AI either, because it requires judgment, and LLMs don’t do that by design.

So it seems like dropping the code review as our basic safety net is inevitable.

3. Comprehension Is To Be Lost

If we get more code and we stop reviewing it, then what does the endgame look like? Short term, we abandon any pretense of understanding the code as we merge and release it. Long term, we lose any comprehension of what’s technically in the product.

Cognitively, creating code by hand is a very different task than reviewing the code created by someone—or something—else. In the first case, we first ideate the architecture, which we keep as the context while we work on the solution. In the second, we retrieve the broad structure from the code. Well, as much of it as we can.

That’s why we typically rely on code reviews by engineers who know the code base. They have built the context gradually and don’t need to create it solely from the code they’re reviewing.

Except we’ll lose this part the moment we stop reviewing the code. Which we will. Because there will be too much code to review.

In other words, the endgame is that we lose the broad comprehension of the architecture, structure, and functionality of the code.

4. Technical Sustainability Is Unlikely

So we stop reading and then understanding the code. How is it different from us not understanding, say, our car’s engine? A short answer is technical sustainability, or rather, lack thereof.

For now, we see a big gap between what AI models can achieve in generating a single, possibly even large, code chunk and how they handle long-term maintenance. A recent paper replicating a real-life scenario spanning over 200+ days of development shows an appalling regression rate (although Opus seems to be significantly ahead of the pack).

Curiously, we don’t yet have practical examples of such scenarios, as the technology hasn’t been with us long enough. Yet, it is a safe assumption that in the long run, regression will increasingly be a pain in the butt, and maintainability will become a major problem.

So far, we’ve addressed it through ongoing work. As developers touch the old code, they use their judgment to decide whether, and if so, how, to refactor the legacy stuff.

But once we lose comprehension of the codebase, that ship will have sailed. We’ll be down to telling AI agents to “fix it,” which they’ll promptly do. Or not. Or they’ll fix one thing and break two others.

Any developer who has had the “pleasure” of working with a really legacy codebase will instantly understand the experience. The best compass in such rocky waters is judgment—one trait that LLMs notoriously lack.

5. Rewrite Is Only Occasionally Optional

OK, we’re going to have plenty of code that we don’t understand and can’t maintain long-term. It doesn’t look like a winning proposition. But maybe it doesn’t matter. Maybe all we need is to redo the whole thing in one big move once it's no longer maintainable.

I mean, get a swarm of AI agents to redo it. That’s precisely the strategy Steve Yegge suggests:

“Software is now throwaway — expect < 1 year shelf life.”
Steve Yegge

A while ago, Cloudflare reported how they had rewritten Next.js—the most popular React framework. Well, one developer did. In a week. For $1,100 in tokens.

Sure, it’s not production-ready, but still. A thousand bucks and a week of tinkering to get a clone of a major javascript framework? Color me impressed.

Let’s not hurry to jump on this bandwagon, though. One reason why it was even possible was the extensive test suite of the original code. It served as the ultimate specification for AI agents. Remove tests, and you remove the conditions for even considering a rewrite.

And even then, you fall into a trap of maintainability. Again, it’s Steve Yegge (emphasis mine).

“You’ll use agents to make a giant refactoring to your system, and then all the tests will be broken. The agents inevitably struggle to fix them. So one day I said, screw it, delete all the tests and make me new ones. And it got through that exercise SO much faster.”
Steve Yegge

The original tests served as a checklist of all the things that the old product did. Now we delete them and generate an entirely new checklist for a new version of the product. It’s like swapping one safety net for another, positioned in the vicinity of the original place. Probably. Maybe.

It may serve well for the code coverage. Not really for backward compatibility. And once we have a product that works with actual customers, we no longer have the comfort of reinventing it on a whim.

6. Experimentation Is Unleashed

As much as all the above are challenges for a sustainable product, they matter little for an experimental spike. If we want to go toe-deep with an idea, we don’t care about maintainability, rewrite potential, or code comprehension. We want to get something out there and observe how customers react.

The upside, though? The ability to have something out there fast is super attractive.

Some of the frontier teams dropped specifications (also known as Product Requirements Document or PRD) and switched to prototyping altogether.

Before we all jump on the “if Anthropic does that, we should do it too” bandwagon, it’s not that easy. Prototyping as the go-to strategy of product development is not new. Amazon has famously been doing it for years, way before AI.

In either case, the prerequisite is to have a customer base ready to jump at any new product/feature proposal and metrics in place that tell us yay or nay. Both Anthropic and Amazon have that because of the existing user base.

A fledgling startup with an unvalidated idea, though? Not really. So, as much as experiments got cheaper, it still matters a lot how we design them. Relatively few companies can afford the spaghetti strategy: Let’s throw the spaghetti on the wall and see what sticks.

7. Attention Is Limited

The picture so far is like this: We have our challenges, but we should be able to put more code and more products in front of customers. And if we trust Jevons Paradox, the increased efficiency of software development should only lead to higher demand (including demand for software developers).

However, there’s one bottleneck we won’t overcome.

No matter how many new products we have, we won’t have more attention to pay. The day will still have 24h. While our devices can host an infinite number of programs, we will actively use only a handful.

Combine that with the ease of creating new products, and the only thing we can possibly get is more noise. There will indeed be tons and tons of new products fighting for our attention. It will only make finding the good ones even harder.

Speculatively, it may create a reality in which we stick with what’s good enough even if, hypothetically, there were better options. Right now, in any given niche, we may have a handful of choices. But if we can spawn product clones at will, there will soon be dozens or hundreds of options. The Paradox of Choice tells us that in such a situation, we are worse, not better off.

If anything, we may prefer to stick with whatever we already use, both because of analysis paralysis triggered by bountiful alternatives and sunk costs associated with the past choice.

8. Automating Attention Away Is Only a Temporary Advantage

If attention is a pie and everyone fights for a piece, the spray-and-pray approach should be advantageous. Look at the hiring landscape as a perfect example.

If I still handcraft my job applications, how many can I do? Several a day? If you’ve outsourced that role to an AI agent, you apply for thousands of jobs as you sleep. A simple game of volume shows that you have a clear advantage.

For a short time, that is. It lasts only until everyone else picks up the same strategy. And oh, by the way, the hiring companies follow suit (or lead suit, depending on the vantage point) and outsource their filtering to AI, too. Suddenly, there’s more noise everywhere, but the quality for everyone has gotten worse. Also, the advantage of automating the attention away has disappeared by that point.

How can you differentiate? Probably by trying to bypass the new AI-controlled landscape and going back to a human-to-human connection.

The same thing has happened with business outreach. By this point, cold outreach is all but guaranteed to be an AI agent. Whoever is still doing it by hand is losing the volume game. But it only creates more noise and reduces the chances of an outreach attempt being even remotely valuable to zero.

The solution? In our case, it’s physical networking. Yup, avoiding the game altogether.

So yes, automating attention away creates new products, new business, new revenue streams. In many cases, this will be only temporary. Automation will degrade whole areas where human connection had a role into a toxic landscape. In those areas, we’ll reinvent the processes so they again enable value exchange. Anywhere else, which is wherever those bonding signals didn’t matter in the first place, solutions will quickly get commoditized. The margins will necessarily get thin.

9. Niches Are Shrinking

One way to respond to emerging business challenges is to address ever-smaller target markets. Since we can generate software more efficiently, what was cost-prohibitive 5 years ago may be perfectly feasible today.

There is, in fact, a positive reinforcement loop at play here with the ease of experimentation. We can spin off a series of experiments addressing a handful of diverse niches and see what sticks. That, in turn, enables better focus on the specific needs of smaller target groups in any single experiment.

We are, indeed, discovering entirely new business opportunities. It might not make any sense to develop a product for $200k for just a handful of users. However, the math can be very different if we can drive costs down to a fraction of the original estimate.

Another reinforcement loop emerges at the intersection of smaller products and technical capabilities. It’s easier for an AI agent to create a smaller and less complex chunk of code. It’s then easier to sustain human comprehension, should engineers choose so.

It’s as if all the stars aligned to tell us: build less.

However, discoverability will be an uphill battle, as noted above. The paradox of choice and sunk costs don’t go away. Maintainability will be a major pain. It may emerge later with a less complex codebase, but it will emerge nonetheless.

10. Validation Is Ascendant

I look at these trends, and I see an intersection. On one hand, we have easier experimentation and potentially smaller products. It’s easy and cheap to try. On the other, if we’re lucky enough to succeed, we should be concerned about maintainability and technical comprehension.

The things on the left call for YOLO-like tactics that AI agents seem to be providing better and better. The things on the right require a more old-school approach that isn’t only more costly but also demands skills that we actively deprioritize in the early stages.

The key question: What happens at the intersection? And how do we know we’re in the transition?

The intersection is validation. It is anything and everything that happens between Problem-Solution Fit and Product-Market Fit. And I can stress enough how important it is. Especially when it’s cheap to experiment.

What’s important here is that, aside from everything we used validation for so far, it’s also a potential turning point for technical strategies. When we realize we might actually have a sustainable product, it may make sense to invest some effort in ensuring we can maintain it in the long run.

By that point, it will unlikely be just “some effort,” but let’s not complain about the strategy that got us thus far.

Insight Is at the Intersection

Neither of these in isolation is fundamentally novel. It’s just the effect of asking, “If the trends we observe continue, what does the endgame look like?” The interesting part happens when we consider how these things affect each other. In other words, what happens at the intersection. Or the intersections.

Take “more code is inevitable” and “attention is limited,” and we can derive that:

• Products will increasingly not be addressed to humans as users (AI swarms talking to other AI swarms, maybe?).

• Which creates an entirely new economic challenge (because why should a customer pay for a product they don’t use?).

Mix “technical sustainability is unlikely” with “validation is ascendant” and we get:

• Potential reemergence of software developers (this time, they’d be “retaking” control of generated codebases once a product is proven).

• Rise of importance of explicit technical decisions about quality (we can YOLO a prototype before anyone uses a product, but as we go through Problem-Solution Fit, Product-Market Fit, and growth, we’d be questioning how much actual understanding we have).

Between “comprehension is to be lost” and “experimentation is unleashed,” we could expect:

• Consideration of what human in the loop actually means and whether they’re well-suited to make decisions (if they don’t understand what they decide about, do we really have a human component in the system?).

• An emergent chasm between an experiment and a production-ready solution that would be harder and harder to bridge (the easier it is to experiment, and the further we can go down that path, the more work and skills we’ll need to make it work eventually).

What Does the Endgame Look Like?

It is surprising how many AI discussions are single-faceted. “Here’s how much better a new model deals with code.” “Here’s how many people it did replace.”

The thing is, change never happens in isolation. It is all an interconnected system in which second-order or third-order consequences play a pivotal role. The fact that someone can imagine a lights-out, human-unattended codebase doesn’t mean that we should automatically expect it to become the norm. We’ll understand that only when we explore the cross-sections.

Only then, we’ll be asking questions like:

• Can we afford to lose technical comprehension of the product entirely?

• How much of human involvement do we want in software design/architecture?

• What tactics, techniques, and practices can we employ to find a desirable trade-off on that account?

• What kind of skills may be needed to achieve the above?

That’s why we need to consider the product management landscape as multi-faceted. That’s why we need to keep asking: What does the endgame look like?

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

There’s a bit of news circulating in different contexts: AI already writes itself. Most typically followed with a heartfelt “Yippie!”

In the essay that went viral, Matt Shumer painted quite a typical “AI is there to take your jobs” picture. Yet, the bit that few people picked on was about GPT developing itself.

Dario Amodei made a similar claim about Claude. Actually, he does that quite routinely. And when you listen to Boris Cherny—the creator of Claude Code—he explains how they get Claude to write its own code.

We could consider what these claims actually mean. I mean, it’s not that critical who or what types the code. What matters is who or what reviews, judges, and accepts it. And how.

We could ask my favorite question: What does the endgame look like? And we have some potential reasons to worry, as we know that models fed upon their own outputs tend to collapse (to use the term researchers chose).

I won’t dig into these today, though. For the sake of this conversation, I can even flow with the hype. So let’s assume that AI indeed writes itself. If it can do something as sophisticated, it should be able to build your startup’s MVP as well, shouldn’t it?

The point is, it’s the wrong question altogether. Let’s look at some startups from quite a vast collection of those we worked with over two decades and see what we can learn.

Agriculture Startup

The basic idea was to monetize quite sophisticated data that the startup had access to. The product would serve as a reliable early warning of conditions that require farmers to make extra preparations.

Since a lack of said preparation means losing the entire crop, the stakes are high, making the monetization stream potentially lucrative.

Or so they thought. The early user interviews confirmed the basic condition. Yet it entirely challenged an ideated solution. The Total Addressable Market (TAM), which is a function of both user volume and Average Revenue Per User (ARPU), shrank significantly. Especially the revenue assumptions proved overly optimistic.

The reason why I like this story is that we invalidated assumptions before building anything. In fact, the moment we started developing the first prototype (with the big help of AI tools), it was a significantly different idea from what we started with.

Putting pre-development validation front and center was absolutely pivotal, as the main effort wasn’t creating a bunch of features but actually getting the earliest version in front of clients and gathering their feedback (a.k.a. learning). To make things spicier, the vegetation cycle creates a sadline for delivery and validation. The next opportunity window? Next year.

Building the wrong thing, even if you can do it cheaply, has costs that go well beyond the development effort.

Social Betting Startup

It’s a pre-AI story, but still relevant. The idea was to organize a social betting game around professional sports events. Two forces were in play initially.

League season is what it is, which creates uncontrollable time constraints. Sadlines again. However, we suggested pacing the development. It would extend the runway while enabling early end-to-end validation of the product idea. Of course, the price to pay was that the early version of the product would not be nearly as feature-rich as initially planned.

The founder decided to go fast. They wanted to have their vision turned into a working product before the start of the season. Higher pace and higher costs, but a sweet prize at the end, right?

Wrong. The whole thing fell apart late in the process because of legal constraints. To defend the founder somewhat, the legal ruling was not obvious, so it was more of a gray area than a blatant mistake. Still, that aspect being a risk should have been an argument for going slow rather than rushing.

If we started today with AI generating the code, the blocker would have been exactly the same. Going slow would still be advantageous.

Real Estate Startup

An idea to disrupt the real estate industry is not original. There are plenty of startups aiming to achieve just that. Yet doing that in a niche with some very specific (and non-obvious) constraints and characteristics, and building a product around them, has legs.

Unsurprisingly, our suggestion was to validate assumptions with throwaway prototypes (largely AI-generated) and limit the effort invested in an actual product. Luckily, the founder was receptive. Maybe not as in “entirely receptive,” but still.

The product idea had its technical challenges. However, they didn’t matter, as before we could even get there, we got blocked by a non-technical issue. Content availability, which was treated as given, was anything but.

That, in turn, triggered a pivot of an entire product. Which is a “Duh!” for a startup, sure enough. But it also rendered the original specs largely irrelevant. If we’d built those, it would have been wasted effort and money.

Again, it doesn't matter how quick you are if you're just painting yourself into a corner.

The Pace of Development Means Nothing If You’re Building the Wrong Thing

I could go on, but by now you probably get the theme. In all those cases, pushing product development (of the original idea) was a bad move. All that despite the fact that we went through a discovery phase in every single one of these cases. And if anything, we aspire to discourage (or at least challenge) founders during the discovery.

If you’re building the wrong thing, getting there faster just means you dig yourself a bigger hole.

The critical effort in product development is not getting something out there. It’s figuring out what the right thing is to get out there. And yes, building and deploying it is one way to figure it out. Not really an optimal one, though. Actually, I can hardly think of a less optimal path.

The inquiry path should always be:

1. Identify the key hypothesis to validate.

2. Figure out the most effective way to verify whether it’s true.

3. Execute.

Occasionally, building the thing may be the most effective way. At some point, it may be the only way. I mean, you can’t be 100% sure people would use the product unless there is a product to use. However, before we’re ready to close the very last gap, there’s typically plenty of better validation methods.

Zig-Zagging Amplitude Matters More than Pure Speed

One of our clients uses the metaphor of zig-zagging. He’s been in this business long enough to understand that there’s no straight path to success. As he puts it, there’s always zig-zagging.

If you look at it this way, an effective strategy to get “there” is not necessarily running faster. It’s optimizing for course corrections. In other words, limiting the amplitude of zig-zags.

Now, the enthusiasm we see for AI largely centers on how fast we can go with developing new features. It’s not about the amplitude of zig-zags at all.

Granted, there’s an advantageous part. If we go faster, we reach each turn sooner than we would have. There’s a cost, too, though. Since we go faster, we’re bound to have more momentum in each swing. The zig-zags get wider still.

Validation Is the Bottleneck

There’s another part that we often miss. The speed-up effect is limited to only a part of the process. AI can indeed generate features fast. But that does not necessarily mean we get through the entire cycle equally rapidly.

And it’s the validation part that makes us adjust the course. Remove this, and we’d be going off the chart. And not in a desirable way.

If anything, the new setup inclines us to go further before evaluating and correcting. After all, building gets faster. Validation is just as slow as it was.

Now, it’s nothing new. Validation has been the bottleneck the whole time. We can get Claude Code to generate an MVP way more efficiently than we developed it 5 years ago. Heck, at this stage, we can even ignore concerns about the long-term sustainability of AI-generated codebases.

None of these will magically make startups succeed, though. If we are building the wrong thing—and, statistically speaking, we do—development pace doesn’t matter nearly as much as we’re told.

“There is nothing so useless as doing efficiently that which should not be done at all.”
Peter Drucker

This post has not been created with Claude Code. 웃 https://okhuman.com/a3oeOg

One message that gets amplified among people diving into AI is that the cost of software development will approach zero. What often follows is the suggestion that it will be easy to build new products.

At Lunar, we’ve been rowing the opposite direction for more than a decade. We advised early-stage founders to build less. Now, one could argue that it was a sound strategy when software development was expensive. Except, as per all the buzz, it is not so anymore.

And yet, I firmly stand where I have been. The Build Less Hill. We can discuss whether the cost of building maintainable software is really approaching zero. Yet, for the sake of this very argument, I may assume it is. It changes nothing. Building less is still a winning product management strategy.

Subscribe now

A Story of One of the Most Successful Digital Products on Planet Earth

Debuted in 1998 to quickly dominate and redefine its niche, 28 years later, Google Search is still with us. “Still with us” is an understatement, though. It remains the most popular website on the internet. It was the cornerstone of the commercial success of what’s consistently one of the most valuable companies in the world.

If there has been a contest to decide the most successful digital product ever, Google Search would definitely be a contender.

After almost 3 decades of development and what we can assume to be tens, if not hundreds, of billions of dollars in lifetime development costs, Google Search serves as a perfect reference point for product management discussions. With such a huge investment, it surely has to have a ton of features.

Nope. Not really. The product is almost as barren as it was in its early days. Yes, we keep complaining about how Google pushes AI answers, product listings, and whatnot to the search results. Before, it was about the sponsored results, and even earlier, ads. Yet despite the billions Google pumped into Search, the product offers shockingly few features.

If the theory that adding features automatically increases the value of a digital product is true (I’ll call it the Build More theory), Google Search shouldn’t exist. Not in its current form. After three decades of adding features, it should have been a combo of Amazon, Salesforce, Facebook, Jira, and what have you. And yet, it is stubbornly clean.

A Curious Lesson from AI Products

“OK, boomer. Don’t “Google” me here. It might have worked 20 years ago, but we now live in the AI era. Things are different now.”

You don’t say. Is that why, literally, the industry consensus is to copy Google Search’s minimalist design and not overload users with visible features?

With all the chat about new AI capabilities, we seem to stick to the good old “less is more” mantra. Especially when it comes to anything human-facing.

Somehow, all these new-era darlings do not flood us with tons and tons of new features. If anyone could create them for “zero cost,” it would be AI labs. And they need to scale the revenues badly, given how much they’re bleeding money (as per their own reports and independent inferences). Oh, and there’s no lack of appetite for broadening their offer, either.

So maybe, just maybe, an ability to generate software for free isn’t that much of an advantage.

The Worst Kind of Nothing

Some time back, wrote a piece on how to be an impactful product manager. The essay stuck with me. Especially the phrase about expensive nothing (emphasis mine).

One CEO who spoke to me about a CPO role described their last head of product as “the worst kind of nothing - an expensive nothing”.

Ibrahim Bashir

While the remark applied to a less-than-great Chief Product Officer, it’s just a proxy for the impact of the products they were working on. By the same token, you could assess products, product increments, or even individual features.

Product changes (product deltas, as I frame them) that neither move the needle nor allow the product team to learn something new are the worst kind of nothing. Expensive nothing. Unless a new feature actually harms the bottom line, that is. Then it’s even worse than expensive nothing.

Google could have added every feature we can think of to Search. Hell, I bet they experimented with quite many of them. And yet they resisted the temptation to add more stuff over, and over, and over again. We still have that (relatively) clean UX to work with.

Build More versus Build Less

Google’s product management masterpiece was not relentless building (a.k.a. Build More). It was the rigorous scrutiny of everything that, eventually, was not added to the product (a.k.a. Build Less).

If we had a magic wand that would make development costs marginal, the outcome would be similar. In fact, Google is so flush that the billions they spent over the years on Search were, in fact, marginal for them.

So, even if the cost of software development really is approaching zero, it changes little. Product does not equal code. Product development does not equal software development.

It’s almost fascinating to observe as we fall for the vision of cheap software generation as a pivotal game changer in an industry that sports an appalling 90% failure rate. We have 99 problems, but a cheaper software development ain’t one.

Validation is Essential

There is one more lesson to take from Google Search and from any other product that has been successful for decades. It’s about how they managed to stay relevant throughout all that time. By now, it should be pretty clear that it’s not more features. What then?

In an earlier piece in which I argued that the pace of development has never been a bottleneck in product management, I made the following observation.

In other words, we never know upfront what will work in a product. We try stuff, see what works, stick with what does, drop what does not.

We can boil it down to one critical meta-skill: validation. Or, more likely, invalidation, since the vast majority of product experiments fail.

For any product-focused person, be it in a startup or an established product organization, validation is an absolutely pivotal skill. And since the discussion with Ibrahim Bashir on “the worst kind of nothing” in product management led us to publishing my guest post on that very topic on his Run the Business, I can only recommend picking it up there.

Run the Business

(In)Validation: The Pivotal Product Management Skill

Sometimes my writing leads to interesting conversations - my recent post on The Unimpactful PM caught the eye of Pawel Brodzinski who writes The Pre-Pre-Seed - below are his thoughts on a pivotal product management skill: idea invalidation…

Read more

4 months ago · 3 likes · Ibrahim Bashir

This post has been human-written. Srsly. I have proof.
웃 https://okhuman.com/FZhXiQ

Last time I made a jab at the so-called SaaSpocalypse, I focused on its financial aspects. Long story short, it’s not an apocalypse. It’s just a regression to normal. And if it all sounds significant, it’s only because the digital product companies were so overpriced in the first place.

The second challenge stands, though. As the story goes, we can all be product developers right now. With the help of modern AI tools, we can generate software that was unthinkable just quarters ago.

That was, in fact, one of the central assumptions of the viral Citrini prediction, or should I say Citrini Prophecy, that painted a grim picture of “2008 global intelligence crisis.” Although you can take only my word for it, this essay was written before Citrini published its doom and gloom scenario.

Update: While the Citrini Prophecy was dubbed as “a substack post that can crash the stock market,” the panic was short-lived.

If you follow the train of thought below, the bounce back shouldn’t come as a surprise. In fact, I don’t claim to possess some secret knowledge. Anyone with a decade of experience in digital product development could probably land with similar conclusions.

So, a well-written prophecy, even if viral, is not yet a reason to panic.

Homebrewed Products Will Eat Incumbents

Here’s a story like many we hear these days. One of my friends ditched Notion, Harvest, and Zoom subscriptions, as he got AI agents to generate a productivity tool for him. A couple of others independently tried to create a prototype that would venture into Duolingo territory. Yes, that Duolingo that seems to be bleeding out despite making a record year on all accounts.

And that’s just evidence coming from my small circle. Imagine people doing that en masse, and the landscape for SaaS products must be all different. Customers drop their subscriptions as they build custom solutions for themselves, while wannabe founders create a fleet of products trying to carve out some of the revenue pie for themselves. Some eventually succeed.

The effect compounds till the existing businesses are no longer what they used to be—shrinking instead of growing.

Subscribe now

Prototyping Is Fun

While some would dub me an AI skeptic, I am a raving fan of AI in prototyping and validation. Going toe-deep with a new idea, be it for a feature or a whole product, is easier than ever. Getting something “clickable” that enables early feedback or even just auto-reiteration of the idea is as easy as writing a prompt.

With some degree of tech-fu, we can make software operational. By that, I mean functionally working in a limited set of scenarios. A capable developer can create a productivity app or a taskboard for themselves. What’s more, it’s ideally crafted to their specific needs.

Scratch-your-own-itch solutions will see plenty of such experimenting. Was it enough to disrupt the existing SaaS model, I’d be preaching SaaSpocalypse to anyone who cared to listen.

Alas, it is not.

Maintenance Is Not Fun

Owning things is a liability. Software is no different. The cost of creating it may be one-third of the total expenses. The rest? It goes to maintenance. Issue fixes, adjustments, changes, security patches, technology updates, infrastructure checks, and whatnot.

A side note, it’s funny how, on that account, software products seem to be similar to premium end products, from military equipment to yachts. Maybe software is a premium product? What would we know?

The point is, though, that the effort required to keep software running is significant. More significant than creating it in the first place. Not only that. It’s also not fun. Not fun at all.

Part of the work comes on its own schedule. Something is broken, and we need to fix it, or we can’t use the app. The security issue is there, and we’re vulnerable unless we apply a patch. And it doesn’t even give us a dopamine rush from accomplishing something. It’s just as it was before. The app still works. Congratulations!

The freshness of the other part—adding new features—evaporates soon, too. It used to be a pet project. Right now it’s just a tool. The UX we decided on doesn’t make much sense in retrospect, but it is what it is. We park our frustration because fixing it would require going back to the whole thing. That. Was. Supposed. To. Just. Work.

Anybody who’s been with their pet project for the long haul instantly understands the feeling.

Accumulation of Tech Debt

And then, there’s tech debt. Generating software with AI gives us a neat illusion of working code. We’d better not look under the hood. Unless we are very rigid about how we prompt, and have expert tech knowledge, and review the generated code thoroughly, we shouldn’t expect anything other than a big ball of mud as the outcome.

If that’s a starting point for the ongoing work of our AI agents, any changes we apply to the product will quickly snowball into something unmanageable. Any single fix will keep breaking other things at random. In old-school software engineering, it’s one of the least fun environments to work in. And it’s not any different with prompting.

Even if the early progress makes us feel invincible, the long haul is anything but. Each consecutive code change is more challenging for an AI agent. Since it will make adjustments, whether it “knows” how to do the task or not, the situation eventually deteriorates to a point where progress grinds to a halt.

We’ve seen that over and over again when humans typed the (crappy) code. With AI, we can get there faster. Like, way faster. If anything, time-to-frustration has shrunk.

Is It Worth the Time?

Between the AI bills, the time willingly spent on early development, not-so-willingly spent on later maintenance, and dealing with the crippling tech debt, we may start asking ourselves questions. You know, questions like:

• Was it worth it?

• Am I really better off saving on a $20-a-month subscription?

• Is my home-brew solution actually better?

Ultimately, we will predominantly arrive at the same conclusion. And it will be in line with Betteridge’s law of headlines. If we need to ask ourselves these questions, then the answer is a straight no.

A company that specializes in developing a specific tool will have advantages beyond efficient code generation (which we can now match, at least in theory). It’s a relatively safe bet that all those advantages are worth $20 a month, which a user would pay for a subscription.

In other words, pet projects will remain just that. Pet projects. They’re fun to play with when they’re fresh, but then we move on to another new shiny thing.

Just make a list of past hobbies, consider how they were “active” over time, and assess which you would still name a hobby today. If anything, pet projects wouldn’t even last as long as your average abandoned hobby.

Pet Project Is Not a Digital Product

What if a pet project turns into an actual product? Or when it’s been considered a product candidate from the outset?

Well, that’s a different discussion, indeed. Yet, this line of thinking is easier to dismiss altogether.

Successful product ≠ code.

In the early-stage product cycle, code generation offers an advantage only in specific stages. Even if we optimistically assumed that the generated code was of production quality, which it is not, that would allow us to make a couple more shortcuts. The rest of the typical product development mess remains largely unchanged.

AI agents won’t make sure you run your user interviews effectively or make good judgments about the feedback you collect. If anything, it will create the “let’s skip this whole Lean Startup thing and go straight to building” highway. While definitely an option, that’s not really an approach I’d bet on.

Moats Are Still There

As much as we keep hearing that there’s no moat anymore, it ain’t true. My friends taking their chances against Duolingo face an immense moat. The incumbents have:

• Validated feature-set.

• Even bigger invalidated feature-set.

• Existing customer base that generates revenue and profit.

• Users who provide usage data.

• Free cash flow that they can redirect in a myriad ways.

• Known brand.

• Investors’ trust.

• An option to purchase an aspiring startup if it’s too promising.

Even if the product and model were entirely copyable, Doulingo shouldn’t worry that much about the next startup with the mission of disrupting or reinventing language learning. They should look at Google Translate, as, in collaboration with Gemini, the duo could easily handle the “lingo” part. And Google is nothing if not flush.

So no, I don’t expect to see a myriad of super-successful startups threatening established SaaS businesses. Product development is a more difficult challenge than building features at a good pace. It has always been.

People will keep trying to build products. More of them will. The bar for trying, a.k.a. prototyping, is way lower than it used to be. The bar for making the product successful in the long run is as high as it was.

Possibly even higher, since all the other people trying to prompt their way to a successful startup will make the landscape so much noisier. Getting through with a good idea will be harder than ever.

The digital product landscape will be very much like the rest of the internet. We can easily generate a lot of stuff. The only problem is that we don’t have any more hours in a day or any more attention we can invest. 10x or 100x times as many new products don’t create a reality in which 10x or 100x as many startups succeed.

If anything, that is yet another reason for SaaS to survive and thrive in the long run. Those that are already established and those that will be lucky enough to make it.

In the first part of this mini-series, I touched upon the financial arguments against alarmist tones.

This post has been human-created. Yup, it’s a genuine bio food for LLM training.
웃https://okhuman.com/tBvzhw

You’ve definitely heard it: it’s the dusk of SaaS. It’s as if we’ve got evidence coming from every direction. Here’s a random set of conversations I had last week.

1. A chat with a fellow leader from a software development company about how they get less and less work, which used to be mainly all sorts of SaaS startups.

2. A story shared by a former developer-turned-product-consultant about how he’s now dropping his productivity tools (Linear, Harvest, Zoom notetaking, etc.) as he’s generating his own tailored productivity tool with Claude Code.

3. Discussion about Duolingo, whose valuation, despite showing healthy financials, nosedived.

4. A conversation with a friend who has an idea to disrupt language learning products with (obviously) a largely vibe-coded tool. Curiously enough, that wasn’t my first friend who set out to pursue the idea over the last year.

I didn’t even reach out to have those exchanges. They came to me organically. In just one week. One might look at the list and suggest that the world is giving us hints.

It’s easy to build a consistent picture of a new reality. One where it’s easy to generate yourself a digital product. Either for own use—and drop all the subscriptions as a result—or to commercially challenge incumbents. One way or another, old-school SaaS would be doomed. Sure, it won’t go down with one quick hit, but a thousand cuts will eventually do the job.

Or will they?

Subscribe now

SaaSpocalypse In Pictures

Let’s look at a few notable examples of what’s been dubbed SaaSpocalypse—the culling of established SaaS businesses. One of the most vivid examples is Duolingo.

A remarkable 75% slide down in 12 months. Color me impressed. All while reporting most active users ever, best revenues ever, best profits ever, and becoming a poster kid for AI adoption (for better or worse). It’s as if they crossed all the t’s, dotted all the i’s, and they still got brutally punished by the markets. Interesting, isn’t it?

While Doulingo is, indeed, a vivid example, they’re hardly alone. Salesforce has just had a record year, too. Sure, the dynamic of growth is slowing down, but what do you expect of such a behemoth? The share price, though? Down by 40%.

Intuit is in the exact same spot. Everything’s up. Save for the stock price, that is. The valuation went down by 30%.

We could go on and on. The question worth asking: Why is it so bad if it’s so good?

What Has Changed?

Obviously, the future projections SaaS companies make may be somewhat more conservative these days. But would that justify such a sell-off? My friend might have ditched Notion, Harvest, and Zoom subscriptions, but how many people would need to follow suit for the product companies to notice? Klarna might have been a big Salesforce client to drop, but we don’t hear it becoming a trend.

For now, it’s still anecdotal evidence.

Ultimately, if such stories scaled, we’d see the impact in the numbers: active users, revenues, profits, etc. And we don’t. Duolingo isn’t worried about two of my friends trying to make a shot at its business. Investors are even less so.

Even if we could generate a product with AI (we can’t, and it has nothing to do with how good the latest Claude Code is), the sheer scale of operations would give plenty of warning before these established business models collapse.

The landscape we see is not that different from what we saw a year ago, but suddenly all we see is gloom and doom.

So what the hell is going on?

The Starbucks Test

The answer may be simpler (and more boring) than we expect. SaaS companies were simply overpriced in the first place. Let’s take all those Duolingos, Salesforces, Intuits, et al and run the Starbucks Test against them.

The Starbucks Test

1. Check the revenues and profits of an established company for the past few years.

2. Assume it’s Starbucks (or any other brick-and-mortar business, really).

3. Figure out the valuation of the company.

We look at the same numbers but draw different conclusions altogether. Established, healthy brick-and-mortar businesses might have their valuations in the range of 25x-30x their net profit. If we looked at, say, Walmart, it would be the same. That is, before investors started treating Walmart as an ad company and pumped its share price.

It makes sense. If you were to buy a private business, waiting 25 years for a return on investment is already too long. Thus, we arrive at such valuations on the premise that there’s a good chance the business will grow and return on investment will arrive early. In other words, these already assume future growth.

So, how would our SaaS companies fare against the Starbucks Test?

The Starbucks Test and SaaS

Save for the last year, Salesforce hovered between break-even and $4B in net profit over the past half-decade. Then it jumped to ~$6B net profit last year. The Starbucks Test would then suggest a valuation around $120B if we considered a broader time window. More if we believe in above-average growth potential (treating Starbucks’ growth as a benchmark).

If we took only the last year as the most meaningful reference point, then $180B might make more sense. Surprise, surprise! That’s where Salesforce’s valuation is now.

Intuit then. Net profits of $4B would put us at a $120B valuation tops. Wanna guess where the discounted stock price lands Intuit now? Yup, just slightly below that mark.

Duolingo? Admittedly, it’s a less established business than Salesforce or Intuit, and it still seems to be on a more aggressive growth trajectory. Still, with their actual net income of ~$160M, the Starbucks Test would suggest a valuation of around $5B. Yes, that’s precisely where it went after the year-long ride not-exactly-in-the-most-desirable-direction.

Can you see a pattern?

One way of framing these stories is that the market stopped treating SaaS as a privileged player. It’s not an apocalypse. It’s just the end of privilege.

Admittedly, losing a privilege may feel like an apocalypse to the formerly privileged. But that’s another discussion.

Regression to Normal

The end of SaaS is not nigh. If anything, the markets found a new darling (AI labs), and the old one is not nearly as fashionable anymore. As a result, the part of valuations based on the promise of future hype disappeared.

It’s not a default assumption that a SaaS product will be growing nearly indefinitely. Such a perception must be earned. For an old-school SaaS product, that is. If you’re building the next-generation-AI-whatever, you can still count on the implied future growth bonus. Hell, if you do that and co-found with some prominent experts, you can cash in on 10x such a bonus.

For everyone else, we started treating digital product businesses as we would any other endeavor. We care more about the numbers we can see, which describe the actual current realities, rather than future projections, which are—let’s admit it—mostly smoke and mirrors.

Startup growth projections were notoriously rosy and as notoriously unreliable (and it’s largely VC’s own doing, let me add). The investors chose to “believe” in super-optimistic projections only because occasionally a startup would go supernova and erase the losses from everyone else who vastly underdelivered.

It was a shaky structure from the very beginning. At the risk of pissing some people off, I welcome the change. SaaS valuations were absurd. And yes, that makes AI labs’ valuation an order of magnitude more absurd in comparison. I, for one, prefer a reality with more modest and healthier assessments.

SaaS as a Business Model Is as Viable as Ever

The subscription-based payment model is as viable as ever. In fact, many companies hit hard by the SaaSpocalypse have just reported strong financials.

As consumers, we grow more and more accustomed to paying for services. Just check how many subscriptions you had two decades ago, a decade ago, and now. I bet the trend is as clear as day.

We’ll never grow short of “our needs we want addressed,” so there will always be ideas for new products and services. Yes, the options we have to address these needs evolve (I’m looking at you, Anthropic). Thus, the products and services we create will evolve too. We can count on human ingenuity and entrepreneurship to see those needs turned into solutions. And we’ll still be paying for them “as a service.”

And if you need a final argument, the rockstars of the startup world—the AI labs—are selling their stuff under the very same subscription-based model. Sure, they do it in a hybrid way (subscription plus usage), but it’s only because they can’t afford a pure SaaS model.

The solutions change. Business model? Not that much.

There is another side to this discussion, focused on the vision of everyone being able to generate their own custom products. This post is already long enough, however. Let me cover the “everyone will be a product developer, so no one will need SaaS” issue in the next article.

Update: A follow-up part that takes a jab at SaaSpocalypse from the product development perspective.

There have been two very similar projects with vastly different timelines.

Project A:

• Built for an established company.

• Covered a new product idea (a small pilot) for their customers.

• Greenfield codebase.

• Developed by a team of 3 people, with one strongly biased toward the product ownership role.

• Mostly an outsourced team.

• Timeline: 9 months (on and off), and counting.

Project B:

• Built for an established company.

• Covered a new product idea (a small pilot) for the internal use of one of their teams.

• Greenfield codebase.

• Developed by a team of 3 people, with one strongly biased toward the product ownership role.

• Mostly an outsourced team.

• Timeline: 3-5 weeks (depending on how you account for conceptual work), and delivered.

The only difference? Mindset. In the first case, despite a startup-like team, the sponsors treated the whole endeavor as a regular corporate project. In the second, it was a classic Skunk Works attitude that limits red tape to a minimum (and then some), to enable quick progress.

Project B embodies an idea of a Corporate Lean Startup. Arguably, an environment even more suitable for the method than a typical early-stage startup.

Subscribe now

Lean Startup Mindset

As I was going through the details of these two endeavors, I was surprised by how many aspects matched one-to-one. Even the finer details, such as team experience, security guardrails, or technology stack, were the same.

Alas, in Project A, any time we had a potential external dependency, we were routed to the corporate grinding machine. Like with the infrastructure. It was yet another ticket for the security team to decide where, when, and how to deploy the app. Expected response in 3 weeks. Which, by the way, never arrived. Despite all the pinging.

Project B? Do whatever’s fastest. Make sure it’s secure. We’ll figure out how to merge it with the existing infrastructure when we need it. If we need it at all.

It’s ruthless compliance versus relentless validation. The former is the default behavior for an established company. The latter is an operating system for a fledgling startup.

Now, it’s not to say that we should ignore compliance entirely. There’s a good time to take care of it, except it’s never at the inception of product development.

Most of the time, product validation means, in fact, invalidation. In each such case, enabling a corporate mindset and addressing compliance from the outset does not make the slightest sense. There are literally zero people who care whether the product that never made it to the market followed all the relevant guidelines.

The difference, thus, is almost purely a matter of mindset.

It Starts with Budgeting

Here’s a tricky part, though. An average corporate product owner would rarely, if ever, have enough positional power to influence the organizational mindset enough to turn Project A into Project B.

In established hierarchical structures, typically, power comes from the same source as the dollars do. Thus, the pivotal people would be sponsors. In fact, it checks in the stories I shared.

Project A funding was like:

• Prepare the broad scope and estimate for an entire product.

• Given that the hundreds of thousands of investment sounds excessive, let’s build only the first part for a small chunk of money.

• Come back to report what you achieved so that we can enter another budgeting cycle.

Project B, in turn, was like: “Here’s a very modest sum. Make sure by the time you run out of it, you’ve validated the idea somehow. Off you go. Shoo.”

Consider the difference. In the first case, the starting point is the product vision. We provide the scope, estimate, and, eventually, the money as derivatives of a (not-yet-validated) hypothetical product. In the second scenario, we make a bet. We start with money and derive the product vision against that constraint.

Funnily enough, starting with a big-ass product vision guarantees that you won’t secure full funding. Finance gatekeepers would push back on absurd budgets required to build the entire thing. The exercise of figuring out the detailed vision and estimation is thus a waste of effort.

It’s ironic that both Project A and Project B landed with similar initial budgets. I can only assume the difference in effort between these two budgeting processes. If I were to guess, I’d go with 3 orders of magnitude.

The Mindset Starts at the Top

If Project A sounds like the norm, it’s because the vast majority of new product development efforts follow its pattern. The reason is very simple. If there’s a decision between Path A and Path B, it’s the sponsor’s call.

It’s not with a product owner, whose interest may lie in a more effective progression toward (in)validation. It’s with someone high up in the hierarchy, who’s most likely disconnected from such trivialities as product development tactics.

What’s more, in most established organizations, the decision-maker will be judged by whether they played it safe. Safe means extensive up-front planning, a corporate budgeting process, and all the compliance they can think of. None of the actual startups follow this kind of playbook.

When a corporate world aims to build a new product, the first question should be: What’s the mindset of a product sponsor? Then a follow-up one: Do they have enough positional power to run something like Skunk Works if they choose to?

Give me good answers to these two questions, and that company will have a head start over any actual startup trying to build in the same niche.

It’s as little (and as much) as the mindset difference.

This essay was human-written, as if it were the 2000s. 웃https://okhuman.com/77nGgA

I was supposed to write more about corporate startups this week, but another bit of news was the proverbial last straw to break my back. Techcrunch reports:

“Humans&, a startup with a philosophy that AI should empower people rather than replace them, has raised $480 million in seed funding at a $4.48 billion valuation.”

You may consider it just yet another random piece of news from the startup ecosystem. But it’s way more than that. It’s like another breadcrumb that allows us to uncover the secret playbook for securing unprecedented levels of funding.

Bear with me, we’re going to explore The Secret AI Startup Funding Playbook™.

Subscribe now

Humans& Story

To better understand the context, let’s look at the story behind Humans&. Let’s start with data.

• The company was founded in October 2025.

• Founders recruit from researchers and engineers of the biggest AI firms, Anthropic, Google DeepMind, and xAI.

• Three months later, they secure half a billion dollars.

It’s not like they have a product or something, let alone any traction. Sure, they have a vision.

There is no product catching up like wildfire. There isn’t even an announcement of one. There’s just an aspirational promise that “AI can be reimagined, centering around people and their relationships with each other.”

Well, that’s it. The end of the story.

See? All those things that they kept telling you about traction, hockey stick growth, and stuff? Doesn’t matter. You don’t discuss the shape of the growth curve if there’s no growth.

Heck, the whole product you need is a landing page.

Humans& Is Not an Outlier

OK, a reality check. Is Humans& an outlier? Maybe they just got lucky, right?

No. There are more of them breadcrumbs. That’s the whole thing. The VCs don’t want you to know that there is a pattern. Take Unconventional AI.

• Do they have a product? Nope.

• What’s their foundation-to-absurd-seed-round time? 3 months.

• Did they secure at least a few hundred million in the seed round? $450M to be precise.

• Was the founder any famous? Duh!

• Is there a bold, aspirational mission? How does “optimizing energy efficiency for AI” sound?

• Does their site look like a vibe-coded landing page? Sure enough.

Well, at least they have a blog. With a single welcome post, let me add. Oh, and a broken email subscription.

The AI Startup Benchmark

One story to rule them all is that of Thinking Machines Labs. It’s like the gold standard for securing seed rounds in the AI era.

Established in February 2025 by none other than a former OpenAI CTO, Mira Murati. You can hardly score any more clout points than that.

How about an aspirational vision? Well, don’t tell me that “empowering humanity” is not enough. To top that, we get nods to collaboration and AGI, too.

Some 5 months later, they secured a $2B seed round, at a $12B valuation, which easily dwarfs the tens of billions thrown at OpenAI earlier that year, on my personal scale of VC recklessness.

Yes, that was before Thinking Machines Labs announced what product they were working on, let alone released anything, or shown any traction whatsoever.

Charisma and Storytelling Worth Hundreds of Millions

While Thinking Machines Labs’ record remains unbeaten, there’s no shortage of contenders. Yann LeCun, a proper AI celeb, eventually got fed up with Facebook and decided to go off and start his own thing.

Do you want to guess what kind of valuation he expects? If you’re guessing billions, then you’re correct. He aims for $3.5B from the outset. I bet he’s getting the money. After all, he’s no short of charisma and has a good story to tell.

If you reverse engineer all these stories, they are curiously similar. They revolve around a (relatively) famous founding team and a vision that is bold enough to play VC FOMO. They also have nothing to show for it. No product, no public announcement, no traction. It’s all belief money.

It’s the literal equivalent of friends & family round. The pre-pre-seed. Except it’s not tens of thousands but hundreds of millions. 4 orders of magnitude bigger.

And yes, it goes against every single bit of advice you could possibly get from VCs. No one is going to admit that there’s no defensible process behind these decisions. You could say it’s pure gambling, but gambling is the VC’s regular day at the office. Those AI investments are pure recklessness even by those already low standards.

The Secret Startup Playbook that Makes Founders Rich

The most basic advice you get when gauging organizational culture is to observe behaviors rather than trust official messaging. It’s “do what they do, not what they say.”

That way, you can reverse engineer the actual playbook to follow if you want to fund your startup beyond your wildest dreams.

The Secret AI Startup Funding Playbook™

1. Get some well-known names from major AI companies to co-found with you. Bonus points for C-level execs, AI researchers, and professors.

2. Define a super-aspirational moonshot AI goal as a mission. Bonus points for helping the entire humanity or reinventing entire domains.

3. Work on something (doesn’t really matter what exactly) for a quarter or so to create an impression of progress. Bonus points if you can lure some more engineers and researchers from major AI firms.

4. Get your hundreds of millions in the seed round. Voila!

Yup, that’s it. No scrutinous validation. No rigorous product experimentation. No meticulous growth management. Not even creative number crunching. No nothing. It’s literally a sure-shot way to build a unicorn.

Bulletproof Strategy

To make things even better, not only does The Secret AI Startup Funding Playbook™ sidestep the toil of careful product development, but it also isolates a startup from the consequences of future problems.

Consider Thinking Machines Labs again. In September 2025, they actually released their first product. To a rather lackluster reception. No market enthusiasm? No problem. They still have their $2B on the bank account.

Soon after, they started losing key personnel, including (most recently) co-founders. Any worries over that? Nah, not really. The VC commitment was not about mere millions, so the runway is incredibly long. There’s no need to get back for more money anytime soon.

If it were your average Joe’s startup, by now, someone would be borderline panicking. The end of the runway approaching at high velocity, not nearly enough traction, and key people jumping ship could sink an established company, let alone a fledgling startup. Thinking Machines Lab, however, can easily ignore all these and more. They’re like a juggernaut of the startup world.

The Secret No VC Is Talking About

Raising an absurd seed round removes accountability for so many areas that it basically breaks the game. The product? We’ll figure something out. Eventually. The founding team? With all the money, we can always lure someone to take over. Fundraising? We won’t need that anytime soon.

The only challenge is really raising that insane money in the first place. Luckily, even for that, you only need to sustain the act for a few months. Then, you enjoy burning through a pile of gold doing, well, whatever the hell you want, really.

Even better, once the money runs out, there will be no shortage of opportunities for a soft landing, as former Thinking Machines Labs co-founders clearly show by rejoining OpenAI.

No one’s going to tell you the playbook works. But remember, do as they do, not as they say. The decades of insisting on growth, revenues, traction, etc., are child’s play now. Truly successful AI entrepreneurs don’t need to care about any of those.

Meanwhile, along with our client, we’ve delivered a working product pilot in a few weeks for around $30k. We’re not going to reinvent education or change humanity. But the early results suggest it delivers value, and we’re confident it has the potential to become a full-blown product.

If you want to discuss these kinds of “playbooks,” I’m always happy to help.

Note, though, they do involve some actual product-development-fu. They may not get you a Techcrunch story, but if you want to build something that’s actually sustainable, I’d suggest it’s a much better path.

This essay has been written by a human (yup, that’s me, tapping into the keyboard).
웃https://okhuman.com/9xOtGg

One of our current clients at Lunar is an established company with their own technical team. And yet, they came to us for help with a new product idea. Right now, we’re building a pilot, which we’ll validate with a few early customers.

The timeline? Weeks.

And that’s precisely the reason they went with us:

“If we were to go with our internal team, it would probably take around a year.”

It’s not that the actual development would be that much more, even though I’m a massive fan of a focused team of 2-3 developers. At the pre-pre-seed stage, rarely more is needed. It’s just that securing the right people and freeing them from all the other arrangements would mean a lot of corporate politics. Outsourcing a small effort was a neat hack in this situation.

However, can you even say that a new product in an established company is at a pre-pre-seed stage?

Subscribe now

Corporate Pre-Pre-Seed

When Lean Startup emerged as an approach to early-stage product development, it didn’t take the stage by storm. While it was an instant hit among those with multiple failed products at their belt, the startups were still all-in on a “brilliant hacker” myth:

“Mark Zuckerberg didn’t need no Lean Startup to make Facebook what it was. He famously moved fast and broke things, and just look where it got him.”

Thus, a side idea emerged. What if we applied Lean Startup principles and techniques in a corporate environment? After all, corporations start new products all the time. What’s more, in product development, they tend to be slow and financially ineffective, so even if Lean Startup was overkill for a startup, in the corporate world, it would have been a huge improvement.

In fact, I would argue that, on many accounts, Lean Startup is better suited to a corporate landscape than to a classic startup. An established company has better tools and more competencies to reach out to a potential target market than your stereotypical couple of technically-minded founders.

The question remains: can a corporate startup be treated as an early-stage startup? A pre-seed, or even a pre-pre-seed?

That’s definitely not an obvious path, but there are good examples of companies that were entirely transformed around that paradigm (Haier often comes up in that context). And we don’t need to expect transformations of whole companies. It’s enough to have one team operating under different principles. If we look for such inspiration, we can go back to WWII times and the origins of Skunkworks.

Build Less Principle

A big challenge for established companies is how increasingly complicated it is to build anything new.

You have to follow the tooling guidelines you use. Everything has to go through security, GDPR, and the like. Hiring people is a process and a big one. Sign-off for expenses is a multi-staged acceptance involving people who have no clue what you’re trying to do and even less time to get it.

However, all those guardrails are a simple waste of everyone’s time if the product experiment fails. And most of them do. Like 9 out of 10 of them.

So what if we could put all those corporate rules on hold till we actually validate that we have at least an appealing product? What if we could build as little as possible, and go back to the guardrails only if we succeeded? In other words, what if we could act as an actual startup, at least from a product development stance?

It would mean building way less before abandoning the vast majority of the initiatives. It would mean trying out way more ideas. Take these two things together, and we create an environment where it’s much easier to start something. Another idea is not necessarily a 2-year-long commitment for dozens of people, but a several-week-long experiment for a single-pizza team.

The only problem is that most corporations are neither Haier (to reinvent themselves entirely) nor Lockheed Martin (to set up product-centered Skunkworks).

Does it mean that a corporate startup is a doomed idea?

Rent Yourself a Startup

Save for a very different approach to product development, the basic idea behind a corporate startup is to create a culture pocket. A culture pocket—or a culture bubble—is a part of a company that operates under a significantly different organizational culture. They adopt different norms. Most likely, they also have a different (less strict) ruleset to follow.

Such an explicit organizational change may be difficult to implement. Yet, there’s a simple hack. Precisely what our client did. They hired an external team that routinely works with early-stage startups.

With one swift move, they circumvented a good part of the corporate rule overhead (well, we don’t have those), created a different climate (we bring our startup mindset), and set up a small, focused force to run an experiment. They couldn’t “create” a startup within their company, so they “rented” one.

The control is still all theirs. If the idea turns out to have legs, their internal team will eventually take it over. Before they start to corporatize it, though, it will have been validated. If, on the other hand, the idea is crap and doesn’t fly, they’ll abandon it by dropping ongoing funding. With one swift move.

This setup avoids two common issues I see in the startup world.

1. Founders’ overinvestment in the idea.
   Startups often go way longer than they should. Since founders start with an idea they love, it’s a tall order to abandon it early. Corporate startup is more calculating, and—arguably—more rational with go/no go decisions.

2. VC overspending.
   The way we organized funding, startups receive big rounds of financing and are expected to spend them all within short time frames. There’s no incentive to stop burning money early, even if we see it’s going nowhere.

Challenges of a Corporate Startup

I started with an example of our client who basically rented themselves a startup to experiment with a product idea. For contrast, another client of ours had a much more straightforward need, and they aren’t doing nearly as well.

Their problem was supporting their ongoing operations. An idea that’s already validated (they have a working business), and where it’s easy to show value delivered (effort saved).

The start was promising. We guided the client through the discovery phase rather than trying to build the solution from the outset. Then, we hit the corporate wall.

Getting gradual funding is, of course, possible. The company is flush, after all. It’s just that each round takes quarters. Even if the funds buy just months of effort of a small team. Ideation-development-validation cycles that should take weeks take months. Quarters sometimes.

We can isolate ourselves from most corporate overhead, but funding ain’t one of ‘em. Renting a startup won’t work if you can’t pay the rent.

That one part doesn’t translate from the startup world. You can find a team with the product development mindset and vast experience in building products. You can find a team that fills the gaps in tech leadership. But they won’t work for a promise of a hypothetical bright future.

In fact, if there’s one thing that guarantees a failure in corporate pre-pre-seed, it’s screwing up funding. It’s almost fascinating how often this is exactly the case. Even when we’re not talking about millions (which tend to be the seed rounds these days), but tens of thousands. But that’s a topic for another post.

By the way, if you are at an established company and consider starting a new product, feel free to reach out. I’m always happy to share the experience (and I’ve seen a lot of those).

The post was human-created: 웃https://okhuman.com/BaNDOA

A discovery phase is, ideally, the first and foundational stage of building a product. It’s where we explore and research the problem-solution fit, consider the business context, envision early experiments, and sketch a broader product development plan.

Two caveats before we move further.

1. Discovery is not—or at least should not be—a one-time exercise. It should be an ongoing activity happening throughout the entire product development lifecycle.

2. The industry hasn’t yet converged on what the discovery phase should be focused on. Wikipedia entry suggests that its output is a feature set. I strongly advocate treating it more as an exploration than a scoping exercise.

My convictions aside, even a planning/scoping flavor of the discovery phase is way better than no discovery at all. In my line of work, where we work extensively with founders at the earliest stages, I see how the discovery phase has become increasingly popular over the last 5 or so years.

Suggesting our customers (pre-pre-seed founders) to hold off on starting development until we go through this early exploration and validate the critical assumptions used to be an uphill battle. Today, it still requires some convincing, but the founders seldom walk away because of our insistence on starting with discovery.

They still often treat it largely as a clarification exercise. Something that’s needed to move swiftly with development later. Well, that’s not what they get.

Subscribe now

Discovery Workshop Design

We typically package the discovery phase into a discovery workshop. There’s no one game plan for those, as we work with founders at different stages of their research.

We follow the double diamond as a general compass for the activities. We use a variety of exercises to first identify the core problem we aim to address, and then figure out the riskiest parts of the envisioned solution. The usual suspects are:

• Assumption mapping

• Customer journey mapping

• Opportunity solution tree

• User story mapping

• And more

However, even when we touch the actual scope of a product (e.g., during user story mapping), it’s more of a reference point than actual scope. It’s tentative. It’s like asking, “If we decided to build an MVP, what would absolutely have to be in?” We don’t decide to build anything just yet.

Because odds are that we won’t be building anything at all.

Possible Outcomes of a Discovery Phase

There are three possible outcomes of a discovery phase.

1. It’s a slam dunk.
   We identified a problem, researched data that reliably confirms the issue is real, figured out a potential solution, and found enough evidence to believe it would work. Oh, and we have access to a group of innovators who are willing to try an MVP and share their experience.

2. It’s uncertain.
   We have strong intuitions to go for it, but not enough hard data to go all-in. We can try to learn more before committing to development, or go straight ahead and build it. In the second case, we accept bigger risks and limit our options.

3. It’s a no.
   For whatever reason, we realize that our initial assumptions were wrong. Be it the cost is prohibitive, or the space is already more crowded than we thought, or there are external (e.g., legal) factors that render the idea unfeasible, or someone has already tried that and failed, or whatever.

Now, the number 1 happens, well, just about never. Curiously, our expectations that this scenario will occur are inversely proportional to how often it actually happens.

Even founders who do discovery precisely because their idea is not a slam dunk expect it to be scenario 2. They expect exploration to land them with a better and/or less risky plan for an MVP.

Almost no founders with whom we’ve run the discovery phase acknowledge the possibility that it might be the final part of their product development effort, i.e., it could positively be a “no.”

And that’s the outcome of every other discovery workshop.

If we consider scenario 3 a failure, then yes, half of well-run discovery phases fail.

What Is a Failed Discovery Workshop?

Before we go further, I’d like to challenge the notion that discontinuing product development work after early exploration is a failure. It sure looks like it, given that at the end of the scenario, there’s no successful product.

However, if we start with the assumption that the product would not succeed in the first place, a “failed” discovery is, in fact, a success.

In both scenarios, we arrive at the same sad realization. The idea we’ve been so in love with wasn’t as good as we thought. It’s just that a “failed” discovery phase got us to realize that much faster and much cheaper. We’ve saved time and money.

In my book, it’s a success.

Still, from the perspective of an aspiring founder, it’s a failure. They give up a dream of building their product.

(At Least) Half of Discovery Phases Should “Fail”

In our experience, around half of the discovery workshops/phases do not lead to further work. And when I say “further work,” I mean it either as MVP development or low-tech experiments. To rephrase this, every other founder who comes to us for help with ideation gives up afterwards.

Again, in my book, it’s a success.

With the other half, we often succeed in delaying the development and stick to experiments that don’t require building software (or we can use shortcuts such as vibe coding).

And it’s good. Decently good at least. Ideally, we’d discourage even more aspiring founders during the discovery.

Why? Imagine you’re a dreamer with a product idea. Imagine it’s two years from now, and you have failed. Would you rather have failed cheaply and quickly or expensively and slowly?

“But Pawel, I believe in my idea, and I’m not going to fail. If I assumed I could, I wouldn’t be starting this thing in the first place.”

That’s all good. Except against your belief, I have hard data. Yes, a whole one-third of all entrepreneurs believe their chances of succeeding are 10 out of 10. Yup, they’re 100% sure their idea is going to fly. Meanwhile, we commonly agree that 90% startups fail. Math tells me that both of these can’t be true at the same time.

So, if you were going to fail, which path would you prefer?

If the cheap-and-fast one, you should actually be rooting for your discovery workshop to fail.

”Failed” Discovery Workshop as a Litmus Test

There’s one interesting side effect of this situation. If you stick with the train of thought I offer above, we get a handy way to validate the discovery work of companies/consultants providing such services.

Ask them about their “failure” rate.

If they’re like “Oh, our clients always go out with a well-designed scope of their MVP,” then avoid them like the plague. They either don’t know what they’re doing with discovery, or they’re selling their development services.

Building an MVP right after the discovery phase should be the last resort. There are (almost) always ways to learn more about the product idea than building it. At the pre-pre-seed stage, the mantra should always be “learn, learn, learn” or “validate, validate, validate,” and not “build, build, build.”

The discovery “failure” rate is, in fact, the success rate of whoever runs the process. They don’t fail. They help their customers to avoid costly lessons.

Full disclosure: at Lunar Logic, we insist on running the discovery phase with our earliest-stage customers, and we also do product development. And yes, that means that by discouraging our customers from jumping right into development and helping them “fail” the discovery, we are giving up on potential work.

This is the way.