Post content
On a flight to Tokyo, three women seated behind me spread out an arsenal of guides, maps, and printed schedules on their trays. For hours they planned their trip with precision: "Breakfast at 08:00, departure at 08:30, 08:37 train, arrival in Asakusa at 09:20, walk until 10:30, 10:34 metro..." It was fascinating. And also a bit terrifying. I survived thanks to the noise cancelling on my headphones.
I travel the opposite way. I buy the flight, book a place to sleep, and the rest is unmapped territory. I carry guides but read them like someone browsing a menu: with curiosity but without commitment. I've returned from cities without having visited some of their most famous monuments. And I don't regret it.
Watching those women build their itinerary, I thought: what happens when they miss a train? What if they arrive at a temple that takes their breath away and want to stay an hour longer? In Japan, with its impeccable infrastructure, maybe the plan survives intact. But change Tokyo for Bangkok or Hanoi, and that schedule becomes optimistic fiction.
This tension between exhaustive planning and improvisation—between following the map or trusting the compass—constantly appears when we build digital products. And the consequences of choosing wrong are much more serious than missing a temple.
Waterfall-type roadmaps are the corporate version of those ladies on the plane. Everything is planned from the beginning: first you gather all requirements, then design the complete solution, then develop each piece in sequence, finally test and launch. It's a downward flow, like a waterfall, where water can never flow back up.
This model makes sense in certain contexts. If you're building a bridge or programming pacemaker software, you need that rigidity. The physics of concrete and medical regulation demand certainty.
But applying Waterfall to a young digital product is like planning every last minute of a trip to a country you've never visited. You're assuming you know the territory before stepping on it. That you know exactly what your users need before seeing them use what you built. That the market will stay still while your team advances linearly for months.
The reality is harsher: you don't know what you don't know. And in digital products, what you don't know is usually very important.
On one of those aimless walks that characterize my travels, I entered a café in Singapore to escape the heat. The place was called Rough Guys Co., and in their bathroom I found something that stopped me. On the mirror glass, with thick strokes and dripping paint, there was a written phrase: "Direction is more important than speed."
In startups, in companies seeking product-market fit, in teams still discovering what problem they really solve, speed without direction is just chaotic movement. You can launch features every week, iterate compulsively, generate constant activity... and remain lost. Or worse: advance confidently toward the wrong place.
Direction doesn't come from a master plan crafted in January for the whole year. It comes from signals: patterns in how people use (or don't use) what you build, conversations with users that reveal frustrations you never imagined, competitive movements... These signals almost always converge on a simple premise: make the best possible product for the people who need it.
That's the compass. Not a schedule. Not a roadmap with fixed dates. A clear direction that can be adjusted when the terrain changes.
But there's no universal answer. Planning versus flexibility isn't a war with an absolute winner. It's a question that changes answers depending on where you're standing.
If you have a mature product with millions of users, you need some structure. You can't completely improvise when every decision affects complex ecosystems. If you're in a small B2B company and a client representing 40% of your revenue requests something specific, your theoretical roadmap instantly becomes wet paper. If you're running a startup searching for product-market-fit and clinging to a six-month plan because "we already decided it at the kickoff," you're choosing rigidity over learning.
You need to know what you need at each moment. Structure to coordinate complexity? Flexibility to discover what works? Speed to not die? Direction to not waste that speed?
I don't believe in being fast for the sake of being fast. The "speed wins" culture sounds exciting, but can also mean burned out teams, fragile code, and users confused by contradictory pivots.
I believe in rhythm. A sustainable pulse where the team can learn, build, learn again. Where direction adjusts based on decisions with information in hand. Where moving forward doesn't necessarily mean adding, but sometimes simplifying, eliminating, perfecting.
And there's something else: the distance between having a hypothesis and testing it with real users has compressed to almost disappearing. Tools like Claude Code or vibe coding are blurring the boundaries between roles that once demanded absolute specialization. A small, multidisciplinary team can now traverse the complete cycle—design, prototype, implement, test—in days, not months. Sprints compress. What determines how long you take is no longer how much time you calculated you'd need, but how much time you decide to dedicate before validating if you're going in the right direction.
This doesn't make Waterfall obsolete in all contexts. But it does disintegrate one of its fundamental pillars: the idea that changing direction is so costly that you'd better plan everything from the beginning. When pivoting costs a week instead of three months, exhaustive planning stops being prudence and becomes unnecessary rigidity.
Traveling without a rigid plan doesn't mean wandering aimlessly. It means keeping clear intention—"I want to understand this city"—while remaining open to the city teaching you how to do it. In product it works the same way. You know where you're going—create value for specific users—but how you get there emerges from contact with reality, not from a document written months earlier by someone who never talked to a real customer.
I'm sure the three women on the plane probably had a wonderful trip. Their plan worked because they chose the right context: a country where infrastructure doesn't fail, where schedules are sacred. Their approach was coherent with the terrain.
My improvisation works because I read the terrain while traversing it. I let the city teach me its rhythms, let the streets indicate where to go next, let a casual conversation with a vendor reveal a neighborhood no guide mentions. It's not aimless wandering: it's following signals that only appear when you're present, attentive, available for what the place has to say.
In product, the question isn't which philosophy is better. It's which serves the moment you're living. And having the honesty to recognize when you need to change from one to another.
Because the only thing worse than a rigid plan in uncertain territory is chaotic improvisation in a situation requiring coordination. And the only thing worse than both is not knowing which you're using or why.
The compass tells you where. The clock tells you when. Knowing which to look at each moment: there lies the real journey.
–
Follow me on LinkedIn to stay updated on new posts.
–
Written with the help of an AI assistant for documentation and trained on my previous texts.