“Clients Have Problems. Go Solve Them.”
This article first appeared on Substack at https://jacoporomei.substack.com/p/clients-have-problems-go-solve-them.
When I was twelve, in 1990, I told my American uncle, who lives in Washington, that I wanted to be a veterinarian.
He said: “Mmm, why don’t you go into electronics, into computer science? Clients have major problems there: you could solve them.”
I listened. I didn’t fully understand why, but it resonated. I already had a soft spot for IT, programming every day on my 286 IBM-compatible PC :-), so, in the following days, it was easy for me to decide I would study computer engineering. And so I did.
For years, many of the decisions I made were, in one way or another, a response to that same idea: clients have problems, go solve them.
Fast forward thirty-five years. Some weeks ago I called my uncle. I told him about Scaling Tales, the personal branding company I co-founded with Riccardo Demi.
His response: “Oh, so you’re not a developer anymore. Now you do something very different from what you used to do.” I won’t say he was disappointed, but genuinely surprised, yes.
A lot of my old programmer friends have said something similar over the years: “Oh, you’ve changed domain.” Some of them say it with a sense of betrayed belonging, as if, by shifting what I do, I’ve abandoned some tribe.
Frankly, my interest lies less in belonging and more in purpose. The superficial view of my work—taken by both my uncle and my developer friends—misses the point: the purpose was the same when I was writing code as it is now that I’m an entrepreneur focused on personal branding.
I don’t write a single line of code for clients anymore. And yet I haven’t changed what I do at all.
Let me explain.
Same problem, different tools
In the early 2000s, I wrote code. I embraced agile thinking early—frequent releases, constant feedback, automated tests—obvious today, cutting-edge back then.
The software worked. But it often didn’t produce the results we’d hoped for. There was output, but no outcome.
Why? Because the problem wasn’t in the code alone. It was in the process.
You can be agile in your department, lean in your team, eliminate every waste from your workflow. But if the context you work in remains slow, rigid, or inefficient, the value you generate will be limited anyway. You’re just moving bottlenecks from one point to another in the system.
That’s why, after starting as a programmer, I moved to processes, then to collaboration contracts, then to business model validation. Because:
-
it’s useless to have perfect software for a dysfunctional process;
-
it’s useless to have a perfect process if the contracts you sign don’t allow you to use it;
-
it's useless to have a perfect product if nobody wants it.
Each time I moved, the tool changed. But the problem I was solving—removing the bottleneck that prevented value from reaching the client—stayed exactly the same.
The real job description
My friend Vasco Duarte used to say something I’ve never forgotten: businesses, in the end, only have two problems—creating demand and converting it.
That’s it. Everything else is a derivative of those two.
Once you see it that way, the thread becomes obvious. Writing code, fixing processes, rewriting contracts—that was the ‘converting’ side: removing what prevented value from reaching the client. Scaling Tales is the ‘creating demand’ side. Extreme Contracts sits in between.
The activity changed, but the problem didn’t.
Why I couldn’t have stayed on code
This is the part that, I think, creates the confusion.
When I say I didn’t stay on code, some people hear that as a change of profession. I don’t. I hear it as following the bottleneck.
And yes, part of that shift was also personal.
If I’m honest, producing value only through code would have been limiting in every way.
First, it would have been boring. I’m curious about too many things to spend decades doing only one.
Second, it wouldn’t have delivered all the value I could deliver. The bottleneck had moved. Staying behind it would have meant optimizing something that no longer mattered enough.
And third—and this is the one that resonates most today—it would have been incredibly fragile.
Programmers spent the last few decades automating entire industries: banks, newspapers, taxis, hotels, record stores. That was called progress. But when the same logic of automation came for them—first with No-Code, now with AI—many reacted as if the rules had suddenly changed.
They hadn’t.
The rule has always been the same: you’re not paid for the activity itself, you’re paid for the problem you solve. If you define yourself by writing code, AI is a threat. If you define yourself by solving problems through software, though, AI is a tool.
The lesson isn’t specific to programming. It applies to anyone who confuses their key activity with their value proposition.
What comes next
I don’t know what tool I’ll be using five years from now.
I don’t know if it will still be Scaling Tales, or consulting, or something I haven’t imagined yet. The specific vehicle doesn’t matter. It never did.
What I know is that there will be a bottleneck somewhere—between what clients need and what they’re getting—and I’ll follow it, wherever it moves. That’s the job. It’s been the job since I was twelve.
My uncle gave me the right advice—”clients have problems, go solve them.” I just decided I would follow it all the way through.
The tool will change. The bottleneck will move. The job won’t.
Best,
Jacopo
Thanks for reading The Sweep! 🧹 Subscribe for free to receive new posts and support my work.