Playing To Win
The Evolution of the Strategic Choice Structuring Process
A Quarter-Century of Progress
This is an ‘inside baseball’ post for hard-core Playing to Win practitioners. The Strategic Choice Structuring Process (SCSP) has been my method for doing strategy for almost 25 years. I have just moved from the fourth to the fifth generation of the SCSP and I chronicle that journey in this Playing to Win/Practitioner Insights (PTW/PI) piece called The Evolution of the Strategic Choice Structuring Process: A Quarter-Century of Progress. And as always, you can find all the previous PTW/PI here.
What is the SCSP?
I am perhaps best known in strategy circles for the Strategy Choice Cascade (SCC) — the five key choices that an organization must make to have a useful strategy. It is analogous to Michael Porter being known most for the Five Forces model for understanding industry structure. Hey, maybe it is about having five things!
But in my own mind, I think that the SCSP is as meaningful and valuable a contribution as is the SCC. I wonder if my feelings are similar to Mike’s, who might well see his definition of strategy as a choice between low cost or differentiation as his most important strategy contribution. Who knows?
Regardless, I have been working on the SCSP for nearly 25 years. It was an effort to answer to the question from many clients: you have told us what a good strategy looks like, and we know ours doesn’t look anything like that now, how do we get from a strategy we don’t like to one we do like?
The SCSP has evolved a great deal over the past nearly quarter century — and much more so than the SCC, which has had only minor changes since its debut 20 years ago. The SCC has had only clarifying wording changes within the same five boxes. They were the questions that needed to be answered for strategy 20 years ago — and that hasn’t changed.
In contrast, the SCSP has had five significant iterations. That is because it is practice-based. The SCC doesn’t change because the nature of the answer needs to be the same. But the process for getting there — SCSP — needs to be adjusted based on what works for teams and what doesn’t. I have kept tweaking it to make it work best for teams creating strategy.
First Iteration
The first iteration of the SCSP took shape in the early 1990s — actually earlier than SCC which was first drawn and described in 1995. The key breakthrough for the first iteration of the SCSP happened at an assignment at Inmet Mining in 1994, as I described earlier in this series. That is when I created the what would have to be true (WWHTBT) question — the idea of reverse-engineering the logic of a strategy choice.
As the image of the first iteration of SCSP above shows, the process started with Issues, then converting them into options that might resolve the issue — what I termed Frame Choice. That was motivated by my observation that management teams could obsess endlessly about issues without progress — until they framed the kind of choice that they needed to make in to cause the issue go away. To me, framing a choice was like crossing the Rubicon — only then was there no turning back.
Then the process generated what I then called options, reverse-engineering them and identifying barriers to choice. I then posited a fork in the road based on whether barriers existed that required further testing or could be resolved without.
This first iteration was still my practice as of 2010 as evidenced by the footer in the bottom right.
Second Iteration
The Playing to Win book in 2013 debuted the second iteration of the SCSP above. Graphically, I eliminated the Issues bubble though still maintained the same description for Frame the Choice. So, I continued to see the importance of this transformative step of converting issues to choices as important.
But instead of talking about options, I changed the terminology to possibilities. This was the idea of Jan Rivkin, with whom I co-wrote a Harvard Business Review article on the SCSP (along with AG Lafley and Nicolaj Siggelkow) in 2012. Jan’s view was that options sounded overly formal and connoted a rigorous plan with financials. Possibilities felt more conducive to putting forth imaginative ideas — that would be tested later. This has turned out to be a terrific advance.
The other thing that changed was the removal of the fork in the road. My experience with teams had already demonstrated to me that there are always Barriers to Choice that require some sort of testing.
Third Iteration
By the time that the book was published, I had long since grown frustrated with the front end of the process. Issues was too vague a starting point. Teams would make long lists of issues that muddied the start of the process more than clarified it. Based on my experience with teams, I knew I had to have a better definition of the starting point. I came to realize that a clearer definition was Problems — as defined by a painful gap between the desired state and the current outcomes, as I described earlier in this series.
This helped me link the front end of the process to choice-making. I argued that the current unsatisfactory outcome is a product of all previous choices interacting with the competitive environment. Thus, the only way to make that painful gap go away is to make a different set of choices than the current choice. This has been really helpful for teams — a breakthrough. In due course, I started every strategy process with creating a Pareto chart of the most painful problems and working on solving the top three problems as the first iteration of strategy.
However, I still stuck with the next step in the process being Reframe the Problem as a Strategic Choice. It always made conceptual sense to me, but it wasn’t at all intuitive for teams.
The rest of the steps in the SCSP stayed the same in this iteration, which was in existence by 2015 as shown by the footer.
However, I made what I consider to be another important advance in the process by making it circular. There are never no problems — unless you are oblivious. Even as you make strategic choices, the next set of problems are there waiting for you to tackle.
Fourth Iteration
In the fourth iteration, which I wrote about in 2020, I finally threw in the towel on the Framing/Reframing as a Choice step in the process. I realized that it was one of those things beloved by the producer (me) and annoying for the user (teams working on strategy). Sigh! So, I dropped it.
I replaced it with the classic design thinking notion of the How Might We question. The idea was to turn the negativity of problem identification to the positivity of a great solution.
The other change was with the Testing step. Over time it had become clear to me that an initial assumption of the process was just plain wrong. The initial idea in the SCSP was that we would identify the Barriers to Choice for each possibility and then test the barriers and choose the possibility that best passed all its tests.
But over many, many processes, two things became obvious. First, in many cases, no possibility passed all of its tests — so we were notionally left without a viable possibility. Second, it became clear that for many of the greatest strategies out there, the company made a choice even though what had to be true wasn’t. However, it had a viable plan for transforming circumstances so that it made something true that wasn’t currently. A simple example is Apple and the iPhone. When iPhone was launched, it wasn’t true that users were keen to type on glass. But Apple worked hard to make that true — and now users think of it as the only recognizable form factor for smartphones.
As a result, determining a viable transformation plan for those things that needed to be true but weren’t currently became a core part of the overall testing phase.
Fifth (and Most Recent) Iteration (above)
However, the How Might We question step ended up being about as popular with teams as Reframe the Problem as a Strategic Choice even though I kept trying to force it. I eventually realized that part of the problem was that the rest of the steps in the SCSP were tasks with processes for accomplishing the task and this was just a mindset shift — a very transitory task at best. It was a case of which one doesn’t belong— a la Sesame Street!
I also came to believe that it is redundant. If I get the team to do a good job on Defining the Problem, the gap essentially defines the How Might We question. I essentially built the framing of the choice into the process for accomplishing the Problem step in the process. The current outcome is a function of the choices we have already made. The existence of the gap means that we need to make different choices. And the aspiration substitutes for the How Might We job. So, I finally punted that box out of the SCSP.
But I added in Test Design because experience had shown me that it is an important step — with lots of work to be done. Creatively and rigorously defining a great test is a task that requires high skill.
And finally, I decided that I wasn’t in love with Testing & Transformation. The transformation word just confused people and got them thinking about often dreaded ‘transformation programs’ and ‘transformation officers.’ I decided to replace it with Assessment, which I see as a little more of a comprehensive term. You have to carry out the designed tests and assess which possibility is the best bet — including determining what elements need to be converted from not true to true and what steps would need to be taken to make that happen.
And the overall product is Choice: an integrated set of choices that compels desired customer action!
Practitioner Insights
I think it is essential to keep improving with practice on anything you do. If you are dedicated to helping others, you need to provide them with a process that guides them. Think of taking them by the hand toward their goal.
Your process to guide them may be theoretically sound — at least in your mind. But that is not the determinative factor. If it doesn’t make sense for those who you are guiding, it doesn’t matter that it might be theoretically sound. It isn’t good enough.
Always use practice — the many repetitions — to make your process easier for users. The goal should be a that you guide with a gentle hand to the elbow — it shouldn’t feel like a kick in the ass or an incomprehensible set of instructions.
When something isn’t intuitive to those who you seek to guide, you need to listen, learn and start tweaking, even if it makes you sad that you have to give something up.
That is the price of developing the most user-friendly and effective approach for those you seek to help.
