In the first part of the Rise of Product Developers series, we explored how Product Developers focus on the domain and users’ problems to build a product. The true value developers bring lies in their critical assessment of what and how they’re building. This approach has always been essential, but it’s become more clear now than ever as AI’s capacity to generate code continues to advance. Because of this mindset, Product Developers refer to Product Backlog Items as hypotheses.

Questioning the Why

In a Product Backlog Refinement Workshop, a conversation unfolds between the Product Developers and a Product Manager:

Product Manager: “We need pagination.”
Product Developers: “What problem are we trying to solve?”
Product Manager: “The page loads too slowly, and I think we’re losing users because of that.”

Questioning the Why So

Product Developer 1: “I can look at how many people are leaving the page without doing anything.”
Product Developer 2: “Could we simplify the process by showing only recent events?”

If they decide to investigate the first idea, they’ll need observability within the product. Observability has increasingly become a high-priority feature, which is an overarching strategy that encompasses various aspects such as instrumentation (product feature that allows monitor and measuring behavior) and testability (making sure that the designs are friendly to effective testing). Enhanced observability equips Product Developers with the means to accurately evaluate both the value and functionality of the product. As the series continues, we will explore how they also depend on observability to retain knowledge.

Shared Requirements Discovery - Think Critically Together

The responsibility of requirements discovery is not exlusive to certain roles. Product Developers clearly play crucial roles in this process.

Product Manager: “That’s true, but a user has said they’ll pay a million dollars if we implement pagination.”
Product Developers: “Is it worth adding complexity for that? Could we determine if displaying only recent events would satisfy them?”

Questioning the Why Now

Product Developers: (to the Product Owner) “Why are we fine-tuning the UI now? We haven’t had many users yet.”
Product Owner: “This user is the key to attracting more users. We need to ensure they’re satisfied.”

Questioning the Functionality (What)

Product Manager: “Perhaps showing only recent events might work.”
Product Developers: “Can you give us an example?”
User: “Sure, for instance, show only the 5 most recent events if there are many.”
Product Developers: “Like this?”

Scenario: Show only recent events when there are too many past events
  Given there were 3 events 3 days ago
  And there were 3 events 2 days ago
  And there were 3 events 1 day ago
  Then I should see only 5 recent events within 2 days in the past event list

User: “Yes, that looks good.”

Using techniques like Specification by Example, Product Developers and users bridge the communication gap with less ambiguity. If also helps them to define the scope of the work critically.

Questioning the Solution (How)

Product Developer 1: “We should generalize this functionality because more listing requirements will likely emerge.”
Product Developer 2: “YAGNI, let’s keep it simple for now.”
Product Developer 3: “How do we know we are done?”
Product Developer 1: “We write the test first.”
Product Developer 2: “And we also test later to uncover unexpected side effects and bugs.” (try to prove what we did is wrong)

Think about mantainability critically

While the world marvels at AI’s ability to pass the Turing Test, Product Developers understand the challenges it poses for passing Regression Tests in product maintenance.

In traditional organizations, the worth of an initiative is justified through logical reasoning and often isn’t questioned. However, even logically sound ideas need to be treated as hypotheses, given the variables of feasibility, the impact on the existing product, and the actual outcome.

Conclusion

Product Developers not only play a role in implementation and maintenance but also shoulder the responsibility of critically evaluating and validating assumptions while preserving key knowledge. An integral part of their contribution is the continuous improvement of their process through their critical thinking skills. However, this trait of constantly refining processes isn’t unique to them alone, which is why it wasn’t highlighted in the examples.

By fostering informed decision-making within the organization, Product Developers play a pivotal role in ensuring the success of the products they develop. In practice, validation and knowledge preservation often go hand-in-hand. In the next installment of this series, we’ll delve deeper into another crucial aspect of Product Developers’ accountability: learning and preservation.

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.