In the build zone
The word "build" became all but a swear word in the Product world. Melissa Perri warned us about "The Build Trap", we all despised the "feature factory" model, and we were trained to always think "Buy, partner, build", in that precise order. All of these are still solid advice for product managers, with one little yet important "but". Most of us, product people, chose this job to build cool stuff that humans like and use. A lot of us want to build, but find it difficult or outright impossible to do so in our daily jobs.Anyone who has ever worked in a big organisation (over 1000 people) knows how hard it can be to get anything done. Endless meetings, paperwork, multitude of stakeholders to navigate. Even if building is allowed, tedious and frustrating processes suck all the joy out of the creative endeavour that is crafting software. This leaves many product creators disillusioned, burned out and resigned.
I also found myself in a similar situation not too long ago, when I started vibe coding my app, 3Smarter.com. Initially, I just wanted to see what those new AI code-writing tools could do, but pretty soon, to my great surprise, I found myself in the "flow state". It's very rare for me to get into the flow at work, too many distractions, collaboration, too much context switching. Playing video games is when I often get into "the zone". One more turn, one more attempt to beat the boss, definitely last level to clear... The flow state is great but dangerous, as time flies and you don't even feel tired. Something similar happened to me while vibe coding. The rush of endorphins when the code worked, the frustration when it didn't, the hope that the next prompt will be "the one". It's "yay", it's "arggg", it's "why the f... don't you work" and everything in between.
That experience reminded me of why I wanted to do tech in the first place. Creativity, solving hard problems, building! How did it go so horribly wrong?
The answer, as they say, might surprise you. Or not. I am tracking it back to when product leadership roles started to fill out with "non-builders". People who never wrote a single line of code in their lives, didn't create a single design, didn't QA or even document a working software, when those people are put in charge of tech products - they often think they can have their cake and eat it. They think they can have totally predictable, value-adding, innovative products created by a bunch of "tech people" who can be fed with two pizzas. And they get very surprised when reality inevitably disappoints them.
Let's try that
I love to hear those words from engineers and product managers alike. After long discussions and negotiations, after data-informed or ego-charged meetings - "let's try that" is a breath of fresh air or the only way not to get stuck. Some things need to be tried (built) to be validated. Reducing risks is part of product management, but only a part. It's infuriating when "product leaders" demand simultaneously innovation, growth and zero risk. It is only setting up product teams for failure and frustration.Why and when to build is a million-dollar question good product managers are paid to answer. Some call it "product sense", but in essence, it's their experience. It's the sum of their observations, learnings, wins and failures. It's the cumulative result of product creators "trying that", building stuff and learning from the process.
Which brings me neatly back to vibe-coding. Right now, there's no faster, cheaper and more accessible way to learn software product creation, to become a product builder. For any reason! Quickly test your ideas, help out a friend, build up your portfolio, or just have fun and get into the "build zone". Industry veterans can be reminded of why we went into this in the first place. While people far from tech can get an appreciation of how non-linear, complex, but also "magical" software creation can be.