What Alan Turing Can Teach Us About Product Management

This is the first post in our Demystifying Product Management series. In this post, we’ll cover why we must seek deep understanding of the product ecosystem (the way things are and what that means for a customer’s progress) as it’s always the first region of revelation.

Values, people, goals, and functions rely on the interplay of two types of tools: Mental ones, tools that impact learning curves and multiple everyday decisions that, in turn, define progress.

Then, the actual tools. The ones that collectively help teams realize that progress. Each tool aims to serve a specific part of this progress. Together, they form the ecosystem.

The Product Management discipline requires us to train our ears for the language spoken by both (mental and actual) tools, as that’s the only way to interpret customers’ progress, and our role in it.

If you understand these forces of an ecosystem, it wouldn’t be hard for you to answer questions like: What applications need to exist and how they need to inter-operate to enable different business processes.

And as SVPG’s Marty Cagan wrote, “In order for a product team to actually be empowered and act with a meaningful degree of autonomy, the team must have a deep understanding of the broader business context.

In this post, let’s set sail to find out how deep understanding and broad business context really help. First stop: Milton Keynes, UK.

Can you guess what this image is (without scrolling down for the answer) –

Source

Think..

..

..

Okay, you guessed it. It is Alan Turing’s momentous invention called ‘BOMBE,’ built to break the encrypted messages sent by Germany’s ENIGMA, during the Second World War.

And this is THE ENIGMA MACHINE (one of the the preserved ones).

Source

Why are we pursuing time travel? Bear with me.

In his seminal 1936 paper, Alan Turing had already applied his endless fascination with logic to something that was unheard of in the 1930s. The possibility of a new kind of machine. The computer.

It is possible to invent a single machine which can be used to compute any computable sequence.
Alan Turing

The idea of dealing with theories without realizing their real world applications, seemed hollow to him. His decision to join Britain’s Government Code and Cypher School was based on the same motivation.

So, what was so complex about ENIGMA’s workings, and how did Alan Turing and his team made the right connections to break them? Let’s find out.

Here’s how a message was transmitted –

1. A German navy officer would type in a message (say, F)
2. Get a code from Enigma (say, A)
3. The code would then be written on a piece of paper
4. Then, this was given to the radio operator
5. The operator would then transmit the message by radio (morse code)
6. The officer on the other side would receive the code, and then type it on his Enigma machine
7. He had a similar Enigma machine with the same configurations as per their CHEAT SHEET, like the one below –

Unbelievable, right?

But, like all of cryptography, the ENIGMA machine is just simple to describe, and infuriating to break. So, now let’s turn towards understanding how all its parts worked together to make an almost impenetrable encryption possible.

Source: Louise Dade

In 1932, a team of Polish cryptanalysts had broken Enigma, because back then, the Germans changed the cipher for the initial settings every few months.

Being aware of this flaw, they resorted to change the settings, at least once a day, leading to 100,000,000,000,000,000,000,000+ possibilities to check before one could arrive at a combination.

Alan Turing, Gordon Welchman, John Jeffreys, Peter Twinn, and other mathematicians had a good start as they could build upon the Polish machine, but that wasn’t enough.

The polish machine, “BOMBA” – automated the search for the initial settings used by Germany’s ENIGMA encryption device, but it was proving to be inefficient because of the increased complexity.

Turing spent a lot of time, trying to understand how the German ciphering device worked by reading the signals transmitted. He knew how the machine worked. How the rotors, plugboard and the cheat sheet were used to communicate secretly.

He knew that the number of combinations was huge (1 quintillion) and that even a team of untiring mathematicians would take years to solve the puzzle.

Here’s a breakup of how these quintillion possibilities could exist.

The British version of the machine was called “BOMBE” and it was an electro-mechanical version which ran faster than the only-mechanical ones, and derived results in hours, instead of days or weeks, equivalent to 36 ENIGMAs.

Still. Their work was unyielding.

They had to think about reducing the number of combinations, which was only possible by guessing the settings. And they were trying hard to eliminate a factor that was not working, and somehow identify a flaw in the settings.

What could possibly be the flaw?

One evening, Turing was out with his team, they were all having fun, except for him, when a chance encounter led to a chance conversation with a British radio operator.

While enlisting her comedic senses to crack jokes and produce interesting banter, the radio operator pointed out that the radio signal intercepted from one of the German towers, was sent by a “male”, and that “he probably had a girlfriend”.

The levity of conversations ensured that the fact went unnoticed.

Turing, though, kept wondering. How could she be so sure?

He decided to speak with her again and learned that all the messages sent by the German in question, began with the same phrase, ‘CILLY’.

That’s it!

‘CILLY’ turns out to be an important needle in the sunlit haystack of German tricks.

Rather than straining their imaginations to pick a random key, the overworked operators would sometimes pick five letters from the Enigma keyboard.

In this case, they probably chose the initials of the operator’s girlfriend. Before cracking Enigma the hard way, it became routine for the cryptanalysts to try out the “CILLIES”, and this exercise paid off.

CILLIES were not weaknesses of the Enigma machine, they were weaknesses of the ways in which it was operated.

The Bletchley Park cryptanalysts discovered that German operators always used a common phrase at the beginning of the message. They also observed that all messages sent at 6.00 AM began with a weather report.

Using this information, Turing realised that his machine didn’t have to search through every possible setting – instead, it can search for words that they know will be in the message.

This in-turn reduced the number of combinations to be checked. Turing already knew that ENIGMA did not map the letter to itself, so ‘A’ (un-encrypted) would never be ‘A’ (encrypted), and he exploited this flaw to yield a favourable outcome.

That day, BOMBE cracked the message in approximately 20 minutes.

They decrypted all the messages recorded till date and then created a map of all the naval ships in position, and could predict, when and where the next attack was planned.

Genius!

Turing and his team improved on Rejewski’s design and changed the course of the war.

It is estimated that breaking ENIGMA reduced the wartime by approximately two years and saved more than 14 million lives.

Good Product Managers bring to the table a similar passion to solve problems at hand, and that requires a deep understanding of the thing itself, and the things that surround the thing.

They need to know how a given system works, what are the possibilities created due to rotors, plugboards, and cheat sheets, and how to attack the problem with this knowledge.

As we enter this process, we must equip ourselves with questions like:

• What’s working, and what isn’t?
• What is expected?
• What does the current ecosystem look like?
• Which feature will address customer’s pain point?
• How to track progress for the customer, and also, what is the best way to address it?

How do you map out broad context?

Direct your love in the right direction.

Good Product Managers love the problem more than the solution, as the solution may change or get versioned (and v1, v2, v3 might not have anything in common with v1).

You have the courage to tread through the cave, until you see the light, and then, to plan work backwards. You play the role of the customer in the organisation, and possess deep empathy for their realities, that seek important change.

Product managers drive the vision, strategy, design, and execution of their product
Sachin Rekhi

In my first outing as a Product Manager (in the Enterprise CRM industry), I had difficulty understanding the product and the market, and why customers demanded:

• The orders to be broken down
• The automation of discount calculation
• The ability to change the information during the course
• The ability to reroute the service provisioning tasks based on product category
• The ability to view the locations where the services were already provided and which areas they were yet to serve
• And many many more

This questioning was proof that the time spent in college wasn’t exactly teeming with insights. I had to live in the domain in which the customers operated. If we understood the background deeper, we could get better in articulating, and responding to their needs.

How does one arrive at an unerring way of thinking about something?

Well, in my case, a looming deadline did the trick.

It was a sales proposal, a late night assignment. And I was documenting responses for the questions asked by the prospect.

I had to have better functional understanding of the industry standards, competition, strengths and weaknesses, best practices, etc. (in Sun Tzu’s words, I had to be “the greatest commander”).

I wanted to see the big picture of a CRM before diving in. But there was too much to read, too much to discuss, and absence of ample time.

Then a bolt struck, I could apply the reverse path, a trick to reduce the possibilities (Hello, Alan!), the most efficient way out.

So I started looking up CRM architecture, but this time with an image search (thanks Google, a picture is, indeed, worth a thousand words), and a shift in thinking occurred.

I searched with something like –

And then, started sifting through interesting visualizations fetched from datasheets –

Within a few minutes, Google had helped me conquer a contextual impasse. It did not answer the questions at hand, but I learnt more about the rotors and plugboards of the game –

• What constitutes the system as a whole (the different blocks, modules, layers, etc.)
• What do customers anticipate
• How it all flows
• In the current situation, what is the customer’s dire need and how the product can ably solve it

Sure, visualisation fires up the neurons and creates a concrete picture in mind, and it’s an engaging way of understanding things, but this is just a way to learn, and you can approach this based on your own learning style.

What’s important here is the realization that a product doesn’t exist in a silo, nor does the problem, and thus, we must have a deep understanding of the ever-changing influences that shape an ecosystem, and the customer’s never-changing quest for progress.

No technology is the center of a system, but rather a constellation of bodies under the influence of each other.
Stephen Sinofsky

A similar depth of understanding has informed how the Intercom team approaches the applications of their product.

At Chargebee, we aim to fit into the customer’s ecosystem by strengthening the billing features on one hand and on the other, with necessary partnerships and integrations.

Beginning this way, brings to the fore, things that matter most to our customers, every single time, and leads to deeper conversations with customers and teammates.

Lead-to-cash, as illustrated below – a not so eloquent example of enterprise parlance – has been a good way to visualize our place in the ecosystem.

Source: TM Forum

When businesses signup for Chargebee, they do that to resolve their subscription management troubles. As they grow, it’s our responsibility to anticipate what they’ll need. And seeking the bigger picture helps us do that.

For instance, an entrepreneur from Albuquerque wouldn’t have international expansion as a menacing problem when she’s just starting out.

But a year or so down the line, when she finds some repeatable processes to attain growth, she would want us to take care of everything (currencies, taxes, languages, reporting, accounting integrations, etc.) she needs to expand in the EU region.

Grasping the big picture helps. But it isn’t enough.

As we’ve seen, for folks who tackled the ENIGMA, from Rejewski to Turing to Welchman, the source of all their achievements was a grounding in a simple way of operating, a passion for breaking down problems, and taking them on, one at a time, with a lens of possibility.

That’s exactly where good Product Management should spring from.

He actually carried on very much as really most mathematicians and scientists do, which is loving the hands-on work, the correctness, the good judgements, and imagination, and not really developing great theories with the ultimate goal of impacting humanity.
Andrew Hodges, Author of Alan Turing: The Enigma

A few words about this series.

There’s little in common between great orchestra conductors, film directors, and product managers. Except for one thing that makes their professions almost inseparable.

The way their minds operate.

It isn’t hard to imagine that their teams (musicians, actors, and engineers, respectively) can perform without them. Still, in most cases, they don’t.

Whether it’s telling a story with notes in Musikverein, Vienna, or depicting a Samurai’s death with the right kind of rain, or scaling user experience for someone who is accessing an application for the 977th time, these men and women are worried about what goes within and without.

Constantly obsessed with articulating the vision of an ideal experience for the user, and also how a team can accomplish that without being seized by the currents of the status quo and deadlines.

Alexander Shelley, Akira Kurosawa, and Ken Norton, all perform in the same domains.

As a student of the Product Management discipline, I’ve learnt a lot from observing the works and thoughts of Sachin Rekhi, Ian McAllister, and many other fine product managers (including my mentors Patrick Phillip and Srinivasa Gokidi, who’ve spent years sharpening their Product Management rigour.)

This series is my little way of thanking them by translating lessons into words. It is also a way of documenting my ongoing journey, and hopefully serving someone who is just starting out, and is as clueless as I was, a few years ago.

Here’s what I intend to cover:

• How to think about, and plan features to address customer pain points
• How to use permutations and combinations to uncover hidden scenarios
• Simple documentation techniques to articulate use cases
• How to translate your understanding of user behavior into wireframes, and how to test your assumptions
• High level architecture planning and data modeling for understanding what will be supported now and how it can be scaled later
• How to build a continuous feedback loop that makes the product better equipped to contribute to customers’ progress