What if we were all product managers without even knowing it?
+In fact, everything can be a product. A simple day-to-day activity, including learning a new field, can be examined through a product lens. Product sense can be integrated practically into most daily tasks and professional situations.
+Today’s popular hackathons are compressed product exercises and excellent testbeds for this product management (PM) view: participants apply product judgment under time pressure. In just a few hours - a mini product lifecycle from idea to pitch - they define a problem, identify target users, prototype a solution, and construct a narrative that makes adoption plausible. They answer, implicitly, the three core product questions: who is this for, why now, and what outcome would make this more than a demo?
+This was my approach to building knowledge in the field: treating my PM deep dive as a product in itself - with a conception, development, and management process. I defined:
+-
+
- the users (future me, readers of articles I am about to write), +
- the problems (confusion about the different definitions that exist for a concept, overwhelming amount of information about the topic, lack of structure in that learning journey), +
- the outcomes / hypothesis (clarity, reusable frameworks), and +
- the small experiments I run each week (applying the knowledge on current tasks, observing and analysing the result, correcting, and iterating). +
From this, I built a 1-page canvas with structured questions applicable to any product situation encountered on a daily basis. It acts as a forcing function: to think systematically about what, for whom, and why.
+Finding a structural framework makes it possible to focus on content rather than form - a principle well understood in research methodology. The same holds in PM. It is more an epistemology for decisions than a new identity: a bridge competency that enables close cooperation between cross-functional team members, ensuring every angle and point of view is valued in the product development process.
+Past experiences look significantly different when examined from a PM perspective. Applying PM vocabulary, structure, and core questions to prior work surfaces responsibilities and decisions that were always there - simply unnamed.
+Shifting from how / when - the core investigation of a project manager - to what / why - the core focus of a product manager - reveals new layers of responsibility embedded in past decisions, highlighting some of them clearly product related. I call this backward reframing. Together with forward learning, it forms a complete learning strategy that considerably deepens understanding of the field. (Find the two canvases here and here.)
Applying this to a past project management role of a communication campaign, the shift is illustrated clearly:
+-
+
- Seen from a project lens, this campaign was about coordinating dates, venues, and materials. +
- Seen from a product lens, it was about designing and iterating an experience that delivered specific value to specific users under real constraints. It was about prioritizing competing needs, clarifying ambiguity, coordinating stakeholders, and translating business goals into delivery choices. +
The reality today is that the bottleneck in many technology projects has moved from implementation capacity to product judgment. Understanding key concepts like product lifecycle, product discovery, or prioritization is crucial to decide what should exist and to ensure product quality and adoption required in an AI-accelerated world.
+My professional activities have always lived at the intersection of analysis, communication, business, and building. Engaging seriously with PM fundamentals connects these domains into a coherent whole: it gives me a precise language - value, users, lifecycle, evidence - that travels across research, strategy, and code. It widens the lenses I can use to look at a problem to solve, using consciously the PM hat.
+That language is not a job title. It is an angle for making better decisions about what to build and why - one that sharpens with every question asked and every assumption tested.
+