Too many products get built because the technology is available, not because a genuine need exists.

A conversation with Ronny, Founding Partner at Sweetspot
Ronny is the kind of person who builds things to understand them. As a founding partner at Sweetspot, he brings deep technical expertise, combined with a career spent launching products from scratch across industries as diverse as broadcast, industrial automation, and offshore energy. We sat down with him to talk about product strategy, what hasn't changed in twenty-five years, and why the best product managers get their hands dirty.
How would you describe your role at Sweetspot?
Among the three founders, I tend to be the one who goes deepest on the technical side. I've made it a point throughout my career to stay genuinely up to date on software and technology, not just follow it from a distance. And that shows up in my work.
For one of our customers, we came in because of a performance problem. The first question was technical: how is this system architected, where are the bottlenecks, what's actually causing this? That's the kind of deep dive I enjoy.
What kind of work genuinely excites you?
The best periods of my career have always been the same: a good team, a well-defined problem, and the challenge of building a solution from the ground up and actually getting it to market. A former boss once said that innovation is the successful launch of a solution to a real problem. I still think that's the best definition I've heard. That's what I love doing.
Both sides of that equation are interesting to me. On one side, the market: is this a real problem? Is there demand? Are there early adopters willing to take a risk on a new solution? On the other side, the engineering: how do you build it, how fast can you move, how do you maintain quality while keeping momentum?
The best periods of my career have always been the same: a good team, a well-defined problem, and the challenge of building a solution from the ground up and actually getting it to market.
There's one other thing I've learned about myself: I like products that actually do something. Products that involve movement, action, a physical dimension. Broadcast, large-scale displays, automated warehouses, offshore systems. When a product manifests in the real world in some way, I find it infinitely more interesting to work on.
You've been doing this for over twenty-five years. What has changed in product management and what hasn't?
When I started, the term "product manager" barely existed. I first heard it at Barco, around 1997 or 1998, when I took a course at a renowned training center, and it was a genuine revelation. It was the first time I found a role description that matched what I actually wanted to do.
Since then, a lot has changed. The rise of agile transformed how software teams work, and product management evolved with it. Then came servitization or the shift from product to product-as-a-service, which is now completely mainstream in software. And now AI is changing how products are built, and increasingly how they're brought to market too.
But one thing hasn't changed: if you don't solve a real problem, nothing else matters. Too many products get built because the technology is available, not because a genuine need exists. Or the problem is real but poorly defined. Or the problem isn't big enough to justify the solution. That's been the underlying cause of most product failures I've seen. That part hasn't changed in twenty-five years, and I don't expect it to.
How do you recognize when something's going wrong, before anyone admits it?
Usually within the first five minutes. If someone can't clearly explain what their product does and for whom, not in a pitch, just in normal conversation, that's a signal. A confused elevator pitch almost always means a confused strategy underneath.
The harder signal is politics. When you walk into a room and feel that different people are pulling in different directions, with competing agendas, that's much more difficult to fix as an outsider.
A confused elevator pitch almost always means a confused strategy underneath.
You're still building products in your spare time. What's that about?
That one started on a warm evening during a holiday in Sicily. While my family had gone to sleep, I was dabbling with the Meteor framework to see if I could build a tool to manage the local music society I’m part of. They were running their administration on a patchwork of emails and spreadsheets. One evening of coding turned into a product.
TamTam is now a proper SaaS application. It handles everything from member management to concert planning, ticket sales, sponsor tracking, and even Peppol invoicing integration. We only have a small customer base, but that's not really the point for me. TamTam is my playground. It's where I test new technologies, experiment with AI, and stay sharp as a builder.
Right now, I'm building an AR feature that lets you visualize a concert hall layout on your phone, so you can see how many people fit, where the sightlines are, and how to set up the stage. Building this teaches me things I bring back to client work every day.
That hands-on approach; is that something you'd recommend to product managers more broadly?
Absolutely. Get your hands dirty. Build something, even just a proof of concept. I've done this throughout my career, and it's changed how I work with engineering teams. When a developer tells me something will take five man-years, I can push back with some credibility. Maybe the truth is somewhere in the middle. But at least the conversation is grounded. That kind of firsthand experience is something no course gives you. The barrier to building has dropped dramatically in the last few years. There's really no excuse not to try.
The barrier to building has dropped dramatically in the last few years. There's really no excuse not to try.
What do you do when you're not working?
I play tennis every week and I’m an avid reader. And music, which is technically a hobby but has gotten somewhat out of hand. I started playing clarinet at forty-five, which is late, by any standard, and ended up joining a local music society, then somehow ended up on the board, which is how TamTam got started in the first place.
Want to explore what Ronny and the Sweetspot team could do for your product? Book a quick intro call.