last tended
Since I began my first full-time job as a UX design consultant I’ve been enthralled by product management and strategy. During my time in this role a majority of the work I’ve done has been for early stage or minimum viable products, and it’s typically resulted in an interesting environment for collaboration and strategy development. These experiences have sent me deep into an exploration of the relationship between product strategy and user experience strategy. Side-stepping the debate of what exactly makes UX strategy distinct (because there are so many overlaps), I’ve been exploring how to define and visualize how I see user experience research and design flow into product vision and strategy. In the process I dusted off my AfterEffects skills and created a very basic animation to visualize the framework I’ve been using.
TLDR; watch the 20 second animation
TLDW; research & cross-functional #collaboration
The skeleton for this was inspired by a tweet from @shreyas
I loved this framework because it presents several product concepts in a super approachable manner— especially for those who are typically less focused on the business objectives for the products they work on. I’ve noticed though, that the business perspective often focuses more on solutions and outcomes, and less on how exactly we get to the right solutions and outcomes. What I wanted to do was expand on this framework a bit to show what it takes to get there, and how it’s the effective collaboration between each of the roles involved in the product process that leads to successful outcomes. I’m biased towards user research and design, but those are just two of several threads stitching together this framework by focusing on understanding the perceived problem, the systems surrounding it, and the people it impacts.
SO, let’s dive in.
These things don’t always have to start with an identified problem or opportunity, but this is typically the most common situation. There’s a clear pain point, a gap in the market, or a way things could be done faster/easier/more fun that sparks an idea. At the surface level this is clearly seen or felt and it’s determined that it’s something that could be worthwhile to address.
Before moving any further and investing resources, we need to build a case. Why exactly should we do something about this? While this doesn’t necessarily have to be centered on the business case or how this could be profitable at some point, that’s almost always at least a factor here. You’ll also notice in the visualization, this is where some of the color-coding comes in. Anything in blue I identify as a product or business centric concept. For me this means I think of it more as a solution or as outcome-centric.
Now that the whole team has decided that this is something we should address, we need to kick off research and discovery to figure out what’s really going on. Research can be seen as both a specific role on the product team, and as a tool used by the other roles. Because of this, research can mean an incredible variety of different things to different people. From design thinking, interviewing, surveys, field studies, competitive analyses, market research, technical evaluations, and more, these methods can be applied in any combination to help us better understand all the pieces at play and system surrounding what was initially identified as the perceived problem. What is key to establishing this comprehensive and shared understanding, is cross-functional collaboration in said research activities. Every role (design, development, product, marketing, sales, etc.) should be actively participating in and learning about the research being conducted by others, to decipher how their findings interact and relate to one another. Thorough and collaborative research can help us to think beyond treating the symptoms, and focus on the proper diagnosis.
Once we’re able to breakdown what we believed to be the problem, we’re able to more clearly see the factors defining and driving what’s really going on. This closer look reveals that there can be several puzzle pieces, each driven by different areas, some factors related to product, some to experience, others to technology, and beyond. I think of this as the solution space because it allows us to break things up, spread them out, and begin to set boundaries for ourselves as we actually start to ideate on what we might do to address the problem. I think it’s important to call out why this isn’t being defined as the ‘problem space’. The approach to establishing this space assumes that the proper foundations have been laid and we thoroughly understand the problem, in turn insinuating that this is built upon the ‘problem space’. The second reason is that the purpose of this space and the identified boundaries are so that we can actually begin solutioning. The information in this space is the starting point meant to guide what we narrow down as solutions to test and develop. Important to note at this point— while we know more than when we started… we still don’t know everything. We should always be listening and pivoting in response to the information we learn.
Using our solution space boundaries as a starting point we can begin to define the what. The vision is how we might articulate the future of what we’ve identified as the system encompassing the problem or opportunity. This is the essence of what we hope to achieve or accomplish for the people, systems, and environments that will be impacted. Often in design thinking this is identified as the north star vision. Forgetting constraints, timelines, budgets, and all else, what is it we dream of achieving? What are our goals or target outcomes for this effort? The clear articulation of this is important because it will be a constant reference point for alignment between the wide variety of stakeholders contributing to achieving this vision.
Product strategy is a big one and I’m not going to be covering all of the bases here. Generally speaking, I see the product strategy as the point where concrete solutioning can come into play. As Shreyas Doshi again neatly summarizes,
Product Strategy—in 1 tweet.
What: Rigorous treatment of where to play & how to win
Why: Drastically improve odds of product success Create org-wide clarity”
There’s a fine balance. It’s taking what we understand from the solution space and determining not only how we might be able to address it, it but choosing which pieces make sense to address so we can ‘win’. Depending on what’s been identified as the solution space and vision, it may make sense to build a strategy that addresses all of it. It may also make sense that there are a few different strategies to address a few different clusters of pieces. There’s no right answer or approach, just prioritize identifying the right elements to address, noting less is usually more. The most important factor at this stage is an emphasis on collaboration as the product strategy is defined. As we draw the line around what ‘pieces’ are going to be covered by the strategy the process is led by all contributing roles, with a hat tip to continuous research as we progress. This collaboration is important in ensuring we’re taking all perspectives into account as some significant decisions begin to be made. Everyone should understand the what and why of what we hope to achieve in the next 3-5 years and why this how is the right way to do it.
OK, it feels like we’ve already done a ton of work but now it’s time to actually BUILD. How do we break this down into action items that we can execute on? This is where the roadmap comes in and we get into everyone’s favorite part of the product process; requirement gathering, process flows, agile, wireframes, JIRA, user stories, sprints, more buzz words, etc. But before that, and arguably the most important collaborative activity, is how we outline the roadmap and choose what to do when. If we did everything right leading up to this moment, this part should be relatively straight forward. If all teams are on the same page for what we have identified as the problem and what we have outlined as target outcomes, we should be able to work together to figure out the right compromises for what should and can be done in what order to optimize for time, quality, and value delivered.
I know I’ve skipped over segmentation and positioning and likely several other important steps. For now I just wanted to focus on the major elements I’ve seen the most of in my work as a user research and designer (selfish probably but I’ll go back to my marketing roots eventually and dive into those as well).
This exploration started out as an exercise because I kept seeing the importance of UX research get undercut when design work was sold or when I was working with clients. I think it’s becoming obvious to most how important user research and design are in understanding the problem developing the right solutions, but what I still think is under emphasized in practice is the importance of cross-functional collaboration. Making sure you have all team members involved at every stage could be transformational for a lot of teams and products. I know, to some the thought of having a developer participate in an ethnographic field study with a UX researcher or to have a product designer observe a back-end dev build part of a database could seem like a waste of already scarce hours. But, those few hours could go a long way during delivery if we all internalize that we’re working towards the same thing; a vision we defined together, and a strategy that we all believe can get us there.