Product vs Project Missions

Product and project missions require different mindsets — but skills transfer both ways. Product thinking sharpens long-term quality decisions; project urgency sharpens execution. Alternating between them has made me more adaptive and effective in both contexts.

Key takeaways

• Product missions focus on long-term vision; project missions focus on scoped delivery
• A product mindset improves project work (maintainability insights clients appreciate)
• Project urgency sharpens execution skills useful when products need to pivot fast

How I Define Them

Over the years I've worked on both product-oriented and project-oriented missions. Each comes with its own rhythm, challenges, and rewards — and I've found that switching between them has made me a more adaptive engineer.

Product-oriented missions (GetGround, Voyage Vibe, Richemont): Ongoing work tied to a roadmap, focused on long-term vision. They evolve as long as the product is alive.

Project-oriented missions (Marcel, Wojo, Adopt): Scoped around specific delivery, usually with tight deadlines and limited horizon. Once delivered, they may only see minor maintenance.

Product-Oriented: Thinking Long-Term

What I enjoy most in product work is the mindset about long-term vision. You're not just shipping the next feature — you're building something that needs to last.

But there are frustrations too. The one I dislike most is the pressure to rush features out the door. Since it's our product, I believe we should build it the "Apple way": don't be first, be better.

Another recurring battle is convincing Product Owners that maintenance matters. Too often, quantity is valued over quality — more shiny features every two weeks, even if older ones still need fixing.

My take: people don't need a new toy every sprint. They'll appreciate a polished one after we fix the cracks in the last batch.

One impactful outcome from this type of work was integrating the STid SDK for access control at GetGround. It showed the power of combining long-term platform thinking with immediate client needs.

Project-Oriented: Racing Against Time

Projects, by contrast, are usually a race against time. The scope is defined, the deadline is fixed, and the mission is clear: deliver on time with the best code possible.

The hardest part? Deadlines are often unrealistic. Projects frequently start late due to poor preparation, yet expectations remain sky-high.

The Adopt project is the best example. We started already behind schedule. A POC existed, but it wasn't reusable at all. I had to push myself to the limit while still handling urgent features and incidents on GetGround.

It was one of the toughest periods of my career. Yet it resulted in success: the client was happy, and the project is still live today.

Skills That Transfer

What surprised me is how much a product mindset helps in project work. When you think beyond the deadline — about maintainability, scalability, or DX — clients notice and appreciate the insights.

In turn, the urgency of projects sharpens your execution skills, which is useful when product teams need to pivot fast.

My Take

I don't prefer one over the other. Alternating keeps me fresh: projects expose me to many domains quickly, while products let me refine and deepen a solution over time.

Having worked closely with Product Owners, commercial directors, clients, developers, and designers, I've learned to adapt my communication and priorities to fit the mission. That adaptability is what allows me to deliver in both contexts.