Graphic in the style of the Digital Explorer Framework: “The Era of Product Guys.” The Build-Measure-Learn loop rises like a sun over the horizon, with a smartphone prototype at its center. Build: hours instead of weeks, Measure: days, Learn: hours. Below: “Ideas become prototypes in hours, not weeks.”
All articles
October 27, 2026 5 min read Short version: 1 min Vibe Coding Innovation Digital Explorer Framework

The Era of Product Guys.How Vibe Coding Turns People with Ideas into Makers.

The 1-minute version· 5 key points
  • There used to be an entire development process between an idea and a test. In the Build–Measure–Learn loop, “Build” was the bottleneck.
  • With vibe coding, I build prototypes myself today – in hours instead of weeks – and test them right away on my phone.
  • This isn't just for product managers: a dispatcher now handles certain monotonous tasks in around 20 minutes instead of three hours.
  • A prototype isn't a product yet. Security and scale still need developers – for the ideas that have proven themselves in testing.
  • The core: I can try out my ideas myself, without first having to set an entire team in motion.

Prefer the full story? Just keep reading ↓

When I experiment with vibe coding today, I often think back to my startup days as a founder and VP of Product. Back then, everything that's so simple, fast and cheap today took an enormous amount of effort.

“It's about being able to try out my ideas myself, without first having to set an entire team in motion.”

Build – Measure – Learn

We ran countless user tests, formulated hypotheses and adapted our product again and again. That's exactly what Eric Ries's Lean Startup approach is all about: Build–Measure–Learn. Build an idea, measure how users respond and learn from the results. Then the next cycle begins. It sounds simple, and at its core it's perfectly logical. But in practice, the biggest problem was often the very first step: Build.

Because before we could test anything at all, someone had to translate our idea into software. We discussed requirements, technical feasibility and design. Then came sprint planning, development, quality assurance and the next round of adjustments. Then we could finally test – only to discover that our hypothesis was wrong, a flow didn't work or users had understood something completely different from what we'd expected. So, back to square one.

That wasn't just expensive. At times, it was downright frustrating. Small bugs in the code could take days to track down. The notorious corner cases in particular – special scenarios nobody had thought of in the normal flow – regularly drove me and the team up the wall. There was discussion, analysis, rework and more testing. Of course, all of that had its reasons. Software has to work. But as a product manager, what I wanted most in the early phase was to learn as quickly as possible. What good is the perfect feature if nobody ends up using it?

Thinking and making – without the detour

Today, I can turn an idea into a working prototype myself in very little time. I can try something out, test it on my phone and change it on the spot. If I don't like a button, I change it. If a flow doesn't work, I adjust it. I don't have to write a ticket first, wait for a developer and push the change through another sprint before I find out whether my idea even makes sense.

The new Build–Measure–Learn loopWhoever has the idea builds the prototype themselves. There's no longer an entire development process between thinking and making.

  1. BuildWeeks → Hours

    Describe the idea in your own words, turn it into a working prototype with vibe coding and try it out right away on your phone. No ticket, no sprint.

  2. MeasureDays · unchanged

    Let real users test it: Where do they get stuck, what do they understand differently, what do they actually use? This is still the step that takes the most time.

  3. LearnHours · unchanged

    Hypothesis confirmed or rejected? Change the button, adjust the flow – and straight into the next round.

Time per cycle

Before
Now

Idea validated? Then development takes over: architecture, security, quality assurance and scaling turn the prototype into a product.

I can think and make without an entire development process having to sit between the two. For me, that's an incredibly powerful feeling. As a product guy, I feel more independent and more able to act today than ever before. And I truly wish I'd had these possibilities back in my startup days.

This isn't about me suddenly being able to code. It's about being able to try out my ideas myself, without first having to set an entire team in motion. And I'm far from the only one having this experience.

People with ideas become makers

A friend of mine works as a dispatcher. He analyzed his own workflow and digitized it with vibe coding. Certain monotonous tasks that used to take him three hours now take around twenty minutes. He's not a software developer. He knows his day-to-day work and knows exactly where time gets lost. Now he can translate that knowledge directly into a solution.

Another friend missed a game from his past that he could no longer find in the App Store. So he simply built it himself. He's not a programmer either. He had an idea and wanted to make it happen. Today, he actually can.

I find these stories fascinating because they show what vibe coding is really about. It's not just about developing software faster. It's about people who used to depend on developers suddenly building things themselves. People who understand their customers, their processes or a specific problem can make their ideas visible and tangible. They no longer have to just explain what they have in mind. They can build something that others can try out.

A prototype isn't a product yet

Of course, a prototype isn't a finished product. If an application needs to run securely, reliably and at scale, you still need experienced developers, solid architecture, quality assurance and professional IT. Vibe coding doesn't replace that work. But it changes the path that leads there. In the early phase, we can test more quickly which ideas actually work and which ones are worth developing professionally. We can learn earlier and invest less time and money in assumptions that later turn out to be wrong.

This is exactly where I see the connection to my Digital Explorers. These are people who try out new technologies on their own initiative, question problems and want to improve the way they work. Vibe coding gives them a new tool. A suggestion for improvement can become a prototype. An idea can become an application. And a single experiment might become a solution that helps others in the company, too.

A new generation of product guys

Perhaps we're witnessing the beginning of a new generation of product guys. And to be clear, I don't just mean men, nor only people with the official title of product manager. I mean everyone who can spot a problem, develop an idea and turn it into reality themselves. People who no longer have to wait for someone else to build what they envision.

Now is the time of the product guys. Not because developers are becoming obsolete. But because far more people are getting the chance to think like product managers and act like builders.

So I'd love to know: Have you already become a product manager yourself? Do you know friends, acquaintances or colleagues who are suddenly building their own products, even though they never knew how to code before? I'm curious to hear your stories.

What this feels like as a team is something I show in the AI Bootcamp: keynote, live vibe coding and hands-on work – ending with real prototypes, without writing a single line of code.

If you want more product guys in your company – let's talk.