≡ Menu

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!



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!


Wardley Mapping Mondays – Competitive Alternatives

Happy Mapping Monday! Today’s #mappingmondays video starts a new series on using April Dunford’s Production Positioning Framework with Simon Wardley’s Wardley Maps. We start today with Competitive Alternatives. 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!



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!


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!



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!


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!


  • 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!


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!



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!

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!


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!


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!


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!



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!


Mapping Mondays – Being Eaten From Below

Happy Mapping Monday! Today’s #mappingmondays video covers how to keep from being eaten from below when deciding which customers to focus on. 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!

Happy Monday! Welcome to another edition of Mapping Monday. I’m Cory Foy, and in today’s video I want to talk about a common problem startups can run into – figuring out which customers to pay attention to and how choosing wrong can cause you to be eaten from below or cornered into a – possibly lucrative – niche.

It all begins – as maps should – with user needs. We find a shared set of user needs – low hanging fruit – and execute on it well. Our market starts to grow and we find a couple of things true: We have a good spread of customers at different levels, and their needs are starting to diverge.

At the enterprise side, we have requirements such as single / integrated sign on, enhanced billing options, differing pricing and payment plans, increased capacity and scaling, customized support, and tighter management of people, not to mention a host of certifications customers would like us to have. These aren’t in the core product, but they are customer needs.

But a large chunk of our customers are early stage or even individual users, perhaps on free plans or smaller payment plans. They have differing needs such as the ability to rapidly integrate new functionality, clear pricing plans, best practices from how other people operate, and basically staying out of their way to get stuff done.

Comparing these needs leads to different maps of components in different stages with one problem – the capacity all comes from the same place. So we make a decision to focus on the larger customers because that’s where the most money is.

Implicitly that leaves a gap in our defenses. Looking at a map for an early-stage customer, there are several gameplays available inside of these value chains, and even more the more we map other user needs. Ideally if we’re going to ignore customers then we’ve built a moat around their needs which prohibits others from making plays into them.

But let’s say we just cede that market entirely. A competitor comes in and because they can’t compete on entire functionality they solve specific needs and provide an API for customers to be able to custom build solutions. As customers leverage the API to build their solutions, the company commoditizes these solutions into their product.

Of course, eventually these customers become successful and they start asking for some of the other things we originally focused on for our larger customers. But in this case the competitor still has an API and can rapidly respond to early stage needs, watching for innovation happening while also potentially meeting the larger customer needs – or simply being happy with a large portion of the market which doesn’t need those things.

This leaves us in a bad position. Now our pipeline of customers slows because our product has become more complex, but we’re also in a highly defensible, niche situation – getting where we are is hard, but hopefully it’s a profitable position because growth from there is going to be challenging.

By ceding a portion of the market to focus on lucrative opportunities we’ve allowed our pipeline – and therefore our growth strategy – to be eaten from below.

Countering this isn’t just “have more people”. It’s about making smart decisions of investment, as well as understanding what problems customers can solve on their own with a series of API calls versus what they need supported and where our strengths in supporting them are. This requires digging into our doctrine and maturity, as well as our business capabilities which we’ll have to save for another video.

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 blogs posts on my site. Have a great week!


Mapping Mondays – Team Capabilities

Happy Mapping Monday! Today’s #mappingmondays video covers how to use maps to help figure out where to grow your teams and their skillsets. 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!


Happy Monday! Welcome to this week’s Mapping Monday. I’m Cory Foy, and in today’s video I want to show how we can think about the investments we need in our organization based on the market direction and component evolution.

Let’s take a look at a company that is building a financial calculator for the market. They want it to be used by all kinds of people. They’ve bet that they’ll bring in their expertise and be able to build out custom products for a wide variety of industries. To get there, they’ve invested in growing significant teams of UI developers, designers, back end developers, and infrastructure teams. But they’ve run into some headwinds – people don’t seem to be buying the product as much as they expected, and when they do it seems like they want heavy integration more than a turnkey solution. Is this trouble for the company?

Well, let’s step back and look at the value chain. We’ll say that one of the user needs is calculating a payment based on real-time rates and credit scores. For this I’m going to rely on the y-axis of visibility. At the top, we need a UI for entering the key aspects and displaying the results. That in turn requires an API endpoint we can send and retrieve data from. That endpoint relies on integration with a special calculation engine, which itself relies on data from credit providers and market rates.

Now, let’s map this landscape. We can see that the UI is custom-built, as is the API. The engine itself is in Genesis, but the data it relies on are all products. We have teams working on just about every step in this chain, but where are the plays at?

Let’s look at the components for evolution going right to left. The data providers will likely end up utilized, but we’re not in a position to make the play to move those components as we don’t have access to the components they rely on.

Next let’s look at the UI. There’s obviously a lot of open space in front of it, but does it have potential to be commoditized? In other words, does making this UI into a product or utility independent of our other components make sense? Do any of our gameplays seem like they’ll be useful? We can do some market research, but given that most of the time the UI is simplified, it is unlikely we should be making a big investment there.

Next up is the API. This does have potential, because we’re using it in our UI, so the gameplays here are significant – especially an Innovate-Leverage-Commoditize. The API is definitely the kind of thing we could see being used in higher-order components – because we’re using it in one already ourselves!

Lastly is the calculation engine. This is something we want to evolve, and likely productize primarily so we can think about operationalizing it – scaling, monitoring, etc.

So if we look at our map, it would suggest that we continue contracting for the data for our engine. We should also deprioritize our UI work, instead favoring a sales process which looks for integrating our API into other provider’s products. In addition, we should be working to operationalize our calculation engine, so we need to make sure we have the right skillsets to help that play along.

Whether this set of plays helps save the company from the headwinds depends mightily on how rapidly they recognize and shift, how capable they are of making the plays, and whether the product is compelling enough for someone to integrate instead of just build themselves. There’s also the danger that since they are relying on downstream data, those providers could do their own ILC play and offer this service.

But we’re certainly in a much better knowledge position of what the potential in the market is, where we could make plays, and what kind of personnel we need to make those plays.

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 blogs posts on my site. Have a great week!