Your job is to deeply understand the problem that your product aims to solve then chase the moving goal of solving every nuance of that problem – Rohini Vibha
effective product discovery is the first step to building effective products. A comprehensive discovery happens when research and design teams are able to manage the problem.
While it is natural to expect contextual inquiries to reveal everything, it is practically impossible to make it a tell all event. As part of interpretation of insights teams are expected to dig deeper in to the problem space as a whole and ask questions in every dimension possible.
It’ not easy. It’s common in the professional world to have folks come up with solutions before defining the problem. It’s easy to imagine solutions as it makes us feel good. It also offers a false hope as everything appears figured out.
Taking a solution-first mindset puts us on an orbit of unpredictability as the odds of success are purely a function of chance. It sets us on a direction that might not deliver value at all as the results are tangential to the customer acceptance criteria.
Problems on the other hand, are disturbing. They raise too many questions and challenge our assumptions. It’s a cognitive load that is better avoided as it will expose our own ignorance. It is too revealing for an average individual to take the risks of digging deeper.
Framing Proper Problem Statements
However, the real output of contextual inquiries are problem statements masqueraded within the overall conversation. For those looking for solutions, the obvious low hanging fruits will be revealed. For those looking for opportunities, nuggets of wisdom will be sprinkled throughout the conversation that will highlight the current challenges of stakeholders.
Collating problem statements and mapping them to different stakeholders brings out the relevance of various aspects of problem to different personas. Some of the important questions the research teams need to consider as they converse with the interview candidates are presented below.
In some scenarios inquiry may reveal multiple problem statements some distinct and others overlapping. In those cases, this exercise needs to repeated for each of the problem statements. It is intellectually overwhelming and even a tiring exercise.
Time invested to frame and reframe the problems through rigorous analysis pals in comparison to the disappointment associated with features that don’t deliver expected impact. Yes, there is a probability of analysis paralysis. However, the remedy to the execution problems of low adoption and conversion rate is better anticipated and prevented by killing the urgency to build.
There are 2 steps in problem analysis.
Multi Dimensional Causal Analysis
While not exhaustive, multi dimensional questions unearth the obstacles the prospects faces in their journey. As researchers we must grasp the Impact, Recurrence, Recognition, Risk and the Resolve dimension to identify the group of roles that are closer to the problem and those that are away from the problem.
Analyzing the nature of Problems
Before Changing the environment to buy a new solution, we will have to change the mindset to recognize the negative impact of existing one.
Problem discovery is about thoroughly examining all ideas presented. Getting the full picture of the problem is the most impactful way to introduce a solution.
According to Standard design school, a good problem statement Provides focus, Inspires your team, Informs criteria for evaluating competing ideas, Empowers team to make independent decisions, Prevents you from conceptualizing all encompassing solutions and Captures the hearts and minds of people you meet
However, it’s quite difficult to form statements that are narrow and to the point. Many problem statements tend to exhibit confirmation bias. Often, problem statements are too shallow to reveal the exact source. Even more, problem statement talk about issues beyond the realm of control.
Reason why product managers struggle to define problems is that they don’t have a fundamental grasp of what they are dealing with. Problems can typically vary on the scale of how structured or defined they are. Falling anywhere between well structured, concrete, and solvable to ill structured, and difficult to define
Solving unstructured problems
Most of the problems a product manager faces are all ill structured. However, the typical approach is to explore each problem as structured. Worse still is that their classification and prioritization doesn’t cut the ice with the customers as they see things quite differently
Challenging our assumptions through effective utilization of data does help overcome some of these limitations. To completely remove the risks of ineffective problem statements we need to take more qualitative exercises to dig deeper into the problem space.
Symptoms are obvious, acute issues, which are witnessed by anyone and everyone. Rarely are symptoms real problems.
General consensus is that a prospect, a researcher experiences the symptoms. There could be larger problem lurking in the background. Focusing on symptoms to draw solutions vastly undermines the effort to build right products.
Sakichi Toyoda used a technique with Toyota Motor Corporation during the evolution of its manufacturing methodologies. To imbibe a scientific approach, he recommended repeatedly asking why five times as we move from known to unknown. This layered questioning allows teams to break down a complex problem to its constituent causes.
Defining Boundary for Root Cause Analysis
Real problems are typically obscure. They only get manifested through issues within or outside the realm of control. In other words, problems inside your organization or larger ecosystem outside may be the root cause of your impediments.
Getting to truth requires you to move from the obvious to the non-obvious. This is only possible by peeling the layers of wisdom through a structured evaluation process.
A modern organization especially one that is focused on information systems is typically challenged by issues in various. An indicative list is given below.
Legacy – Physical Infrastructure, Policy Infrastructure, Utilities Infrastructure, Business Architecture, Security Architecture etc
Landscape – Data Governance, Digital Infrastructure, Supply Chain Networks, Geographic Presence, Organization Structures, Procurement Efficiencies, Business Trends etc
Model – Cost Structures, Revenue Streams, Business Finance, Vendor Relationship, Channel Management etc
People – Human Capital Management, Talent Acquisition, Compensation Management, Talent Development etc
Process – Process Integration, Automation Footprint, Process Orchestration, Escalation Procedures etc
Tools – Integration Tools, Data Mapping Tools, Enterprise Software, Manual Tools etc
Forming Effective Problem Hypothesis
Implementing the 5 why?’s within these categories by diligently going through each of these 6 categories of Legacy, Landscape, Model, People, Process and Tools will help us cover a majority of the potential root causes.
Exploring each of these areas in depth based on the inputs from contextual interviews is essential to framing a compelling problem hypothesis
Humans have a tendency to restrict their thinking to a single cause to a specific problem. A lot of people fall into the trap of tunnel vision in problem solving. We have all kinds of unsolvable problems only because of the problem solvers inability to explore multiple dimensions.
A problem hypothesis should explore all the dimensions noted earlier. Design principle of finding all the root causes is the first step in effective solution hypothesis.
Legacy refers to the blueprint. History of why an organization or industry made a particular choice. How the ramifications of such choice is being felt even today. What problems where they dealing with then, that made them select an option causing problems today.
For example, take a factory building automobile spare parts started in 1970 and compare it with a similar factory built in 2000. There will be umpteen differences you can see in Architecture, Floor Planning, Layout, Security Protocols etc. Each of these could be contributing to say a “safety problem”
Even between two companies started in the same year, we can see a lot of differences in choices based on location, capital availability, talent, knowledge parity etc.If you are building a solution to improve workplace safety, you need to really think about the kind of environments that the problem was originally identified.
Reviewing all relevant legacy factors surrounding design, technology, architecture, infrastructure will help figure out the potential contributions of bad investments of the past.
Landscape refers to foundation. Barebone essentials that are necessary for the particular organizations or industry. How these constraints dictate the symptoms we see today. The evolution of thinking within the organization and the evolution of policy framework within the industry that propelled these adoptions.
For example, a decade ago privacy wasn’t a major concern. Necessity to consider data governance tools that encompass every aspect of protecting customer data was not available nor anticipated. Landscape was conceptualized and evolved oblivious to its needs.
Today, GDPR is a major theme and protecting customer data is no 1 priority. However, if the existing architecture doesn’t have provisions for single point integration then we will have leakages at different points which are just symptoms of the larger problem of a broken infrastructure.
Model refers to the building blocks. Components that hold the organization and industry together. It is the understanding of how different parts come together in synchronized operation to deliver overall value to customers. Business models encompass the organization’s relationship with its vendors and customers.
For example, till a decade ago business were depended on CAPEX to manage operations. Products, Solutions and Services were offered by vendors as a one time purchase which the company passed on to the customers as they had to include it in their budget to make the purchase.
Today, organizations don’t buy but rent. An organization that is completely working on a buy model carries inefficiencies which affect the its operations and create issues. Similarly each component of a business model might impact various functions and create problems which requires to be corrected.
Similarly a business could be having problems in people management, process management and Tools management which could be the root cause of problems being experienced.
These 6 categories together can be used in the ishikawa diagram to visualize the cause and effect comprehensively. Furthermore, each cause needs to be assessed on it’s impact, risk, insights and benefits. A comprehensive list of all root causes along with their assessments are fed into the Problem Hypothesis Statements.
Characteristics of Sound Problem Statements
I don’t have a magic formula for prioritizing the world’s problems – Bill Gates
A good product results from a blend of in the box and out of the box thinking. Teams require a good problem statement to sprout wild ideas. Ideas, a lot of them need to be sparked off in order to figure out the best options.
A sound problem statement is broad enough to encourage creativity and narrow enough to articulate the specific outcomes. Problem hypothesis statement is a good start to the problem framing process. An outcome of thorough root causes evaluation based on inputs gathered during contextual inquiries.
Unfortunately, today’s customer problem statements are just afterthoughts. Reverse engineered from a solution the business stakeholders are eager to fund. An exercise in hindsight that yields little or no value. Forming a valuable problem hypothesis is a rigorous process that requires back and forth conversations with prospects or customers.
While it is comforting to assume that we can collect all the inputs necessary during first customer interaction, the reality is far from the truth. Problem hypothesis while credible enough may not be accurate enough. Analysis of the current state must include synthesis of gap in reaching the ideal state.
Here is an opportunity for product design teams to get back to prospects one more time in order to validate the relevance and resonance of these problem statements to their actual first hand experience. Unless we are able to uncover the specific needs, all our teams effort may end up off missing the mark in terms of customer expectation.
Customers are expecting to move away from the bad today to a better tomorrow. Different segments of customers have different levels of pain. Consequently, their expectation of delta in the new solution should be an offer relative to their experience. As we move from “what is ?” to “what if”, we need to be clear about the profile of prospects who we expect to be our customers.
Now that we have a list of problem hypothesis, we need to look at creating a list that incorporates both a customer point of view and business standpoint. Most organizations are neck deep in prioritizing features and publishing roadmaps. While it is a valuable ritual to prioritize backlogs, our belief is that design led product development must prioritize problems.
Frameworks to Leverage in Problem Validation
As a product leader we are looking to build features that are desirable, feasible and viable. With problem prioritization we are initiating validation of these criterias against each problem hypothesis. Moreover, we are also looking to know where each customer stakeholder is in their journey to resolve the problem.
What all is being done within the prospect environment to emerge problem free. Problem – Awareness Map is the first step.
Once we know the hands on journey of each customers, it becomes easy to know the customers insights on problem list. In fact, this exercise will reveal more. It can help us
The mark of a great man is one who knows when to set aside the important things in order to accomplish the vital ones – Brandon Sanderson, The Alloy of Law
Balancing customer needs and business interests requires a more diligent problem prioritization. We have mapped customers journey with each problem. As a product team we need to be able to say which of these problems on an aggregate level fall into the opportunity bucket.
A categorization i find particularly useful is one leveraged by Michael Skok to categorize problems on their opportunity attractiveness. He states that problems can be grouped into Unworkable, Unavoidable, Urgent and Underserved.
We would like to use a slightly modified scale to map problems into categories such as Unworkable, Unavoidable, Un Important, UnderServed and Unsatisfied. We then map them with factors such as Frequency of Experience, Volume of Users Affected, Organizational Effort to Stabilize and Resource Hemorrhage with a goal to estimate the cost of inaction for the customer.
Problem Intensity Map thus helps understand critical nature of the problem to this prospect. Alignment of problem factors to the business objective they have signed up to. Also , grasp the priority of accountability their careers rest upon. Unless stakeholders feel a personal stake in solving the problem and an authority to support it. Solution uptake will be dismal.
Both the problem awareness map and problem intensity map require a further depth of detail. Normally this kind of information requires extending the conversation to organizational stakeholders beyond the participants in contextual inquiries .
It is indeed quite intimidating to ask for this information. Even more daunting is getting access to a certain level of people who can answer these questions. Mind you, the real value of research is in incremental learning. We can only develop deep layers of knowledge when we can ask more questions to the right target audience.
Here lies the opportunity to validate once again the real customer who can benefit from the product. Making sense of the patterns we see through complimenting data points is crucial. We can only get the full picture over an extended period of time. Continue challenging what we know through a sustained learning effort.
More often than not problems are very subtle and delicate. It is natural and easy for customers to shift attention away from uncomfortable problem definition into solution discussion. This premature shift in focus impacts discovery teams ability to sharpen the problem definition.
Conversations with stakeholders beyond the realm of user level participants is essential to map the problems to the organizational objectives and goals.
Helping people part with their dollars requires influencing them to acknowledge the need to solve.
You have to acknowledge a problem exists before you can actually go about finding a solution – Demi Moore
Most people and organizations feel ill at ease in grasping the severity of the issues at hand. A trait that is deeply ingrained in each one of us. As we climb the corporate ladder, we are reinforced by teachings of positivity. Ignoring the negative is a way of life for lot of honchos who wish to shrek responsibility.
Being in denial is a defense often used by people who do not want to acknowledge that bad stuff is occurring in their work lives under their very watch. Denial is a form of reality distortion that makes a situation worse for the stakeholders involved. A reason to avoid something. An approach to sidestep analysis of past bad decisions.
Identifying the problem is quite easy in comparison to understanding the problem and addressing it. Role of product discovery is to help prospects overcome this unconscious neglect. Helping stakeholders to be cognizant of the fact that just ignoring things won’t necessarily make them disappear.
Stakeholders Problem Solution Insights
This table serves two purposes
For each prospect, for each problem and for each stakeholder we try and grasp how well they recognize the problems and what’s their thought process on the approach to take in order to solve it.
This tabulation has been prepared taking in view AIDA model in marketing which describes potential customers journey as one via Attention, Interest, Desire and Action.
Point to note is that we are grasping the customers sentiment of how this problem needs to be solved from their point of view. Being empathetic to their individual situations, we can learn about the constraints that are guiding to a particular choice.
It’s high time to grasp what they feel, what they think, what they see, what they hear. A lot of product leaders believe innovations as the only way forward. However, customers perspectives are quite distinct resulting from their situation.
Executives who are well versed in sales know first hand how much customers try and salvage value out of their existing investments. If you are faced with a situation where customers are insisting on enhancing existing solutions in spite of better value in innovation, then it’s highly possible you are interacting with the wrong prospect or it’s high time to prod deep into customers goals and their satisfaction with existing tools.
There may not be a real problem except that they are stuck with a recently purchased solution that is not delivering full outcome. All that they want is an extension to complement their existing landscape or a quick fix that will keep things functional. Oscillating within the zone of tolerance and the zone of acceptance.
It’s a good time to revisit the Kano Analysis and map the problems at hand to the levels of customer satisfaction and functional implementation. This model was first published in 1984 by Dr Noriaki Kano, professor of quality management at the Tokyo University of Science.
Kano articulates that any solution is about layers of expectations. This model has several representations and interpretations. At its core, this model encourages product designers to think about how products satisfy customers’ needs. It begs the question of how value is created. What will increase value ? what will decrease value ? what will maintain value ?
customer satisfaction is visualized through a two-dimensional construction. Mapping customers requirement against the customer‘s satisfaction. satisfaction dimension ranges from extreme satisfaction or delight to extreme dissatisfaction or frustration. Empowers designers to think constantly about customer delight in each and every feature.
Not one requirement but the bouquet of all needs and their levels of satisfaction. Idea is that each need comes with a distinct expectation. An individual requirement might just meet expectations, while other might go beyond expectation, while a few more could delight customer. It is about how each requirement was fulfilled that defines the overall customer satisfaction.
Pundits of product management recommend kano model to prioritize features that will get shipped. However, this model can be used to understand customer dissatisfaction with the existing feature set also. A feature is a mechanism to complete a task(s) / Job (s) expecting a fruitful outcome. A problem or distasteful situation results when that outcome doesn’t materialize.
A part of the conversation with customer should involve discussion on Jobs/Tasks they were trying to complete. Constructing a Job Statement (Job(s) + Outcomes) is essential. Identifying the tools that are currently being used to fulfill these jobs follows next. Mapping these Job statements to the problem hypothesis occurs last.
Problem Job Map
Objective of this analysis is to formulate the job statement. Depending on the structure the number of roles vary. Each role or group contributing to a role under consideration, the job statement will vary. However, it’s important to abstract and form statements that discuss the overall objective.
Action + Object + Outcome = Job Statement is a simple equation to define such a statement. Form all statements as possible and find the connection between them and the problem hypothesis.
Jobs Tools Map
Next Step is to identify all the tools associated with customer environments and figure out the list of tools being used to complete a Jobs. These tools could be manual or semi automated or fully automated tools. Some of these could be done inhouse or outsourced and completed via contractors. Idea here is to gain an overall perspective of all the tools being used.
Tools Satisfaction Map
Now that we know Jobs our stakeholders were trying to accomplish, the tools they were using and the problems associated with tools, we need to grasp the level of satisfaction they currently have. We can learn a lot about the features, their benefits and value from this exercise.
introducing new features not required to a product may just become an expense item without really boosting customer satisfaction while on the other hand, adding one particularly delighting feature could be a game changer. In other words, few 10x better solutions may have a higher delight score then having a lot of me too features.
Pain -> Cause -> Problem -> Jobs -> Tools -> Insights -> Ideas.
FIND MORE CANVAS
Last updated Sep. 1, 2018
MOHAMMED ABUBUCKER ALATHICK
Program Director – Product Management
Digital Product Management Training and Leadership Tools
be a product rockstar.
We accelerate digital product success by enabling people, establishing process and facilitating product development
Product Excellence. Simplified