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



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s