Why developers don’t participate in product discovery
So much has been written about delivery and so little about discovery.
Discovery is the fundamental part of the product development process and it consists of many steps. One of my observations as a product manager is the lack of developer presence in many of the discovery phases. In this article I would like to focus on the user interviews.
Do developers in your team regularly show up to user interviews? In my experience there are cases I could count on my fingers.
It always seemed to me that talking to the users, observing their behaviour and hearing about their wishes and complains is what everyone in the product development has to be curious about. Not only it is fun, but it also plays a vital role in the success of any business. It turns out that developers show little interest in being part of user interviews.
For a long time I have been trying to encourage my team mates to join any type of user tests. But all my attempts failed. I decided to understand why.
I scheduled short calls with each in my development team and asked a set of questions that would help me find out their point of view better.
I found out that 4 out 5 of developer in my team haven’t been a part of a user interview in the last year.
More than that, I revealed two main reasons they think prevent them from joining.
1. “It takes too much time from me, I don’t want to waste it”
Common opinion is that if they spend their hours on research, things won’t get done and the product development will slow down. Especially, when one has to be involved in a discovery project for about a week, it feels too long to miss out from the development work. And even one hour of an involvement as a listener seems to be disturbing.
One of the team members said that he would feel interrupted and going back to where he left off would take some time from him.
Some developers mentioned that they are avoiding meetings and that would be another type of a meeting that they would need to attend.
What we are failing to communicate is that time invested in talking to people is not a waste. It helps identify most pressing problems, validate or invalidate defined assumptions and in the end of the day get to know the users better. Everyone in the team can benefit from that.
How can you say that you delivered, if you actually didn’t? When discovery hasn’t been taken seriously, the solution can turn out to be nothing that users need. User interviews are the last and very important part in the discovery process, involvement of all the relevant stakeholders is a factor to success. Having at least one representative from the tech team helps checking users feedback on technical feasibility on spot. That saves time and eliminates redundant follow up assumptions.
2. “It is not part of my job”
There is a notion that everyone has to do their job. And discovery is the job of researches, designers and product managers. It is not the core of a developer job, so why to be present in the area that belongs to other colleagues specialising in it?
One of the interviewees mentioned that one hour spent on a user interview can be used more efficiently.
Considering that developers belong to the solution space, focusing on the validation of the user problem is inessential to a developer role and that one hour can be invested more beneficially.
Another reason that interviewees find making the participation in the user interviews unnecessary is product managers providing them with the summary.
Being a product manager myself, I can confirm that sharing a summary of the interviews is important. That is a way for me to make sure that everyone is at the same page, especially because the developers were part of the discovery process from the very beginning.
Marty Cagan states that product management falls in the intersect of 3 fields — business, UX and tech. And a representative of each of these spheres is important in the discovery process. Tech is not being limited to coding the solution only. That would be a primitive way of looking at it. Developers get to participate in the workshops, ideations and very importantly in the user tests to make a valuable input in the development. In the end of the day, they know the product the best.
How to explain to developers importance of their presence?
Discovery process is being underestimated. We spend so much time on delivery which can be clearly seen by the number of methods and approaches that have been developed (kanban, scrum and etc), but there is very little attention that is being paid to the discovery.
Huge mistake.
It is the discovery that helps to get to the real user problem. We go into discovery phase with many assumptions and hypothesis and in the process we find out THE problem that users are facing in reality.
In the end of the day, ideas need to succeed in 3 areas:
- Usability
- Feasibility
- Viability
A check on feasibility requires a tech person being in the discovery crew. That helps resolving popping up questions on the go and moving faster. And it doesn’t mean that the whole team has to be there. Having one person is already a great help.
If things don’t change, you should change your actions
In order to make developers more involved in the discovery, especially user interviews, ThoughtWorks recommends the following.
- Involve the developers from the very beginning, so that they have a sense of belonging to the idea and develop a level of interest in proving or failing to prove the commonly defined hypothesis.
- Start by inviting them to the casual user chats that you can organise in the office. This is a more relaxed environment that can be a nice beginning and help break the barriers that engineers might have.
- Send a separate invite to the people that you wish to see during the interview. Do it in a form of a private message and not a sudden invite on the calendar.
In my team the #1 is being taken care of already, but it seems that a separate invite instead of a blocker was agreed to be a better way of involving them, everyone interviewed said they would make them feel more responsible and would encourage them to join.
Of course, it is not mandatory for the developers be an active part of the discovery, but creating a user-centered culture will benefit everyone involved in the product development.
