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.
Thank you for your insightful comment Erik. You are absolutely right that the principles outlined in the manifesto are deeply rooted in established fields.
The intention with this manifesto is not to claim novelty, but rather to advocate for the consistent and full implementation of these proven human-centered design principles within our product engineering practice.
I believe that by explicitly stating these commitments, we can help bridge the common gap between theoretical understanding and practical application of software and more importantly - product engineering.
I love this so much. The only way to get value out of the product approach is to destroy the silo between the "product dept." and the "engineering dept."
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.
Thank you for your insightful comment Erik. You are absolutely right that the principles outlined in the manifesto are deeply rooted in established fields.
The intention with this manifesto is not to claim novelty, but rather to advocate for the consistent and full implementation of these proven human-centered design principles within our product engineering practice.
I believe that by explicitly stating these commitments, we can help bridge the common gap between theoretical understanding and practical application of software and more importantly - product engineering.
I love this so much. The only way to get value out of the product approach is to destroy the silo between the "product dept." and the "engineering dept."