The Product Engineering Manifesto
A Call for Partnership Between Engineering and Product
The 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.
(Looking for the way to implement the manifesto in your work? Check this out here.)
What We Want
Own Problems, Not Just Implement Solutions
Requirements are hypotheses, not facts.
We seek clarity on why before determining what.
We demand:
Access to customer research and user feedback
Partnership in defining what "done" actually means
Clear problem definitions, not predetermined solutions
Collaborate in Discovery, Not Just Participate in Delivery
Discovery is where customer problems meet technical possibilities.
We demand:
Active participation in product discovery
Partnership in rapid prototyping and validation
Autonomy to propose innovative technical approaches
Understand Success, Not Just Deliver Features
We refuse to build without understanding the value we create.
We demand:
Transparency on business metrics and KPIs
Visibility into the impact of our technical decisions
Partnership in defining meaningful success measurements
Reliability and Quality Are Core Features
Quality, reliability, and tech debt directly impact user experience and business outcomes.
We demand:
Prioritization of technical health alongside features
Quality requirements integrated as acceptance criteria
Reliability and performance goals as core product metrics
What We Bring
Product Sense, Not Just Technical Skills
We understand users, business models, and market dynamics.
We've grown product sense through years of seeing what works and what doesn't.
We're not just coders—we're problem solvers who happen to use code as our medium.
Customer Empathy, Not Just Code Quality
We care about the humans using our software.
We understand their frustrations, their workflows, and their goals.
We want to build solutions that genuinely improve their lives, not just satisfy specs.
Innovation, Not Just Implementation
We see technical possibilities that others miss.
We know what's emerging in the technology landscape.
We can suggest solutions that leverage new capabilities and avoid old limitations.
Pragmatism, Not Just Perfectionism
We understand trade-offs.
We know when to choose speed over elegance, when to build versus buy,
and how to balance technical debt with business velocity.
We bring practical wisdom to product decisions.
Systems Thinking, Not Just Feature Focus
We understand how technical decisions impact long-term product success.
We see the connections between code quality and user experience,
between system reliability and customer trust,
between technical debt and innovation velocity.
We think in systems, not just features.
What We Promise
Problem Ownership, Not Just Feature Accountability
When we own problems, we take responsibility for outcomes.
We'll stay engaged beyond the initial implementation.
We'll monitor, measure, and iterate until we achieve the desired results.
Transparency, Not Just Status Updates
We'll share our technical insights, our concerns, and our ideas openly.
We'll explain trade-offs in business terms.
We'll surface risks early and suggest alternatives proactively.
Partnership, Not Just Service
We'll challenge your assumptions respectfully and offer our perspectives honestly.
We'll collaborate on solutions rather than just implement your decisions.
We'll be thought partners, not just execution partners.
Growth, Not Just Delivery
We'll continuously develop our product sense,
customer empathy, and business understanding.
We'll become better product creators, not just better programmers.
The New Operating Model
Instead of: "Here's what we need built"
We want: "Here's the problem we need solved"
Instead of: "Can you estimate this?"
We want: "How should we approach this?"
Instead of: "When will it be done?"
We want: "How will we know it's working?"
Instead of: "Engineering will implement"
We want: "Engineering will partner"
Instead of: "Deliver the feature"
We want: "Solve the problem"
Instead of: "Fix tech debt in your spare time"
We want: "Reliability is a product requirement"
Instead of: "Technical metrics are engineering concerns"
We want: "Quality metrics drive business outcomes"
The Future We Build Together
We are part of product teams that integrate discovery with delivery, align technical innovation with strategic vision, and harmonize technical excellence, customer empathy, and business outcomes.
This is our collective voice.
We demand partnership, ownership, and respect as product creators.
The moment engineers are invited into the why, everything changes. When we treat discovery as a shared space rather than a handoff phase, what we build becomes more resilient and far more aligned to real user needs. One layer I’d add is that this shift doesn’t just make the product better, it also makes engineers stay longer. Psychological ownership feeds motivation in a way Jira never will.
This is the result of working in the wrong company within the wrong team or the wrong people.
Most of the content reinvent ideas that already exist in the field of software and established by disciplines like HCI (Human-Computer Interaction), UX design, and ISO standards like ISO 9241-210 on Human-Centred Design (HCD) in which, developers are indeed involved in the process, together with people from other teams.
Eg UX conduct user interviews, thematic analysis, coding it, present it to people of different teams involved in listening, watching some interview as reference, some behavioral analytic recording too and then discussion with people brainstorming.
“We understand the why before we build the what" it's not devs, it's the application of human-centered design that understand users, tasks, and environments before defining solutions. It was created in 1999 in order to create software and user interfaces due to the complex nature of the human being.
“Customer outcomes over feature output”, the same: HCD principle states to design for experience and real-world impact, not features.
“Systems thinking, not just feature focus” but core UX mindset, is systems-level thinking in order to have good interaction and service design. Not only, it was called User System Centred Design within HCI for a reason.
“Discovery collaboration over delivery execution” but participatory design and continuous user involvement is a pillar of HCI and ISO 9241-210.
Here the problem not only is the company and team in which one unfortunately end, clearly a feature list team, but if someone feels the need to empathize because all of this sounds like a dream or first ever heard, then there's a need of personal updating.
If everybody involved in building would just follow the instructions we have since over 40 years about how to do it, we all would be happier and with a better understanding of the surrounding.