≡ Menu

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 }

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!

Transcript:
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!

{ 0 comments }

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!

Transcript:

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!

{ 0 comments }

Mapping Mondays – Tower and Moat

Happy Mapping Monday! Today’s #mappingmondays video covers an interesting gameplay known as Tower and Moat which can be devastating to a market when executed well. As always, a full transcript is included below the video along with some links to the ILC play. 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, and welcome to another edition of Mapping Mondays! I’m Cory Foy, and in today’s video I want to cover a gameplay known as Tower and Moat – a play which, when executed well, is basically quicksand to a business trapped by a competitor making the play.

First, a quick recap. In our maps we see components go through evolution from Genesis to eventual utility. However, when a component becomes utilized, it enables higher order components to be based off of it. So basically utilization of something – like electricity – enables things to be built which incorporate it – like the internet – which themselves can enable higher order ecosystems like Twitter or Websites.

In this case, let’s pretend we’ve built a business around selling computer servers to customers. We have a large customer base, and we’ve done really well for ourselves. We’re effectively selling productized computing power to our customers. Then, one day, Amazon comes along and offers computing power as a utility. Customers don’t have to think about requisitioning servers, backups, upgrades or anything else. They can basically just turn on more compute power.

Initially this doesn’t have a huge impact. Customers tend to already have contracts, and have to figure out how to incorporate this new model into their thinking. So initially we have the luxury of a runway of market inertia to buoy our revenues.

But now the question comes up of – how do we survive, or even thrive? “Beat Amazon!” becomes our rallying cry. But one of the biggest challenges of utilitized components is the amount of capital and inertia it takes to overcome it. So we start figuring out how we’ll also offer our own set of utility services, and how we’ve got more experience, better customer service, and all the magic thinking of why a customer would want to use us over them if we just offer what they offer.

But Amazon doesn’t care about that. They’re going for market domination, not winning small segments. So in this case they begin building what is known as a Tower and Moat strategy. First, they recognize that utility components are characterized by being embedded in higher order components. So they open up an API and let people start building things on top of them.

See, they know that what will eventually happen is higher order components will emerge that they can than commoditize. This is known as Innovate, Leverage, Commoditize (https://blog.coryfoy.com/2019/08/mapping-mondays-innovate-leverage-commoditize/) because other people do the innovating.

To fund this play, they create a tower of revenue around the utility services. So people pay to use the API, and to harness the compute power. Then, as higher order components emerge, they commoditize them and offer them for free, because they have enough revenues to do that.

Back to us – let’s say that we anticipate a higher order change happening, and so we start looking at the incremental steps that come after the utilitization of server compute. The problem is – people begin building things on top of Amazon’s API, so they can see in real time where people are innovating, while we’re doing it through user surveys or customer exit interviews. And even if we successfully open up a new market, it’s likely Amazon will be able to rapidly commoditize it using a Pricing Policy play of…free.

Unfortunately, by the time we’ve figured this out, more of the market has moved into integrating Amazon deeply into their innovations, making it hard for us to do a counterplay of our own ILC, and potentially sending us into a death spiral of losing market share.

But does that mean that it is all graveyards and tombstones when a competitor utilitizes a product we rely on as a core of our business? Not necessarily – but it does require rapid movement and anticipation that feels unnatural.

As an example, I once took a class on commanding large scale emergency incident operations as my background also includes being the Assistant Fire Chief of a department in Florida. One of our final scenarios was a wood-frame apartment complex under construction. An initial small fire is called in and we found the only way to stop it from destroying the entire complex was to arrive on scene and immediately call for six alarms. For context, each alarm for us is 3 fire engines, a ladder truck, an ambulance and a battalion chief. So we’re effectively calling for 24 fire apparatus and 6 ambulances for what many departments would normally consider a one or two engine response.

That’s because the potential was so high that we had to make a bold, rapid move early in. Since that class I’ve witnessed two major fires with that exact scenario, both of which turned into total losses for the complex under construction – one in Ybor City, FL which burned 4 city blocks, and one in downtown Raleigh, NC just about 2 years ago.

So what’s our equivalent of calling six alarms? First, the recognition that our normal business indicators aren’t going to help us here. Everything is going to seem manageable, but if we’re looking at our landscape, we can see the dangers of the play – especially if our competitor has the revenue streams to be able to execute the moats.

Now we need to be able to anticipate the evolution of the market. We’re now relying on bets which are hopefully based on deep understanding of user needs. We’re looking for ways to leapfrog the evolution and get people building on top of us. As an example, we could commoditize the API by incorporating it in our own APIs to give people access to second or third level order capabilities. If we can pull that play off, then we can begin running our own ILC play – and hopefully our own Tower and Moat strategy while also diversifying the sources of that utilized API so we don’t find ourselves cut off from it suddenly.

All of this requires incredibly astute understanding of the market, user needs and evolution direction, as well as a willingness to make bold bets with high agility and maintaining a great experience of our core product. Which means we want to do this while we have the capital to invest – because once revenue drops start to happen, investing in riskier moves is going to be harder and harder to justify.

So if you find yourself with a business that evolves around core components which are ripe for evolution to utility, start thinking about the plays you have around it and how you can protect yourself from the inevitable sweep that will come – before you find yourself looking up videos on saving yourself from quicksand.

If you have any questions or are interested in mapping your own organization’s challenges, feel free to reach out on Twitter at @Cory_foy or via email at hello at coryfoy dot com. And be sure to check back next Monday for a new Mapping Monday! Have a great week!

{ 0 comments }

Mapping Mondays – Negative Gameplays

Happy Mapping Monday! Today’s #mappingmondays video covers negative gameplays and how you can search your maps and gameplays for exploitable weaknesses before your competitors do. 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!

Transcript:

Happy Monday! This is Cory Foy, and in today’s Mapping Monday I want to talk a little about negative gameplays and how we could anticipate them through maps. I’m going to use a very real example for many of us – money – and how it can be impacted.

For our map, let’s start with a user need of purchasing something that costs more than the cash we have available to us. We have a couple of things in our chain – collateral (usually the thing itself, like a property), Trustworthiness (generally a credit score) and a Lender. In turn, the Lender will need access to Cash, Profit Margin, and Risk Profiles. One of the influencers of Cash and Profit Margin – here in the US at least – is an interest rate influenced by the Federal Reserve known as the Prime Rate. For many types of credit transactions, the rates are tied to the rate set by the Federal Reserve – and therefore move with it.

If we want to show how we can take action, we can map this with some different types of axes. Ultimately the thing we want to influence is getting a better – in this case, lower – rate for the money we have to borrow. After all, if we can borrow money without any interest rate at all, then we have a lot more flexibility.

But each of these can have different impacts on the cost of borrowing. The less trustworthy you are, the higher your cost of borrowing is. Or the more that the transaction hits certain risk profiles, the more expensive it is. Also, the more the lender wants a profit margin, the more expensive borrowing can be, but that is limited by various consumer laws in certain cases.

Now, if we want to reduce our cost of borrowing, we can make some positive gameplays. For example, we can improve our credit score to improve our trustworthiness (ignoring the outright problems for people and credit scores for this video). We can also improve our risk profiles – bringing on an additional cosigner, or bringing additional collateral.

Now, generally as an individual we have little control over the other factors – we don’t control Profit Margin, nor do we control the Prime Rate. But what if we could? I mentioned earlier that Profit Margin doesn’t have as big of an impact because of regulation, and there are definitely moves to reduce those margins from a regulatory perspective to reduce the cost of borrowing.

But let’s say we can’t control regulations, and we’ve moved all of the other needles as much as we can. What about that Prime Rate? Is there a game play we could get to move it? To find out, we need to figure out what it’s made of.

The Prime Rate is actually a set of other rates. The WSJ Prime Rate and the 11th District Cost of Funds are both rates set by surveying banks to see what they are charging. Impacting those requires a coordinated effort to change those financial institutions. The Federal Discount Rate and the Fed Funds Rate, however, are both under the influence of the Federal Reserve. They set the cost of borrowing money – either from each other, or from the Federal Bank directly.

Changing these rates directly impacts the cost of borrowing – higher rates for banks to borrow money means higher rates for them to lend it. However, these rates are a tool that the Federal Reserve uses for a specific reason – to balance the health of the economy. The healthier the economy, the better it is able to take the higher rates. The worse the economy, the lower the rates go to spur more lending which, the theory goes, leads to more growth.

This means if we’ve tried our other options, we really want that lower rate, and we have the power, we can run a negative gameplay against the economy itself. By driving uncertainty and fear into the economy, the Federal Reserve may act by lowering the key rate targets to encourage the economy to come back up. There are lots of ways to inject fear into an economy – from falsified Press Release plays to hacking of key systems to Trade Wars, but all can end up with the same impact if sustained long enough.

Obviously this is a hugely unlikely scenario, but highlights a way that you can look at your systems to find exploitable weaknesses in your plays before your competitors do. After all, they may not be as likely to just play on a “Differentiation” gameplay – especially if they are desperate or unscrupulous.

Hope this has helped show the importance of looking for weaknesses in your maps. If you have any questions or are interested in mapping your own organization’s challenges, feel free to reach out on Twitter at @Cory_foy or via email at hello at coryfoy dot com. And be sure to check back next Monday for a new – and happier – Mapping Monday! Have a great week!

{ 0 comments }

FASTER Fridays – Story Points

Happy Friday! This week’s #fasterfridays is a great watch if you have hidden work in your teams. We talk about using story points – as opposed to hours – to generate insights across some different categories of work. 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. Have a great weekend!

Transcript:
Happy Friday, and welcome to another edition of FASTER Fridays! One of the insights I like to help organizations with is an understanding of how they spend their time. But there’s a catch – measuring how people spend their time is itself an activity, and if done in too much detail, or with too much burden, can cause its own set of problems.

To solve this, I use something with a lot of information already out there – story points! I really like them because after the initial figuring out of how they work, teams can run with them. Unlike how story points are taught, I want teams to try story pointing lots of activities – not just user stories.

As an example, let’s say we think we’re spending a lot of time on maintenance activities or paying off technical debt. We would put a card in whatever tracking system we’re using – from Jira to Post-It Notes, and size it like any other work. We can then see the balance of feature work to maintenance work to see if we’re investing properly.

I also like using them for bugs, defects and escalations. Traditionally these are trickier because it’s hard to know up front how long it will take. So what should we do? Post-size! That’s right – I’m not trying to get teams to be clairvoyant – instead trying to get them insights they may not have.

Combined together, we can generate pictures of how teams spend their time. And across clients I tend to find interesting correlations between teams which have a healthy balance of maintenance work and feature work – when that investment is skewed towards feature work, we tend to see time spent in escalations and defect resolution rise.

But that’s not the only picture we can tell. Sometimes it’s not about the mix of work, but about the types of activities highlighting organizational or tool gaps. This graph shows similar point tracking, but categorized into value work – which would be feature, maintenance, tech debt – and enablement work – in this case, work setting up environments for deployment, manually testing deployments, etc. What we found is that the lack of a staging environment was costing this company around $2mm a quarter in enablement work when they did their deploys. We were able to use these insights for cost justification for a new staging environment, and also were able to show the associated drop in costs once it went online.

Finally, I’ve been asked before about why not simply use hours and time tracking. There’s two reasons for that. The first is that it can be a burden to collect at that level, especially for teams. But the bigger reason is that I often work hard to keep executives from wanting all estimates in hours and Gantt charts. If we switch back to hours-based estimates and tracking, even for something like this, it says that points and relative sizing are not good enough for “real work” and can end up with them totally ignored.

So if your teams seem to have lots of ancillary work stealing time from what they want to be doing, try capturing and sizing it, and then looking at the aggregate numbers. You might find some really interesting insights that open the doors for adjustments and improvements in the way you work.

Hope you’ve enjoyed this. Feel free to check out all of the FASTER Friday videos on my blog, and if you’d like more information do reach out on Twitter at @Cory_foy or via email at hello at coryfoy dot com. And be sure to come back next Friday for another Faster Fridays video!

{ 0 comments }

Mapping Mondays – Value Chains

Happy Mapping Monday! Today’s #mappingmondays video goes back to basics and covers the notion of looking at User Needs as well as constructing a Value Chain and ultimately turning it into a map by applying various aspects of motion and direction to the components. As always, the links in the video are below, and 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:
Over the past couple of weeks we’ve talked about various Gameplay and Doctrine in relation to Wardley Mapping. But all of this makes a critical assumption – that our maps are solid. But we haven’t talked as much about what is in these maps or how they’re formed. So let’s touch on the core of building a map – the Value Chain.

In its simplest form, the value chain starts with a set of user needs and lists the components necessary to deliver those user needs – and the components necessary to deliver those components. As an example, let’s say I wanted to write a hit song. I’m going to need music and songwriting. And I’m also going to need a way to record, publish and distribute the music. For song writing I’m going to need a sense of musical theory, as well as research into what constitutes a hit song right now. We can go further and talk about instruments, lessons, recording equipment and many other components.

So far we have a graph of components connected to a single user need. Is this a map? No, not yet. One of the key distinctions Simon makes in his discussion about maps is that we need direction and movement to turn a graph into a map. The primary axes we see are component evolution from Genesis through Utility, and – less important – the visibility of the components. But do these have to be the only directional guidance? Not at all! We could try overlaying things like Roger’s Diffusion of Innovation Theory (made popular by Geoffrey Moore in Crossing the Chasm) and looking for components getting ready to “Cross the Chasm”. Or we could overlay the Dreyfus Model of Skills Acquisition to think about how we help our users progress in their knowledge of the components. The point is that we need directional capabilities for the components to understand how they’ll move in our space and where we can make plays at.

Speaking of users and their needs, we started with a single user with a single need. But often we have more than one user – or even differentiation between customers (people who buy our product) and users (people who use our product). They are going to have a variety of needs, and it’s worth mapping out those needs and the components necessary to look for overlaps and strategic advantages. Make a product compelling enough and your users can override the challenges in procurement and purchasing. Or make it easy enough to purchase or integrate and it might become a de facto standard even if the users don’t care for it.

But ultimately it’s important to have hypotheses and test them out with maps. If you think you have a strategic advantage, that advantage should be articulated on a map and obvious when it is. And then spend a little more time trying to poke holds in that obviousness.

If you’d like to learn more about Value Chain Mapping and User Needs Analysis, you can start with Simon’s seminal post on it as well as the chapter in his book. You can also look at some ideas from Jeff Patton and his User Story Map. And finally, check out both the Dreyfus Model of Skills Acquisition and Moore’s Crossing the Chasm. I’ve included the links here and will also post them in the blog post for this video.

And 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.

{ 0 comments }

FASTER Fridays – Relative Sizing

Happy Friday! This week’s #fasterfridays touches on one of the more challenging parts of software development – estimation. We talk about Planning Poker, and then touch on Team Estimation which approaches estimation from a different perspective with the same goals. 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. Have a great weekend!

Links:

Transcript:

Happy Friday! Welcome to this week’s FASTER Friday. When I first created Mapping Mondays and Faster Fridays, I knew I was creating a commitment to be able to deliver two videos per week. That commitment wasn’t based off of a wild guess – I had an idea of how long things would take – estimates if you would.

In our teams, we also want to be able to understand what we’re able to commit to. There’s a large variety of ways of doing this – from Cycle Time to Story Points both of which I have articles I’ll link to. Interestingly both methods require a form of sizing – for Story Points to get the actual story point, and for Cycle Time a way of understanding different sizes of work flowing throughout the system to know what our expected Cycle Times are.

Unfortunately, the primary way we talk about sizing work is using Planning Poker. Planning Poker – which is a great exercise – is where a team has a deck of cards following the modified Fibonacci sequence – 1,2,3,5 and so on. They then pick a story from the backlog, read it, discuss it, and then vote on it by each member picking a card and then everyone showing their card at the same time. The lowest and highest then talk about their perspective and there’s a revote, with the goal to get consensus.

However, while notionally we use this as a sense of relative estimation and sizing, the mechanics require us to already have a notion of time mapping in our heads. So instead I try a Team Estimation game which removes points completely until the very end. Here’s how it works.

We still start with some backlog of work we want sized, and we still pick the stories up one by one and discuss them. But then instead of voting on story points or t-shirt sizes, we lay it down in a column. We then lay the next one either below, to the left or to the right of the first one, depending on if we think it’s about the same size, smaller or larger. We then continue going through this process until all of the cards are in columns.

At this point, if we’re primarily focused on flow and cycle time, we can ask whether there’s enough difference for us to track them separately. However, if we want story points, we can now use planning poker to size each column, instead of each card.

What’s nice about this method is we have the ability to insert columns during the initial process, or consolidate at the end. Basically we can focus on the cards and how much work is in them rather than trying to map to a specific pointing process. We also don’t have to be strictly linear in our sizing of our columns.

So if you or your team find yourself struggling to size work, try not sizing it and merely placing it instead. It might help drive out the conversations around the items, putting the focus on collaboration instead of points.

If you’re interested in more, I go a little more in-depth in a some blog posts on sizing, even sizing in Kanban. I’d also recommend checking out Mike Cohn’s “Agile Estimating and Planning”

Hope you’ve enjoyed this. Feel free to check out all of the FASTER Friday videos on my blog, and if you’d like more information do reach out on Twitter at @Cory_foy or via email at hello at coryfoy dot com. And be sure to come back next Friday for another Faster Fridays video!

{ 0 comments }

Happy Mapping Monday! Today’s #mappingmondays video covers a very powerful gameplay called Innovate-Leverage-Commoditize where you allow others to figure out the market for you, and then simply commoditize what they discover. As always, the links in the video are below, and 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, and welcome to another edition of Mapping Mondays! Often when we look at Wardley Maps, we look for opportunities to act by moving components between phases – productizing a custom built component, or driving a component towards utilities. But what if we can get other people to tell us where we should make our plays with minimal investments on our part?

That’s the heart of a specific gameplay known as Innovate-Leverage-Commoditize. Many of us are familiar with Amazon, Google and Microsoft’s products which provide computing power in the cloud. We can think of this as a utility – basically something we just turn on and off like electricity. If we’re not one of those providers, we can use this to our advantage. Often companies in the Genesis or Custom Build phases are looking for products or platforms they can use to build things with. So let’s take a space that hasn’t been commoditized and expose an API – in this case, we’ll expose social media feed access as an API, built on top of compute as a platform.

We then launch this API to the broader world, and people begin taking advantage of it, building interesting new mash ups of data, all using our API. We’ve now enabled a whole series of innovations to occur on top of our platform – meaning we’re both an enabler and have the ability to see the metadata of usage to analyze where the really interesting moves are.

As we see usage continue to creep up, we Leverage this data to spot patterns. We then move up the stack a level and fully Commoditize a portion of that – potentially disrupting other business models in the process. Now we’re even more entrenched in the market because we’re the default information provider and we have the core products. If we’re following good Doctrine, we’re doing this in a way where we are also a joy to use, so people are more likely to keep building on top of us, allowing us to continue exposing other high-order APIs, watching people use them, and then leveraging that knowledge to Commoditize additional markets.

The tricky part about this is disrupting this flow once it is in place isn’t a matter of outcompeting in parallel. You have to clearly map your market and understand the higher level components and the plays necessary to productized or commoditize above the currently commoditized layer, effectively attempting to control the information flows above the platform. This can take some really forward thinking, but without it you might end up continually playing catch up.

If you’d like to learn more about ILC, Simon Wardley has a great chapter in his book on it, as well as a fantastic Twitter thread. I’ve included the links here and will also post them in the blog post for this video.

And 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.

Until next time, have a great week of mapping!

{ 1 comment }