The Rise Of The Product Developers - Part I, Beyond User Needs

Inspired by my colleague Bas Vodde’s recent conference talk, I’m embarking on a series about The Rise of the Product Developers. This first piece will focus on how Product Developers can adopt a strategic approach to user requirements.

Product Developers build products by understanding the domain and customer problems.

Product Developers are not simply coders who translate user wishes into code. They are an emerging profession that is fueled by user needs but goes beyond that by understanding the business domain deeply and having genuine empathy toward the user’s problems.

Genuinely understanding user’s problems

Product Developers take each Product Backlog Item as an invitation to them and the users to collaborate closely to understand their problems genuinely. While addressing the customer’s problem with a holistic view of the product, they expand their expertise in solution and business domains. As a result, they can often provide more effective solutions than users could imagine. “Why” and “why not” are common in their conversations. Their learning journey continues beyond delivering the product increment. Product Developers validate their learning by evaluating the impact of the product and how users are using it as early as possible. Then learn from it.

Seeing the domain

Product Developers must know that their goal is not limited to the individual user needs they’ve been assigned to work on but rather the creation of a product that effectively serves the business domain. While individual user requirements may seem volatile when viewed in isolation, taking a broader perspective and considering the problem the product solves within the business domain can reveal a more stable and reliable foundation. It helps to reduce the frustration of “changing requirements.”

Becoming domain experts

To effectively serve the business domain, Product Developers must expand their expertise beyond the solution domain and become domain experts. Without domain expertise, a developer requires someone else to translate between the customers and them and have someone else translate from the business domain to their solution domain.

Product Developers do not dismiss users’ input by assuming that “users don’t know what product they want.” Instead, they understand the importance of close collaboration with actual users to develop a product that aligns with the business domain and expands our knowledge as domain experts. Techniques like Specification by Examples can be invaluable tools in the development process, helping to surface the domain language.

Next, here are a few well-intended but easily misinterpreted statements on this topic I cannot afford not to quote (for fun and more profound truth):

• “Product Developers don’t listen to users but try to understand them” - My colleague Bas
• “User requirements are not important.” - My colleague Viktor
• “Despise the user needs strategically, but take them seriously tactically.” - Chinese proverb

(Please don’t quote them out of context, except for the Chinese proverb, which I made up).

To conclude, Product Developers take ownership of creating a successful product that maps to the business domain and addresses user problems effectively. A visionary Product Owner provides guidance, but the product Developers are the ones who make it happen sustainably.

As technology continues to evolve, the role of a developer is changing, and I’ll explore what that means for Product Developers in the next part.