The grey matter shift
The scarce resource in building technology products is no longer technical. It never was. We just forgot.
Issue #02 · May 2026
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 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.