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.
1. Investigating the problem space (rather than just the solution space) together
Typical of early-stage innovation work, the focus is less on what product solutions we want to build and more on what problems or use cases we want to address for people.
These discussions start with significant unknowns: What problem or use case are we trying to solve? Who is the target audience? Why is this problem or use case important to pursue?
Not involving more of the Engineering team during these discussions makes it difficult for them to feel connected to the work, to understand how we decided on specific ideas to explore, or why our target users would react a certain way to them. This can lead to slow starts, a lack of empathy for who we’re building for, and a bias towards more feasible ideas that don’t address actual needs or problems.
A. Encourage early feasibility discussions to facilitate Discovery direction
When Engineering is intentionally involved in the early investigation of a problem space, they learn alongside us and gain a foundational understanding of the underlying causes or motivations that might’ve led to the use cases and needs that are not adequately met.
What this looks like, in practice, is not just having Engineering present during research sessions but sharing knowledge that enables them to provide early input on possible product directions that address user needs and also has a feasible path to realization. As we start identifying the benefits that potential solutions should provide to users, Engineering can start a parallel process of their own discovery work by jump-starting tech explorations that emphasize technical capabilities and limitations as direction.
This collaboration might even help uncover insights you wouldn’t have otherwise. For example, in a recent product discovery workstream, early versions of a concept included a live video feature. Video was hypothesized to be a must-have feature to address artists and fans’ need to feel more connected with each other. Engineering, however, pointed out the massive technical undertaking that live video streaming requires and because of their familiarity with the problem space, pushed us to determine just how critical this feature would be to address the user need by testing an audio-only experience as an alternative. To everyone’s surprise, users that were presented with the concept had a very positive response, and some even expressed a strong preference for an audio-only experience over video. In this case, Engineering input spurred us to re-investigate the role of live video in addressing the use case. Had that not occurred, there was no telling how long we would have gone down the video path before having to turn around.
B. Encourage wider Engineering involvement in brainstorming and assessing ideas
Sometimes Engineering can feel disconnected from the product they’re developing if they don’t have a part in conceptualizing it – they don’t necessarily understand its value. By brainstorming ideas alongside other functions, Engineering not only takes part in the creative process, they are also more familiar with affordances from different tech stacks, which can unlock new possibilities to ideate on and resources to leverage for innovation.
For example: After holding brainstorming workshops for a new product solution in one of our teams, we narrowed down to a handful of ideas to consider further. We held another workshop where we broke out into several groups, and each group was assigned a few of the concept ideas. For each concept, the objective for each group was to gather informal answers to a series of questions:
- What technical capabilities would this concept require?
- What is the “t-shirt” size level of difficulty to implement each of the capabilities?
- What dependencies or gaps might we have? E.g., are there other teams that would have to account for this in their roadmap plans? What technical skills or expertise does the team lack and need to fill?
- Are there any known constraints and limitations? E.g., this capability might not work on smart TVs.
Going through the informal exercise above gave the team an initial sense of what might be needed to implement the concept. In some cases, they also built early prototypes of the concepts just to learn more about their feasibility and explore different possibilities for implementation, which they weren’t aware of until performing the exercise above.
2. Building to learn
In early stage Discovery when ideas are nascent, there is sometimes hesitancy to have Engineering start building when ideas haven’t been validated and pivots might occur. However, there are many opportunities for Engineering to build for the purposes of learning or answering questions we wouldn’t otherwise have. Rather than building solutions, we can build concepts to provoke and extract more knowledge about the problem space.
With this mindset, a strong Engineering and research partnership in the beginning makes a lot more sense than previously thought – especially during Discovery when you are not aiming for perfection, you are perfecting as you go.
A. Consider “Engineering prototypes” to obtain specialized user feedback
What is meant by “engineering prototypes?” Sometimes static or click-through design prototypes (think Figma or Sketch) are sufficient for the user feedback we want to obtain. Other times, we may want to capture feedback about interactions that require real-time context or assess how well personalization features or recommendations are performing. These scenarios cannot be easily “faked” in design concepts because they require some amount of code development and are therefore great use cases to partner with engineering. We refer to these as engineering prototypes.
As an example, one of our teams needed to understand what an acceptable level of latency would be for users when using wireless devices for sound input and output. Rather than build this test or functionality into the app itself, user research worked with Engineering to build a simple website as a prototype that allowed people to test different levels of latency and provide feedback.
B. Identify your MVE (Minimum Viable Experiment)
In contrast to an MVP (Minimum Viable Product), we refer to an MVE (Minimum Viable Experiment) as an experiment that allows you to test the central premise of your business idea in the fastest and shortest way possible within a real test environment. Unlike concept testing, an MVE allows Engineering to test out feasibility hypotheses and user research to learn about the different possible ways to address the problem space by running “live” experiments with real users.
For example: Recently, an Engineering partner for a Discovery project put together an Engineering Discovery Spec, which outlines the technical requirements for an experiment, not a product or feature. The difference between a Discovery spec and a regular Engineering spec is its focus on unlocking a new capability as opposed to scoping out new features to build. A capability, the Engineering partner mentioned, can be thought of as “the interface for a requirement, and the features are the implementation.” In our case, based on Discovery stage research, we had identified interactivity to be the capability that if unlocked, can deliver on users’ needs. Participants mentioned many different interactive features that would address their needs. However, our goal was to identify the fastest, most valuable, and feasible way to unlock interactivity. The Discovery Spec explored the different affordances and limitations of our current tech and proposed a solution that wasn’t perfect or ideal, but would allow us to launch an MVE that would help us learn and iterate towards the most ideal product.
C. Shorter Sprints
When operating in a vast unknown space, it is tempting to spend a generous amount of time understanding every corner of said space before picking a direction to explore, jeopardizing our ability to adopt an agile and iterative development process. The key to iterative development is making incremental progress based on learnings as quickly as possible. Shorter sprints can unlock our ability to explore with more intention and test out potential directions while simultaneously building our understanding of the space.
In recent Discovery work, one of our teams adopted weekly sprints to ensure we were learning something new, enabling decisions, and narrowing down our focus on a weekly basis. As mentioned before, during the Discovery stage, you are not striving for perfection; you are optimizing for learning. Thus, investing efficiently but minimally in things that will unlock cumulative learning is essential. There is no need for flashy deliverables, high-fidelity prototypes, or detailed product specs.
The weekly sprint cadence encouraged us to set practical and attainable learning goals and helped us avoid investing too much time improving on concepts or iterations, ultimately speeding up the process to identify a value proposition worth investing more time in. Shorter sprints also reduce the daunting nature of Discovery work by allowing you to break big milestones into small bite-size pieces that are easier to chew on.
3. Consider how User Research can support early stage Engineering work
So far, we focused a lot on how Engineering can get more involved with early Discovery work, but how can we as research practitioners get more involved with early Engineering work?
A. Providing input on product requirements and technical specs
As research and UX practitioners are often advocates for the end user, it seems obvious that we should be reviewing product requirements (e.g. user stories) and technical specifications to flag any potential issues or inadvertent risks to the user. However, we often find ourselves not prioritizing this due to limited time. Making time for this is one of the most effective ways to impact what gets built.
When user stories are being written and product requirements are defined, our input on whether they capture the user POV accurately is paramount. This is because when research is complete and findings are presented, everyone takes away something different from the results and they are subject to different interpretations. Aside from ensuring alignment and accurate interpretation of research, making time for this task can give you a good sense of what your partners took away about users and what actions they’re taking. This knowledge can in turn shape or improve how you want to communicate future findings for maximum impact. Reading technical specs also helps to speak their language, building empathy for your partners.
B. Go back to basics with heuristic evaluations
When we need to assess usability in the earliest design of a user experience (think version 0.5) but don’t yet have enough of an experience to conduct usability testing with users, a heuristic evaluation can suffice. These lightweight assessments can identify immediate usability violations as well as further areas of investigations for the next version without the time and cost of setting up user research sessions. Engineering can then incorporate changes into an early working version and the assessment can guide decisions for creating core flows in version 1.0.
Conclusion
In summary, our collective experiences partnering with Engineering more intentionally during several exploratory projects have helped evolve our own mindset regarding innovation.
In addition to restructuring work to be more concurrent, we found that incorporating technical considerations early helped accelerate the Discovery process. Whereas before we had been resistant about placing tech limitations on blue sky thinking, we started to use them more as loose parameters to spur creativity. Where we used to lead with user value as the primary signal for assessing early stage possibilities, we included technical feasibility as an important companion signal that helped us further narrow in on an initial direction.
These practices with Engineering not only helped us be more agile, but improved one of the most important outcomes of Discovery, which is to discover a solution that is valuable for users and feasible for the organization.
Spotify is an EPIC2022 Sponsor. Sponsor support enables our unique annual conference program that is curated by independent committees and invites diverse, critical perspectives.
References
Rosala, Maria. 2015. The Discovery Phase in UX Projects
Nielsen, Jakob. 1994. How to Conduct a Heuristic Evaluation
Rehkopf, Max. User Stories
0 Comments