6 min read
When James, Andy P and I sat down to discuss on Day 58, I used a word that I've never used before: Problemscape.
James chuckled at the word and we both thought it sounded funny. I'm not sure what he thought at first impression, but seeing as I used the word as a natural expression of a concept I was trying to articulate, I thought it was interesting at least. I'm not the biggest fan of smashing two words together and making it a word, but this word held something that I chose to explore on Day 59.
After Andy P and I finished our conversation on the morning of Day 59, I was left feeling quite confused and unsettled. It wasn't as if loads of conflict arose throughout the conversation, it was simply that our attempt of creating shared understanding seemed to obfuscated the concepts that I felt were otherwise clear (and maybe flawed, but clear at least).
Going Back To 10,000 Feet
During the conversation, I told Andy that I thought we were running over paths we've tread before and I was concerned we'd lost direction. I asked him if he'd bare with me for a moment while I tried to illustrate an idea that I had while he was talking. I hope he'll accept my apologies as I admit that my eyes may have glazed over a bit while I conceived this.
Assembling The Problemscape
I felt our conversation began within the domain of one specific concept but quickly traversed into the broader territory of the bigger problems that we were trying to solve in this project. I began scribbling words on sticky notes and assembling them as I spoke. I wasn't exactly sure what I was after but I knew I wanted to visually represent the problemscape and verify whether or not we were talking about the same thing.
I broke down the whole project as we knew it into different categories. Here were the categories as I saw them:
There were several different audiences we were targeting: From individuals to organizations—each with their own type and flavor.
We had a range of problems that we were looking to solve.
Context of Offering
We had two different contexts for offering: Public and private.
How Value Is Delivered
We had different methods of delivering value:
- Training (topical)
- Mentoring / Coaching (application)
- Project (doing it for you...)
We had different durations in which the value could be delivered:
- ⅛ Day
- ¼ Day
- ½ Day
- 1 Day
- 12 Weeks (6 sprints)
We had different methodologies which we could apply to the delivery of value:
- Design Thinking
Frequency of Delivery
We had a range of frequences at which the value could be delivered:
- Daily (Full-Time Immersive)
We had a range of disciplines that allowed us to strategically and tactically define and solve problems (that is, how we approach delivering our value):
- Front-End Development
- Project Management
Modes of Engagement
We had different modes of engagement:
Outcomes, Not Outputs
When I started exploring the outputs, I listed a range of items, but realized at the end that the output doesn't really matter for the context of this project. Whether the output is a website, a web app, a physical product, a startup, or a social enterprise, as long as the problem is being solved and the desired outcome is met, the output could be anything...
Read this awesome article by Ben Sauer for more details on why I chose to frame it this way: Outcomes, not outputs.
What Are Proposed Solutions?
In looking at the Problemscape by myself, I realized that the proposed solutions (value propositions) are just different packages of the following elements:
- Target Audience
- Audience's Problems
- Our approach to solving the problem
- The focus of the value
- The outcome
When I looked at the Problemscape on my desk, I realized that I could select the individual elements and piece them together into a package. That package would be the core elements of the value proposition. Additional language and framing was necessary of course, but the core elements were there.
I think this exercise allowed me to step outside of each individual problem-solution pairing and look at the broader landscape of the problems and solutions we were proposing. This enabled me to reflect on the project as a whole and make sure that we were solving the problems we set out to solve and that we were meeting the needs of the audiences we defined in our research. It allowed me to think through each of the individual personas that represented broader groups of people and walk through their problems from their perspective.
It gave me the confidence to know that nothing was being left out. I could now see all the individual packages (value propositions) and make sure that we had total coverage over the Problemscape. We had a bunch of packaged solutions and some of them overlapped, but I needed to see how they all fit into the bigger picture of the project that we first set out to explore.
The Purposes of Canvases In General
One thing I've discovered as I've attempted to use things like the Business Model Canvas, the Value Proposition Canvas and Andy T's Project Canvas, is that I like concept but I often find myself butting up against the structure of the canvas. I like to design the categories of the canvas as pertains to the project and its specific domain (DSL if you like). I think that calling this exercise a 'Problemscape' might be overly grandiose, but maybe not. Maybe the elements together are helpful in other contexts. I think that the idea of using a canvas to break a problem or project into smaller parts is the main concept. How you do it and what you call each section is dependent on the DSL of the project.
What Do You Think?
I think this exercise was very effective and am curious to hear other people's thoughts. Have you done anything like this before? Have you embarked on an exploratory project and found yourself struggling through the details of many different concepts? Have you battled against blurred boundaries within concept definition? How did you approach the problem?
I'd be curious to hear your thoughts and learn from your process.