A systems-focused product strategist working across AI, computer vision, IoT, and smart infrastructure explains what really stalls startups — and how to build for scale
Startups don’t usually fail because the idea is bad. They fail because of the bad timing, fuzzy decisions, and scattered execution. As the 2024 report by Embroker says, more than 40% of startups pointed to internal missteps — not the market — as their main reason for shutting down. They built fast, burned bright, and broke apart under pressure.
That’s because what separates a strong product from a sustainable one often isn’t vision — it’s structure. The invisible architecture: how teams make decisions, how feedback gets processed, how the product evolves as complexity grows. Some founders learn this the hard way. Others bring in people who’ve already built those systems across industries, products, and cultures. People like Denis Prodan. A former athlete who turned his discipline into design thinking, Denis has led product development for award-winning devices, AI-driven platforms, and real-time smart city tech. But what makes his work stick isn’t just clever features or flashy roadmaps — it’s the ability to build systems that help teams keep going when things get messy.
In this interview, Denis explains why so many promising startups stall — and how to build the systems that keep them moving.
Denis, so many startups now blame a lack of structure for their failure. Why do you think structure is still so overlooked in product development?
Because it’s invisible when things are going well, and urgent only when they’re not. Early on, most teams rely on speed, instincts, and individual effort. That can work up to a point. But when the product grows — or pressure hits — the lack of structure becomes painful. You start seeing duplicated work, unclear ownership, and decisions made on vibes instead of signals.
Ideas don’t fail. Systems do. That’s when product debt piles up. Features ship, but value stalls. I’ve seen teams with great traction fall apart because they lacked even basic systems for prioritization, iteration, or decision-making.
Was that always your approach, or was there a moment in your career when you realized the power of systems thinking?
That shift happened when I started working across very different kinds of products — IoT fitness hardware, mobile apps, AI platforms. The complexity forced me to stop thinking in tasks and start thinking in feedback loops. I realized that success didn’t come from having all the answers upfront, but from building structures where teams could adapt quickly, learn from signals, and keep momentum. Once I saw that in action, it became my default mode of working.
And now you mentor other founders as they build their own product systems. What’s the first thing you try to teach them?
I try to make them comfortable with uncertainty and help them build a system that doesn’t collapse under it. Most early-stage teams don’t need answers. They need a loop that shows them what’s working, what’s not, and what to do next. Once that’s in place, clarity follows. So does confidence.
Your work spans fitness tech, AI, and smart city infrastructure. But the through-line seems to be system design. How do you approach building a product system from scratch?
I always start with two questions: What’s predictable here? And what’s chaotic but worth managing? From there, I design a system that ties together user outcomes, team operations, and feedback loops. Whether it’s a wearable or a city camera, the goal is the same — reduce guesswork, allow for iteration, and make decisions traceable.
In your experience, what makes a framework or tool truly stick with a team, even after you’ve moved on?
It sticks if it lowers the mental load and sharpens clarity. The best tools I’ve built give teams a shared language, smart defaults, and just enough flexibility to evolve. If the team feels like they co-created the system — not that it was handed down — it tends to last.
Many teams launch fast but get stuck later. You often step in at that fragile pre-PMF stage. What’s the first thing you look at when joining a product that’s struggling?
I look at the last five product decisions and how they were made. Most early-stage issues aren’t about features — they’re about judgment loops. Are they optimizing for learning or scale? Do they really understand the user? Are they solving a real problem or just building something that looks polished?
You’ve created reusable templates in Notion, Figma, and even in AI architecture. How do you decide what to standardize — and what to leave flexible?
I lock in the things that are expensive to redo but rarely change: structure, naming, workflows. And I leave room for creative friction where it matters — like messaging, edge cases, or design nuances. A good template should guide without boxing anyone in.
As co-founder and CPO of PLONQ, you led the creation of a behavioral health device that later won the prestigious Red Dot Award — one of the most globally recognized accolades in product design. What did your systems thinking contribute to making it both functional and award-worthy?
At PLONQ, I co-founded and led the design of a behavioral health device aimed at reducing nicotine dependency. My systems approach combined behavioral science, predictive modeling, and BLE-integrated hardware. We ran hundreds of design iterations, including dozens of 3D-printed prototypes, to perfect the form factor and haptic feedback — essential to building trust and reducing friction for first-time users.
Though I exited before the Red Dot Award was received in 2022, the product retained the design DNA and interaction architecture developed under my leadership. That foundation played a critical role in its later recognition and adoption.
At Bownce, where you served as CPO and helped bring the product from idea to launch, the team earned a European Design Award in 2023 — a top international honor in digital product and interface design. How did your approach make such a complex fitness device work so smoothly?
Initially, we explored the idea of integrating an AI-powered personal trainer, but I made the strategic call to focus the first version on delivering core training value with maximum stability. Our goal was to create a physical-digital product that felt immediate and intuitive — no complex onboarding, no steep learning curve.
To achieve this, I built the system in modular layers: computer vision, movement analysis, and app experience. Each component had clear inputs and outputs, allowing us to iterate and evolve without breaking the overall structure. The device and app worked as a tightly integrated loop, delivering real-time feedback through movement, vibration, and visuals. That synchronization created a sense of immersion and flow that resonated even with first-time users.
We saw over 80% retention among our early users — which, for a hardware-integrated fitness app, is a strong indicator of real engagement. That validated not just the novelty of the concept, but also the usability and intuitiveness of the product system we designed.
The result was a product that felt both responsive and approachable — and that structure helped us hit 700+ pre-orders before launch and ultimately earn Bronze at the European Design Awards.
With Parkspot.ai, you’re building an AI platform that helps cities detect open parking spots in real time — a high-stakes problem tied to traffic, emissions, and urban planning. How did you bring structure to something so complex and unpredictable?
We started by controlling what we could: camera placement, update intervals, and user touchpoints. We then modularized everything unpredictable, such as traffic patterns and edge-case visuals. Instead of trying to build one big perfect system, we broke it into testable, trackable units. Every layer had a clear input, model, and output, each with its own metrics and learning loop.
You’ve worked in Europe, the U.S., and China. Do your systems change across cultures, or do some principles always apply?
The fundamentals do: feedback loops, decision hygiene, shared context. But interface changes.
In the US, it’s about momentum and iteration. In Europe, it’s alignment and validation. In China, speed is combined with hierarchy. If you’re rigid, you fail. If your system is built for resilience, it flexes across cultures.
You’re often brought in to help “unstick” teams. What’s a clear sign that a team needs systems, not just more features?
When everything feels urgent but nothing feels clear — that’s a sign. Or when feedback keeps coming but never turns into actual learning. Most teams don’t lack ideas — they lack mechanisms for turning chaos into progress.
For founders who feel overwhelmed by too many moving parts, what’s your best advice for building a resilient product process?
Don’t try to build the perfect roadmap. Build a feedback loop. Focus on small hypotheses, short cycles, and learning every week. You can’t eliminate chaos, but you can convert it into signals. That’s what resilient systems do.
