≡ Menu

Wardley Mapping Mondays – Operations Doctrine

Happy Mapping Monday! Today’s #mappingmondays video continues the series on Doctrine looking at the seven principles of Operations. 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 this week’s Mapping Monday where we’re in the middle of exploring Simon Wardley’s Doctrine. So far we’ve looked at two categories of Doctrine covering principles and patterns of Communication and Development including things like Focusing on High Situational Awareness, Using Appropriate Methods and Challenging Assumptions, and I’ve linked to those videos in the blog post with this video, so be sure to check them out!

For our third category we want to look at how we operate as an organization. That means looking at 7 doctrine principles: Managing Inertia, Optimizing Flow, Thinking Small to know the details, Focusing on Effectiveness over Efficiency, Doing Better with Less, Setting Exceptional Standards, and Managing Failure. Let’s dive in!

Our first doctrine principle is Managing Inertia. Imagine you’re a business owner. You’ve developed a successful business – one that has grown and employs hundreds or thousands of people in a specific space. You’ve been in business for a while and seen all kinds of people try to get into the same space, all thinking they have a unique approach. But you know that they’re all underestimating what it takes to really be successful in this line of business, and so when yet another startup enters the space you don’t think anything of it. Suddenly, 2 years later, it seems like you can’t go 2 hours without hearing about more business loss to this startup. What happened?

We got comfortable. Wardley lists three climatic patterns which explain: Success Breeds Inertia, Inertia increases the more successful the past model is, and Inertia can kill an organization. In short, success makes us comfortable, and we lose the methods of evaluation that got us where we are. We don’t want to panic about every new entry, but we should have a method for evaluating what they bring, and understanding what threat they represent – maybe allowing us to acquire or block them if they really are a threat.

Inertia is a fascinating topic, and Wardley identifies 16 types of inertia as shown here, and linked to in the article with this video.

Interestingly, when a business finds themselves like our friends above, there’s typically people in the organization it’s not a surprise for. In fact, they may have been trying to raise the alarm about what they saw, but found themselves tied up in organizational politics, red tape, or bottlenecks, so the information couldn’t get where it needed to go. These flows of information are critical, and we want to optimize them. Our second principle – optimize flow – tends to bring up ideas of Kanban and the flow of software development, but there are many flows of capital in an organization – including information, risk, development, financial and many others. We want to ruthlessly find the bottlenecks which prevent us from driving towards the key value for our users – and clear them out. I recently did a video on Value Stream Mapping which shows a reduction of 10 months in a development process we got by visualizing the key processes and then clearing them out, which I’ll link to below.

Optimizing Flow goes hand in hand with our next principle about Thinking in the Small to know the details of what is going on. As we grow and become successful, we tend to trust our downstream processes without fully understanding them. This can lead to waste and delays. This doesn’t mean that as a leader you have to micromanage! Instead think about a line of sight – when you have a question, there should be a clear line of sight from the lowest levels to the high level strategy that is inspectable. And you should inspect it every now and then. Not only do you learn things, but you can inspire confidence and pride from your teams as they show you what great things they’re doing.

However if you’re going to inspect, your focus should be on effectiveness over efficiency. In other words, don’t optimize ineffective processes! As an example from fire rescue, when we have a large fire, we need some sort of an external water source. Hopefully this means there is a fire hydrant nearby. In training, we may see that firefighters have an inefficient way of pulling the supply hose off of the truck to drag it to the hydrant, and you work with them that lets them pull it off 40% faster. But then your chief comes along and has them simply stop at a hydrant on the way in, hook the hose to it without turning it on, and then drive to the fire, cutting a 7 minute process to 45 seconds with a higher level of effectiveness.

Back to business, one of the counterintuitive things I show my clients is that if you want to go faster, work on less things at once, and reduce the delays between the steps. We don’t have to actually improve the steps themselves to see significant improvement. We want to do better with less – and that means a culture of Kaizen – not just continuous improvement, but a ruthless focus on it. We need measurement, transparency, openness – as well as trust and safety. And the continuous is critical here – we can’t just do a single “blame session” and think we’ll get the same benefits as a cadenced reflection. We should be open to experimentation – and failure.

Which brings us to the last two principles – Setting Exceptional Standards and Managing Failure. You are what you prioritize, and you set the tone for your employees. This means setting the bar at the very best that can be achieved – not burnout, not overachieving, but sustainable, innovative, amazing people. And along the way we’re going to be trying new things, entering uncharted waters. We’re going to be making bets on unproven gameplays. Our maps will be wrong. So be prepared to have a culture where failure is planned and designed for. Distribute risks to reduce impact. Try things like “Pre-spectives” where we talk about what could go wrong before we do something.

So those are Wardley’s doctrine principles of Operations: Managing Inertia, Optimizing Flow, Thinking Small to know the details, Focusing on Effectiveness over Efficiency, Doing Better with Less, Setting Exceptional Standards, and Managing Failure. Take a look at your organization this week. What things do you not know the details of? What things are inefficient? What things are at risk? And – what can we do about it? Maybe – start with a map! I’d be delighted to hope on a 30 minute video call to help you get started. And if you have any other questions or just want to let me know how it’s going reach out on Twitter at @cory_foy or via email at hello at coryfoy dot com. Until next week, let’s get moving!









{ 0 comments }

Happy Mapping Monday! Today’s #mappingmondays video continues the series on Doctrine looking at the nine principles of Development. 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 this week’s Mapping Monday. Last week we introduced 6 categories of Simon Wardley’s doctrine – Communication, Development, Operation, Structure, Learning and Leading, as well as covered the four doctrine principles in Communication – Be Transparent, Focus on High Situational Awareness, Use a Common Language and Challenge Assumptions. Communicating is critical for every organization, especially as we figure out what we should be doing – our gameplays and strategies, and hopefully you found some great ways to integrate these into your organization.

The act of figure out how to get to what we should be doing is the focus of this next category of doctrine – Development. It’s a big one, both in impact and number of principles. What are Simon’s doctrine principles for Development? Know Your Users, Focus on User Needs, Think Fast, Inexpensive, Restrained and Elegant, Remove Bias and Duplication, Use Appropriate Methods, Focus on the Outcome – Not a Contract, Be Pragmatic, Use Standards Where Appropriate, and Use Appropriate Tools. Whew! Let’s not waste any time.

Knowing our users is something driven into every business. But do we really know them, or are we making assumptions about who they are and how they use the things we create? For example, building a car rental that people can reserve without needing to talk to anyone sounds great. Until you don’t think about what happens when they drive that car into an area with no cell signal and it shuts down. I’ll also mention that in knowing our users we should also understand the bad with the good. We might think of software which can track and lock down our devices as helpful – until they’re used in abusive situations. So spend time with them, in their actual environments. And build diversity of opinions and people in your teams to challenge assumptions you make about those users.

Once we have an understanding of our users, we want to focus on their needs. In a Wardley Map, User Needs are the anchors we use for all down level mapping. However, we have to be prepared for two challenges. The first is that different users may have different, conflicting needs. We need to be prepared to balance out those approaches. The second is that, when we talk about components in Genesis and Custom Built, user needs are uncertain. We’re still in a discovery process. So we’ll see more rapid evolution of them as we learn more from them.

As we focus on those needs and start to think about how to meet them, we want to be in a mindset of Thinking Fast, Inexpensive, Restrained and Elegant. This term – known as FIRE from Dan Ward’s book – is about having a bias towards action, in a lightweight way that stays focused on the need we’re solving but is high quality enough to be built on top of. This is a good place to learn more about Extreme Programming – the idea of working small, fast and with high quality, in a way that can be evolved. Or invoking the acronym I heard most from Ron Jeffries – YAGNI – You Ain’t Gonna Need It.

And when we don’t need it, we want to remove it. The doctrine principle of Remove Bias and Duplication is a strategic look at YAGNI. We want to share maps, collating them and looking for both duplication and bias – specifically around gameplays that don’t match the evolutionary lifecycle. For example, if something is a commodity, we likely shouldn’t be building it – though as Cat Swetel says, sometimes that can be an advantage and we should be very clear that we’re diverging from the norm and be prepared to defend why.

Using Appropriate Methods is perhaps one of the most powerful statements in its simplicity. While we’ve seen a big shift over the past 15 years towards agile methods being the norm, that doesn’t always mean we should approach it that way. In a Genesis phase, rapid discovery doesn’t fit well into Scrum like models, though it can be a good container for discovery if the cycles are short enough. On the other hand, when we have an implementation of a utility component, it’s likely that a sequential process will work very well, and what we’re looking for are more Six Sigma ideas of waste and delay reduction. There is no magic solution, and you should understand what you’re trying to accomplish.

And when we talk about what we’re trying to accomplish, we run into our next doctrine principle – Focus on the Outcome – Not a Contract. This fits in to the Agile Manifesto notion of Customer Collaboration over Contract Negotiation. We should look for ways to work towards delivery valuable things that mean the needs of the user value we’re discovering. We should be open – on both sides – to finding better ways of working together, knowing that contracts aren’t necessarily evil – if we find the ones that fit what we’re trying to deliver.

When we are trying to deliver, we want to Be Pragmatic. If we can leverage off-the-shelf components, we should do that. Know what your core competencies and wins are – and focus on them. As Simon says, “Always challenge when you depart from using something that already exists”.

Along with being pragmatic, we should Use Standards Where Appropriate. If we have components we can build on top of, we should build on top of them. If there’s a standard, we should try to use and improve it, or we’ll run into the notion of just adding to the standards and getting bogged down in supporting things which don’t further our goals.

Finally, we want to Use Appropriate Tools. This means looking at our situation and ensuring we have the right level of awareness. If we’re making a financial bet, we should have financial models. If we think we’re outplaying our competitors, we should be able to show the map of the landscape validating that decision. There’s no reason to just start driving and hope you get there – even in a brand new startup you have customer discovery and validation you’re driving towards, and you should focus on getting those hypotheses answered.

So as you go to develop this week, start asking yourself how your doing. Do you know what your users need? Are you thinking in small increments that can move quickly? Are you using the right method for the agility you need? And are you making the most of your investment in time by removing bias, duplication and adopting standards? There’s always more we can do, and it doesn’t have to be big! I’m excited to hear how you all make it happen. And if you have questions, need help, or want to let me know how it’s going reach out on Twitter at @cory_foy or via email at hello at coryfoy dot com. Until next week, let’s build something great!









{ 0 comments }

Wardley Mapping Mondays – Communication

A person standing in front of bookshelves with the communication principles listed on the left

Happy Mapping Monday! Today’s #mappingmondays video starts a new series on Doctrine beginning with the four principles of Communication. 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 this week’s Mapping Monday. Often when we think about Wardley Mapping we dive into the “mapping” part of it. But mapping is a tool we use to look at our landscape and figure out what gameplays we can make. And we can’t get there without a common operating model – our doctrine.

The word doctrine certain conjures up a military context, filled with rigid structures and a single way of thinking. But the US Army defines doctrine as the fundamental principles by which the military forces – or elements thereof – guide their actions in support of national objectives. In other words, it’s a body of thought on how they operate together, focusing on how to think, not what to think.

Similar to how the military took past experience and turned them into fundamental principles, Wardley lists a set of doctrine, defining them as universally useful patters that can be applied regardless of context. While there are several ways he presents them, I find a division into six key categories – Communication, Development, Operation, Structure, Learning and Leading – to be a great way of breaking them down. So over the next several weeks we’ll take each of these categories and dive deeper into the doctrine within them.

But let’s not wait! Our first category – Communication – is perhaps one of the most vital set of principles we can tackle. Our organizations have lots of people with amazing information that can help us – but only if we let them. Simon’s doctrines within Communication are Be Transparent, Focus on High Situational Awareness, Use a Common Language, and Challenge Assumptions.

Transparency is something we all say we strive for, but can be hard in practice. Many of us like to be a story teller – a hero – bringing the ideas together that will save our organization or create the next big thing. Or, we don’t like people to see things messy – afraid they’ll think we don’t know what we’re doing.

So this first doctrine principle of “Be Transparent” is about turning that around. We should bias everything towards being open. We should share our maps, our strategies, our approaches and gameplays as wide as we can to get the most input and insights. This also means we’ll get their concerns, their challenges, their messiness to our perfect story. We should be prepared for that – rather than ignore it and let the market or our competitors show us our flaws.

Transparency doesn’t mean we just make all of our private conversations public. We should have more awareness than that. Which happens to be Wardley’s second doctrine principle – Focus on High Situational Awareness. The guidance I give organizations I work with is that you need systematic methods for analyzing and evaluating what is happening around you. Wardley Maps are, of course, a great way of doing that.

As an example, let’s say Amazon has just announced they’re moving into your market. The first thing you need isn’t a response. It’s a map of what exactly it appears they are doing and how that fits into – or disrupts – the current landscape you operate in.

The other aspect I tie closely with situational awareness is Commander’s Intent. This is the notion that as a leader your teams understand the intent of their actions and how they fit in to the overall strategy. As another example, let’s say you are trying to compete in a disruptive market that requires a lot of exploration. You may direct your operations teams to reduce costs, but they should understand that in a high-discovery phase we don’t want to lock down all capacity to the minimums – we’re going to have some waste as we move along the path and stabilize. Otherwise they may march towards making things as lean as possible – at the detriment to your disrupting teams.

The third doctrine principle is Use a Common Language. In the Lean world we refer to this as “Standard Work”. Standardized work is the playbook. It’s what the team has decided is the best way — at this point in time — to get the job done and succeed on a daily basis. (https://www.ame.org/target/articles/2013/beginners-guide-lean-standardized-work-%E2%80%94-linchpin-lean). So we should make sure that people understand roles, approaches and terms – as well as things like movement in a map, what mapping is, and the approaches and gameplays we want to take. And we should create checkpoints for verifying we’re all talking about the same things – and have a common repository for reference we can update when we’re not.

The final doctrine principle under Communication is “Challenge Assumptions”. One of the most powerful statements I got was from Jabe Bloom who told me “The people telling the story determine what’s possible in the story”. That means not only should we be comfortable challenging assumptions – as Wardley says “there is no place for ego if you want to learn” (http://blog.gardeviance.org/2017/01/a-smorgasbord-of-usefulness.html) – we should also create methods for allowing those assumptions to be exposed.

To highlight this, imagine we got this paragraph from our Chief Product Officer. It sounds reasonable, but it also feels like there’s something not right. But how do you challenge it? How do you pick apart the pieces that don’t feel right without the storyteller feeling like you’re picking them apart?

But now let’s attach a map to the statement. Now we can ask questions about why we’re choosing this attack versus another, what the danger of competitors evolving a key component before we can, and even questioning some key elements the tactics were based on. Cat Swetel says that Wardley Mapping is the democratization of strategy (https://twitter.com/13895242/status/1192846872194383877) and that’s what makes it so important.

Transparency, Situational Awareness, Common Language, Challenging Assumptions. It’s a lot for one week, but I have confidence that you’ll find ways to start the journey in your organization. And if you have questions, need help, or want to let me know how it’s going reach out on Twitter at @cory_foy or via email at hello at coryfoy dot com. Until next week, here’s to challenging ourselves!









{ 0 comments }

FASTER Fridays – Value Stream Mapping

A value stream map going from idea to ship with a processing time of 97 hours and a total time of 688 hours

Happy (early) Friday! This week’s #fasterfridays covers a powerful tool for understanding processes and delays in your organization – Value Stream Mapping. It walks you through a small example, and then a real world example from one of my clients. 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:

Hello! I’m Cory Foy, and in this Faster Fridays video I wanted to walk through a technique known as Value Stream Mapping. This is a powerful technique from Lean Manufacturing which allows you to understand not just your process, but the delays, queues and time spent in them to find out what’s really slowing you down.

In the upper left hand you can see a Value Stream Map I did for a client many years ago. This was obviously a rough sketch, but we were able to do it quickly. But what is a Value Stream Map? At its core, it is a way of visualizing the flow of work in a system. But the power comes from mapping your actual process – not how you want it to – or wish it did – work.

Our map begins at an entry point into the system. Ideally this is the very beginning, perhaps where an idea first gets introduced. We then walk through all of the steps until it leaves our system or we get the value we need, in this case, Shipping software. It’s possible for this to go even further. For example, a hospital’s value stream may not end when a patient is discharged – they may want to track post-discharge steps, follow up appointments, or even readmissions.

Once we have our process, we then look at the processing time in each step. In this case we’re dealing with people, not machines, so design may take 2 days of work, but it takes the designer two weeks to devote 2 full days towards the design. Likewise the development team may spend two full weeks developing, but it takes them 12 weeks to get those two weeks – either because of meetings, context switching, escalations and other work. Finally we ship it, which is a full-day deployment but our piece is only an hour of.

Now that we have our processing time, we need to look at our queues – or the places work sits while it’s waiting to move downstream. It is very rare to have perfect efficiency, so in this case we see that once an idea comes in it takes on average a week for Design to start, two weeks for development to start once design is done, and an average of three weeks for it to be deployed due to the organizations six-week deployment cycles.

So to close this out – our processing time calculated by adding up just the time spent working – was 97 hours – or about 2.5 weeks of work to go from idea to ship, it takes 688 hours to actually get it out the door – about 17 weeks – resulting in an 14% efficiency.

But is that real? That seems wasteful, doesn’t it? Now let’s go back take a look at that client diagram and actually sketch it out to see how it was.

In this case we start with a request coming in. ending in Project Kickoff! Yes, we haven’t even started developing yet! We then map out the processing times and queues between them. These came from the actual teams and executives and represented average waiting times. But even this doesn’t tell the entire story, because in at least three places we can get rework. For example, at the first review stage an average of 20% of requests get kicked back to Opportunity Analysis once. In the second review work gets kicked back to Product Analysis 50% of the time!

When we mapped all of this out, we found it was 286 hours of work over 1592 hours, or 7 Weeks of Work, but 10 months to get those 7 weeks. So when we talk about wanting to go faster, we didn’t need to look at engineering – we could drastically improve the responsiveness of the organization simply by reducing the queuing time between these steps, without even having to remove any of them!

So if you want to try it yourself, start with your own process. Map out the times inside steps, then the times in-between steps. Calculate your times, recover from your heart attack, and then work on clearing those bottlenecks! Your entire organization will thank you.

And if you get stuck or need any help, don’t hesitate to reach out at hello at coryfoy dot com. I regularly perform assessments and VSMs for clients in a wide variety of industries and governments, and would be more than happy to help yours.

Until next time, here’s to tracking down your delays!









{ 0 comments }
A wardley map showing remote work and rapid delivery evolving to be critical elements

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 in this week’s Mapping Monday I want to finish off a series on using Wardley Mapping and the Product Positioning Framework to find the best ways to position your product to your customers.

So far we’ve covered four of the five plus one components of product positioning. So now it’s time to look at our last grouping – Market Category and Relevant Trends. These are incredibly powerful and important because they help our customers map their internal models to what our product does and understand why it’s important to them. But what does that mean?

Well, in previous videos we’ve talked about looking at Competitive Alternatives to your product – shown here as comparing our Bug Tracking Tool to a Spreadsheet,

as well as diving into the Unique Attributes of our product, and comparing those to our competitors. But that’s not what we want our customers to have to do. We want them to be able to rapidly identify with our product – to “get it” from the start.

The fifth component in Dunford’s framework is Market Categories. I briefly explained earlier how they help customers use what they know – their internal mental models – to figure out what they don’t – what our product is. But that also means that if they’re not doing mapping like we did earlier, then they are making assumptions. And if we’re not careful, those assumptions can lead to negative experiences, since customers will have expectations about what our product is in relation to the market.

As an example, throughout this series we’ve declared ourselves as a bug tracking tool. If we run with that as our market category, customers are immediately going to put us in a very specific box. They likely have experience with Jira, or Trello, or Service Desk, or many other products. They’re going to expect certain features like reporting and integration. They’re going to expect certain pricing models. And they’re going to be frustrated if your product doesn’t follow the market leader.

But, one of the other exercises we did was determining our target market and the value we give to them. And in this case, it wasn’t about bug tracking, but about coordination and collaboration. Yes, tracking work was important, but it wasn’t the critical element.

So maybe instead of a Bug Tracking Tool, we market ourselves as Team Coordination Software. It allows us to rapidly have people understand our focus area – teams that need to coordinate work – while also sidestepping us from the crowded Bug Tracking market. However, we may want to find other competitors labeling themselves in this market and map out their streams to understand how we’ll fit in to assumptions customers may have.

Market Categories give us the power of assumptions. But next we need the power of action. And in this case we can create a deadly combination with Wardley Maps and the Product Positioning concept of Relevant Trends. Here we’re helping customers understand why they need to make this shift now – so they aren’t left behind.

For example, software development used to be a somewhat stable process. We owned and built the software, and we often owned and possibly built the compute power the software ran on. So we controlled the pace of delivery and the structure of teams.

But compute power has shifted towards being a utility, and software increasingly relies on building parts from off the shelf or open source components. This has an underlying effect on the components that rely on it.

Because now the notion of rapid delivery is more critical, and being able to effectively coordinate and collaborate work across many sites around the globe is becoming the norm. Therefore the principles of remote work apply to how we get things done every day.

We can now show customers these trends, and be able to talk about how the market evolution means that they need better tools for coordination and collaboration that allows them to take advantage of the evolving market. Then you can get them excited for what you have to offer!

So when you have a product, or are thinking about creating one, I’d highly recommend picking up Obviously Awesome and then combining Wardley Mapping and her Product Positioning framework to create some Obviously Awesome insights!

Hope you’ve enjoyed this series! 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, stay awesome!









{ 0 comments }
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 }