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