How do you move from the problem space to the solution space in your team?

  • 17 October 2022
  • 6 replies
  • 61 views

Userlevel 7
Badge +13

Before jumping into building the what, how do you collaborate with your team on defining a solution to your customer’s problems? Would love to hear how you all approach this.


6 replies

Userlevel 3
Badge +2

Hi @scott.baldwin, 

We usually try to start with the Product Strategy phase. In this stage, we have three main steps that allow us to collaborate with the team and stakeholders. These steps are:

  • Research 
    • Understand the “Why”: We understand the idea, business, goals, desired outcomes, and users, among others.
    • Audience & Market: We research about the actual audience and market.
    • Hypothesis: As an outcome, we create several hypotheses to test in the second stage.
  • Research validation:
    • Audience, Market, and Willingness to Pay: We test our assumptions.
    • Vision Co-creation: With all the information gathered we co-create as a team with the stakeholder and create the vision of the product, feature, or idea.
  • Product Validation: We test product UX/UI and identify the ideal product to implement.

We have all these phases, stages, and steps, and we usually do it with the three principal roles (Product, Design, Tech) and the stakeholder.

This process has been a great help in the alignment of the team across all the strategy definitions.

Userlevel 3
Badge +2

I’ve done this a few ways, but most recently I’ve found success with this method:

 

Define the problem: gather existing insights around a feature and user needs.

User Discovery: learn how users solve the problem currently (if possible) and learn about pain points. Technical teams are invited to attend user research sessions.

Tech discovery: bring technical teams into to the problem space (sometimes this is a workshop) with design and product, give them space to ask questions and clarify their understanding of the problem. Then we talk about the specific pain points are that need solving, and ideate ways our product could be altered to solve those problems. This may look like bringing wireframes to a workshop and having teams rip them apart and put them back together. It may look like solutionising from scratch.

Stakeholder discovery: present the problem and possible solutions forward, get input and feedback on the practicality of the solution (specifically from user facing stakeholders such as customer success)

User story mapping: with technical delivery teams, define a user story map to plan out what work needs to be done to alleviate user pain points. This is effectively the ‘building of the backlog’.

Early validation: test prototypes with users (based off of what has been agreed in user story mapping) to test whether we are on the right track. Small tweaks may be made here in designs or functionality, but not usually anything major. Technical teams are invited to attend user testing sessions.

 

Build, release, communicate to stakeholders and customers!

Userlevel 7
Badge +13

Love it @Parveen Downer that’s a great framework. Sounds like you and @Michel Hauzeur have some good overlap in terms of having intentional time to explore the problem and I really like how you bring others into the process and involve your technical teams in discovery — so many folks don’t do that.

Userlevel 3
Badge +2

Thanks @scott.baldwin! It’s definitely a fine balance of involving more stakeholders early in the process and stopping it from being ‘product planning by jury’. I find involving technical teams earlier in the discovery process makes it easier to communicate the ‘what’ when we get to user story mapping and they have a better sense of ‘how’ to approach the build (including future iterations of the product). We may not be scaling now, but we want to set ourselves up to do so later without having to refactor too much.

Userlevel 3
Badge +2

Thanks @scott.baldwin!! Well its being a journey full of learnings, but at the end how @Parveen Downer comment, everything is about have earlier conversations with those who have the vision, are impacted or want to be part of it. 

Userlevel 6
Badge +12

Personally, we tend to tackle is very similarly to @Michel Hauzeur and @Parveen Downer. But just to re-iterate a little bit from my perspective: 

  • Understanding the Problem 
    • ​​​​​​​Sometimes this means looking at an existing list of known problems or hypothesizing specific problems that the user isn’t fully aware that they’re having. 
    • Items in the “hypothesis” phase tends to go into a deeper evaluation process than problems/ideas defined by users already. This means we discuss in a small team, look at metrics, and identify whether or not there’s supporting evidence to further the process for that item. 
  • Identifying the Solution 
    • ​​​​​​​Once items get out of the hypothesis phase or we have a well-defined “problem” to solve, we have to start coming up with solid ideas as to how to solve the pain point/problem. 
    • This usually consists of a few “flash meetings” that involves discussing potential solutions for one or two of the existing problems we’re focusing on. 
    • Ideating and conceptualizing the solution usually becomes a barrier in smaller teams because it ends up being (as @Parveen Downer said) “product planning by jury” - even before the validation starts. 
    • Running it by the engineering/development team at this point is generally a sound approach (which is why we do it). Outlining the user journey through the solution and creating user stories empowers developers to tell us if we (PM) are absolutely mad/insane. 
  • Validation 
    • ​​​​​​​Preliminary wireframes, mockups, and general prototypes are usually good enough to share with customers during feedback/focus groups.
    • I usually end up working with the UI/UX Designer to create mockups and prototypes in Figma, then export to Zeplin to create flows (which shows each use case/action of the solution in a flowchart design). 
    • We give internal stakeholders a week to make comments and begin the feedback cycle until we’re satisfied enough to share with the customers. 

 

The rest, as they say, is history. We all know the implementation side of things. Discovery is always a rather remarkable process that will always have a few quirks unique to each team; while still having a significant amount of overlapping principles/purposes. 

Reply