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.

A fractal is a structure in which, when you look closer, you will discover self-similarity at different scales. (wikipedia).

Zoom In and Out Scrum

Fix The Empirical Process Control

In Picture A, you can find a typical representation of a Sprint in Scrum, which is, perhaps, a misunderstanding of both iterative development and empirical process. After a sprint, the organization should have an updated direction, embodied by an updated product backlog, as shown in Picture B.

Rotate and Zoom In 1

Let’s rotate Picture B inward and zoom in to reveal some details in a successful Scrum team. Within a Sprint, you can find multiple iterations, and each adds a done increment to the product, gets full-cycle feedback, and delivers customer value. The team will limit the Work-In-Progress by finishing one item before moving on to the next one, as shown in picture C. Scrum is iterative doesn’t mean a Sprint is one iteration.

Zoom In 2

If you zoom in again, you can find a successful Scrum team’s way of working repeats the above pattern. For the one item they are focusing on, they break it down into many small iterations, and each of them is a steady stepping stone towards their goal and seeks to have full-cycle feedback. As shown in picture D, a team will use practices like ATDD, TDD, trunk-based development, continuous delivery, etc.

Zoom In 3

Let’s look even closer. A successful team with many members does not work in a single thread (some do, using mob programming). They may split an item into smaller tasks and work in parallel. But as we saw before, all these tasks belong to the same item, and everyone is continuously coordinating and integrating. It will look like picture E. It might look intimidating for many, but not for a team practice collective code ownership, continuous integration, communication through code, and self-managing coordination, in addition to their individual practices like TDD. Unfortunately, decision-makers usually do not have visibility at this level, and Scrum Teams typically are not equipped with the technical practices that enable them to experience this.

Zoom Out

Now, let’s zoom out. How do you scale Scrum? A LeSS Sprint should look like picture F. The entire development organization focuses on the same direction. Teams may focus on different user-centric items, but these items belong to a limited number of larger topics. They integrate and coordinate by themselves all the time. At the end of the Sprint, the organization has an updated direction, reflected in their single, updated Product Backlog.

The Wrong Fractals

All models are wrong, but some are useful. Like many people in the LeSS community, I’ve had this mental model for many years, which helped me organize my thoughts on software development at different scales. I kept it to myself because I thought the problems and constraints differed at each level, and my mental model could be an oversimplification. On the one hand, now I feel there’s enough similarity to call it a fractal structure. On the other hand, I see the danger of it. I found there are a couple of things worth noticing.

• The Sprint itself is not part of the fractal. A Sprint has unique qualities. For example, it has an arbitrary timebox, which is the cadence of the organization.
• A misunderstanding of Scrum is that the work should be pre-planned to remove dependencies, typically by the management. The integration and coordination are also led by management, usually when the individual tasks are done. As shown in the picture, this model is too wrong to be useful.