By Jen Mowery, Lecturer of Agile Methodologies & Project Management, Harrisburg University of Science & Technology
Rest & Reset
We all need a break sometimes. Especially now, when many of us have become mostly confined to our houses, blurring the lines between work and home environments, it can be essential to get away when possible. One of my favorite things to do when I need a recharge is to head to a quiet beach town and dive into a good book. This time, it was HBR’s 10 Must Reads on Design Thinking. As usual, this literary journey sparked some key takeaways for me.
While reading through The Innovation Catalysts by Roger L. Martin, one of the articles contained in HBR’s anthology, I was suddenly reminded of a time earlier in my career that brings me great joy. Before I was teaching agile methodologies, I held leadership roles in another organization. During that time, I worked with teams who would come to me with some pain point or another and we would sit around a room with white boards and post-it notes and dream up potential solutions to these problems. We used to call these “jam sessions”, and it just so happens that my initials are JAM as well. I didn’t know it then, but those jam sessions were essentially basic design thinking strategy sessions.
Pain Storm. Sol-Jam. Code-Jam.
In his article, Martin talks about how some of the bright minds at Intuit used design thinking to help revamp their customer satisfaction scores and create a revolution at the company that’s led to years of innovation and successful product development. One of the strategies that the innovation catalysts at Intuit use is something that they call “pain storming”, “sol-jamming”, and “code-jamming”. The idea is relatively simple, but for anyone used to a more traditional style of product design in a corporate setting, it can be difficult to get used to.
The main concept is this: how do we know what to create if we don’t know first-hand what our consumers are going through? How do we know we’re doing the right thing if all we do is innovate based on stale data or some manager’s best guess at what consumers need? In order to truly bring useful products and services to consumers, we have to understand their pain points. We need to speak to them, spend time with them, understand what they want or need to do and why they can’t do it with the products and services currently available. This is exactly the research that sits at the heart of Intuit’s pain storm sessions.
Once they fully understand the consumer’s pain points, Intuit quickly moves onto sol-jam sessions, which are aimed at rapidly prototyping solutions to the customers’ needs. Following that process is the code-jam, where Intuit developers quickly code minimally viable software for the consumer to get their hands on, test out, and give feedback on. The whole process can happen in as little as four weeks, meaning that it’s a fast and fun way to design real solutions that meet real needs and are guaranteed to delight customers.
In SAFe, we have a different word for Intuit’s innovation catalysts: Product Manager. Product Managers are absolutely essential to successful innovation, and the ones that will be most successful are the ones who are willing to go pain storm chasing. Back when my team and I would have jam sessions, we were brave enough to brainstorm solutions fearlessly, understanding that even the ones that didn’t seem feasible were still valid. But we were only able to do this because we spent time understanding the needs of the people we were solutioning for.
It was my job as a leader to allow my team to take the time to truly understand the customer’s pain, understanding that this journey might lead to some unexpected or even upsetting revelations. And after that, I had to ensure that the team felt safe enough to explore every idea until we found a solution that worked for all parties. I was able to do this because I knew that my team—and all teams, at their core—wanted to deliver value. It is inherent in human nature to want to remove pain from others.
Product Managers must motivate their teams to dig into the pain of the customer. They must push their teams to continue solutioning, even when things get tough. They also guide the customer through their own journey, helping them better understand their own pain points, which can result in an unshakable relationship built on trust.
It may be the case as I move onward in my journey that I only take interest in projects that begin with the pain storm. I’ve seen too many instances where we attempt to solve the problem before we understand the problem, or too many instances where the design team believes they know what the customer needs without that emotional exploration and customer connection. More often than not, this kind of design creates more pain points than it improves.
Design to Delight
Another article in the HBR 10 Must Reads on Design Thinking, Design for Action by Tim Brown and Roger L. Martin, described a case study that points back to the success of design thinking in the education environment. Education has always been a passion of mine, and I believe that in order to improve education, we must explore and emotionally connect with the needs of the student. This is my current focus. If you’re interested in learning more, you can check out the case study on the Peruvian school system that benefited from IDEO’s design thinking assistance here.
As the saying goes, build it and they will come. But I believe that we should build it with them while they’re are already here.
Brown, Tim, and Roger Martin. “Design for Action.” Harvard Business Review, Sept. 2015, hbr.org/2015/09/design-for-action.
“Colegios Innova Schools.” Colegios Innova Schools, 2017, www.innovaschools.edu.pe/.
“Designing a School System from the Ground Up.” Www.Ideo.Com, 2014, www.ideo.com/case-study/designing-a-school-system-from-the-ground-up.
Harvard Business Review. HBR’s 10 Must Reads on Design Thinking. Harvard Business Review Press, Apr. 2020.
Martin, Roger. “The Innovation Catalysts.” Harvard Business Review, June 2011, hbr.org/2011/06/the-innovation-catalysts.
Scaled Agile. “Product and Solution Management.” Scaled Agile Framework, Scaled Agile, 26 Sept. 2019, www.scaledagileframework.com/product-and-solution-management/.