User research & Engineering: better together during discovery
Julia Tan and Carolina Aldas of Spotify provide some recommendations on how user research and Engineering can improve their collaboration during the Discovery Phase to come up with more feasible product solutions.
When we think about the “Discovery” phase in the product development process, we often picture product owners, design, and researchers working to understand a problem area, the needs of end users in that area, and testing product ideas that might deliver on those needs. When no product exists yet, it can be difficult to justify Engineering’s time.
As such, the Discovery phase tends to be heavily driven by product owners, designers, and insights practitioners by default, and Engineering takes a more active role when product requirements and specifications become more defined. The process looks more like a relay race than synchronized swimming. In the process of passing the baton, important context gets lost and some agility is compromised.
We’ve all been there. We devote time and energy to truly understand people, their needs and motivations. We identify and user-test solutions that have a high promise to deliver user and business value, only to find out it’s not entirely feasible to implement said solutions. We feel deflated when the scope of the product solution is altered to a point that is significantly different from the original concept imagined – with potentially less value. In some cases, we have to go back to the drawing board after spending considerable time and effort on a solution we were all bought into. How did we not see this coming? We did our best to keep everyone informed… right?
The sequential nature of this collaboration can sometimes lead to such a scenario. As big tech continues to push the boundaries of agility and cross-functional collaboration, it is important to consider staggering research and Engineering work by involving your technical counterparts in the Discovery stage more intentionally, and considering tech constraints as an asset to agile product development rather than an exploratory limitation. Below we delve into some recommendations and examples of how we collaborated with Engineering in ways that were both efficient and impactful.