Opportunity Assessment and Problem Pyramid: another way to look at a problem


In this post I will speak about two techniques to elicit a problem and present it. One is the problem pyramid and its light alterations that can be used to elicit a definition of a problem. Another is the opportunity canvas that in my mind can be used in addition to the problem pyramid or instead of it for the purpose of eliciting the problem definition as well as portraying it in a canvas like format similar to Product or Business Model Canvas.


Even though I have already been working with software requirements for over 5 years, I believe I still lack a well-formed and structured method of eliciting information about a problem and then describing it so that it can be addressed. I will be asking a lot of Whys and of course, in the beginning of the project I will utilize a well-known problem statement format to capture the definition problem being addressed. I find that very often it is difficult to put enough meaningful information into the template and it becomes too general and thus meaningless. Quite often, the problem ends up being put together as “legacy design that makes any changes to the software very costly to implement and support impacting level of customer satisfaction. A solution then is to reduce cost of making changes to the system”. Frequently the only solution option then becomes to replace existing software with new software as a way to address the problem. Other solution options are not being looked at period.

Couple years ago I have found out about the problem pyramid concept (term coined by Robin Goldsmith) that allows to present the problem very neatly.

I have used this tool retrospectively trying to understand how well was the original problem statement put together and was able to find flaws in my work. I have also used this inconsistently during the actual elicitation sessions when I was trying to grasp the definition of the problem as seen from customer’s point of view. There were some challenges with using this tool however because often my work starts not from review of a problem but from review of a solution presented as a problem. You might have encountered something similar in your career where you are given a specific project to work on that may sound like “Implement or replace system A with system B; Implement interface for communication between system A and B using API”. You have a few choices then: start doing exactly what you are told, trying to figure out functional/solution requirements in the process and communicating them to the team or question what exactly you need to do starting a series of conversations to get to the actual driver of the project and the problem it is addressing. When trying to reverse engineer the problem being addressed based on the incoming solution description, there is another tool that may come handy. If you have read the disclaimer, you might have guessed its name as Opportunity Canvas. If so, you are right, this is the tool I want to focus more on in the next few paragraphs. .

Let’s look at a couple of scenarios where these tools can apply.

Figuring out what the problem is using Problem Pyramid
Recently I have had an opportunity to elicit information about challenges with existing software we are enhancing faced by larger customers. The representatives of those customers were able to meet me in person so I organized an impromptu meeting with those people and included the product manager so he was aware of what was going on.

Initial issue brought up by the customers sounded like “inability to partition CAD incidents based on certain criteria”.

We had a whiteboard and I was standing in front of it doing my best to figure out what questions I actually need to ask. I could not come up with anything better other than asking them to tell me a story of what is happening today to understand the context in which the problem materializes. After understanding the context better, I focused on getting a better sense of the symptoms i.e. how the users were actually experiencing the problem. Next, I asked the question about the implications of the problem i.e. what is the outcome of the symptoms as they appear. Having got a better sense of that, I was then asking questions about what would it mean to address the problem i.e. what would success look like for those customers.  I also asked about any steps users do today to try and get the issue resolved – any software or manual processes involved.

After some discussion, it turned out we dealt with more than 1 problem. A specific issue that was elicited was that a CAD incident could disappear from the list of incidents visible to the reporter without informing the reporter that the incident was successfully transferred to someone else and was being worked on.  The implications were that the issue was causing fear among reporters of the incidents that the system did not keep track of the incident and hence it was not available for first responders (officers) to see. The implication of that was dispatch of the incident was essentially delayed and whoever needed 911 help might have received it too late. Successful resolution of the problem meant that at no point in time there would be a lost incident that no one in dispatch knew the status on.

My notes from the meeting look quite unstructured even though I was able to capture some of the key statements.

Meeting notes

The definition of the problem that we could then discuss with development team came down to include the following aspects:

  • Who is affected
  • What are the symptoms (scenarios when issue materializes, how often the issue occurs, how the issue is experienced by the user)
  • What are the outcomes (how does this affect the dispatch process)
  • Why is the problem happening – root cause
  • What is success (what would change if the problem goes away and how can that be measured)

This really looks a lot like an aforementioned Robin Goldsmith’s Problem Pyramid even though my notes are far from articulating anything as structured. Item in red is what I have failed to elicit during the face-to-face session with the customers and had to elicit via the phone prior to a meeting with the dev team.

The main difference with the problem pyramid is that the sections for solution options and actual scope of the solution were not actually filled in during the meeting with the customers. That was not done for a number of reasons – a) main goal was to first understand the actual problem b) doing both in a single meeting could well be an overload (similar to when I have tried doing as is and to be cjms in a single meeting).

The problem pyramid after the first meeting with the customers then looked like

Problem pyramid problem completed

To fill in items in red I needed an entirely different meeting where I actually presented the problem and then facilitated a silent brainstorming session with the dev team. In my opinion, it may be difficult and unnecessary to complete both the problem and solution parts together when dealing with a complex problem that is still ill-formed.

Where this tool fails in my opinion as well is capturing information about existing solutions and workarounds people do today because keeping that will be one of the solution options worth considering. Secondly, the problem pyramid is lacking context about the specific profiles of customers experiencing the problem and affected roles/personas. Something I refer to as the story unraveling which sets the context for the problem. That information can be captured however there is no immediate reminder about it in the technique’s skeleton. Nevertheless, it is a great tool that can be used during initial elicitation of the problem with the team or the customers.

Presenting the problem or opportunity using Opportunity Canvas

I have found out a term “opportunity assessment” from SVPG website. I have used that template on a project back in 2013 but can’t say it has helped me much then. Recently I read Jeff Patton’s book “User Story Mapping” that introduced a similar concept “Opportunity Canvas”. The purpose is to define the opportunity we are thinking about pursuing either by starting from the definition of the problem being addressed or the feature/product idea that might have come first before a problem was recognized.

I have used this technique twice in the past month and both times it worked well communicating what is known about a problem or opportunity so far. If we look at the structure of the canvas, we can see it is broken down to 10 sections, two of which are numbered exactly the same (Problems and Solutions). By the way there is an article explaining the opportunity canvas and specifics of using it in real projects that you can review as well. The author was also inspired by Jeff Patton’s book.

  • Problems or solutions (1, 1) – pain points or solutions to certain pain points
  • Users and customers (2) – who is affected by a certain pain point
  • Solutions today (3) – if there are ways to address the pain today, what are those
  • User value / How will users use your solution (4) – what is the value in case the change is made
  • User metrics (5) – what to track to know the impact of the change
  • Adoption strategy (6) – how customers will start using the solution and how they are going to be informed
  • Business problems (7) – what is the value to your business given that a solution is in place
  • Business metrics (8) – how would you measure success from standpoint of your organization
  • Budget (9) – how much money, time and resources will this opportunity require

When a colleague was looking at this tool he asked me the reason for having two sections numbered exactly the same. Frankly speaking, I don’t recall the official rationale for this but my thinking goes back to the book where Jeff mentions that often we are presented not with problems but with solutions that we then have to analyze to understand the actual need for the solution. In this case, the starting point for the opportunity canvas can either be the problem or the envisioned solution proposed by one of the stakeholders.

Both times I used this technique I used it posthumously (after the actual conversation). This is of course not the best and effective strategy since the initial conversation that does not follow the format can easily miss some of the key elements that you have to assemble later to complete the canvas. That makes the whole process relatively ineffective. Nevertheless, even using the tool after the initial conversation but before any go-no go decisions are made still has merit.

What feels better comparing to the Problem Pyramid is that not only there is a place to mention the user and/or customer, but also that besides customer the business is kept in mind. Also, there is a place for a budget that can be used as a restraining mechanism setting clear boundaries for the cost of the solution. Lastly, the tool allows to specify existing workarounds or solutions in place allowing to assess the priority of the issue being looked at.

What I still lack even with Opportunity Canvas is the context element to describe in which context the problem actually occurs. I have a feeling that both customer section and adoption strategy could be used for that purpose however it is not intuitive. I also lack ability to describe scenarios in which the problem occurs. Finally, it really is unclear how to handle a case with a few related symptoms that may point to the same or multiple problems. Should an opportunity canvas be put together for each of those problems or a single canvas can be used to aggregate many similar problems into one.

To me it means that preliminary work needs to be done to dissect some of the sections into more specific parts. It is important to do a draft runthrough on your own, putting together everything you know in a canvas-like template. That will help to identify questions you definitely will need to focus on during the canvas workshop.

opp canvas completed


Here is my interpretation of how Opportunity Canvas sections can correlate to a Problem Pyramid.

Comparing oopc and pp

Overall, opportunity assessment feels more like a tool to be used with a group of internal stakeholders (at least parts of it) when you already have a certain grasp of the problem to be addressed. At the same time, parts of it can be used together with problem pyramid when you are just collecting information about the problem you want to find solutions for. Also, the exercise of filling both problem pyramid and opportunity canvas can be split into 2 or even 3 parts: problem definition from customer’s perspective, problem definition from perspective of the business and solution definition if you don’t have the right audience for all parts at the same time. The problem pyramid can be enhanced with some of the elements of the opportunity canvas like Business challenges and Business Benefits to include the point of view of the business stakeholders onto the problem.

The resulting template for the customer/user facing problem definition would then include all of the items I mentioned above

  • Who is affected
  • What are the symptoms (scenarios when issue materializes, how often the issue occurs, how the issue is experienced by the user)
  • What are the outcomes today (how does this affect the dispatch process)
  • Why is the problem happening – root cause
  • What is success (what would change if the problem goes away and how can that be measured)
  • Solutions today  – existing workarounds

as well as the Solutions today section. In this case we should have enough information to put together a well-formed problem statement from customer’s point of view and later extend it with business perspective and then with solution options.

I look forward to trying this version of the tool and sharing what happens



Applying Customer Journey Map for capturing As Is experience across a suite of products

I am a software analyst and in this and a few other posts I will be sharing my thoughts about systemworkflows I am revisiting at work, how I approach their redesign and what difficulties I encounter. This post talks more about development of a customer journey map for a number of personas across existing suite of products.  I haven’t written posts like this in a while and from a writer’s perspective they may honestly suck. I may also be wrong in what and how I do. You are free to tell me what you like, what you did not even get to because it was so difficult to comprehend and what you don’t like/don’t agree with. The way to get in touch is Facebook, email (donotcross03 at gmail dot com)
There are two capabilities we plan to include for users in the feature set we are currently working on: adding persons and vehicles to a CAD (Computer Aided Dispatch) call. While it sounds simple, this work becomes quite challenging because it affects multiple products used by different roles.  In the past I have already done the investigation on the side of the product I am working on (911 incident dispatch software) and that research gave me a relatively good understanding of the work to be done in the context of a 911 dispatcher’s workflow.

Information coming from dispatch however can be utilized by other personas like first responders (fire fighters, police officers, command staff) and record clerks (records division in police departments usually) meaning that there are integration points in system workflows between dispatch and responders, booking officers and record administration. This also means that whatever we want to build, needs to be designed in such a way it could be integrated into all those workflows that I still did not have a good understanding of.

I needed to understand the integration points between our part of the puzzle and the other products before putting together a vision of the to-be state for user flows we were planning to add. After thinking about the tools that could let me do that, I ended up selecting customer journey map for definition of as is experience and user story map for description of the to-be state of things.

Below I am sharing my experience with the technique and some of the observations.

I am not going to speak much on the topic of how great customer journey mapping great and provide a lot of details on all of the scenarios where this tool can come handy. There are existing great articles already that can tell you more about customer journey map: http://www.modernanalyst.com/Resources/Articles/tabid/115/ID/3367/Customer-Journey-Mapping-for-Business-Analysts.aspxhttps://www.slideshare.net/vedenin/customer-journey-mapping-for-business-analystshttps://conversionxl.com/blog/customer-journey-mapping-examples/, https://experience.sap.com/skillup/discover-your-wow-factor-with-customer-journey-mapping/. There are even tools online that you can use to start building your CJM (e.g. https://uxpressia.com/).

The reason I have chosen cjm is that this tool provides a way to decompose user’s interaction with a product or a company in general from high-level tasks and goals to very specific steps and elements the person is interacting with. Besides that, the tool can help to capture the emotional aspect of interacting with the software pinpointing areas of experience today that are causing frustration and are subjects for improvement or on the contrary cause delight and therefore should not be lost.

My plan was to organize a two part meeting where during the first meeting we would build an as is cjm involving person and vehicle information and then during the second part of the meeting we would assemble the to-be part of the process primarily affecting dispatch. Spoiler alert: the second part of the meeting did not work out very well and that is one of the lessons learnt from this exercise. Nevertheless, the part where we have described as is experience, worked out pretty well.
CJM allows to convey the story of using a product through quite a few lens:
  1. Persona – a specific type of the user / customer who is working with the software
  2. A certain segment of user’s entire experience with the product (finding out about the product, using the product, interacting with support)
  3. User goals (understanding what the user is trying to achieve during that specific part of the process)
  4. Touchpoints (parts of the software, specific persons a user is interacting during their experience with the product)
  5. Process / tasks (actual steps of the user, specific actions they take)
  6. Emotion (feelings the software invokes during the process of experiencing it, be those positive or negative)
These lens are coming from Uxpressia’s CJM template (see image below). SAP presents a slightly different view – you can review it by following one of the links above.
Excerpt from CJM
The idea of the technique is to break down the experience of a product by a user to phases and then go through the specific steps in each one of those phases to understand areas of improvement that then can be used as the rationale for new projects and become target outcomes whose project strive to achieve. The length of the process of preparing a high-quality CJM can vary from hours (for smaller products) to weeks (researching the CJM of interacting with a large company like an airline) and can consume a lot of resources.
Preparation for the workshop
Since I was planning to have a 2 part workshop where both as is and to be would be explored, I invited product management representatives as well as onsite developers and quality assurance from my team. There are pros and cons for doing it this way. On one hand, developers may not be as effective in contributing to the as is process since typically they don’t interact with users as much as product management does. On another hand, product management representatives from other products may not necessarily be the best audience to come up solutions specific to your part of the product that they not be very knowledgeable about. The one definite positive outcome of such a team setup is that at the end of the workshop, both development and product management come to a shared understanding of what is typically happening in the product today. In my opinion, another positive side of this setup is that everyone is more alert to the meeting because the conversation about how the interaction takes place is happening now and there are questions being asked and eyeopeners coming up this very moment

Since I knew I was pressured on time, I tried to focus on phase, touchpoints and process for specific personas skipping emotions however those did come up primarily after realizing the deficiencies in the existing workflows.

To actually conduct the workshop, I needed to have some preparatory materials explaining the customer journey map (I had my materials ready from a workshop I ran in January with dispatchers so I planned to reuse those), my rough understanding of the existing cjm (in case the whole conversation turned out to go the wrong way, I needed a plan b that could be used to trigger thought process in the group), and a few reminders (I’ve printed out images of some of the most used screens in the system to remind attendees about the workflow users were going through). That actually proved to be helpful when identifying pain points in the existing flows.

I also took a few large paper sheets we usually use during our periodic SAFe-based release planning (that is something worth another topic on its own) and placed them on a wall.  The idea was to use the drawing board for as is process and then switch to to be and map it out using those sheets glued to the wall.

As for the group size, the workshop included 3 product managers for products that represent a large set of the entire suite, myself, 2 senior developers, 1 QA and 1 UX designer who was primarily observing what was going on. I have sent out the invites in advance however I failed to mention that the workshop is intended as a primarily offline activity. Because of that one of the product managers was present remotely constantly watching what is going on via a camera.

The exercise I prepared as an introduction to cjm is quite simple and easy to do. It is a task to draw a map for ordering food for a family gettogether on a Sunday evening while watching a movie. I have prepared a few slides explaining what I would expect from the participants and even did my own cjm for that in case things really go south however once I’ve explained what I want: phases, steps, touch points and told them it was ok to draw using blocks everything went really smooth. You can review the full example here https://docs.google.com/presentation/d/1BBmLfWXaE6BEAoWYisx4rou8J5lp8vdN_sdyffK43dI/edit#slide=id.p

Lastly, to run the workshop I also needed to define the approach – whether it is scenario-based and we review everything in context of a certain nature of a 911 call or it is a generic 911 call and we try to outline all of the possible branches the call process may follow. After a discussion with a UX designer, I came to a conclusion it was best to focus on specific scenarios rather than describing a generic call that would add too much often irrelevant facts and make it really easy to forget specific steps that may come up only for certain natures (i.e. how an in progress robbery is handled may differ from a suspicious person or domestic violence call).

The workshop, actually
The workshop was scheduled for 2 hours with the first hour dedicated to investigation of as is experience. It actually took 1.5 hours and one of the contributing factors was that not all of the participants realized it was an offline meeting only so some of the time was eaten communicating updates to the person online however we found a way to mitigate that more or less.

Before we have started I have shared the agenda that included the following main points:
  1. As is process from a 911 call to what happens after arrest
  2. Integration points between P&V throughout different products
  3. To be process for person and vehicle entry
I have explained that we would be using the cjm for this and explained what cjm comes down to (the lens described above).

The first step was to determine the actual phases of a 911 incident and put those on the board. Initially, it felt more like a show and tell activity where I am standing in front of the board and everyone is waiting for me to write stuff and then nod in agreement or disagreement. That however was exactly the type of thing that I wanted to avoid. Because I was pressed with time, I skipped the exercise of trying to draw our own cjm for a pizza evening and very briefly explained it by drawing the blocks representing phases of the process (Determine food, find pizza place, find the right pizza, order, get delivery and enjoy the meal). I had to call everyone to the board to make sure engaging the participants into the conversation was really easy. That actually helped and everyone being closer to the board and given an actual marker had more rationale to do something.

The product managers were the ones who helped me to define the actual phases (911 call, CAD Incident, Arrest, Booking, Report, Report to prosecution, IBR report, Court case, Sentencing and Jail Management). Since the software we are developing does not cover some of those phases like Report to prosecution, court case and sentencing), those were mentioned with diving deep into details of what actually happens in those workflows.
The next step was to actually find out what is being done process wise by involved personas during each of the phases under discussion (911 call, CAD incident, Arrest, Booking, Report, IBR report).

I have used a specific example (domestic violence in progress resulting into arrest). Domestic violence is a frequent flyer in the world of 911 incidents where one of the spouses exerts verbal and/or physical violence onto their partner or children. This scenario may evolve into a variety of others including homicide, shooting, manslaughter, etc.) and can be a good starting point to understand all of the involved public safety processes
Adding meat to the bones
During this part of the workshop, we focused on adding actual details to each process phase. CAD Product manager added details related to the 911 call and CAD Incident. Law Product Manager was collaborating with Records Product Management (both were law officers in the past) on the arrest, report and IBR part of the process. As you can see in the resulting map, some parts were left blank (intentionally). At the end of the exercise, this is what the board looked like.
22555920_10155803295224127_1194948475_o (1)
Digitized map
I have then converted the map into a digital format using uxpressia.com that turned out to be a nice tool for my purposes. There are some things that took time to figure out but I was able to put the whole thing together probably in under two hours. The result looks something like this (I removed pain points and ideas from here for the purpose of not releasing sensitive information)
Next steps
The As Is map was intended to be the first part of the meeting and frankly speaking I probably should have stopped right there since the to be part of the meeting clearly did not go as planned. I also had to stop it half through since I already ran over time scheduled for the meeting. I think I will focus on the to be map (I will use storymapping to define it) in one of the next posts.
Lessons learnt

Number one: As is map is a good way of bringing different people to a common understanding. It is helpful for product management, development, myself because all of a sudden you are seeing the whole process in front of you with touchpoints, pain points and areas of improvement. You can challenge your own assumptions and build something common using the parts coming from everyone

Number two: when covering bigger processes, it is a bad idea to combine as is and to be into a single meeting because of complexity, amount of thought involved. Fatigue will develop naturally resulting into lower engagement level among participants

Number three: this exercise can easily take days hence it is important to understand what it is exactly you are trying to find or what aspect of the entire flow you want to focus on

Number four: you don’t necessarily need to build the map of the entire process if you are making changes to a part of the process. The reason I tried walking through the whole process was that I never did it before and felt this would be a good opportunity

Number five: it is important to develop a scenario-based mindset in the events of a complex process or a process crossing multiple products otherwise there is a high chance of getting rid in the myriad of details that may not be relevant in a particular scenario. If you want to compare or build alternative maps, you can dedicate a whole day to running a few scenarios and describe different maps every single time. This time I was unable to organize a day-long workshop with product managers

Number six: it really is debatable whether or not to invite development to as is maps. On one hand, hearing the conversations they are likelier to understand more about the current process and better see the problems we are trying to address. On the other hand, it is valuable time that can be spent on other important tasks. Up to you to decide!

Number seven: it does make sense to do a warm up exercise with a simpler map to build the right expectations with everoyone and transform the exercise into a collaboration as opposed to show and tell the main problem with which is not picking brains of others enough to have the learning happen

Number eight: bringing food (donuts) is a good idea because it gives people sugar, boosting their thinking process and b) who does not like donuts?

Number nine: sharing info in advance is optional. Someone will review it however most likely not

Number ten: prepare screenshots/wireframes/images from existing product, photos of existing customers to trigger thought process. This also means you may need to have done some preliminary cjm yourself just to make sure you can help bring everyone back on track in case someone wanders off
There are more things but I think I will stop here for now