There is a moment in every project when everything clicks. The team is tuned in, decisions land fast, the market responds, and you feel like the wind is behind you regardless of what you do next. Hiring feels easier. Conversations close faster. The next step feels obvious before you’ve finished thinking about it.

That feeling is real. It is also fragile. And most people don’t notice it leaving until it’s already gone.

What momentum actually is

Not enthusiasm. Not a good quarter. Not a team that gets along.

Momentum is the compounding of small wins, aligned energy, and external validation into a force that lowers the activation energy for everything around it. When it’s present it feels structural, like a property of the project itself rather than something generated by the people inside it. Decisions that would normally require three meetings get made in one. People volunteer solutions before the problem has been fully stated. The market leans in.

When it’s absent, the same actions feel like pushing against resistance that wasn’t there before. Not because the work changed. Because the force that was making it easier has gone, and now you can feel the actual weight of everything.

“When momentum is present it feels structural. When it’s absent you feel the actual weight of everything.”

When it goes

It rarely leaves dramatically. It cools.

Gradually the friction starts accumulating on different fronts at the same time. A hire that doesn’t work out. A deal that stalls without a clear reason. An investor who responds slower than they used to. A team meeting that used to feel energising that now feels like maintenance. A partner who takes four days to reply where they once took four hours.

None of these individually would matter. Deals stall. Inboxes fill up. People get busy. But when several of them happen simultaneously, the texture of the work changes. The tailwind is gone. Every decision now requires more force than it did before.

In a startup, in a career, in a long project, this pattern repeats. The peaks feel like the natural state. The troughs feel like something has gone wrong. Usually nothing specific has. The compounding just stopped, and now you’re running on the underlying fundamentals instead of the force that was amplifying them.

Real or perceived

Here is the uncomfortable question: is it real or is it in people’s heads?

Do teams lose momentum because something objectively changed, or because people get less excited over time and the friction is mostly psychological? Does the investor go quiet because the opportunity changed, or because the energy in the room at the last meeting was different and they felt it without naming it?

The honest answer is probably both, and that makes it harder to diagnose. Because if the momentum loss is real you need to change something external. If it’s perceived you need to change something internal. And if it’s both, you need to know which is driving which before you do anything. Acting on the wrong diagnosis accelerates the problem.

What seems clear is that momentum has a social dimension that pure execution metrics don’t capture. It lives partly in the belief of the people around you. And belief, once it starts to waver, is harder to restore than almost any operational problem.

Reading the room, one person at a time

Some people don’t notice when momentum leaves. They keep pitching with the same energy to a room that stopped leaning in three meetings ago. They miss the investor who has gone politely quiet, the team member who stopped volunteering ideas, the partner whose replies got shorter. These are signals. They are not subtle once you know what to look for.

But not everyone looks. Some founders operate at the level of the project, tracking metrics, managing milestones, reading the aggregate. Others operate at the level of each individual relationship inside the project. They notice the cooling before it becomes cold. They feel the shift in a single conversation before it shows up in the numbers.

Whether that is emotional intelligence or pattern recognition built from enough cycles of gain and loss is an open question. What is clear is that founders who have it operate differently. They don’t just manage the momentum of the venture. They manage the momentum of each relationship that holds the venture together. And in a world where you are trying to make real something that doesn’t yet exist, where uncertainty is the only constant and belief is the primary raw material, that ability to read and shape individual momentum is one of the most underrated skills a founder can have.

“Belief, once it starts to waver, is harder to restore than almost any operational problem.”

What you can do

Momentum can be rebuilt but not faked. Manufactured enthusiasm without underlying substance accelerates the loss rather than reversing it. People feel the difference.

What does work is small, visible forward motion. A closed deal. A shipped feature. A new partner announced. A metric that moved in the right direction. These matter disproportionately when the tailwind is gone because they lower activation energy artificially while the real thing rebuilds. The team needs to see something moving. Not a vision slide. Something that actually moved.

The worst response is to wait for momentum to return on its own. It doesn’t. It is rebuilt deliberately, relationship by relationship, win by win, until the compounding starts again. That process is slower and harder than it looks from the outside. It requires the same energy as building momentum the first time, but without the excitement of starting something new.

The invariant

Momentum is not a given. It is a result of alignment, of early wins, of a market that responds, of relationships maintained with enough care that the belief inside them stays alive.

The projects that sustain it longest are not the ones that never lose it. They are the ones where someone noticed it leaving early enough. Not at the project level, but at the level of each person, each conversation, each relationship that the whole thing depends on. Early enough to do something about it before the cooling became cold.

That recognition is the skill. The rest is just execution.

Fernando Martín is Managing Director of NEXMO Movement Data Hub (UC3M), Venture Builder at MOVEN, and founder of Eccocar. He writes here about venture building, AI agent operations, and the European technology landscape.

The Invariance — by Fernando Martín In a constantly evolving world, only value is the invariance that holds everything together.

Thanks for reading. If this resonated, share it with someone who needs to read it.

Leave a comment

Spain won the World Cup. And by the way, I am very happy about it. It has again made millions of my fellow Spaniards happy everywhere in the world and showed everybody that if you chase it hard enough, you can get it.
They won playing football. Not tactics designed to waste time, not simulation, not backroom arrangements or engineered draws. A generation of players taught to play the right way, who won because of it, not in spite of it.

That doesn’t always happen. Which is exactly why it matters when it does.

I’ve been sitting with that result and thinking about what it means outside of football. About venture building, about professional ethics, about the gap between how you are supposed to play and how most people actually play. I don’t have a clean answer.

That is the essay.

The temptation is real

In venture building, the pressure to oversell is constant and ambient. It is not the exclusive territory of bad founders. It is the water everyone swims in.

The deck that stretches the numbers just enough to clear the threshold. The pilot that gets described as a contract in the next investor call. The TAM slide that conveniently includes markets you will never realistically reach. The update that buries the bad news in the appendix, below the fold, after three slides of momentum metrics. None of this is lying in the way that gets you prosecuted. It is the daily management of the gap between what you have and what you need people to believe you have.

And it works. That is the uncomfortable part. It often works. The founders who tell the cleaner story raise more, hire faster, and close sooner than the ones who name every risk in the room. The market does not reliably punish optimistic framing. Sometimes it rewards it handsomely.

“The market does not reliably punish optimistic framing. Sometimes it rewards it handsomely.”

The spectrum

There is a spectrum here and pretending otherwise is its own kind of dishonesty.

On one end, there are founders who lie structurally and at scale. Who raise on fiction, build nothing, and leave employees, investors, and customers holding the damage. Theranos is the famous version. There are a thousand less famous versions that never make the news because the amounts are smaller and the victims have less access to journalists.

On the other end, there are founders so rigidly transparent that they cannot sell anything to anyone. Who name every risk before the investor has decided they like the opportunity. Who correct their own pitch deck in real time when a number feels slightly aggressive. That is its own kind of failure, and it is not virtue. It is an inability to hold the tension that selling requires.

Most people live somewhere in the middle, making small daily choices about how much to round up, how much to omit, how much to frame. The question is not whether you are on the spectrum. You are. The question is where, and whether you are honest with yourself about it.

What it actually costs

I tend toward honesty in ways that I know have affected my professional outcomes. Not perfectly. Not always. But as a default that I return to even when it costs me something.

I have been in rooms where naming a real risk killed a conversation that might have gone somewhere. I have watched competitors describe the same stage of product development in language so confident it made our honest framing sound like weakness. I have lost deals to people who were further along on the story than on the substance. That is not a complaint. It is an observation about how the game is actually played, as distinct from how it is described.

How comfortable you are with the gap between what you say and what is true is not purely a moral question. It is also a psychological one. Some people carry large inconsistencies without measurable cost to their sleep, their relationships, or their self-image. Others carry small ones badly. Knowing which one you are is more practically useful than any ethical framework. The framework tells you what you should do. Your psychology tells you what you will actually do, and at what price.

I know which one I am. I can take very little to bed. That shapes my choices in ways that are not always optimal by the metrics the market uses to keep score.

"The framework tells you what you should do. Your psychology tells you what you will actually do, and at what price."

The invariant

Spain won. And they won clean. That is not always how the tournament goes. Football has its share of results that were manufactured by other means. The World Cup is not the market, and the market is not football. The analogy has limits.

But there is something in that result worth sitting with. That playing the right way and winning are not always mutually exclusive. That sometimes the discipline you maintained when it would have been easier to cut a corner is the same discipline that made you good enough to win when it counted. That the thing you refused to compromise became the thing that compounded.

I don’t know if that is a rule. I have seen enough of the opposite to know it isn’t always true. I suspect it is more of a bet than a guarantee. A bet that playing straight compounds in ways that are real but slow, that the relationships built on honest ground last longer than the ones built on a good story, and that the version of yourself you don’t have to maintain is easier to sustain over a long career than the one you do.

I keep making that bet. Not because I am certain it pays off. Because the alternative costs me something I am not willing to spend.

Fernando Martín is Managing Director of NEXMO Movement Data Hub (UC3M), Venture Builder at MOVEN, and founder of Eccocar. He writes here about venture building, AI agent operations, and the European technology landscape.

The Invariance — by Fernando Martín In a constantly evolving world, only value is the invariance that holds everything together.

Thanks for reading. If this resonated, share it with someone who needs to read it.

Subscribe now

Leave a comment

Running two ventures simultaneously as a fractional operator is not a workload problem. It is a context problem.

The meetings were happening. Fathom was capturing everything. The information existed. What didn’t exist was a system that held it all together between sessions, surfaced what mattered, and let me walk into the next conversation without rebuilding the picture from scratch every time.

That is what I built.

The tax nobody talks about

When you run a single company with a fixed team, context is cheap. It lives in the room, in the shared history, in the person who was also on last Tuesday’s call. You don’t have to reconstruct it. It’s just there.

As a fractional operator, the context is never just there. On any given week I might be vibe coding a new tool in the morning, in a sales presentation by lunch, writing a venture concept in the afternoon, and on a strategic call with a ministry by end of day. Each of those requires a completely different mental mode. And each of them leaves a trail of open threads, commitments, and next steps that don’t wait for me to catch up.

Every time I switched modes I was paying a switching tax. Not in hours, but in mental overhead. Pulling up notes, re-reading summaries, trying to remember where a conversation had landed, what the next step was, who was waiting for something from me.

Fathom solved the capture problem. Every meeting was transcribed, stored, searchable. The information existed. But information sitting in a folder is not the same as a system that uses it. I was still the one connecting the dots, every time, from scratch.

I didn’t need more information. I needed something that held the thread.

“I didn’t need more information. I needed something that held the thread.”

Why a human Chief of Staff doesn’t work here

A traditional Chief of Staff works for a CEO with a fixed organisation, a fixed office, and a context that doesn’t shift radically from week to week. You can onboard someone into that role. The scope is stable enough to hire for.

As a fractional operator, the scope is the problem. One week I’m deep in European data space regulation for NEXMO. The next I am digging into a new venture concept: business model, product, market size. The week after I’m back in Madrid coordinating a Ministry meeting. No single person can hold all of that context across all of those worlds and be available when I need them, at the cost that makes sense for the structure I operate in.

The alternative is to build it. So I did.

The hardware layer

The first decision was infrastructure. A Chief of Staff that only works when your laptop is open is not a Chief of Staff. It’s a tab.

You need something always on. That’s the only real requirement. I use a Mac Mini M4 at home, configured as a server, but this is not a Mac Mini story. A Raspberry Pi does the job. An old laptop you leave running in a corner does the job. The hardware investment is trivial. A decent setup costs less than a single day of consulting fees.

Tailscale handles remote access so I can reach it from anywhere. The infrastructure decision came before the software decision because the tool only works if it runs continuously, in the background, processing and surfacing information whether I’m in a meeting, on a plane, or asleep.

The always-on constraint is what makes everything else possible. The device that satisfies it almost doesn’t matter.

The software layer

The agent platform is OpenClaw, running on the always-on server. It connects to Gmail, Fathom, and WhatsApp. Fathom transcripts feed into it after every meeting. Gmail keeps it aware of ongoing threads and commitments. WhatsApp conversations, where a lot of real venture communication actually happens, feed into it as well. Nothing important falls outside the system’s awareness.

I communicate with it through Telegram and Slack. Both work. Telegram is faster for quick checks on the go. Slack sits inside the same workspace as the venture teams, so the CoS is present in the same channels where work actually happens.

The configuration is where most of the real work lives. OpenClaw runs on a set of structured markdown files that define how the system thinks and operates. There is a Soul file that defines the identity and operating principles of the agent. There are Agent files that define each venture context, the stakeholders, the current priorities, the open threads. There are files that define how to communicate, what to escalate, and what to ignore. Together they are not a simple instruction. They are a detailed operating manual written in plain text, versioned, and updated as the ventures evolve.

Getting that right took iteration. The first version surfaced too much. The second version was too conservative. The current version has learned, through repeated adjustment, what I actually need to know versus what I can find when I go looking. That calibration is ongoing. The system evolves as the ventures evolve.

It also connects to my calendar. It knows what is coming before I do. If I have a meeting on Thursday, it surfaces the relevant context on Wednesday without being asked. That proactive layer is what separates an agent from a search tool.

“A Soul file. Agent files. Communication rules. A detailed operating manual written in plain text.”

What it actually does

On a typical morning, before I open my first email, the system has already processed whatever happened overnight. Fathom transcripts from late meetings. Calendar changes. Anything flagged across the Slack channels it monitors.

What I get is not a dump of information. It is a prioritised picture. What needs attention today. What is still open from last week. What I committed to in the MOVEN call that I haven’t acted on yet. What the NEXMO team is waiting for.

The key metric, the one that matters most to me, is simple: I no longer start a session by asking myself where I left this. The thread is held. I pick it up and keep going.

That sounds small. It is not small. The switching tax was invisible until it was gone. Now I notice it immediately on the rare occasions the system misses something and I have to reconstruct context manually. That friction, which used to be constant, now feels like an exception.

The invariant

The Chief of Staff didn’t make me faster at doing things. It made me faster at knowing what to do next.

That is a different kind of value, and it is the kind that compounds. Every week the system has more context. Every month the operating manual is more precise. The longer it runs, the less I lose in the gaps between sessions.

If I had to give up one tool in my current setup, this would be the last one I’d let go. Not because of what it automates, but because of what it holds.

Context is the scarcest resource for a fractional operator. I stopped treating it as something I had to rebuild. I built a system to hold it for me instead.

Fernando Martín is Managing Director of NEXMO Movement Data Hub (UC3M), Venture Builder at MOVEN, and founder of Eccocar. He writes here about venture building, AI agent operations, and the European technology landscape.

The Invariance — by Fernando Martín In a constantly evolving world, only value is the invariance that holds everything together.

Thanks for reading. If this resonated, share it with someone who needs to read it.

Subscribe now

Leave a comment

I write about the things that don’t change in a world that won’t stop changing.
I believe adding real value is what gives us purpose, keeps us happy and improves our lives.

Every June, the professional world slows down. Meetings get postponed. Decisions get pushed to September. Inboxes empty out. Most people treat summer as a pause.

The ones who compound their position use it differently.

Distribution is not built in sprints. It is not built with campaigns, sequences, or tools. It is built in the moments when everyone else stops showing up. And it takes years.

What happened in Madrid last week

Last Thursday I was in a room at UC3M in Madrid. Representatives from the Spanish Ministry of Transport. Data space operators from Barcelona, Zaragoza, Vitoria, Bilbao. Researchers, startups, cluster associations, infrastructure companies. People who had traveled the night before, on Sant Joan, because they thought the conversation was worth it.

Nobody ended up in that room by accident.

The event was organised around NEXMO, the mobility data hub where I serve as Managing Director. But the reason the room was full had almost nothing to do with NEXMO specifically. It had everything to do with one person who has spent years building an ecosystem of trust in the Spanish mobility and data space. Someone who called people, showed up at their events, contributed to their projects, introduced them to each other, and kept doing it long before there was a clear commercial reason to.

That person convened the room. The room showed up because of what he had built over years of sustained effort. That is distribution. Not the event. The years of work that made the event possible.

“That is distribution. Not the event. The years of work that made the event possible.”

What distribution actually means

Most founders confuse distribution with marketing. They are not the same thing.

Marketing is a message sent to an audience. Distribution is the accumulated result of showing up, repeatedly, in the right rooms, with something real to contribute. It is relationship infrastructure. It is the reason people answer your call, forward your name, and think of you when the budget is approved or the project is ready to move.

You cannot buy it. You cannot shortcut it. You can accelerate the communication layer with tools, but the underlying trust is built at human speed, which is slow, and compounds in a way that most founders underestimate until they see it in action.

The Ministry of Transport was in that room in Madrid. UC3M wants to continue pushing the project. Companies that had never heard of each other are now in conversation because they met in that space. None of that happened because of a product demo or a LinkedIn post. It happened because someone spent years earning the right to convene that conversation.

The compounding logic

Distribution compounds in a way that software never did and never will.

A relationship that earns you access to one room earns you introductions to three more. A reputation built across two years of showing up in the right conversations becomes the reason you get called when the budget is ready, the partnership is needed, or the decision is being made. The access you earn compounds into more access. The trust you build compounds into more trust.

Software does not compound like this. A feature shipped today does not make tomorrow’s features easier to build. But a relationship earned today makes tomorrow’s relationships easier to start. The asymmetry is enormous and most technically-oriented founders ignore it entirely because it is slow, invisible, and impossible to put in a dashboard.

“A reputation built across two years of showing up becomes the reason you get called when the decision is being made.”

The NEXMO event was not a one-off success. It was a visible output of compounding. The next event will be easier to fill. The next partnership will be easier to start. The next conversation with the Ministry will happen faster. That is the logic at work.

What this means in 2026

Software is free. Execution is cheap. The technical layer of building a product has been commoditised to the point where it is no longer a differentiator. We have covered this ground in earlier issues.

What follows from that is simple: if the product is no longer the moat, the distribution infrastructure is. The founders who win are not the ones who built the best product in isolation. They are the ones who built the trust infrastructure that gets their product seen, evaluated, and chosen over alternatives that may be technically comparable.

And building that infrastructure requires a different kind of discipline than building software. It requires patience with slow feedback loops. It requires contributing to ecosystems before you need anything from them. It requires showing up consistently over a time horizon that most founders are not willing to sustain.

Summer is when that discipline is tested. The calendar says pause. The compounders keep going.

The invariant

Distribution was always the game. We confused it with marketing for too long, and then we confused marketing with tools for even longer.

The room in Madrid last week was a reminder of what it actually looks like. A person who spent years building something real in an ecosystem. A network that showed up because of what he had built. A project that now has the Ministry, the university, and a room full of operators behind it, not because of a product, but because of the trust that preceded it.

Build the ecosystem before you need it. Show up before there is a reason to. Contribute before you can extract.

That is the only distribution strategy that compounds.

Fernando Martín is Managing Director of NEXMO Movement Data Hub (UC3M), Venture Builder at MOVEN, and founder of Eccocar. He writes here about venture building, AI agent operations, and the European technology landscape.

The Invariance — by Fernando Martín In a constantly evolving world, only value is the invariance that holds everything together.

Thanks for reading. If this resonated, share it with someone who needs to read it.

Subscribe now

Leave a comment

I write about the things that don’t change in a world that won’t stop changing.
I believe adding real value is what gives us purpose, keeps us happy and improves our lives.

For two decades, software was the moat. If you could build it and your competitor couldn’t, you won. The ability to ship a working product was itself a competitive advantage. The code was the castle.

That era is over.

What made software a moat

The barriers were real. Engineers were scarce and expensive. Infrastructure had to be built and maintained. Shipping a production-grade product took months, sometimes years, and required a team with specialised skills that most organisations couldn’t assemble quickly. The compounding advantage of a mature codebase, one that had been tested against real users, hardened against edge cases, and integrated into customer workflows, was genuinely difficult to replicate.

These constraints shaped everything. Valuations were built on them. Hiring strategies were built on them. The entire venture capital model of the 2000s and 2010s was built on the assumption that technical execution was the hard part, and that whoever solved it first and fastest would be difficult to dislodge.

They also created a generation of founders who confused the ability to build with the reason to build. If shipping was hard, then shipping was the achievement. The question of whether anyone needed what you shipped was secondary, something to sort out once the technical problem was solved.

“A generation of founders confused the ability to build with the reason to build.”

What collapsed it

Not one thing. A sequence.

Cloud computing commoditised infrastructure. You no longer needed to own servers to operate at scale. The capital expenditure that once separated serious players from aspirants became a monthly subscription anyone could afford.

Open source commoditised the stack. The frameworks, the databases, the tooling — everything that once required years of engineering effort to build from scratch was now available, maintained by communities, and free to use. The technical foundation of most software products stopped being a differentiator the moment it became available to everyone simultaneously.

And then AI commoditised the act of writing code itself. The last remaining barrier, the human expert who could translate a business problem into working software, became assisted, accelerated, and in many cases replaceable. What took a team of ten and six months now takes one person and a weekend. Sometimes less.

Each layer of the barrier dissolved in turn. The moat was drained from the outside in, over twenty years, until there was nothing left to defend.

Where the moat moved

The moat did not disappear. It moved.

Distribution is a moat. The ability to reach the right customer, at the right moment, with enough trust already established to have a real conversation. That does not come from a codebase. It comes from years of showing up, building a reputation, and earning access. It cannot be replicated overnight by someone who just decided to enter your market.

Customer relationships are a moat. Not the CRM record. The actual relationship, the understanding of how a specific organisation makes decisions, who the real stakeholders are, what they have tried before and why it failed, and what success looks like in language that matches their internal vocabulary. That knowledge is not transferable. It lives in the person who built it.

Proprietary data is a moat. Not data you bought. Data you generated by operating, by running transactions, by watching how customers actually behave rather than how they say they behave, by accumulating signal over time that nobody else has access to because nobody else was in the room.

Domain expertise so deep it cannot be faked is a moat. Eight years running a mobility platform teaches you things about enterprise fleet management, about how automotive companies evaluate vendors, about the gap between what procurement says it wants and what operations actually needs, that no amount of research can replicate. That expertise is yours. It is not in any training dataset in a form anyone else can use the way you can.

“The moat did not disappear. It moved.”

What this means for how you build

If the moat is no longer technical, the dangerous thing is spending your time and capital as if it still is.

The founders who lose in this era are not the ones who cannot build. Building is no longer the filter. The founders who lose are the ones who build beautifully and distribute nothing. Perfect product, empty pipeline. Technically impressive, commercially invisible.

The allocation question has inverted. In 2010, the right move was to put most of your energy into the product and trust that distribution would follow from quality. In 2026, quality is assumed. Anyone with a weekend and access to the right tools can produce something technically competent. The scarce resource is the relationship, the channel, the trust that gets your product in front of the right person at the right moment.

This does not mean stop building. It means build fast, build cheap, and spend the time you save on the things that cannot be automated. The conversations, the relationships, the accumulated understanding of a specific problem in a specific industry that makes your solution the obvious one rather than just another option.

The invariant

The moat was never really the software. It was always the insight the software encoded, the understanding of a real problem earned through proximity to real customers, that made the product worth building in the first place. And it was always the relationships that gave you access to that problem before anyone else knew it existed.

The technical layer sat on top of those things and made them look like the point. Now that the technical layer is free, the underlying assets are exposed for what they always were.

The castle was never the code. It was what you knew, and who trusted you enough to let you solve it.

Fernando Martín is Managing Director of NEXMO Movement Data Hub (UC3M), Venture Builder at MOVEN, and founder of Eccocar. He writes here about venture building, AI agent operations, and the European technology landscape.

The Invariance — by Fernando Martín In a constantly evolving world, only value is the invariance that holds everything together.

Thanks for reading. If this resonated, share it with someone who needs to read it.

Subscribe now

Leave a comment

I write about the things that don’t change in a world that won’t stop changing.
I believe adding real value is what gives us purpose, keeps us happy and improves our lives.

Everyone can ship now. A landing page in an afternoon. A scoring tool before the next meeting. An AI agent running on your own hardware over a weekend. The technical barrier is gone. Which means prototyping speed is no longer a differentiator — it’s the baseline.

The question that remains is the same one it always was. Does this add real value to someone’s actual problem?

Intent before interface

Earlier this year I was working with NEXMO, a mobility data space running under a European public research mandate with a fixed deadline and limited resources. The team needed a way to prioritise which use cases to activate first. There were more candidate use cases than capacity to run them, and the decision had real consequences — the wrong prioritisation meant wasted effort, missed stakeholder commitments, and a showcase event with nothing credible to show.

The Use Case Scorer I built for that problem was not technically interesting. It was a structured scoring model that weighted strategic fit, data availability, partner readiness, and time to demonstrable output. It took a few hours to build. What it took much longer to produce was the logic behind it — which dimensions actually mattered to this specific programme, in this specific political context, with these specific constraints.

The tool followed the thinking. The thinking followed the problem. That sequence — business intent first, interface second — is the only sequence that produces something worth using.

“The tool followed the thinking. The thinking followed the problem.”

A prototype built in the opposite order — interface first, problem fitted to it afterwards — is a demo. Demos are not useless. But they are not the same thing as a tool someone opens every day because it makes their work better.

The tool that runs your operation

I run a chief of staff agent on a Mac Mini at home. It connects to my real workflows — calendars, communications, project notes, ongoing ventures. It surfaces what needs attention. It drafts, it summarises, it flags. It runs while I sleep.

I did not build it to demonstrate that it was possible. I built it because I needed it. The difference sounds small. It isn’t.

A prototype that doesn’t survive contact with your own operations isn’t ready for someone else’s. The moment you depend on something yourself — when breaking it costs you something real — you start making different decisions about how it’s built. The edge cases you would have ignored become the cases you fix first. The interface you would have left rough becomes the thing you polish because you use it every morning.

This is the test I apply to everything I build now. Would I run this in production for my own work? If the answer is no, it isn’t finished. If the answer is yes, it has a chance of being useful to someone else.

The public face as proof of work

When I needed an operational website for my independent work, the deployment took an afternoon. GitHub to Vercel, domain pointed, landing page live. The tooling is that fast now. Any competent operator can do it before lunch.

What the tooling cannot do is decide what the page needs to say, to whom, and with what level of specificity. That took longer. The question was not technical — it was strategic. Who lands on this page? What do they already know? What do they need to believe by the time they leave? What does the absence of certain information signal, and is that the right signal?

Execution was free. Judgment was the asset. That pattern repeats across everything worth building.

What the agentic era actually changes

In 2020, a working prototype bought you credibility. It was proof that you could build — that the idea was not just an idea but something that could exist in the world. That signal had value because building was hard and slow and most ideas never made it to a demo.

In 2026, a working prototype buys you nothing on its own. Everyone has one. The venture landscape is full of impressive demos built over a weekend by a single person with access to the same tools you have. The demo is no longer the filter.

The new filter is whether the thing you built is grounded in a real problem, for a real person, with a real consequence if it doesn’t work. That filter is not new — it’s the same filter that always separated products from projects. What’s new is that it’s now the only filter left, because the execution excuse is gone.

You can no longer say the idea was good but the team couldn’t build it. You can no longer say the prototype would have validated the hypothesis if only there had been time. There is time. There are tools. The question is whether you understood the problem well enough to build the right thing.

“The execution excuse is gone. The question is whether you understood the problem well enough to build the right thing.”

The invariant

The prototype was never the point. It was always the cheapest way to test whether you understood the problem well enough — a forcing function that turned vague thinking into something concrete enough to be wrong about.

Now that it’s even cheaper to build, the test is purer. The signal is cleaner. A prototype that adds no real value is now just visible evidence of a thinking problem, not a building problem.

The bar hasn’t risen because the tools got better. It’s risen because the tools removed every excuse except the one that was always there: did you understand what you were building, and why it mattered to the person you were building it for?

That question has no agentic shortcut.

Fernando Martín is Managing Director of NEXMO Movement Data Hub (UC3M), Venture Builder at MOVEN, and founder of Eccocar. He writes here about venture building, AI agent operations, and the European technology landscape.

The Invariance — by Fernando Martín In a constantly evolving world, only value is the invariance that holds everything together.

Thanks for reading. If this resonated, share it with someone who needs to read it.

Subscribe now

Leave a comment

Most founders pitch what they built. The best ones pitch what the customer loses if they don’t change. Those are completely different conversations. Guess which one has a chance to close?

What understanding actually means

Not personas. Not user interviews. Not NPS scores. Those are proxies — useful proxies, but proxies nonetheless. Real understanding means something harder and more specific: knowing their P&L logic, their internal political structure, who owns the budget, and what failure looks like for the person sitting across the table from you.

It means knowing the difference between knowing someone uses your product and knowing what their job costs them when it goes wrong.

But there is one element that most people skip entirely, and it is the one that determines whether a deal moves or dies: the internal champion. Every large organisation has people whose incentives can be aligned with what you are building. A manager who needs a win before their next review cycle. A director with a genuine conviction that the problem you are solving matters. Someone whose compensation, promotion, or professional reputation gets better if you succeed.

Finding that person is not manipulation. It is how enterprise sales actually works. If your champion has no skin in the game, they will not fight for you when the budget committee asks hard questions. If they do have skin in the game — if solving this problem is also solving something for them — then you have an ally inside the organisation who will move things you cannot move from the outside.

“If your champion has no skin in the game, they will not fight for you when the budget committee asks hard questions.”

Map the organisation. Find the person whose interests align with yours. Then make sure they know it.

The role you think you play

When you enter a large enterprise relationship, you arrive with a theory of your own value. You know what your product does. You know the problem it solves on paper. What you do not know — and cannot know from the outside — is where you actually sit in their value chain, whose priorities you are serving, and what your success means in the context of their broader commercial logic.

That understanding does not arrive in a pitch meeting. It builds slowly, through conversations that seem unrelated, through the questions they ask that you didn’t expect, through watching how they talk about you internally when they think you aren’t listening. At some point, if you are paying attention, the picture sharpens. You realise the role you thought you were playing and the role you are actually playing are not the same thing.

That gap — between your theory of your value and their reality of it — is where most enterprise relationships stall. Closing it is not a product problem. It is a listening problem.

Why large organisations are a different game

Early in my career I worked inside the Intel and Apple collaboration on modem programs for the iPhone. These were fast American organisations by any standard — high execution speed, clear accountability, relentless focus on ship dates. And yet the product itself was extraordinarily complex. Modem programs involve hundreds of edge cases, deep hardware-software interdependencies, and regulatory requirements across dozens of markets. You could not have the whole picture from day one. Nobody did. You built it incrementally, through relationships and accumulated context, over years.

Large enterprises in any capital-intensive industry work the same way, but slower. The sales cycles are long. The decision-making structure involves more stakeholders than any org chart will show you. The people you meet in a first conversation are rarely the people who control the budget. And the organisation’s resistance to change is not stubbornness — it is the rational behaviour of a system that has spent decades building processes that work, client relationships that depend on reliability, and a workforce that follows well-greased procedures for good reason.

That same structural weight is also a position of strength. Large enterprise clients come with distribution, with brand credibility, with staff who know how to execute at scale. When they move, they move with force. The challenge is not convincing them that change is possible. It is convincing the right people, in the right order, that this particular change is worth the disruption.

“The organisation’s resistance to change is not stubbornness — it is the rational behaviour of a system that has spent decades building what works.”

That requires understanding their business at a level most founders never reach, because most founders stop at the product conversation.

What the agentic era changes — and what it doesn’t

The tools we have now have collapsed the cost of software execution. What took months takes days. A hypothesis can become a working prototype before the next meeting. That compression is real and it matters.

But it is important to be precise about what it collapses. It collapses the software side. For organisations that are heavy in hardware, semiconductors, physical manufacturing, or complex regulated processes, AI does not compress the cycle in the same way. The supply chain constraints are still real. The validation requirements are still real. The safety certifications are still real. AI can help those organisations move faster on specific sub-problems — improving yield, predicting failures, optimising schedules — but it does not dissolve the fundamental physics of operating in the physical world.

What this means for founders is precise: the execution advantage AI gives you is asymmetric. It is largest in software-heavy problems and smallest in hardware-heavy ones. In both cases, the understanding problem — knowing what to build, for whom, and why now — remains entirely yours. AI does not compress that. If anything, because execution is now so cheap, the cost of misunderstanding the customer has gone up. You can now build the wrong thing faster than ever.

Front-load the business thinking. Then execute at machine speed.

The invariant

Technology changes every cycle. Customer logic changes slowly — and the larger the organisation, the slower it changes. This is not a criticism. It is a structural reality. When you are trying to change a large organisation, you are not only affecting its processes and its P&L. You are affecting careers, internal hierarchies, existing vendor relationships, and sometimes the political balance between divisions that have been competing for resources for years.

The founders who endure are not the ones with the best technology. They are the ones who understood that before they wrote a single line of code, and let that understanding shape everything that came after.

The grey matter shift we talked about in a previous article is not abstract. This is what it looks like in practice. Spend it on the right problem.

Fernando Martín is Managing Director of NEXMO Movement Data Hub (UC3M), Venture Builder at MOVEN, and founder of Eccocar. He writes here about venture building, AI agent operations, and the European technology landscape.

The Invariance — by Fernando Martín

In a constantly evolving world, only value is the invariance that holds everything together.

Thanks for reading. If this resonated, share it with someone who needs to read it.

Subscribe now

Leave a comment

I write about the things that don’t change in a world that won’t stop changing.
I believe adding real value is what gives us purpose, keeps us happy and improves our lives.

Subscribe now

A few months ago I was building a tool for MOVEN. Nothing dramatic, a venture scoring system to evaluate business ideas against a structured set of dimensions. The kind of internal tool that, in a previous life, would have sat on a backlog for six weeks before anyone touched it.

I opened Claude Code. I described what I needed in plain English. I iterated a few times. I deployed to production.

The whole thing took an afternoon.

I got goosebumps.

Not because the tool was impressive. Because of what it meant. In my head, involuntarily, I started doing the calculation. NEXMO. MOVEN. Eccocar. Intel. The mental comparison ran itself before I could stop it. And what it produced wasn’t satisfaction. It was something closer to vertigo.

We thought we were fast. We had no idea.

What 2020 actually looked like

Let me describe what building an equivalent tool at Eccocar in 2020 would have required.

First, someone would have written a brief. Then a Product Owner would have refined it into user stories. A Scrum Master would have facilitated the sprint planning. A Team Lead would have estimated the effort. A backend engineer would have built the API. A full-stack engineer would have built the interface. A UX designer would have made sure it didn’t look like it was built in a basement. Everyone would have attended the daily standups, the sprint review, the retrospective. There would have been a staging environment, a QA cycle, a deployment checklist.

Six people. Six weeks. One internal tool.

And we were considered a fast organisation. We were proud of our velocity. We shipped features that enterprise clients at Amadeus actually used. We thought we were operating at startup speed.

Sitting there with my laptop, having just deployed a production-ready tool in an afternoon (in English, not even in code), I realised that what we called fast in 2020 was the stone age. Genuinely. The comparison isn’t cruel. It’s just accurate.

The two fronts that drained everything

Here is the thing about building a software startup in 2020 that nobody fully prepared me for: you were fighting two completely different wars simultaneously.

Front one: technical development. You needed to hire engineers before you could build anything. Engineers were expensive, scarce, and opinionated. You needed a CTO whose timeline estimates were, charitably, optimistic. You needed a process: sprints, standups, retrospectives… because without it, six people working on the same codebase produced chaos. The MVP cost money before it produced anything. Which meant you needed funding before you had proof.

Front two: market validation. While the technical front consumed most of your attention and almost all of your cash, you were supposed to be simultaneously validating that anyone would actually pay for what you were building. This required customer conversations, pilots, proposals, and the particular kind of psychological resilience required to keep selling something that doesn’t fully exist yet.

Most founders, and of course I include myself, were never trained for both fronts at once. We were good engineers, or good commercial thinkers, or good operators. The ones who could hold all three simultaneously were extraordinarily rare, and they burned out faster than anyone else.

The result was a startup ecosystem where an enormous amount of energy, money, and human talent was consumed before a single customer received a single euro of value. Seed rounds existed to fund the gap between idea and first paying customer. That gap was expensive because building was expensive. Investors were, in a very real sense, paying for the cost of execution, not the value of the idea.

You spent months fighting the clock, draining your runway, making the pitch deck more polished, hiring carefully, managing the sprint velocity, hoping that when the MVP finally shipped, the market would validate your assumptions. Most of the time it didn’t, at least not in the form you expected. Then you iterated. More runway. More runway. More runway.

Extremely draining. And the startup had still not shown any value whatsoever.

What changed

The software development effort is now, for most purposes, gone.

That sentence deserves to sit on its own.

Not reduced. Not improved. For a solo founder building a software product in 2026, the execution layer has been compressed to the point where it is no longer the binding constraint. You can describe what you need in plain language, iterate in real time, and deploy to production in hours. You need a domain, a GitHub account, and enough technical literacy to understand what you’re asking the system to build. That’s it.

The implications cascade immediately.

No seed funding required to reach MVP. No hiring required before you can build. No sprint planning, no standups, no retrospectives. No runway anxiety during the build phase. No gap between idea and first customer conversation, because you can have a working prototype before the conversation ends.

Time to first value: hours, not months. Cash required to reach MVP: near zero. Team size required: one person who understands the problem.

And here is the part that still makes me stop when I think about it: the solopreneur who ships a tool tomorrow that solves a real problem for a paying customer overnight has built something more valuable than the team of four that raised €300,000 for an MVP in 2020 and spent eight months building it. Same value delivered. Fraction of the effort, the cost, the time. You can even sell it on TrustMRR and make an exit without ever having a team.

The definition of a startup needs updating. The person with a clear idea, a paying customer, and an afternoon is a founder. Full stop.

What didn’t change

And here is the invariant, the thing that 2026 didn’t touch at all.

You still have to understand what someone will actually pay for.

The tools are extraordinary. The speed is real. The cost compression is permanent. But none of it matters if you don’t know what problem you’re solving, for whom, and why they would choose your solution over doing nothing.

The grey matter shift (which I wrote about in the last issue), accelerates in this environment rather than reverting. When execution is free, judgment is everything. The founder who wins in 2026 is not the one who can prompt the best. It’s the one who understands the customer’s business well enough to know what to build before a single line of code is written.

The two fronts collapsed into one. The technical front is mostly solved. What remains is the market front, the understanding, the translation, the judgment. And that front was always the harder one. We just used to be able to hide behind the technical front when it got uncomfortable.

A word on moving atoms

There is an important exception to everything above: startups that move atoms.

Manufacturing, hardware, physical infrastructure, robotics: these still require capital, time, and teams. You cannot deploy a factory with Claude Code. The compression I’ve described is specific to software, and software specifically.

But even here, the tools are changing the internal velocity of complex organisations. AI-assisted development is compressing the software layer of hardware companies — the control systems, the interfaces, the data pipelines. The ventures being built at the intersection of physical industry and software intelligence — where the challenge is applying AI reasoning to decades of manufacturing process — benefit asymmetrically from these tools even if they can’t eliminate the physical constraints entirely.

The atom-movers still need time, capital, and teams. But their software engineers are now dramatically more productive than they were in 2020. The gap between software ventures and hardware ventures is narrowing, even if it hasn’t closed.

The utopia at the end of the road

There’s a version of this story that ends somewhere extraordinary.

If tools keep getting better and cheaper, and there is no structural reason they won’t, then the cost of solving a software problem approaches zero. Every person with judgment and a customer problem can build the solution themselves. Value creation gets democratised in a way that no previous technology enabled.

Elon talks about this. Universal Basic Income, energy from the sun, AI and robotics solving the physical constraints. A world where the economy of abundance frees humans from the necessity of work.

It’s a compelling vision. I just have one question for the people building toward it.

If we are no longer defined by what we do professionally — if the work identity that most of us have built our entire sense of self around dissolves into abundance — what exactly are we going to do with all that time?

If the last few years of social media are any evidence, the answer involves a lot of very confident opinions, a great deal of outrage, and an X account.

Maybe the real scarce resource, in every era, is the same thing it has always been: the wisdom to know what actually matters.

Only value holds.

Fernando Martín is Managing Director of NEXMO Movement Data Hub (UC3M), Venture Builder at MOVEN, and founder of Eccocar. He writes here about venture building, AI agent operations, and the European technology landscape.

The Invariance — by Fernando Martín In a constantly evolving world, only value is the invariance that holds everything together.

Thanks for reading. If this resonated, share it with someone who needs to read it.

Subscribe now

Leave a comment

Subscribe now

For most of the last two decades, building technology products meant fighting on two fronts simultaneously: the market front and the technical front. You had to understand what to build and you had to be capable of building it. The second constraint was real. Developers were scarce, deployment was slow, debugging was expensive, and the gap between idea and shipped product was measured in months, not hours.

That constraint is gone now. Or close enough to gone that it changes everything.

What’s left, the thing that hasn’t been automated, the thing that resists, is understanding. Real, hard-won, uncomfortable understanding of the business problem you are trying to solve, the customer you are solving it for, and the economic system they operate inside.

The grey matter is shifting. The premium is moving from technical execution to business judgment. And most people building products haven’t fully absorbed what that means.

What the last fifteen years looked like

I’ve been close to this problem from multiple angles. At Intel I validated modem programs that ended up inside multiple generations of the iPhone. The work was precise, technical, and demanding. It was organised around the assumption that the hard part was getting the technology to work. The business case for a faster modem was largely assumed. The challenge was execution.

Don’t get me wrong, delivering technology in that environment is not easy, but getting Apple to agree to get those modems into their flagship product, was also not a walk in the park.

When I founded Eccocar in 2017, I carried that assumption forward for longer than I should have. We spent enormous energy on the technical architecture, the SaaS platform, the integrations, the fleet management stack. And we built something genuinely good. But the moments that actually moved the business were never technical. They were the moment we understood that enterprise clients didn’t want software; they wanted a way to show their sustainability commitment to their own customers. Thy were the moment we understood that the Tier 2 Rent a cars saw our technology as the opportunity to improve the user experience of their customers (NPS) and fight for some market share. They were the moment we learned what Amadeus actually needed, specifically, in language that matched how they thought about their own business.

The technology was table stakes. The business insight was the asset.

I didn’t fully name this at the time. It was easier to stay busy with the technical work, because technical work is legible. You can point to a feature, a deployment, a fix. Business understanding is harder to show. It accumulates slowly, and it looks like nothing until suddenly it looks like everything. It compounds every day, with every meeting, every intereaction, every new player in the ecosystem… And it needs time to settle down.

”The technology was table stakes. The business insight was the asset.”

What the shift actually means

The tools we have now have collapsed the execution layer. What took a three-person engineering team six weeks I can now do in an afternoon, not by being smarter, but because the cost of turning a decision into a deployed product has dropped by an order (or two) of magnitude. Especially and specifically in software development.

This should be good news for everyone. In practice, it’s disorienting for people whose professional identity was built around technical execution, and it’s quietly revelatory for people whose real skill was always judgment.

Here is what the shift means concretely.

The bottleneck moved upstream. When execution is cheap, the thing that limits outcomes is the quality of the decision that precedes execution. A bad hypothesis, shipped in an afternoon, is still a bad hypothesis. Speed amplifies clarity. It also amplifies confusion. If you don’t know what you’re building and why, you can now be wrong faster than ever.

Customer understanding compounds differently than technical skill. Technical skills have a shelf life. The stack you mastered in 2019 is partially obsolete in 2026. Business understanding, the kind that comes from sitting across from customers, watching them work, and understanding what they actually care about, gets more valuable the longer you accumulate it. The depreciation curve is inverted.

The ability to translate is now the rarest skill. The professionals who will matter most in the next decade are not the ones who can prompt AI well, and not the ones who can code. They are the ones who can move fluently between a business problem and a technical solution. The ones who can sit with a customer, understand the real shape of their problem, and then direct an AI system to build something that actually solves it. That translation layer is irreducibly human (yet). It requires context, judgment, and accountability that no model currently provides.

Why this is hard to accept

Engineers, and I include myself in this, are drawn to technical complexity. It’s satisfying in a way that business work often isn’t. You can feel yourself making progress. There are right answers. The feedback loop is tight.

Business understanding has a much messier feedback loop. You spend weeks learning an industry, building relationships, mapping the real decision-making structure of an organisation, and you can’t show any of it in a pull request. The value is invisible until it isn’t.

This is why so many technically strong teams build products nobody buys. Not because they can’t build. Because they spent their grey matter budget on the wrong problem.

I’ve watched this pattern repeat across the startups I’ve been close to, and I’ve fallen into it myself. The technical problem is always more tractable than the business problem, so you work on the technical problem. The product gets technically impressive and commercially inert.

“The technical problem is always more tractable than the business problem, so you work on the technical problem.”

What to do about it

The practical implication is simple, if uncomfortable: spend more time with customers than with your IDE. Not to run surveys or collect feature requests. To understand the actual business they are running, the pressures they operate under, and the definition of success they are accountable to.

Ask what their job costs them if it goes wrong. Ask what the decision they’re about to make looks like to their board. Ask how they explained your product to someone who wasn’t in the room. The answers to those questions are more valuable than any technical specification.

Then build the smallest thing that addresses what you learned. Use every tool available, and there are extraordinary tools available now, to ship it fast. Observe what happens. Go back to the customer. Repeat.

The loop hasn’t changed. What’s changed is that the technical half of the loop is now almost free. Which means the business half, the thinking, the listening, the judgment, is where all the value lives.

The grey matter is shifting. Point yours at the right problem.

Fernando Martín is Managing Director of NEXMO Movement Data Hub (UC3M), Venture Builder at MOVEN, and founder of Eccocar. He writes here about venture building, AI agent operations, and the European technology landscape.

The Invariance — by Fernando Martín

In a constantly evolving world, only value is the invariance that holds everything together.

Thanks for reading. If this resonated, share it with someone who needs to read it.

I believe in adding real value.

Not as a management platitude — as a first principle. Every person, in their professional and personal life, should be adding value to someone. From your own knowledge to your company. From your company to your customers. From your personal experience to the people around you.

This is the quintessence of life in society. We are all interconnected. We generate problems for each other, and we generate the solutions to those problems. The whole structure of civilisation is, at its core, a network of value exchanges — some of them transactional, some of them invisible, most of them taken for granted.

I’ve believed this for a long time. But I believe it more urgently now than I ever have. Because we are entering an era where the question of who is actually adding value — and who is merely processing information in circles — is about to be answered in the most unambiguous way possible.

The great clarification

Every repetitive white-collar job that adds no real value to the customer is going to be replaced by an agent running on artificial intelligence. The data entry. The format conversion. The report assembly. The meeting summary. The first draft of the document that everyone edits into the same document it was before.

I want to be clear about this: that is good news.

Not for the people whose jobs disappear, in the short term. That disruption is real and the transition will be uncomfortable for many. But at the systemic level, what is happening is a clarification — an enormous, accelerating, irreversible clarification of what human work is actually for.

Whether the model is sitting in a data centre owned by Anthropic, OpenAI, or Google, or whether it is open source and running on a local server with a couple of GPUs in your basement — it doesn’t matter. Intelligence is becoming a commodity. The ability to move digital information from one format to another, to synthesise a document, to draft a response, to classify an input — these are things AI can do today, in many contexts, better and faster than we can. That window is not closing.

What this means is that the tasks which remain — the ones that resist automation, the ones that require judgment, the ones that require someone to be accountable for the outcome — those tasks are now more visible than they have ever been. They were always the hardest. They were always the most valuable. But for decades, they were buried under layers of process, bureaucracy, and low-value activity that consumed the majority of most professionals’ working days.

The agents are clearing that ground. What’s left standing is the work that actually matters.

What I’ve seen from the inside

I’ve been building technology products for fifteen years — across modem programs at Intel that ended up in multiple generations of the iPhone, across eight years founding and running Eccocar as a B2B SaaS platform with enterprise clients, and now directing a sovereign data space at UC3M.

In that time, I’ve watched technical acumen go from being an asset to being table stakes. Knowing a tech stack deeply — and being able to deploy solutions with high margin — was always valuable. But for most of my career, deployment cycles were slow, debugging was expensive, and the distance between idea and shipped product was measured in weeks and quarters, not hours.

The tools changed everything about that.

What used to be a three-week cycle to find a bug, understand it, plan a fix, implement it, test it, and deploy it — is now fifteen minutes. Not because the thinking got easier. Because the execution layer got dramatically cheaper. We don’t spend seven meetings analysing a mistake. We ship a fix, observe what happens, and move forward. The feedback loop compressed by an order of magnitude.

The result is not that thinking matters less. It’s that thinking is now the primary constraint. When execution is cheap, the thing that limits you is the quality of the decision that precedes it. When prototyping is fast, the bottleneck is the clarity of the hypothesis being tested. When code can be generated, reviewed, and deployed in minutes, what differentiates outcomes is whether the person directing that process understands what they are actually trying to build — and why.

This is the shift that most discussions about AI in the workplace miss. They focus on what gets replaced. The more interesting question is what gets revealed.

The skills that compound

Technical acumen still matters — more than ever, actually. But it now means something different. It is less about the ability to write code fluently, and more about the ability to design systems: to understand how components interact, where failure propagates, what the second-order effects of a change will be.

The professionals who will compound in value over the next decade are the ones who can do three things simultaneously:

They can see the system — not just the task in front of them, but the workflow it belongs to, the problem it is solving, and the constraints it operates within.

They can make decisions under ambiguity — not wait for complete information, not escalate indefinitely, but form a judgment and commit to it while staying open to revision.

And they can take accountability for outcomes — not just for outputs. Not “I delivered the report” but “I improved the thing the report was supposed to improve.”

These skills were always the hardest to develop and the hardest to hire for. What’s changed is that AI is making it impossible to hide behind the other kind of work. The gap between someone who has these skills and someone who doesn’t is widening faster than any point in my career.

Why I’m writing this

I am not writing this to warn anyone. The tone of most AI commentary oscillates between breathless optimism and existential dread, and I find both exhausting.

I’m writing it because I think the value-addition frame — the simple, human idea that we are here to be useful to each other — is the most practical lens for understanding what is happening. The question is not whether AI will change your job. It will. The question is whether, when the process layer is stripped away, there is genuine value underneath.

For most people who are good at what they do, and honest about it, the answer is yes.

The agents are not coming for the value. They’re coming for the noise around it. And clearing that noise — if we let it — is the opportunity of a generation.

Fernando Martín is Managing Director of NEXMO Movement Data Hub (UC3M), Venture Builder at MOVEN, and founder of Eccocar. He writes here about venture building, AI agent operations, and the European technology landscape.

The Invariance — by Fernando Martín
In a constantly evolving world, only value is the invariance that holds everything together.

Thanks for reading. If this resonated, share it with someone who needs to read it.

Leave a comment