Embracing Simplicity: A Fresh/Old Look at Problem-Solving in Innovation
Recently, I stumbled upon the Osborn-Parnes model of Creative Problem Solving (CPS), and its simplicity struck me. It just clicks.
While reviewing it, I had one of those "aha" moments, realizing it mirrors the process we employ in our work at Design Sprint Academy. Though it wasn't a groundbreaking discovery, the confirmation that we're on the right track was reassuring, particularly because in our field ambiguity and uncertainty often accompany the journey of innovation and new product development.
I thought it would be a good idea to share it with you, for a couple of reasons:
It might boost your confidence in your own approaches, if you follow this model. If not you might understand why your approach is not optimal and where you could improve it.
While this CPS model is intuitive, it only outlines high-level steps and I’d like to show more concretely what happens at each stage. As they say, the devil is in the details. Considering that many of you are in product/innovation and facing challenges similar to those our clients face, I hope that sharing Design Sprint Academy’s approach to creative problem-solving will offer some inspiration.
Here's how we at Design Sprint Academy tackle an innovation project.
1. Mess or Objective
The starting point of our projects is usually fuzzy, unclear, and messy. Our clients come to us with broad requests such as, “We need to do something with AI” , “We want to target a new customer audience with our product” or “ What features do we need to build to be competitive?”. These are hardly problem statements primed for immediate solution development.
2. Fact-finding
As tempting it might be to jump into solutions, we take our time to understand the existing landscape surrounding the challenge. It varies from project to project, but generally involves conducting customer interviews & surveys, talking to stakeholders, doing competitive analysis, trend watching, reviewing any existing user research and prior attempts to address the problem.
This phase can be particularly challenging—not only are we not yet close to finding a solution, but the problem itself still lacks clarity despite the accumulating data. By the end of this phase most important data are identified and analyzed, laying down a solid foundation for the next stage of problem identification and decision-making.
At Design Sprint Academy we call this part of our process Groundwork, and it typically takes us 1 - 2 weeks to do it.
3. Problem-Finding
In our world that’s called Problem Framing. It’s a half-a-day to a day workshop where key stakeholders and key decision-makers come together. Following a structured process, facilitated by DSA, they leverage the data gathered during Groundwork to identify and define clear problem statements.
The outcome is a working problem statement that not only reflects business objectives but also addresses real customer needs. That is made possible by grounding the decision-making process in the insights and data collected earlier — also ensuring the identified problem is both relevant and actionable, backed by stakeholder support.
4. Idea-Finding
It’s the start of the solution development. For the type of problems we work on (requiring novel, innovative solutions - that’s why it’s called innovation), the Design Sprint is our go-to method. It’s fast, user centric, and collaborative. In just a few days many alternatives, possibilities and ideas for responding to the problem statement are generated by a small cross-functional team of experts.
At the end of the design sprint the most promising solution is selected informed by both expert opinions and customer feedback.
This is typically where our direct involvement at Design Sprint Academy concludes. We guide our clients through the most challenging aspects of problem-solving, from identifying the problem and securing stakeholder buy-in to creating a user-validated solutions. However, this is not the end of the problem-solving process.
5. Solution-Finding
At this stage, the solution undergoes a more rigorous scrutiny, extending beyond its initial desirability. Teams develop a business case or model to assess the solution's viability, ensuring it aligns with business objectives and has a sustainable value proposition.
Additionally, feasibility is thoroughly evaluated, considering technical capabilities, resource availability, and potential constraints
All these criteria are used to evaluate, strengthen and refine the initial solution developed in the design sprint, until the solution reaches a maturity level suitable for implementation, ensuring it is not only desired by users but is also viable for the business and technically feasible.
6. Acceptance-Finding
Potential implementation steps are identified. If it’s an existing product, then a product roadmap is created outlining the updates or features to be developed, adhering to the company's established delivery methodology—be it Agile, Waterfall, or another process.
For new value propositions conceived by innovation teams, this stage might result in the design of a pilot or a Minimum Viable Product (MVP).
After this phase, organizations get in their comfort zone as they start executing and delivering the solutions, following familiar workflows.
It’s the so called exploitation phase, where the focus shifts to delivery, a process many organizations have mastered and which is characterized by the application of well-practiced workflows, with teams operating within their areas of expertise to bring the innovation to life.
CONCLUSIONS
This CPS model helps me better understand why so many teams fail or struggle when trying to develop solutions, and that is because they skip critical steps.
When a challenge is formulated, regardless how vague or broad (e.g let’s add gamification to our product), the teams jump to idea-finding or solution-finding, skipping not one but two critical steps, data-finding and problem-finding. It's unsurprising that the resulting ideas might lack depth or fail to address real problems, business or customer, leading to solutions that ultimately may not be implemented.
Even when teams do attempt to identify the problem before devising solutions, many still omit the crucial data-finding phase, rendering problem framing a superficial process mired in bias and assumptions.
A good symptom of that is when teams are doing design-thinking workshops or design sprints without the necessary groundwork, resulting in what's termed “innovation theater”.
It's also important to recognize the distinct roles various stakeholders play at different stages.
A common mistake is involving stakeholders at inappropriate times. For instance, senior executives should participate in concise Problem Framing sessions, making decisions based on data without being required to be part of a week-long problem-solving workshop (they will say “No”, btw).
Conversely, subject matter experts, such as designers, researchers, or engineers, should contribute to the idea-finding phase but not be expected to make strategic business decisions.
Reflect on your problem-solving process with these questions:
- Are we covering all stages, or are we skipping any?
- Which stakeholders are we involving at each stage, and is their involvement appropriate?
- What tools, methods, and frameworks are we applying at each step?
- Is there a clear outcome for each stage that facilitates progression to the next?
- Do we consistently adhere to this problem-solving process for every project?
Addressing these questions can help refine your approach, ensuring that your team effectively navigates from problem identification to solution implementation.
