From Brushes to Product Strategy - A Journey Through Creativity, Leadership and Curiosity
The "Rabbit"
I ran a shoe repair "business" before learning multiplication tables. Due to low ROI from my family, I had to close it down after a few months. The company itself was simply called "Rabbit". Everyone already knew what I did, so a descriptive corporate identity apparently seemed unnecessary. I did have a logo, painted by me with a brush and watercolours on a piece of plywood and nailed to the garage door.
There was no career prophecy hidden in a six-year-old repairing shoes, but the basic impulse was already there: make something, understand something, change something, give it form. I have never been particularly good at accepting default settings, whether they belong to an object, a system or an idea. Long before I knew that design, product strategy or systems architecture existed as professions, taking things apart and wondering whether they could work differently already seemed like a perfectly normal way of interacting with the world.
The ship of beautiful madmen
That probably had something to do with the environment in which I grew up. My parents were eclectic, deeply curious people for whom engineering, art, science, music and philosophy were never separate departments. My father worked in technology through IBM, Honeywell-Bull and other companies of that era, but computers were only one part of a much wider world. Both of my parents were seriously interested in astronomy and astrophysics; they drew star maps together, telescopes were part of the household, and nights at the observatory were simply part of life. I grew up looking at the sky as something to understand, not as decoration or zodiac mysticism.
The same home contained painting, literature, classical music, philosophy, electronics, tools, photography, nature and a considerable amount of humour. My mother brought Bach, classical guitar, Tom Waits, absurdity and her own artistic sensibility; my father brought Cohen, classical music, Zen, engineering and the practical habit of understanding why something worked rather than merely accepting that it did. Around them was an equally unlikely circle of photographers, astronomers, artists, writers, scientists, philosophers, engineers, physicists, professional divers, underwater photographers, movie pyrotechnicians and other beautifully weird and creative people. I grew up on a ship of madmen, and it was a wild and wonderful ride.
Nobody called any of this "multidisciplinary thinking". Knowledge simply crossed borders because the people around me did. Photography came early, together with the darkroom, chemicals and the strange pleasure of watching an image emerge where apparently nothing had existed. Computers entered the same world without replacing anything. On the C64, my father taught me to connect a small portable IBM oscilloscope to the cassette deck and adjust the head with a screwdriver while watching the signal. One of the most frequent phrases of my childhood was probably SYNTAX ERROR, which in retrospect was useful training: something did not work, therefore the interesting part was finding out why.
Making things followed naturally. For a school art assignment at around nine or ten, while more sensible children were producing respectable schoolwork, I built a giant fly from construction-site and household rubbish: spray cans, wires, plastic pipes, nylon and whatever else seemed useful. The teacher loved it, kept it, and years later I discovered the same fly in photographs from a surrealism exhibition at the Cvijeta Zuzorić Art Pavilion, credited as the work of an unknown pupil from my school. My first exhibition, apparently. Nobody thought to tell the artist.
The important part was never the number of interests. It was the absence of hard walls between them. A camera was optics, chemistry, composition and psychology at once; a computer was engineering, logic and imagination; astronomy was mathematics and wonder; art trained perception while dismantling a machine exercised the same curiosity from another direction. I did not set out to become a generalist. I grew up assuming that knowledge was connected and that looking beyond the immediate subject was simply how understanding worked.
When the borders became real
The 1990s demonstrated rather violently that people were perfectly capable of building walls where none needed to exist. Yugoslavia collapsed into war, sanctions, poverty, nationalism and increasingly loud demands to choose a tribe, precisely when I was becoming old enough to decide what sort of person I intended to be. Having grown up among people whose friendships, interests and identities crossed categories without asking permission, the sudden insistence that a human being should be reduced to one collective label struck me as both dangerous and profoundly stupid.
A group of friends and I responded in our own way, including creating our version of the Toledo Order, inspired by Buñuel and the surrealist lineage around him. Art, humour, absurdity and deliberate provocation became both entertainment and a refusal to be reduced to the available tribes. Those years also turned abstract ideas about systems, authority and human behaviour into observations with rather higher stakes. Apparently stable institutions can become fragile very quickly; authority and competence are not synonyms; people behave differently under pressure; rules depend on the assumptions beneath them; and systems that pretend human psychology does not exist eventually encounter it anyway.
Much later, parts of those lessons would acquire cleaner professional names: negotiation, stakeholder management, organisational behaviour, leadership, incentives, conflict, risk and decision-making. At the time, they were simply life.
From brushstrokes to pixels
During and immediately after those years, painting became a much more serious part of my life. It sharpened the way I looked at proportion, balance, colour, negative space and the relationships between parts, while giving all that restless observation somewhere tangible to go. When digital tools later became another medium, none of it felt like abandoning one world for another. From brushstrokes to pixels, I developed a lasting fascination with the dialogue between art and technology, and much of that visual thinking eventually travelled with me into interaction and product work.
Structure, from crystals to people
My formal academic field is Mineralogy and Crystallography I studied at the University of Belgrade, which looks absolutely unrelated to product strategy if a life is read as a list of job requirements. It was not a deliberate preparation for technology or design. I was interested in it because structure itself was interesting.
Crystallography gives an unusually clean way of seeing how apparently simple elements produce complex forms through relationships. A lattice is not meaningful because it contains a collection of points; its character emerges through position, repetition, symmetry, orientation, constraints and transformations. Bravais lattices fascinated me because a relatively small number of structural principles can explain an enormous variety of visible forms. Once the underlying relationships become clear, complexity stops looking like a pile of unrelated pieces.
I would never claim that crystallography "taught me product design". That would be convenient mythology written backwards. It did, however, strengthen a habit that later became central to almost everything I do: looking for the structure underneath the visible object, finding the dependencies between its parts, and tracing what happens when one relationship inside the larger whole changes.
Military service added another kind of structure, this time made of people. I became a Corporal and led and trained a ten-man squad, which is a reasonably efficient way to discover that ten people wearing identical uniforms remain ten different people. Authority, discipline and rules matter, but so do credibility, judgement, trust, temperament and the ability to understand what is happening on both sides of a hierarchy. My position required working with the men I led and the officers above me, translating between different expectations while keeping the unit functional.
That experience turned out to be remarkably portable. Organisations, teams and stakeholder groups are obviously not military units, but hierarchy, responsibility, conflicting priorities, imperfect information and human psychology do not disappear because everyone now has a laptop. Being able to move between levels, understand what each side actually needs and keep the larger structure coherent became one of the most useful parts of my professional work.
These days I train one stubborn Shiba Inu, which is by far my most tremendous success.
Marccolò Doganini performing "Striped Violin Concerto for Canis Minor, Allegro e Presto"
Where all of it became work
I never really had a moment when I "became" a product person. By the time digital products became my profession, most of the machinery was already there. Science and engineering had trained the instinct to ask how things worked; art and photography had trained perception; the ship of beautiful madmen had made crossing disciplines normal; the 1990s had made me suspicious of tribal thinking and unquestioned authority; crystallography had given me a formal language for structure; military service had added leadership, hierarchy, responsibility and pressure. Product work simply gave all of those things somewhere to meet.
Over more than twenty-five years, I worked across SaaS, telecommunications, automotive and navigation, workforce management, enterprise software, maritime and land-based logistics, gaming and betting, and a collection of other domains that initially appeared to have very little in common. The subject matter changed constantly, but beneath it the same structures kept reappearing: people trying to achieve something, information moving through a system, rules allowing or preventing actions, incentives shaping behaviour, technology imposing possibilities and constraints, and organisations trying to reconcile what they wanted with what could actually be built.
That variety never felt like repeatedly starting from zero. Every new domain required learning its language and realities properly, but the deeper skill was learning how to recognise the structure underneath unfamiliar terminology. A shipping platform, a workforce-management system, an automotive experience and a betting back office may look unrelated on the surface, yet all contain actors, states, permissions, dependencies, flows, exceptions, feedback, competing goals and consequences. Once those relationships become visible, the problem stops being an intimidating mass of details and starts becoming something that can be reasoned about.
That is still essentially what I do. I design complex, large-scale systems and have spent years grasping why things break and how to make them whole again. Most of my work begins where things are messy: too much data, conflicting goals, unclear decisions, systems accumulated over years, stakeholders looking at the same product from incompatible positions, or users trying to work around logic that made perfect sense to somebody inside the organisation. The job is to find the structure that brings those pieces together and makes complexity feel simple without pretending that the underlying complexity has disappeared.
My work therefore expanded naturally beyond individual interfaces. I have worked across almost the entire product lifecycle: initial analysis, research and interviews, understanding users and their goals, identifying business and strategic opportunities, defining information and UX architecture, specifying functionality, developing concepts and prototypes, iterating with stakeholders, presenting decisions, and carrying those decisions into development-ready delivery. I can work deeply inside one interaction when that is where the problem lives, but the larger the systems became, the less sense it made to treat the interface as an isolated object.
Some projects made that particularly obvious. Automotive and navigation work could span the first mile, the drive itself and the last mile, with electric-vehicle behaviour, range anxiety, mapping, driver interaction and the physical car affecting one another. Maritime and land-based logistics placed interfaces on top of operational fleets, vehicle management, economics, predictions, automation and competitive information. Workforce-management products had to reconcile employees, schedules, permissions, organisational hierarchies and business rules. Large back-office gaming and betting systems involved traders, agents and other specialist roles operating inside dense networks of data and rules where a seemingly minor structural decision could propagate far beyond the screen where it first appeared.
Working on systems like those gradually moved my focus from product and interaction design towards product strategy, architecture and leadership. It was not a move away from design, and certainly not a promotion out of "real work". It was the result of following problems backwards until reaching the point where they actually originated. Sometimes the problem was an interaction. Sometimes it was information architecture, an unresolved business rule, a permission model, a process that should not have existed, or two stakeholder groups whose objectives were quietly incompatible. A polished interface placed on top of the wrong structure simply makes the wrong structure prettier.
From product design to product strategy
The larger the products became, the more often the useful question changed from "How should this screen work?" to "Why does this exist, what depends on it, who does it affect, what happens when it changes, and does the surrounding organisation actually support the decision?" At that point product design, product strategy, architecture, negotiation and organisational thinking stop being cleanly separable activities.
I still value execution because strategy that cannot survive contact with implementation is mostly decoration. I can move from broad framing into flows, information architecture and detailed interactions, then back out again when a local decision exposes something broken deeper in the system. A small usability issue can turn out to be a damaged permission structure. An awkward interaction may reveal a business rule nobody has questioned for years. Two teams may be solving different versions of the same problem because they do not even share a definition of the object they are discussing.
The ability to trace those relationships is one of the main consequences of everything that came before. I tend to work through a system in my head before putting it on paper, follow decisions and consequences several steps beyond the obvious interaction, and ask how the thing will behave once real people, real data and real operational pressure arrive. The useful solution is rarely the most impressive-looking artefact. It is the one that still makes sense after the system starts living.
That also changed the way I approach leadership. I have led and mentored teams of designers, including groups of twenty or more, but I have never been interested in turning my own habits into doctrine. Different problems deserve different methods. My role has usually been to establish direction and context, make important constraints visible, help people understand the larger system, and intervene when experience can prevent unnecessary mistakes. Leadership is not getting everyone to reproduce one person's method. It is creating enough clarity that good decisions can be made without every decision having to come from the same person.
Much of the work also happens between disciplines. I do not code professionally, but I need enough technical understanding to know when an idea creates unnecessary development complexity, when an implementation constraint is genuine, when it can be negotiated, and where a seemingly elegant concept becomes unreasonable once it reaches engineering. The same product conversation may involve front-end and back-end developers, management, clients, analysts, designers and domain specialists, each describing the same system from a different position. A significant part of product leadership is therefore translation, not reducing one discipline to another, but building enough shared structure that they can work on the same reality.
Communication through glass
The longer I worked on products, the more communication became inseparable from everything else. Good communication is my primary tool and one of the most essential aspects of almost everything in life, whether verbal or written in person, or on the other side of the glass through product design and logic.
Somewhere along the way, that understanding condensed into one of my more useful bits of accidental "wisdom":
Bad UI is rude, and bad UX is confusing talk.
A product is constantly speaking to somebody. It tells people what exists, what matters, what they are allowed to do, what is expected from them, what has happened and what will happen next. When that conversation is coherent, users rarely stop to admire the logic because they are too busy getting on with what they came to do. When it fails, they are forced to reconstruct the assumptions of the people who built it, understand internal organisational logic they should never have needed to see, or guess what the system wants from them.
This is why I find the distinction between "soft" communication and "hard" product work rather artificial. Negotiating with stakeholders, interviewing a user, structuring information, defining a workflow, presenting strategy and designing an interaction are different manifestations of the same underlying problem: information, intention and consequence have to move from one side to another without being mangled along the way. A complex product can fail because its data architecture is wrong, because its interaction is confusing, because two departments never aligned their definitions, or because somebody with enough organisational power approved an assumption nobody challenged. The visible failure is often only the final consequence of something that went wrong much earlier and much deeper in the system.
Looking beyond the box
All of this is probably why I have never understood the urge to remain carefully enclosed inside a professional niche. If a problem is human, technical and systemic at the same time, why should the useful answer necessarily come from a design book, a design tool or even design itself?
Most of these paths are old, omnipresent, and walked by many before us. They were recently put and wrapped into a shiny design box. They don't deviate from any broader principle. They have been here for a couple of thousand years, as far as our species and psychology are concerned, and even longer regarding natural laws and patterns. They are all around us. You just need to notice, adjust, apply, and make them usable.
A structural relationship from crystallography can illuminate product architecture. Psychology can explain why a rational-looking workflow repeatedly fails once actual people enter it. History can expose institutional behaviour that looks novel only because the reference window is too short. Photography can teach attention and framing. Military experience can reveal how rules behave under pressure. Games can expose feedback, motivation, consequence and emergence with unusual clarity. None of this means collecting exotic references for decoration. It means refusing to stop looking simply because the current professional box already contains a convenient answer.
A narrow field of view can make someone extremely efficient inside a known problem while making the edges of that problem almost invisible. I would rather understand the larger system first and then decide which specialised tool, method or discipline is useful inside it. Tools and methods are useful, but they are not the work itself. They change constantly. Clear principles, observation and common sense tend to survive rather longer than rigid rules and passing trends.
Brownian thoughts and the city in my head
My way of solving complex problems is difficult to reduce to a neat methodology diagram. When a project is complex enough, I construct it as a three-dimensional system in my head. The closest comparison is a city. I move through it rather than merely looking at the map: down into streets, through intersections, along routes people actually have to use, into blind alleys and buildings that appear perfectly reasonable from above but stop making sense once the city begins to live.
I enter from different points and let different actors move through it. I change one rule and watch where the consequences travel. I look at traffic, bottlenecks, unnecessary detours, isolated areas and places where several structures are trying to occupy the same space. I trace decisions forward and backwards and try to predict how the system will behave in the real world rather than only in the ideal state imagined during a workshop. I also look for what already works and should be left alone, because changing something merely to demonstrate that design has occurred is another form of default thinking.
Then I leave the city running. Sometimes for hours, sometimes for days. Parts of the problem collide with things from psychology, technology, logistics, history, crystallography, art, games or some old conversation. The path can look almost random from the outside, but there is always a gravitational centre. I have described it as Brownian motion that crystallises: thoughts move widely, but the original problem keeps pulling useful connections back towards it until the apparent disorder resolves into structure.
Once that internal structure becomes stable, the visible output can happen very quickly. I once described it as solving a project in my head in 3D, almost meditating, walking through it and exploring it, and then folding everything into a solution with one swift, decisive swing. That final swing may become an architecture, strategy, workflow, prototype, presentation or set of screens. The apparently fast part is only fast because most of the work has already happened somewhere less visible.
Making complexity visible
One of the clearest physical expressions of this way of working came at TomTom in Amsterdam. When a product becomes large and complex enough, keeping it inside individual screens, files or people's heads often becomes part of the problem. Journeys, behaviours, dependencies, assumptions, edge cases and competing requirements need to be pulled out into shared space until the system can be seen as a whole and decisions can be traced through their consequences. Sometimes that means stepping away from the screen entirely and covering a wall with the problem, moving through it physically, rearranging relationships and letting the structure emerge in front of everyone. The wall was never workshop theatre or decoration; it was simply another way of making complexity visible enough to reason about.
Working at TomTom's Amsterdam office. The saga continues across the whole office. :)
The work now
The same approach now extends beyond conventional product roles. My current independent work includes product and systems research, AI workflow architecture, local-first software, policy work and a large reactive game-system framework. On paper those can again look like unrelated branches. In practice they are variations of the same problem: complex rules, people, information, technology, decisions and consequences that need to remain coherent as the system grows.
AI workflow work is a particularly good example because the technology changes while the underlying leadership problem remains surprisingly familiar. Working with multiple agents sometimes feels less like "using AI" and more like being an AI squad lead: keeping agents in line, maintaining context, deciding who should do what, making sure different pieces still serve the same objective, verifying what comes back, and preventing everyone involved from creating a total mess. The interesting part is not the novelty of the tool. It is designing the surrounding workflow so that capability does not become chaos.
That has led me into long-lived knowledge bases, recovery procedures, explicit state, verification, traceability and ways of maintaining human control over processes that can otherwise drift remarkably quickly. The same old questions return in new clothing: what is the source of truth, who is allowed to change what, how do we know whether a decision propagated correctly, what happens when a component fails, and how do we recover without rebuilding the whole system from memory?
The OpenAI Data Exporter grew from a much more concrete irritation. I wanted a local, private way to process the official ChatGPT export and turn conversations into usable Markdown and PDF documents while preserving embedded material. Rather than waiting for somebody else to build the version I wanted, I built it myself as a browser-based, local-first tool without accounts, uploads, telemetry or a backend. The scale is smaller than many of the enterprise systems I have worked on, but the instinct behind it is recognisable from "Rabbit": understand the problem, take apart the available structure, and make the version that ought to exist.
Another strand is a large reactive and neuroactive RPG systems framework in which psychology, perception, cognition, identity, social behaviour, decision-making, persistent world state and causality are interconnected rather than treated as decorative layers. Building it requires thinking several levels below the visible experience: not merely what appears on screen, but which rules made it possible, what remembers it, what changes because of it and how consequences propagate through systems that may initially appear unrelated.
Policy work followed the same route from another direction. Looking at contemporary hiring practices led me into the boundary between candidate assessment and productive labour, and eventually into an independent proposal for an EU-level framework dealing with classification, transparency, compensation and ownership. Again, the subject changed but the machinery did not: identify the actors, incentives, information and power relationships, find where the existing structure produces bad outcomes, then change the structure rather than merely treating the symptoms.
None of this requires pretending to be an expert in every discipline it touches. Generalism, at least as I understand it, is almost the opposite. The broader the field of view becomes, the more obvious the limits of one's own knowledge become and the more valuable real specialist expertise is. The useful skill is recognising relationships, learning enough of an unfamiliar domain to ask better questions, knowing when someone else's depth is required, and keeping the whole system visible while specialists work deeply inside their parts.
On becoming
Seen as a conventional biography, shoe repair, painting, astronomy, photography, computers, surrealism, crystallography, military leadership, psychology, technology, logistics, negotiation, product design, AI workflows, policy and game systems look like an unnecessarily complicated collection of detours. That is not how I experience them, and it is not really what this article is about.
The personal history matters because it explains the professional trajectory. Each layer altered the way later problems were understood. Art and photography sharpened perception. Science and crystallography reinforced structural thinking. Growing up among people who crossed intellectual borders made multidisciplinarity normal rather than aspirational. The 1990s strengthened resistance to tribal certainty and unquestioned authority. Military service added leadership, hierarchy and human behaviour under pressure. Twenty-five years of product work then tested those instincts against real organisations, real users, real money, real technical limitations and systems large enough that mistakes propagated.
That professional experience changed me in return. Individual interactions became products, products became large operational systems, and those systems led naturally into strategy, architecture, negotiation, leadership and questions that did not belong neatly to a single discipline. Today most of my work begins with complexity, messy data, competing goals and unclear structure. The objective is still remarkably simple: understand the system well enough to make it coherent, traceable and intuitive, so that everything clicks without requiring the people using it to understand the machinery underneath.
That is also why I rarely settle for defaults. I take things apart, whether they are products, workflows, ideas or methods, and try to understand the logic holding them together before deciding what should change. The tools have changed repeatedly, from brushes and darkrooms to design software, enterprise platforms and AI agents. The underlying work has not changed nearly as much.
Generalist by curiosity, not by default, I eventually realised that these pieces were never steps on a ladder, but points in a large, invisible lattice that had been taking shape all along.
Perhaps becoming is simply recognising the pattern that was there long before you knew what to call it.