The Product Engineering Manifesto: How To
Table of Contents For Product Engineering Culture
In my previous article, I shared with you The Product Engineering Manifesto, a desired way of working for engineering teams that maximizes our impact on the products we build.
This is my open call for a partnership between engineering and product teams. In an era when coding skills are no longer a differentiating value, true winners are those who focus on solving real customers' problems, and all the technicalities behind that are just tools.
This article serves as a roadmap for implementing the Product Engineering Manifesto in practice, drawing on the content I have published over the past two years.
The Manifesto Breakdown
Problems to solve, over requirements to fulfill
It’s easy to say - give me a problem so I can find a solution. But what is “problem”, actually? The book “Are Your Lights On” has an excellent and concise explanation: “A problem is a difference between things as desired and things as perceived.”.
Based on the book and my personal experiences, I created The Problem Solving Framework, 8 8-step process that helps you clearly define what the problem is, its root causes, who has this problem, ways of solving it, and how to monitor it.
The framework aims to find a good balance between jumping into instant solutions and spending weeks overthinking.
Discovery collaboration, over delivery execution
Delivery only makes sense if you build the right things. Otherwise, it doesn’t matter if you are “Elite” according to DORA metrics or have mastered development with GenAI. As long as you push the wrong things to production, your effort is wasted.
Discovery processes have many faces:
MVP, PoC or Prototype will walk you through determining what kind of discovery we are talking about. Whether it’s about PoC and validating technical feasibility, Prototypes address usability risks. And on top of them we have MVP the Minimum Viable Product - the smallest possible product that is valuable, usable and viable.
Changing the Way Product Is Built - The truth is that most of the requirements we get as engineers are hypotheses, not facts. The quicker we can deliver things to customers, the faster we will learn if they have actual value.
Changing the Way Problems Are Solved - on top of the above point, we cannot just follow what’s being presented to us as “requirements”. As leaders, we must establish sufficient credibility to foster a genuine partnership with product teams. Here you will learn how to do that.
Customer outcomes, over feature output
It doesn’t matter how many features we deliver to customers. In fact, often overloading a product with functionalities no one uses has the opposite effect. They only increase the complexity of the software and grow the maintenance efforts.
Instrumentation and Observability Culture provides insights for defining telemetry infrastructure to gain a comprehensive understanding of systems, applications, products, and business. Once we have complete data, we can truly move fast and validate our assumptions.
And this moves us to Changing the Way Decisions Are Made About Which Problems To Solve. It’s a reminder that we, engineers, are product leaders too. Our job is to observe our fields through instrumentation and then combine them with the company’s vision, product strategy, and other inputs we should actively seek.
Moreover, often only we understand the true value of technicalities, and only we can present it as product value. Working Backwards: Creating Effective PR/FAQ Documents is an excellent way of translating between technology and product.
Finally - tech strategy. Each of us has a backlog of tens, if not hundreds, of initiatives related to tech excellence. However, for many, the surprising part is that it’s up to us to prioritize this appropriately and find alignment with business needs. To help with that, I built the Engineering Strategy Framework, which is supposed to define a roadmap for months, if not years, ahead.
Reliability as a product feature, over tech debt as an afterthought
The Engineering Strategy Framework, mentioned smoothly moves us here, to the reality where tech debt, tech excellence, and quality are equal to product functionalities.
That’s right, reliability is a system feature. In Intro to SLA, SLO, and SLI, I provide more information about error budgets, SLAs, and what it means to be “reliable enough”.
In Non-Functional Requirements, I provide more information about setting quality standards, Core Web Vitals, The Twelve Factor App, Google SRE, and other resources that can help with this.
On top of these, Optimizing Your "20% Time for Technical Debt" is a food for thought about why it’s dangerous to address all things tech debt outside of the regular product development cycle.
Product creation, over code production
All of these: defining the why, discovering the right solutions, focusing on customer outcomes, and embedding reliability into the product development cycle shift our role from mere coders to true product creators.
In AI Will Take Coders’ Jobs, and Who Is at Risk of Losing Their Job in 2025? I share my thoughts on why we need to shift from coding to value generation to stay competitive in the market.
End Words
Engineering has evolved. Coding skills are no longer the differentiator — product thinking is.
This manifesto is a reminder that we are not just implementers of someone else’s roadmap. We are creators, partners, and stewards of user value.
We bring the technical insight that helps shape product strategy. We embed reliability, quality, and observability into the way we work — not as extras, but as core product features.
If this vision resonates with you, don’t wait for permission. Start showing up this way.
That’s how you earn a seat at the table — not just to code, but to co-create.
The Product Engineering Manifesto
Problems to solve, over requirements to fulfill
Discovery collaboration, over delivery execution
Customer outcomes, over feature output
Reliability as a product feature, over tech debt as an afterthought
Product creation, over code production
We demand partnership in product strategy, not just technical execution.
We understand the why before we build the what.
We measure success by user impact, not story points completed.
We treat technical health and reliability as core product value.
We are product creators—code is our medium.