(If you have not yet watched the full series, beware: this writing is smart and full of spoilers)
I came very late to the Game of Thrones TV series. I only started watching in the penultimate season, then watched the series backward, episode by episode from season 7, episode 4 (I'd heard there was a battle involving dragons). My co-workers laughed at this unorthodox approach. "How can you understand what's going? It's so complex!' they told me. "It won't make any sense if you don't start at the beginning!" they warned. I ignored them and was hooked until the final scene of the final episode. And then I realized there were several takeaways I could apply to my work in innovation and software product development. Many of them hold true for all kinds of products.
Product managers and business leaders often start with a grand vision for an end product. It may be tempting to spend a long time building it and then expect some glorious transformation at the end, delivered with a big bang (like an epic battle for humanity or the fiery assault on a seat of power). But far more impact can be delivered by breaking the product down into a series of parts that deliver consistent value on their own while knitting them together as elements of the roadmap to a more comprehensive and complex ecosystem. This is the principle behind iterative development starting with a minimum viable (or, as I like to think of it, minimum valuable) product, or MVP.
Similarly, product teams benefit from the combination of different talents - analysis, design, engineering working together to shape product through multiple lenses. This doesn't mean it's easy. Often it's not, precisely because individual team members may be blinkered by their own biases which may create friction. But constructively working to harness these differences of perspective usually makes for a better product.
Product teams need to have a clear vision of what their product stands for. It's almost hackneyed these days to talk about 'the vision thing", but it still matters. Customers are not the only ones with a big why. You must also consider your company's big why. What is the North Star that will guide your product decisions and interactions with your customers? How will you communicate to your users what you stand for and why your product matters? How will you do so in a compelling way? Think about how your product will epitomize the values your user have come to expect (e.g. simplicity, security, fun, reliability) with each interaction.
Product teams have the opportunity to generate even more loyalty for their products, and to expand their user base, by involving both potential and long-term loyal users in the ongoing process of product development. The long acknowledged Ikea Effect holds that customers feel greater affinity for things they help create. Gathering and incorporating customer feedback also helps to build the trust and delight that make it more likely that users will become enthusiastic ambassadors for your product. Our client, Domino’s has seen the impact of this first-hand. An app that allowed their customers to design new menu items, promote them and share in the revenue and revolutionized their approach to customer engagement.
Sometimes product teams need to be equally ruthless. So often we see teams get wedded to a feature or design because it's so well done or took so much effort. But it doesn't matter if customers don't want it and won't use it. It doesn't matter if it's a solution in search of a problem. If the customer sees no perceived value in the feature, don't waste valuable time and effort on it.
How do you get users (and business teams and enterprise budget funders) to use and support ongoing development of your product? Use your MVP to help tell the story of the roadmap. While it is minimal, it should also help point users in the direction where it is going. It's not just about elaboration of features; it's about communicating the utility and possibilities that will be unleashed as the product evolves. Communicating this is as important as celebrating what is in place at the beginning.
Product teams can benefit greatly from small pilots with test audiences before taking new features to the broader customer/ user base. But only if they are done well. This means that the purpose must be clear, the expected learnings must be well defined and properly tracked, and the criteria for success must be understood and agreed. And of course, the team has to learn from the pilot and apply the lessons going forward.
The complacency of incumbency is one of the greatest threats to product teams. This is why the practice of ongoing user research and user feedback is so critical. We often see teams become so hyper-focused on individual features or incremental improvements that they lose sight of the big picture. Product leaders must have a multi-pronged approach to the collection of user feedback. While there is always room for user research and prototyping around existing and adjacent functionality, set aside adequate time and resources for pure discovery and exploration of emerging white space. And just as importantly, structure your team, and ensure your organization is aligned, to be able to pivot and respond when these explorations indicate a change in direction is warranted.
Indeed, product teams succeed on the power of story, writ both large and small. Writ small, user stories that developer use are better when they are less focused on what a specific feature is, and more focused on what it is intended to accomplish. How will it add value to a user? Why does it matter? This helps developers build empathy for the user and use their creativity to actually make a difference to them, rather than being constrained by directions on specifically how it should be done. Writ large, a compelling product story stirs the imagination of users and opens them to possibilities of how their lives may change for the better. Ultimately this leads to the type of product that brings shared value, both to the customers and the company that serves them.
I came very late to the Game of Thrones TV series. I only started watching in the penultimate season, then watched the series backward, episode by episode from season 7, episode 4 (I'd heard there was a battle involving dragons). My co-workers laughed at this unorthodox approach. "How can you understand what's going? It's so complex!' they told me. "It won't make any sense if you don't start at the beginning!" they warned. I ignored them and was hooked until the final scene of the final episode. And then I realized there were several takeaways I could apply to my work in innovation and software product development. Many of them hold true for all kinds of products.
Even complex, sophisticated ecosystems can be broken into small digestible components.
Yes, the series is sprawling and complex. Yes, there were multiple tangled relationships and many deaths, marriages, and betrayals to unravel, but each of the primary characters had a well-defined journey and fascinating path of their own that could be unpicked and followed like a golden thread. And even without full context, each episode on its own was enthralling and entertaining, with elements that captured the imagination.Product managers and business leaders often start with a grand vision for an end product. It may be tempting to spend a long time building it and then expect some glorious transformation at the end, delivered with a big bang (like an epic battle for humanity or the fiery assault on a seat of power). But far more impact can be delivered by breaking the product down into a series of parts that deliver consistent value on their own while knitting them together as elements of the roadmap to a more comprehensive and complex ecosystem. This is the principle behind iterative development starting with a minimum viable (or, as I like to think of it, minimum valuable) product, or MVP.
Start with the big why.
“Sometimes when I try to understand a person’s motives, I play a little game. I assume the worst. What’s the worst reason they could possibly have for saying what they say and doing what they do?” (Littlefinger, Lord Baelish). Littlefinger is on to something here. Wars are perpetually being fought. Weird alliances are made and it seems that almost everyone who is anyone in Westeros has pretensions to the Iron Throne. But they fight and kill for many different reasons: honor, love, freedom, fear, power, family.
What motivates your users? Like the various denizens of the seven kingdoms, users are trying to solve something when they come into contact with your product. It's not just enough to watch what they do, but to understand the context in which they do it and to understand why they do what they do. Your challenge as a product team is to get to the why of what customers are doing. Only when you begin to tackle the broader question of what users are trying to accomplish in their lives, which will help to drive a better product, not just incremental feature improvements.Cross-functional teams work... but that doesn't mean it’s easy.
The realms of men were able to defeat the army of the dead because different communities formed a team with complementary skills: wildlings and Northmen who understand the challenges of fighting in winter, the fierce Dothraki with their exceptional horsemanship and the highly disciplined Unsullied warriors, with their unfailing loyalty to their liberator, Daenarys.Similarly, product teams benefit from the combination of different talents - analysis, design, engineering working together to shape product through multiple lenses. This doesn't mean it's easy. Often it's not, precisely because individual team members may be blinkered by their own biases which may create friction. But constructively working to harness these differences of perspective usually makes for a better product.
Be true to your brand values.
"You stand in the presence of Daenarys Stormborn of House Targaryan... Queen of the Andals and the First Men... the Mother of Dragons.. the Khaleesi of the Great Grass Sea, the Unburnt, the Breaker of Chains" (Missandei of Naath). Every house in Westeros has its own sigil and motto that defines who they are: The Starks' motto is "Winter is Coming". The "iron born" Greyjoys live by the words "We do not sow" (no, they pillage and steal). Even the free folk have a defined set of brand values, though they have no lordly house: "We do not kneel" (to any lord or lady).Product teams need to have a clear vision of what their product stands for. It's almost hackneyed these days to talk about 'the vision thing", but it still matters. Customers are not the only ones with a big why. You must also consider your company's big why. What is the North Star that will guide your product decisions and interactions with your customers? How will you communicate to your users what you stand for and why your product matters? How will you do so in a compelling way? Think about how your product will epitomize the values your user have come to expect (e.g. simplicity, security, fun, reliability) with each interaction.
Let your fans co-create the product and tell your story.
Queen Daenarys calls herself the Breaker of Chains. But more importantly, so do her loyal followers. After she frees the Unsullied army she bought from a slaver, she sends them out as envoys to other communities of captives throughout Slavers’ Bay. They tell the story of the Breaker of Chains and persuade other slaves to take up the fight, creating the conditions for their liberation.Product teams have the opportunity to generate even more loyalty for their products, and to expand their user base, by involving both potential and long-term loyal users in the ongoing process of product development. The long acknowledged Ikea Effect holds that customers feel greater affinity for things they help create. Gathering and incorporating customer feedback also helps to build the trust and delight that make it more likely that users will become enthusiastic ambassadors for your product. Our client, Domino’s has seen the impact of this first-hand. An app that allowed their customers to design new menu items, promote them and share in the revenue and revolutionized their approach to customer engagement.
Don't be afraid to eliminate elegant features if they don't meet the user’s needs.
Poor Randall and Dickon Tarly. They were both elegant, accomplished fighters, with a sense of honor, fine sword-fighting skills and a competent party behind them. But they refused to bend a knee to Daenarys so they became just another pair of dragon crisps. They did not serve her purposes, so she eliminated them.Sometimes product teams need to be equally ruthless. So often we see teams get wedded to a feature or design because it's so well done or took so much effort. But it doesn't matter if customers don't want it and won't use it. It doesn't matter if it's a solution in search of a problem. If the customer sees no perceived value in the feature, don't waste valuable time and effort on it.
Use your MVP to share the vision of your product's potential.
How do you convince your enemies to form an alliance in the battle against the army of the dead? You capture a zombie soldier and lay it at their feet.How do you get users (and business teams and enterprise budget funders) to use and support ongoing development of your product? Use your MVP to help tell the story of the roadmap. While it is minimal, it should also help point users in the direction where it is going. It's not just about elaboration of features; it's about communicating the utility and possibilities that will be unleashed as the product evolves. Communicating this is as important as celebrating what is in place at the beginning.
Good pilots shape the future.
In a spectacular moment of triumph, young Arya killed the Night King, shattered his army of the dead and saved the realms of men, just when all seemed lost... thanks to her deft ambidextrous knife work. But those who were paying attention had seen that exact maneuver before, when she was sparring in the Winterfell courtyard with Brienne of Tarth.Product teams can benefit greatly from small pilots with test audiences before taking new features to the broader customer/ user base. But only if they are done well. This means that the purpose must be clear, the expected learnings must be well defined and properly tracked, and the criteria for success must be understood and agreed. And of course, the team has to learn from the pilot and apply the lessons going forward.
Those who fail to adapt, fail to survive.
“The Red Keep has never fallen. It will not fall today.” (Cersei Lannister). Cersei relied on her historical strengths to protect her, even as the world around her was literally crumbling. She refused to see the reality that strategies and defenses of incumbency which had worked in the past were defenseless against a new threat with innovative new technology (dragonfire).The complacency of incumbency is one of the greatest threats to product teams. This is why the practice of ongoing user research and user feedback is so critical. We often see teams become so hyper-focused on individual features or incremental improvements that they lose sight of the big picture. Product leaders must have a multi-pronged approach to the collection of user feedback. While there is always room for user research and prototyping around existing and adjacent functionality, set aside adequate time and resources for pure discovery and exploration of emerging white space. And just as importantly, structure your team, and ensure your organization is aligned, to be able to pivot and respond when these explorations indicate a change in direction is warranted.
Embrace the power of stories.
"In the end, there's nothing more powerful than a good story." (Tyrion Lannister). After decades of war and death the person who takes the throne, by acclamation of the lords and ladies of Westeros is not the one who was most successful in battle or the most ambitious, but the quiet, "broken" keeper of the realms' history and stories.Indeed, product teams succeed on the power of story, writ both large and small. Writ small, user stories that developer use are better when they are less focused on what a specific feature is, and more focused on what it is intended to accomplish. How will it add value to a user? Why does it matter? This helps developers build empathy for the user and use their creativity to actually make a difference to them, rather than being constrained by directions on specifically how it should be done. Writ large, a compelling product story stirs the imagination of users and opens them to possibilities of how their lives may change for the better. Ultimately this leads to the type of product that brings shared value, both to the customers and the company that serves them.
