What "done" actually means — and why it is always negotiated, never defined
The definition of done is the most-debated, least-agreed-on concept in Agile. Here is what I have learned from running it across real teams.
Product Owner · Product Manager IT Leader Wrocław, Poland
Product ownership.
Engineered in.
Where technical depth meets product delivery — for software projects that cannot afford ambiguity.
Photo coming soon
About
Where product thinking meets engineering reality
I started my career writing code for the police. Not the most obvious path to Product Ownership — but it turned out to be the best one.
Twenty-two years across law enforcement, regional government, and commercial software delivery taught me where projects actually go wrong: in the gap between what a stakeholder says they need and what an engineering team builds. I have spent my career living in that gap.
At Vazco, where I have worked for seven years as an embedded Product Owner and Project Manager, I own product roadmaps end-to-end — from discovery with clients to sprint ceremonies with dev teams. I can read a user story and review a database schema. That combination is rarer than it should be, and it kills ambiguity before it becomes rework. I use modern AI tooling to accelerate documentation, research, and requirements work — staying sharp across long engagements.
22+
years in IT
7
years embedded PO at Vazco
3
sectors: law enforcement · regional gov · private sector
PSM I · TOGAF 9
certifications
Services
What I do
Embedded Product Ownership
I join your development team as a full Product Owner — owning the backlog, running Scrum ceremonies, and representing your vision to engineers while keeping engineering reality visible to you. I work in your tools: Jira (including administration and configuration), Linear, Confluence, or whatever your team already uses. This is the model I have operated in for seven years. Full accountability. Ongoing engagement.
Product Discovery & Requirements Definition
Turning a business goal into a developer-ready specification. User stories, acceptance criteria, functional requirements — precise enough that your team can act without a second clarifying meeting. Particularly effective when the problem is not yet well-understood.
Backlog Structuring & Roadmap Design
For backlogs that have grown into a liability: reprioritization against strategic goals, technical debt identification, and a roadmap that stakeholders can commit to. I have run product roadmaps across environments where the stakeholder politics were more complex than most startups will ever face — EU grant programs, multi-agency law enforcement coordination.
Technical Business Analysis
For complex domains — regulated industries, legacy modernisation, multi-institution data exchange — where requirements analysis requires someone who understands both the business process and the data model behind it. I can talk to architects and auditors in the same meeting.
Agile Process Review
A focused assessment of how your team is working: ceremony quality, Product Owner–developer collaboration patterns, story quality, backlog hygiene. Clear findings, practical next steps. A good entry point if you are not sure what you need yet.
How I work
Every project is different. My process adapts accordingly.
Step 01
Discovery call
A 30-minute conversation about your situation. No pitch, no deck, no retainer proposal. I need to understand the problem before I can say whether I am the right person for it.
Book a time →
Step 02
Scoping
If there is a fit, I propose an engagement structure — remote by default, on-site in Wrocław if needed. The format depends on the project: hourly for focused consultations and audits, project-based for defined deliverables, retainer for ongoing embedded work. I adapt to your team's tools, rhythm, and reporting needs.
Step 03
Delivery
I do not bring a fixed process and force it onto your team. What I do bring: early starts (I am at my desk by 7:30–8:00), full daily availability, and a hard boundary at 8 hours. Work-life balance is not a buzzword — it is how I stay sharp across long engagements.
What colleagues say
In their own words
"Marcin stands out for exceptional productivity — delivering the most tasks in the team while maintaining a fast, efficient pace. He is characterized by above-standard commitment — when the situation demands it, he doesn't hesitate to put in extra time to meet deadlines and ensure key elements are in place."
Writing
Observations from the gap between business and engineering
I have been meaning to write about product ownership, software delivery, and what twenty-two years in IT actually teaches you — things that rarely show up in certifications or frameworks. Watch this space, or follow me on LinkedIn for the occasional piece in the meantime.
Why public sector IT experience matters in commercial software delivery
Twelve years in law enforcement and regional government taught me things about accountability and stakeholder complexity that no startup ever could.
Managing product backlogs with AI-assisted tooling — what actually works in 2025
I have been connecting Jira and Linear to AI agents for task management. Here is an honest assessment of what it changes and what it does not.
If your project has requirements that no one agrees on, stakeholders who pull in different directions, or a team that delivers output without progress — that's the conversation I'm built for.
Start with a 30-minute call. No pitch deck, no retainer proposal. Just a conversation about your specific situation.
Open to senior embedded Product Owner and Product Manager roles (full-time or long-term contract). Connect on LinkedIn →