Most people who work in product development agree that it is essential to understand key problems in order to build good solutions. This often involves understanding the customer or finding new products. It has also become common for engineers, who are responsible for building the product, to be involved from the start. This is explained in more detail in this blog post by SVPG. Product discovery only works when the people who build the product stay close to the problem. In empowered product teams, engineers co-lead discovery rather than just implement specs, which helps us reduce value, usability, feasibility, and viability risk.

A big problem that keeps happening with our products is that we slowly start to lose track of our customers’ problems and the specific steps they take. Our product managers often had a very good understanding of customer problems. This was because they did a lot of interviews, visited customers and conferences, and did research. The designers who were involved in the interviews had a good understanding of the users and their problems. However, it was already clear in the 1:1s that some background information was missing. I think this is because it’s not just about building a full-time understanding of problems and customers, but also about developing good designs that delight potential users. This is especially common among engineers. This is probably because they not only have to understand the problem and what the proposed solutions look like, but also how to best implement them technically, combine them with existing solutions, etc. Also, engineers, like product or design teams, often have the chance to explore topics that aren’t directly related to the product. For example, new frameworks, etc. Designers also have this opportunity, but to a lesser extent. For product managers, it would quickly become apparent if they did not address the main problems of their customers.

Another point is that in recent years, there has been a strong trend away from product and design teams making strict specifications that have to be implemented 100% (feature team) and toward engineers actively participating in finding solutions (product team). This trend is being made stronger by tools like Loveable and Supabase. These tools help product managers, designers, and engineers make prototypes that are ready to use. Because of this, the traditional roles are becoming less clear, and there is more talk about the product creator as a new role. Agile methods have led to a greater focus on discussions to create alignment and less on extensive documentation. This “context decay” is well known in software engineering research as architectural knowledge vaporization: critical rationale and constraints evaporate across handoffs unless we deliberately capture and share them.

Context still Matters

As I wrote in a previous blog post, context is still one of the most important factors in making sure that everyone is working on the same problem. Last time, we focused more on specific ways to communicate inside the company. This time, I would like to describe the extra ways we have thought about making sure everyone on the team understands the problem and the product well.

One of the main problems we had in the product team was that engineers often couldn’t say exactly what a solution was being built for and how it fit into the bigger picture. In the past, this led to software and database designs that had to be rebuilt later. We’ve created a format called “design validations” to deal with these issues. This happens every week with the whole team. The designer explains the new designs. Beforehand, the product manager explains how the new feature solves customer problems and what real-world processes it will model. The engineers responsible also explain how these points are mapped in architectures and where adjustments can be made. Everyone focuses on the details. For example, instead of discussing a written story, we talk about specific ideas and support them with facts and stories from interviews. For three months, this format has helped the team create a process for talking about new features early and efficiently with everyone involved.

However, engineers often mention one problem in one-on-ones: they don’t understand the processes that take place in the real world. They also don’t understand the customer’s view of problems and our solutions. This was especially clear with new team members who weren’t properly introduced. Before, we had tools to make sure new engineers talked with at least 15 customers in their first three months to learn more about them. Customer Success and Sales also held regular webinars to explain their daily work. This allowed new team members to meet other teams and learn about their perspectives. We also try to visit a customer’s site at least once a year. Unfortunately, this is difficult to do for all remote employees. After we put these things in place, though, we often got feedback that something was still missing: we needed to really understand what customers do and where they have problems. We have therefore introduced a new component. There are realistic simulation games for various fields where you are put in the perspective of a specific professional group. Microsoft Flight Simulator is famous for letting you fly planes realistically as a pilot. In some versions, you can even play as an air traffic controller. There are also bus, truck, and even surgeon simulations. We found some good simulation games on this list and organized “LAN parties” as a team. Some team members studied the simulation in advance. This led to very detailed questions in the one-on-ones, especially from the engineers. They wanted to know if our customers’ business cases were feasible and the specific steps they took in production.

Outlook

Right now, it’s too soon to say for sure how well this has helped the team understand the product and the problem. However, we are already thinking about other possible steps. So far, we have only introduced the simulation and run through specific work steps that are relevant to our product. In the future, we want to improve these simulations by using our application at the same time during team meetings to really understand the interfaces. It is also important to mention that simulations are a great empathy primer and can boost situated understanding, but they complement (not replace) real-world observation. We still schedule regular customer visits—going to the place where work happens—to see constraints and workflows first-hand.