SCAMPER

SCAMPER

Challenging status quo

Challenging status quo

After the brainstorming sessions, it became clear that one of the main challenges for the team was moving beyond familiar ways of thinking. Decision-making was often shaped by established practices, while ideas for change needed clearer spaces to be explored and validated. Recognizing this dynamic helped me understand where facilitation could add the most value. The problem we were trying to solve was complex, as was the process behind it. Gaining a deeper understanding of that process was essential before moving forward. Since the BAs had strong domain expertise as accountants, their collaboration became key to unpacking how things actually worked. I proposed a SCAMPER session as a way to create that shared understanding and explore alternatives. Even though the product was not yet defined, there was already a strong initial direction emerging from brainstorming. SCAMPER allowed us to step back, question assumptions, and explore different paths before committing to a single approach. This shift created the space we needed to apply lateral thinking to specific product decisions.
After the brainstorming sessions, it became clear that one of the main challenges for the team was moving beyond familiar ways of thinking. Decision-making was often shaped by established practices, while ideas for change needed clearer spaces to be explored and validated. Recognizing this dynamic helped me understand where facilitation could add the most value. The problem we were trying to solve was complex, as was the process behind it. Gaining a deeper understanding of that process was essential before moving forward. Since the BAs had strong domain expertise as accountants, their collaboration became key to unpacking how things actually worked. I proposed a SCAMPER session as a way to create that shared understanding and explore alternatives. Even though the product was not yet defined, there was already a strong initial direction emerging from brainstorming. SCAMPER allowed us to step back, question assumptions, and explore different paths before committing to a single approach. This shift created the space we needed to apply lateral thinking to specific product decisions.
Scamper img
Scamper img

LATERAL THINKING

The idea to challenge

The idea to challenge

One of the first challenges we addressed using this approach was the structure the product would follow. During research, we observed two different ways users organized their files: tax → customer → year and customer → tax → year. Both approaches reflected real mental models, and acknowledging that diversity was an important starting point. Using SCAMPER as a lens helped us step back and explore alternatives beyond a direct translation of existing behaviors. We questioned what could be combined to support the widest range of use cases, and which elements were essential to preserve meaning without adding unnecessary complexity. Through these discussions, we learned that supporting both structures would significantly increase development effort, as each required a different calculation logic to reach the final tax value. By reframing the problem and focusing on adaptability rather than completeness, we concluded that the customer → tax → year structure offered the most flexibility while remaining feasible within our constraints. This exercise helped the team align around a shared direction and reinforced the value of lateral thinking when navigating trade-offs between user needs and technical realities.
One of the first challenges we addressed using this approach was the structure the product would follow. During research, we observed two different ways users organized their files: tax → customer → year and customer → tax → year. Both approaches reflected real mental models, and acknowledging that diversity was an important starting point. Using SCAMPER as a lens helped us step back and explore alternatives beyond a direct translation of existing behaviors. We questioned what could be combined to support the widest range of use cases, and which elements were essential to preserve meaning without adding unnecessary complexity. Through these discussions, we learned that supporting both structures would significantly increase development effort, as each required a different calculation logic to reach the final tax value. By reframing the problem and focusing on adaptability rather than completeness, we concluded that the customer → tax → year structure offered the most flexibility while remaining feasible within our constraints. This exercise helped the team align around a shared direction and reinforced the value of lateral thinking when navigating trade-offs between user needs and technical realities.