Double hatting a Product Design + Management role these past few weeks have pushed me to look at product design in a different perspective. Previously, I admit I haven’t been trying hard enough to understand why “we’re doing what we’re doing”, and my product thoughts were something I treated as merely suggestions I can offer to the team. I used to think that whatever feature has been decided on, I’d only need to focus on finding the design solution to solve it. But these days, prioritising which problems to solve and deciding on what to build for the next two weeks drove me to a quest to dig, dig, and dig some more.

Working on a product that has a huge user base affords me the access to a great number of feedback, which is great on paper but not always so ‘great’ when you have limited resources. I think, it was only now that I truly understand what it means to understand who exactly your users are, in what context are they experiencing these problems, and why these problems are happening in the first place.

The past couple of weeks, I’ve been going through a few things over and over:

1. Finding Problems and Understanding Them – which problems happen most frequently, and affects the biggest percentage of our customers? The loudest of your customers aren’t always representative of the majority, so I have to take qualitative feedback with a grain of salt. At this point, I need to support qualitative data with some user research: who is writing in (or giving this feedback) and why? What kind of quantitative data do we have (which are maybe raw for now, so what kind of questions should I be asking so I could find relevant data)? Are they problems for the target market that we’re focusing on? If not, I don’t immediately set it aside. I still have to ask the next question.
   
2. Understanding the Problem in the Perspective of Different Users – even if feedback came from a small but loud minority, does it actually also affect the majority of our customers? If yes, sounds like solving it will have a big impact for our product! For each feedback we receive, I seek out to know more — who is experiencing this problem, why does this customer care about it, what specific pain point are they experiencing?
   
3. What are the Possible ways to Solve this Problem? – the fun part about brainstorming: you don’t have to worry about resources or time (just yet!). Coming up with ways to solve some problems also involves people from other teams, and this requires an active effort to reach out because I realised that not everyone is used to just approaching you to share ideas!
   
4. Narrowing Down Solutions – this part may be tricky. I quickly learned that despite having done as much research as I could, solutions will still need to be tested and validated (and some experiments I couldn’t always do on my own). I read that some teams have a “Discovery track” in their Scrum process precisely to validate and test problems and solutions.
   
5. Measuring Success – I’ve come across some problems that are hard to measure by just quantitative data (either by clicks/taps, sessions, etc) just because it’s more on the intangible side of things, and for those maybe I could only get assessment through qualitative feedback. But for everything else, finding which metric will show if the needle would move is my next challenge. How will I know this solution worked, and if not how would I know why it failed?
   
6. Deciding on What to Build, and By What Means – to be honest, this is the trickiest part for me because I just doubt even what I initially thought were “good ideas”, and then try to convince myself through different means. This includes getting feedback from engineers and other teams. Some questions help: does this problem happen frequently, and to most users? After which I have to balance the answer to that with time and resources.

This is still an ongoing process for me but from the perspective of a designer, asking all these questions made it easier for me to understand why I’m designing something: for whom, and what for.