≡ Menu
Transformation is a multi-dimensional journey. We start with our current way of working, discover ways to adopt the practices, and then executing in the new way

A lot of my work involves guiding large organizations through significant change. As part of that work, I’ve developed a list of 10 questions leaders should ask when they are considering asking their teams to adopt something new. After sharing this with a few people they wanted to see it posted publicly to be able to reference, so here it is!

Before I get to the list, there’s a couple of key principles that guides this. First, as I first learned from Alan Chedalawada and Al Shalloway, transformation is a multi-dimensional journey. In the book Managing Transitions, Bridges talks about how people don’t just go from the Old Way to the New Way – in between is a dangerous Neutral Zone that requires significant vision and leadership to get through:

Transformation is a multi-dimensional journey. We start with our current way of working, discover ways to adopt the practices, and then executing in the new way

On top of that, we bring in the concepts that people have to have time to grow into new ideas. It starts with the introduction of the idea, then initial implementation, then execution, then sustainability and flexibility. When it is first introduced they will need clear guidance and direction – including rules of use – to help them. As they move towards operation, they will rely less on the rules and more on intuition. As it matures to sustainability, they will be able to not only intuit the actions, but flexibly respond to changes.

Below is a starting list of questions you should ask for any change initiative. Remember that people are looking to you for guidance, leadership and clarity, so your job is to continually guide them on the path with the right messaging and direction.

Question Notes
What is the change? Self-explanatory, but you should be able to clearly articulate the change in a short sentence.
Who is responsible for leading the change? Self-explanatory as well, but important to articulate who is the actual responsible leader for this change.
What does success look like? This is perhaps the most critical line to define. If we can’t objectively define what success looks like, then the teams and managers will likely not be able to understand or measure success, leading to frustration
Who is impacted? (Primary, Secondary, Tertiary) Nearly every change will impact people beyond the initial group. At a minimum it will impact their managers, staff or peers. Think about these groups as you fill out the other questions as secondary and tertiary groups may require similar change management
What new behaviors do we expect? Similar to defining success, we should be able to articulate the behaviors we want to introduce or stop. These may not always be directly on the team or people themselves – for example, changing a way of reporting may mean other groups stop emailing the CTO directly.
What behaviors do we expect to stop?
What performance management impacts are there? (How do people know they’re successful? How do their managers know they’re successful?) This is especially applicable to role changes. Are we expecting people to take on new roles or responsibilities? How would that be reviewed and monitored?
Who needs to be trained? What do they need training on? Self-explanatory, but may be far reaching. For example, a new role may interact with groups in a new way, so those groups will need (even informal) training and communications of what to expect.
What is the timeline for implementation?

  • Comms plan
  • Trainings
  • Start of new process
  • Cadence for check ins (recommend 2-3 within first 6-12 weeks)
It’s worth taking a little bit of time to map out a timeline. People need enough time to process the change and be trained. In addition, for certain experimental changes you may want a cadence for getting feedback on how the process is going and whether to adjust the roll out.

Make sure this timeline and plan is available to the people impacted by the change whenever possible.

What does the Maturation framework look like?

  • Infrequent to Frequent
  • Ad-Hoc/Informal/Heavyweight to Structured / Formal / Lightweight
  • Inflexible / Incapable to Flexible / Capable
  • Inconsistent / Early Adoption to Consistent / Maturing
From an operating perspective, people are initially going to be just starting with this process, using inflexible methods of implementation (e.g. rules-based) and will likely have to explicitly think about it in order to implement the change.

As they mature in adoption it will become more intuitive and resilient to variances.

As a leader it’s worth thinking about how we can measure and guide people through this process to make sure they’re appropriately heading down the right path. We can’t assume we can tell someone something once (even if we write a doc) and they will get it. What checkpoints will we need? What types of behaviors do we expect 4 weeks in? 8 weeks in? 16 weeks in? Will we need additional training or examples?

If you have any questions or you or your organization are looking for ways to be more effective, don’t hesitate to reach out today for a 30 minute call that could change the impact of your entire organization.

{ 0 comments }

Happy Mapping Monday! Today’s #mappingmondays video shows the next part of the series of how we can use Wardley Mapping for identifying value and target markets as part of April Dunford’s Product Positioning Framework from the book Obviously Awesome. If you’re interested in finding out how to apply this to your organization, don’t hesitate to reach out via Twitter or email hello at coryfoy dot com!

Links:

Transcript:

Happy Monday! I’m Cory Foy, and welcome to Mapping Mondays! This week’s video continues a several week series on mapping strategic advantage by combining Wardley Maps and April Dunford’s Product Positioning framework from the book Obviously Awesome to show how we can map out Unique Attributes of our product.

Last week, I presented a value chain map for a company that provides a bug tracking tool. The first step in Dunford’s framework is listing competitive alternatives – what your customer would do if they didn’t have your product. We compared it to a shared online spreadsheet, showing how we could think about competitive alternatives by considering what happens when components were in different stages.

What didn’t change was the components between the two options. That’s partly because we approached it from a high level view – for example, “Data Store” meant an actual database for our application but the spreadsheet itself for the alternative.

But for this next step in the product positioning steps, we want to dive deeper and look at Unique Attributes. These are capabilities or features that our offering has that the competitive alternatives do not. And one of the best ways to do that is visualizing it on a graph!

Let’s look at that value chain map again, but focus on the core proposition of a bug tracking app – tracking bugs! What we want to add to this graph is what makes us unique. Of course, we don’t know what makes us unique until we’re compared to our alternative, so let’s start with adding in how we accomplish these things – what we think makes us unique.

For example, to collect Bug Information, we have a standard Bug Entry Form. We also have an API that people can use to create bugs in the system. Finally, we have integrations with several market leading tools to create bug tracking items in our system when those source systems detect errors.

For timing information, users can manually update the fields in the system, or we can automatically update them when certain actions happen, either in our system or through our integrations.

Bug Status can likewise be manually updated. Or we have integrations with source control providers that allow us to update the status based on the acceptance of a Pull Request, or even a Pull Request with successful passing tests.

Taken together this starts to paint a broader picture of how we stack up against a simple spreadsheet. But let’s actually look at our unique attributes by doing this exercise with our competitive alternative.

With a spreadsheet, we capture bug information by filling out columns. Most online spreadsheets have an API you can also use to write to cells, so that’s an option.

Timing information can also be updated manually or in an automated fashion using formula triggers.

Finally, Bug Status can of course be manually updated by changing a column, or via an API.

If we overlay these, we start to get a picture of our unique attributes.

Clearly our application integrations win out here – whether it’s creating bugs, updating timing information, or being able to update bugs based on code changes. But does this seem right? Certainly we have stronger unique attributes in the other areas, right?

And, in fact, we do. Dunford says that the unique attributes are often technical features, but can also be things like your delivery model, business model, or specific expertise. And I’d add one more – your evolution of components.

Let’s go back and turn the value chain map of our system into a Wardley Map. We can see that many attributes of it – even the API – are products. This means customers can build components on top of our API because it’s providing an interface into the key steps into our system.

Now, let’s look at the Spreadsheet. Here we can see that, while it does have an API, you’re going to be manipulating cells, not managing bugs. This means that the API is really more in the Genesis / Custom Build edge – in order to make it useful you’re going to have to build your own abstractions on top of it.

Combining these we can see that an additional unique attribute we have is one of maturity – we have a more evolved view of the market and needs for our customer’s needs. And they can build custom integrations more easily when they do need to do that.

So when you’re working to determine your unique attributes, being able to compare value chain graphs can produce some key insights, but mapping those components can expose additional unique attributes that go beyond your features to your approaches and advances.

Hope you’ve enjoyed this video! As a reminder I offer free consulting sessions if you want to get started in mapping, and work with organizations across the globe helping them understand and improve their processes and strategies. If you’d like to set up a call, don’t hesitate to reach out on Twitter at @Cory_foy or via email at hello at coryfoy dot com. Until next week, may you find and celebrate those attributes that make you unique!










{ 0 comments }

Wardley Mapping Mondays – Unique Attributes

Happy Mapping Monday! Today’s #mappingmondays video shows the next part of the series of how we can use Wardley Mapping to map out unique attributes as part of April Dunford’s Product Positioning Framework from the book Obviously Awesome. If you’re interested in finding out how to apply this to your organization, don’t hesitate to reach out via Twitter or email hello at coryfoy dot com!

Links:

Transcript:

Happy Monday! I’m Cory Foy, and welcome to Mapping Mondays! This week’s video continues a several week series on mapping strategic advantage by combining Wardley Maps and April Dunford’s Product Positioning framework from the book Obviously Awesome to show how we can map out Unique Attributes of our product.

Last week, I presented a value chain map for a company that provides a bug tracking tool. The first step in Dunford’s framework is listing competitive alternatives – what your customer would do if they didn’t have your product. We compared it to a shared online spreadsheet, showing how we could think about competitive alternatives by considering what happens when components were in different stages.

What didn’t change was the components between the two options. That’s partly because we approached it from a high level view – for example, “Data Store” meant an actual database for our application but the spreadsheet itself for the alternative.

But for this next step in the product positioning steps, we want to dive deeper and look at Unique Attributes. These are capabilities or features that our offering has that the competitive alternatives do not. And one of the best ways to do that is visualizing it on a graph!

Let’s look at that value chain map again, but focus on the core proposition of a bug tracking app – tracking bugs! What we want to add to this graph is what makes us unique. Of course, we don’t know what makes us unique until we’re compared to our alternative, so let’s start with adding in how we accomplish these things – what we think makes us unique.

For example, to collect Bug Information, we have a standard Bug Entry Form. We also have an API that people can use to create bugs in the system. Finally, we have integrations with several market leading tools to create bug tracking items in our system when those source systems detect errors.

For timing information, users can manually update the fields in the system, or we can automatically update them when certain actions happen, either in our system or through our integrations.

Bug Status can likewise be manually updated. Or we have integrations with source control providers that allow us to update the status based on the acceptance of a Pull Request, or even a Pull Request with successful passing tests.

Taken together this starts to paint a broader picture of how we stack up against a simple spreadsheet. But let’s actually look at our unique attributes by doing this exercise with our competitive alternative.

With a spreadsheet, we capture bug information by filling out columns. Most online spreadsheets have an API you can also use to write to cells, so that’s an option.

Timing information can also be updated manually or in an automated fashion using formula triggers.

Finally, Bug Status can of course be manually updated by changing a column, or via an API.

If we overlay these, we start to get a picture of our unique attributes.

Clearly our application integrations win out here – whether it’s creating bugs, updating timing information, or being able to update bugs based on code changes. But does this seem right? Certainly we have stronger unique attributes in the other areas, right?

And, in fact, we do. Dunford says that the unique attributes are often technical features, but can also be things like your delivery model, business model, or specific expertise. And I’d add one more – your evolution of components.

Let’s go back and turn the value chain map of our system into a Wardley Map. We can see that many attributes of it – even the API – are products. This means customers can build components on top of our API because it’s providing an interface into the key steps into our system.

Now, let’s look at the Spreadsheet. Here we can see that, while it does have an API, you’re going to be manipulating cells, not managing bugs. This means that the API is really more in the Genesis / Custom Build edge – in order to make it useful you’re going to have to build your own abstractions on top of it.

Combining these we can see that an additional unique attribute we have is one of maturity – we have a more evolved view of the market and needs for our customer’s needs. And they can build custom integrations more easily when they do need to do that.

So when you’re working to determine your unique attributes, being able to compare value chain graphs can produce some key insights, but mapping those components can expose additional unique attributes that go beyond your features to your approaches and advances.

Hope you’ve enjoyed this video! As a reminder I offer free consulting sessions if you want to get started in mapping, and work with organizations across the globe helping them understand and improve their processes and strategies. If you’d like to set up a call, don’t hesitate to reach out on Twitter at @Cory_foy or via email at hello at coryfoy dot com. Until next week, may you find and celebrate those attributes that make you unique!










{ 0 comments }

Wardley Mapping Mondays – Competitive Alternatives

Happy Mapping Monday! Today’s #mappingmondays video goes back to the basics with a tutorial for creating your first map. If you’re interested in finding out how to apply this to your organization, don’t hesitate to reach out via Twitter or email hello at coryfoy dot com!

Links:

Transcript:

Happy Monday! I’m Cory Foy, and this week’s video starts a couple week series on using maps to evaluate strategic advantage. Recently I’ve been reading the book Obviously Awesome by April Dunford, who lists out five + one components of effective Product Positioning: Competitive Alternatives, Unique Attributes, Value (and proof), Target Market Characteristics, Market Category, Relevant Trends. While some of these are focused on more traditional market research, there’s a lot we can use Wardley Maps for to help us dig in. Let’s start with competitive alternatives. Dunford defines this as what our target customers would use or do if our product didn’t exist. What’s great about that is this definition lends itself very well to Value Chain Maps.

Let’s imagine we’re a software company that provides a bug tracking tool. So we start with a user need of tracking work for a software team. Looking at the components we need to do that, we have users, bug information, timing information, and bug status. These rely on a data store, which is also a dependency of reporting. We also have the notion of remote access and an implied security model. We may also have assignment of bugs to users. If we map these components, several end up in the Product or Utility stage. What Dunford asks us to do is think about how else customers would solve this problem without our product. And one interesting way to do that is to think about the solutions if those components were in Genesis / Custom Built.

In that context, we still have users, bug information, timing information and bug status, relying on a data store, with reporting and assignment. But instead of our tool, customers use a shared spreadsheet. Especially with something like integrated Google Apps, you get users and security (from the company’s domain users), Bug Information (a column), timing information (also a column, though maybe with a formula auto-updating), bug status (a column with fixed choices), remote access (it’s a Google Doc) and even assignment (a column). The primary weakness would be in reporting.

Comparing the maps, we can put some cost / timing estimates on here. For example, setting up users is free for the Google Docs case, but will require work in our application, unless we integrate as a Single-Sign on Provider. Typically bug tracking tools require setting up projects, bug definitions, and user access, all which take time. Worse, the cost of change for a bug definition might be higher in our application if we have to deal with ensuring historical data doesn’t change.

So, we have some challenges. As Dunford says in her book “but if the real alternative in the mind of a customer is Excel, you can’t say your product is easier to use unless it is easier to use than a spreadsheet.” By mapping out the user needs and thinking about de-evolution we were able to map some alternatives we don’t traditionally think about, which means we have to think carefully about what differentiates us as well our positioning. We’ll spend some more time on that next week when we talk about unique attributes.

Hope you found this week’s video useful! If you’re trying to figure out the best way to get started with mapping or applying strategic thinking with maps, don’t hesitate to reach out on Twitter at @cory_foy or via email at hello at Cory Foy dot com. And I’ve included a link to Dunford’s book in the blog post for this video. Until next week, happy mapping!









{ 0 comments }

Wardley Mapping Mondays – Your First Map

Happy Mapping Monday! Today’s #mappingmondays video goes back to the basics with a tutorial for creating your first map. If you’re interested in finding out how to apply this to your organization, don’t hesitate to reach out via Twitter or email hello at coryfoy dot com!

Links:

Transcript:

Happy Monday! I’m Cory Foy, and welcome to another Mapping Mondays video! In this week’s video I want to go back to some basics of Wardley Mapping and help you create your first map.

Wardley Mapping is, at its core, a way of understanding the landscape of components necessarily to deliver one or more user needs. So, we’ll start by asking a simple question – who are your users? And can you identify one need a user has that they come to you for? Take a piece of paper and write that need at the top, circling it. Here we’ll use the example of eating a sandwich.

With a user need identified, we now need to understand the components necessary to service that need. For each component, write it somewhere below the user need, circle it, and connect it to the user need. For our sandwich, we’ll need bread, cheese, protein, vegetables, and condiments. These are our high level components.

Next, what components do we need to service these high level components. For bread, we’ll need flour, for cheese we’ll need milk, for protein we need either a meat or, say peanut butter, vegetables we could have tomatoes and lettuce, and condiments we could have mayonnaise and mustard.

We may need to do this loop a couple of times to get our components – the goal here isn’t necessarily to capture every permutation or level, but to drive out to interesting insights, which is where the art of this comes in. For example, we’ll show that for flour we make it ourselves, so we need wheat and a flour mill.

Once we have our components and the interconnections we’ve drawn what’s known as a value chain. This allows us to have a picture of what’s necessary to deliver that user value. It’s not a map yet, but we’re close!

To make it a map, we have to add one more piece – movement. Simon Wardley defines four stages of component evolution in his maps. In Genesis it’s all brand new, from scratch. Custom Built has enough knowledge to be able to be assembled, but we have to do it every time. Product means it’s something we can purchase, and a utility means we can treat it like electricity – it’s something we can just get, without thinking about it.

So we need to take our components and map them to the stages. When we map this out, we notice that a majority of our components are products, but bread is something we custom build using genesis components. The underlying assumption is that components will evolve through these stages as they become more widely adopted. So bread will eventually mature to be a product we purchase based on this simple view. In that case, the investments we have in things like the flour mill will become less valuable, so we can think about how we transition as an organization to handle a new reality of bread as a product.

The other thing we can look at is other components that lead to new business opportunities. For example, someone has to order a sandwich – even in their own head – and the sandwich has to be assembled. If we do it ourselves, we may buy the components, but we still custom build the sandwich. That could also move towards productization, creating new markets for suppliers for the ingredients for the sandwich, and possibly even moving towards sandwich as a service – I either order a sandwich and it comes, or I subscribe to sandwiches and every day a new one shows up.

But now you have your first Wardley Map! From here, you want to map more of your user needs, and ask questions about the landscape that gets generated. And as you ask more questions, there are a wealth of resources available to help. Simon has a wonderful blog and a book in progress. There’s a great forum, Wiki and Slack Channel, and Ben Mosior has LearnWardleyMapping.com. And, of course, I’m always happy to jump on a call and help you create your maps, or ask questions about your organization. Just reach out on Twitter at @Cory_foy or via email at hello at Cory Foy dot com. All of these links are also on the blog post for this video.

Until next week, have fun with your new maps!










{ 0 comments }

Wardley Mapping Mondays – Doctrine

Happy Mapping Monday! Today’s #mappingmondays video dives deeper into the four phases of Doctrine and how you can think about them playing together in your organization at each phase. If you’re interested in finding out how to apply this to your organization, don’t hesitate to reach out via Twitter or email hello at coryfoy dot com!

Links:

  • Doctrine Patterns
  • Doctrine is not a checklist to follow
  • Wardley’s Doctrine
  • Transcript:

    Happy Monday! I’m Cory Foy, and welcome to this week’s Mapping Mondays video! So far in this series we’ve talked a lot about mapping as a mechanism for understanding your landscape and discovering where you can make plays and, and have even talked about some of the different types of plays you can make.

    However, the capability to make a play is dependent on several factors. The first is the context and landscape – you’re likely not going to have a good play with a first mover advantage if you’re competing in a utilitized component space. But once you’ve understood the types of gameplays that are contextually relevant, we still need the doctrine to be able to execute them.

    Simon Wardley defines Doctrine as universally useful patterns that can be applied regardless of context. I like to think of it as the operating model for your organization. In this chart, we can see the doctrine based on varying categories – Communication, Development, Learning, etc.

    As part of this chart, Simon suggests coloring in that doctrine based on your assessment of it within your organization. Naturally we are all going to have weak areas, so Simon provides a second view of the doctrine based on varying phases. Let’s take a closer look at these phases.

    In Phase 1 we’re establishing our base operating model. We need to know our users so we can focus on user needs. We need to use a systematic method of learning so we have the data to challenge assumptions as well as being able to focus on high situational awareness. We need to use a common language so we can remove bias and duplication. And we need to use the appropriate methods, thinking small – knowing the details about what we’re doing and why we’re doing it.

    In Phase 2 we’re establish our capabilities of making gameplays. We know that strategy is iterative, not linear, so we need to manage inertia and bias towards action, moving fast and thinking about small teams operating with FIRE – fast, inexpensive, restrained and elegant. To do this we’re going to need to value effectiveness over efficiency, distributing power and decision making, knowing that it’s not just the aptitude of the teams – but their attitudes towards focusing on the outcomes. We need to be pragmatic, using standards where appropriate, and using the appropriate tools. But ultimately we need to be transparent about our goals, operating methods and direction, as well as manage failure – because when we’re iterating and moving fast, that’s going to happen.

    In Phase 3 we’re raising the bar for our teams. From a leadership perspective, we’re committing to directions but being adaptive along the path. We understand strategy is complex, so we think big, being curious and taking appropriate risks to bias towards the new. We need to seek the best we can find, but also be humble – listening to needs, being selfless and standing up for the direction. Leaders need to be the owner of the direction and strategy, setting exceptional standards, but also providing teams with purpose, mastery and autonomy. We’re still looking at the FIRE methods, and we want to continue to do better with less. Part of that is using the data we’ve been gathering to understand how to optimize our flow with Lean Thinking.

    Finally, in Phase 4 we’re firing on all cylinders. We’re designing for constant evolution, understanding that there is no core, because everything is evolving, everything is transient. We’re able to not only use appropriate methods, but shift into appropriate cultures – exploring the landscape like Pioneers, establishing footholds in the market like Settlers, and scaling and operationalizing components like Town Planners. We’re listening to our ecosystems, not just visualizing our landscape, but actively understanding how we can exploit the weaknesses of the markets and our competitors.

    So as you look at your landscape and gameplays, think about the doctrine that needs to be in place to be successful at making that play. And when you identify weaknesses, focus on improving them. This improvement is a key part of the assessment and maturity models I’ve worked with clients across the globe to implement, and I’m always happy to share more information about Doctrine and other assessment models if you find them useful.

    If you do want more information, feel free to reach out on Twitter at @cory_foy or via email at hello at Cory Foy dot com. And as always, thanks for watching and be sure to check out all the Mapping Mondays videos on my site!

    Until next week, Happy Mapping!










{ 0 comments }

One of the goals of agility is to be able to respond rapidly to market change. But do you feel prepared to wake up to a product announcement from Amazon disrupting your entire business? Would you know what steps to take?

Instead of being worried, we can get mapping! Wardley Mapping, coined by Simon Wardley, is a way of understanding markets and components in a way that allows us to visualize and anticipate change in markets – and develop strategies and gameplays for how we can respond to them.

In November 2019, I gave the inaugural version of this talk using real-world cases of work with organizations to map their landscape and show the strategies that allowed them to reshape their future at Lean Agile Kansas City. You can find both the video and slides below.

If you’re interested in learning more about Wardley Mapping, or how to apply it to your organization, don’t hesitate to reach out at hello at coryfoy dot com, or on Twitter at @cory_foy. And be sure to check out my Mapping Mondays series as well as the recommended links just below the video.

Thanks again to the whole crew of Lean Agile KC for having me out!

Note 11/9/2019: The audio on the video has been fixed! Enjoy!

Links:










{ 0 comments }

Wardley Mapping Mondays – Making A Play

Happy Mapping Monday! Today’s #mappingmondays video is a joy to hear – because we look at how you can make a gameplay with Voice First! If you’re interested in finding out how to apply this to your organization, don’t hesitate to reach out via Twitter or email hello at coryfoy dot com!

Transcript:
Happy Monday, and welcome to another Mapping Mondays video! Wouldn’t it be amazing if instead of just listening to me here and asking questions on Twitter you could just ask a question during the video and I could respond? Or you could make comments about things as you watched and get a summary of points about the video you responded to at the end?

This level of interactivity is part of the goal of the Voice First movement. People like Brian Roemmele are at the forefront pushing the boundaries of what is possible with devices like Alexa, Siri and more. It’s easy for us to sit back and take in the fruits of this work, but what if we wanted to join in. Could we understand what Voice First could impact, and what gameplays we could make in it?

First, we need to start off by defining what we mean by Voice First. Let’s start with a simple user need of “interacting with things using our voice” and look at the resulting value chain. The state of the technology right now is that we can custom build apps which can be leveraged as part of products such as Alexa and Siri. This is good, because it means the landscape is such that we can start building things on top of the ecosystem, rather than trying to build the ecosystem itself.

Next, what about evolution? We’re probably going to have the most rapid success where we can take small leaps. Typically the smallest leap is when something has an API already and we’re changing the entry and interaction methods. Much harder are those things which don’t have an API or entry methods, so we’ll try to stay away from those for now.

Now on to our real starting point – user needs. What things do people do every day that also interacts with an API? Let’s look at some user needs which are done online:

Buying Things, Setting Calendars, Paying Bills, Ordering Food, Calling People, Scheduling that long needed Vacation or some appointments we need to take, Playing some Games, Looking Up Information (use that all the time!), Interacting with our IoT devices like Lights or our music . Speaking of music – Playing Music and Learning Subjects.

We have many possibilities of interactions that could be transformed with Voice First. If we map out the value chains for these, we start to see some commonalities. Some of these are one-off events – Setting a calendar entry or changing lights. We probably don’t have much of a gameplay there because creating a fire-and-forget voice call to an API is pretty commoditized. But others require interaction. Some of that interaction is human-based, which is going to be highly genesis if it’s even possible. But others have interactions which can be automated.

As an example, paying bills is something which requires multiple steps between several systems. Payment information is needed, and sometimes it may come out of different accounts. We also have to set up the bill itself to be paid, so the bill’s account information will need to be stored and automated. Finally, the specific way we pay the bill is going to differ from site to site.

To succeed, we ultimately want a commoditized interface capable of interacting with disparate systems underneath it. We want people to be able to say “Siri, pay my car loan” and “Siri, pay my electric bill” without having to navigate the complexities and specifics of each type of bill. We built a system like this for scheduling inspections back in 2004 which allowed users to interact with a single form and schedule inspections across multiple jurisdictions with wildly different websites.

Now, from a doctrine perspective, we don’t want to necessarily start with a commoditized interface. We want to build iteratively towards this commoditization, recognizing that our strategic advantage will be a system that can map other systems into our schema.

Note that, other than layering the voice-response as a market mover, this is pretty traditional strategy. We’re looking for openings of painful things from our users and moving to make that pain go away. But the evolution of voice-first commoditization as a product means that we also have a first mover advantage with a market differentiator and can leverage parts of the ecosystem such as trusted payment stores.

Finally, if we’ve done a good job separating concerns in our systems, using voice instead of text entries becomes much easier since we’re treating it as a secondary input mechanism. The primary advantage we’re getting is being first to market with a unique offering – but if we don’t have a good product solving needs underneath it, then once others join in the fray we’re going to have a tough time defending our position.

So when you’re trying to understand the impact of a new technology, start with the value chain necessary to leverage that technology. Then look for ways that existing systems parallel integrate into that value chain and take advantage of building integrations which allow for the new technology to be integrated into a good business model. Or, if those integrations don’t exist, find ways to build Those integrations and provide those as a service to the market.

Hope you’ve enjoyed this video! If you’re interested in learning more about applying mapping and strategy within your organization feel free to reach out on Twitter at @cory_foy or via email at hello at coryfoy dot com. And be sure to check out all of the Mapping Monday blog posts on my site. Have a wonderful week!










{ 0 comments }

Mapping Mondays – Landscape and Climate

Happy Mapping Monday! Today’s #mappingmondays video goes a level up from mapping to look at the strategy cycle, including Doctrine, Landscape and Climate – with a touch of Doctor Strange. As always, a full transcript is included below the video. And If you’re interested in finding out how to apply this to your organization, don’t hesitate to reach out via Twitter or email hello at coryfoy dot com!

Links:

Transcript:
Happy Monday! Welcome to another Mapping Mondays video. I’m Cory Foy, and in today’s video I want to step up a level from maps themselves and talk about how they fit into the broader environment of strategy and operations.

Some years ago I took a class called 30×500, run by Amy Hoy. In it, she talks about the notion of “Idea Quicksand” and how trying to focus on having a great idea locks you into the notion that ideas – how we win – come from inside you. That they are magical and powerful. And this puts you at the mercy of magical and powerful forces.

But we don’t want to be at the mercy of magical forces! Unfortunately, we let ourselves flail around because of them. That’s because we come up with our Purpose as a company – our great thing! – and then we try to lead everyone to succeed in that mission.

However, Simon Wardley talks about a broader cycle – and one that breaks this notion. Instead of Purpose -> Leadership, we instead look at our Landscape, the Climate, and our own Doctrine, and use those to determine the game plays and actions we’ll lead with.

In the movie “Doctor Strange”, our lead character is asked for his advice on a patient who has been shot. The other surgeons know their purpose is saving lives, and based on their ideas this patient can’t be saved, but his organs can help others.

However, Dr. Strange steps back. He looks at the Landscape – the patient has been shot, but didn’t immediately die. The bullet itself is still in perfect shape causing minimal damage. But yet the patient is dying. He then looks at the Climate – what external forces would impact what is going on? In this case, the bullet has lead, and that is leaching directly into the body, causing a toxic reaction. But! This is a reaction that can be reversed – if the bullet can be removed. He then looks at the Doctrine – they have the skills, equipment and support to be able to attempt the surgery. He then Leads everyone through this – helping the other doctors rapidly connect the dots about what is going on, and getting them onboard with the action. In the end, they are able to save the patient (even if Dr. Strange decides to go reckless towards the end).

Likewise, in our businesses, we shouldn’t rely just on gut feel or stories. Gut feel in our Dr. Strange scenario is what led the ER doc to get Dr. Strange. But he was able to apply a framework to collect information and make informed decisions. And because he has those maps of the Landscape, Climate and Doctrine, if someone disagreed, they would be disagreeing with conclusions of the maps – not with the story teller.

And this is critical. A couple of weeks ago I had a conversation with Jabe Bloom of Praxisflow, and one of the quotes I wrote down was “The people telling the story determine what’s possible in the story”. But if we step back and instead approach strategy and actions with maps, we can have conversations about the where and how, and then weave the story to lead others to take action.

So next time you have a decision a group of you are working through, try mapping the Landscape, Climate and Doctrine. See how that changes your story. And then let me know on Twitter at @Cory_foy with the #mappingmondays hashtag! And if you need help coming up with those maps, don’t hesitate to reach out on Twitter or at hello at coryfoy dot com.

Thanks for watching! Be sure to check out all the videos on my blog at https://blog.coryfoy.com/mapping-mondays, and we’ll see you next week for another Mapping Monday!










{ 0 comments }

Mapping Mondays – Pioneers, Settlers, Town Planners

Happy Mapping Monday! Today’s #mappingmondays video covers different types of roles necessary throughout the evolution – what Simon Wardley calls Pioneers, Settlers and Town Planners. As always, a full transcript is included below the video. And If you’re interested in finding out how to apply this to your organization, don’t hesitate to reach out via Twitter or email hello at coryfoy dot com!

Links:

Transcript:

Happy Monday! Welcome to a new Mapping Monday video. I’m Cory Foy, and in today’s video I want to cover three types of roles we see in organizations, what Simon Wardley calls Pioneers, Settlers and Town Planners which is based on Robert X Cringely’s idea of Commandos, Infantry and Police.

In previous videos we’ve talked about the idea of Innovate-Leverage-Commoditize, as well as the Tower and Moat gameplay. In all of these cases, we require the ability to industrialize components and then incorporate those utility components into novel, uncharted components, which we can then leverage and commoditize.

However, the people we need to industrialize components are not typically the same as those we would expect to create novel ideas based on those components. Nor would we expect those people to be the types of people who can take a novel idea and find a market for it. So that means the type of gameplay we want to employ depends heavily on the types of people we have in place.

Let’s start with an existing productized component which we want to build an ILC / Tower and Moat type play on top of. We have an API we want to expose to a broader audience for people to incorporate into their innovations. Immediately we think about the operationalization of this component. It has to work well. It has to be scalable and fast. We want it to have significant uptime since upstream components will rely on it – but we also want to make sure we’re paying attention to the cost of running the service.

To make this work, we need people who are metric driven, happy with amazing operational efficiencies and analytics, and know how to model scenarios and respond to them. These are what Wardley refers to as “Town Planners”. For example, in most cities you have stoplights, but the timing of those stoplights is often decided through careful modeling by engineers who work though and measure the complexity of the interactions between the traffic, stop lights, and the roads.

Once we have a stable, scalable API, we need to find the innovations which are going to work on top of it. This search for a business model which solves our user needs requires rapid innovation, exploration and cycles. We’re going to be operating from a position of uncertainty in an market which isn’t yet defined and is likely constantly changing.

To make this work, we need people who are comfortable with failure, experimentation, uncertainty and driving from a cycle between user needs and gut feel. These people – known as Pioneers in Wardley’s terms – are path finders looking for novel approaches. These are the kinds of people comfortable building a building and putting no sidewalks in, then watching where people walk to figure out the best place to put the paths.

Once we have something which is gaining traction, we need to start leveraging and commoditizing it. Typically our pioneers like being able to explore, not productize. So for this, we need people who can watch market reactions, who can understand differentiation between products, and know how to take an interested customer and grow that interest throughout their organization. This last group – known as Settlers – are able to spot trends, like the paths stomped in the grass. They can listen and synthesize feedback, and know how to make success happen and constantly improve a product. These are going to be the people leveraging the work from the pioneers and making our innovations into marketable products.

So zooming out, successful plays like ILC and Tower and Moat are going to require a mix of capabilities which you may not be used to exercising. In a typical business, you may trend settlers into town planners. Or you may be a startup filled with pioneers wanting to make a long term play. In all of these cases, it’s important to look at the skills and approaches you’ll need to enable whatever gameplay you go after.

Hope you’ve enjoyed this video! If you’re interested in learning more about applying mapping and strategy within your organization feel free to reach out on Twitter at @cory_foy or via email at hello at coryfoy dot com. And be sure to check out all of the Mapping Monday blog posts on my site. Have a great week!

{ 0 comments }