The product-development literature tends to treat “product management” as a single, stable role. In my experience it is not. The person who takes an idea to its first paying customer, the person who takes a product to Product-Market Fit, and the person who runs a mature portfolio are doing three different jobs, and organizations that conflate them pay for it in a very specific way: they get process without direction, or direction without delivery.
This service is about giving the product side of the business an owner who has done all three jobs, and who treats the product as a business asset rather than as a feature list.
When it makes sense
- The portfolio has no gravity. Multiple initiatives are running, none of them has a crisp business case, and every quarter the portfolio is re-argued from scratch. Someone needs to own the whole of “which things deserve resources, and in what order” — and defend that call.
- Discovery is broken. The product keeps shipping what the team or the loudest stakeholder wants, instead of what the market will actually pay for. The problem is rarely effort; it is that nobody owns the evidence.
- The product is pre- or post-Product-Market-Fit, and the organization has not adjusted. As I have written, product management is not the same job on the two sides of PMF. Applying the playbook from the wrong side of the line is how good teams burn a year.
- Pricing, packaging, and the commercial side of the product are an afterthought. The product is technically fine and commercially invisible, because nobody connected the two. I have run pricing-model and commercial work on Breek.gr for exactly this reason.
What I bring to the table
Product management was my core function for a decade: as head of product management at ProcEQ, as the global process owner for R&D portfolio management at Hilti, and as the product owner behind Breek.gr, where the role extended all the way to running the product’s development organization and its commercial evolution. On the development side of the table, I have shipped open-source software and run full-stack projects myself, so the product side of the conversation never floats free of what the engineering side actually has to build.
In practice, an engagement covers some or all of the following, shaped to the situation:
- Portfolio discipline. Crisp business cases, explicit stage gates, and a documented basis for every “no” — so that the annual re-argument stops being a political event.
- Discovery that produces decisions. Structured customer and market work whose output is a decision with an owner and a date, not a research report that gathers opinions.
- Prioritization that survives contact with reality. Sequencing that trades off effort, risk, and learning explicitly, with the trade-offs written down where everyone can read them.
- Delivery governance. Cadence, metrics, and a rhythm of review that keeps the delivery organization honest without turning every sprint review into a performance review.
- The commercial side of the product. Pricing, packaging, and positioning — the parts of “product” that engineering organizations most consistently under-invest in, and that most often explain why a technically sound product does not pull its weight.
What an engagement looks like
These engagements are typically embedded rather than advisory: I work inside the organization, with the team, for a bounded period — commonly one to three months for a focused problem (portfolio cleanup, PMF assessment, pricing), or longer when the organization needs the role itself covered while a permanent hire is found.
Every engagement starts with a written scope: the decision or outcome the engagement exists to produce, the evidence that will be used to make it, and what success looks like when I leave. It ends with the product organization able to run without me — which is the actual deliverable, and the reason I keep the scope written down in the first place.
Start with a conversation if the product side of the business has been running on momentum and you want it running on judgment.
