Archive for the ‘Decisions’ Category

Your response is your responsibility.

If you don’t want to go to work in the morning, there’s a reason. If’ you/re angry with how things go, there’s a reason.  And if you you’re sad because of the way that people treat you, there’s a reason. But the reason has nothing to do with your work, how things are going or how people treat you. The reason has everything to do with your ego.

And your ego has everything to do with what you think of yourself and the identity you attach to yourself. If you don’t want to go to work, it’s because you don’t like what your work says about you or your image of your self.  If you are angry with how things go, it’s because how things go says something about you that you don’t like.  And if you’re sad about how people treat you, it’s because you think they may be right and you don’t like what that says about you.

The work is not responsible for your dislike of it. How things go is not responsible for your anger. And people that treat you badly are not responsible for your sadness. Your dislike is your responsibility, your anger is your responsibility and your sadness is your responsibility. And that’s because your response is your responsibility.

Don’t blame the work. Instead, look inside to understand how the work cuts against the grain of who you think you are. Don’t blame the things for going as they go. Instead, look inside to understand why those things don’t fit with your self-image.  Don’t blame the people for how they treat you. Instead, look inside to understand why you think they may be right.

It’s easy to look outside and assign blame for your response. It’s the work’s fault, it’s the things’ fault, and it’s the people’s fault. But when you take responsibility for your response, when you own it, work gets better, things go better and people treat you better.  Put simply, you take away their power to control how you feel and things get better.

And if work doesn’t get better, things don’t go better and people don’t treat you better, not to worry. Their responses are their responsibility.

Image credit Mrs. Gemstone

Choosing What To Do

In business you’ve got to do two things: choose what to do and choose how to do it well.  I’m not sure which is more important, but I am sure there’s far more written on how to do things well and far less clarity around how to choose what to do.

Choosing what to do starts with understanding what’s being done now.  For technology, it’s defining the state-of-the-art. For the business model, it’s how the leading companies are interacting with customers and which functions they are outsourcing and which they are doing themselves. In neither case does what’s being done define your new recipe, but in both cases it’s the first step to figuring how you’ll differentiate over the competition.

Every observation of the state-of-the-art technologies and latest business models is a snapshot in time.  You know what’s happening at this instant, but you don’t know what things will look like in two years when you launch. And that’s not good enough. You’ve got to know the improvement trajectories; you’ve got to know if those trajectories will still hold true when you’ll launch your offering; and, if they’re out of gas, you’ve got to figure out the new improvement areas and their trajectories.

You’ve got to differentiate over the in-the-future competition who will constantly improve over the next two years, not the in-the-moment competition you see today.

For technology, first look at the competitions’ websites. For their latest product or service, figure out what they’re proud of, what they brag about, what line of goodness it offers.  For example, is it faster, smaller, lighter, more powerful or less expensive?  Then, look at the product it replaced and what it offered. If the old was faster than the one it replaced and the newest one was faster still, their next one will try to be faster.  But if the old one was faster than the one it replaced and the newest one is proud of something else, it’s likely they’ll try to give the next one more of that same something else.

And the rate of improvement gives another clue.  If the improvement is decreasing over time (old product to new product), it’s likely the next one will improve on a new line of goodness.  If it’s still accelerating, expect more of what they did last time.  Use the slope to estimate the magnitude of improvement two years from now.  That’s what you’ve got to be better than.

And with business models, make a Wardley Map.  On the map, place the elements of the business ecosystem (I hate that word) and connect the elements that interact with each other.  And now the tricky part.  Move to the right the mature elements (e.g., electrical power grid), move to the middle the immature elements (things that are clunky and you have to make yourself) and move to the middle the parts you can buy from others (products).  There’s a north-south element to the maps, but that’s for another time.

The business model is defined by which elements the company does itself, which it buys from others and which new ones they create in their labs.  So, make a model for each competitor.  You’ll be able to see their business model visually.

Now, which elements to work on?  Buy the ones you can buy (middle), improve the immature ones on the far left so they move toward the central region (product) and disrupt the lazy utilities (on the right) with some crazy technology development and create something new on the far left (get something running in the lab).

Choosing what to work on starts with Observation of what’s going on now. Then, that information is Oriented with analysis, synthesis and diverse perspective.  Then, using the best frameworks you know, a Decision is made.  And then, and only then, can you Act.

And there you have it.  The makings of an OODA loop-based methodology for choosing what to do.

 

For a great podcast on John Boyd, the father of the OODA loop, try this one.

And for the deepest dive on OODA (don’t start with this one) see Osinga – Science, Strategy and War.

How to Choose the Best Idea

We have too many ideas, but too few great ones.  We don’t need more ideas, we need a way to choose the best one or two ideas and run them to ground.

Before creating more ideas, make a list of the ones you already have.  Put them in two boxes.  In Box 1, list the ideas without a video of a functional prototype in action.  In Box 2, list the ideas that have a video showing a functional prototype demonstrating the idea in action.  For those ideas with a functional prototype and no video, put them in Box 1.

Next, throw away Box 1. If it’s not important enough to make a crude physical prototype and create a simple video, the idea isn’t worth a damn.  If someone isn’t willing to carve out the time to make a physical prototype, there’s no emotional energy behind the idea and it should be left to die.  And when people complain that it’s unfair to throw away all those good ideas in Box 1, tell them it’s unfair to spend valuable resources talking about ideas that aren’t worthy.  And suggest, if they want to have a discussion about an idea, they should build a physical prototype and send you the video.  Box 2, or bust.

Next, get the band together and watch the short videos in Box 2, and, as a group, put them in two boxes.  In Box 3, put the videos without customers actively using the functional prototype.  In Box 4, put the videos with customers actively using the functional prototype.

Next, throw way Box 3.  If it’s not important enough to make a trip to an important customer and create a short video, the idea isn’t worth a damn.  If you’re not willing to put yourself out there and take the idea to an important customer, the idea is all fizzle and no sizzle.  Meaningful ideas take immense personal energy to run through the gauntlet, and without a video of a customer using the functional prototype, there’s not enough energy behind it.  And when everyone argues that Box 3 ideas are worth pursuing, tell them to pursue a video showing a most important customer demonstrating the functional prototype.

Next, get the band back together to watch the Box 4 videos.  Again, put the videos in two boxes. In Box 5 put the videos where the customer didn’t say what they liked and how they’d use it.  In Box 6, put the videos where the customer enthusiastically said what they liked and how they’ll use it.

Next, throw away Box 5.  If the customer doesn’t think enough about the prototype to tell you how they’ll use it, it’s because they don’t think much of the idea.  And when the group says the customer is wrong or the customer doesn’t understand what the prototype is all about, suggest they create a video where a customer enthusiastically explains how they’d use it.

Next, get the band back in the room and watch the Box 6 videos.  Put them in two boxes.  In Box 7, put the videos that won’t radically grow the top line.  In Box 8, put the videos that will radically grow the top line.  Throw away Box 7.

For the videos in Box 8, rank them by the amount of top line growth they will create.  Put all the videos back into Box 8, except the video that will create the most top line growth.  Do NOT throw away Box 8.

The video in your hand IS your company’s best idea.  Immediately charter a project to commercialize the idea.  Staff it fully.  Add resources until adding resources doesn’t no longer pulls in the launch.  Only after the project is fully staffed do you put your hand back into Box 8 to select the next best idea.

Continually evaluate Boxes 1 through 8.  Continually throw out the boxes without the right videos.  Continually choose the best idea from Box 8.  And continually staff the projects fully, or don’t start them.

Image credit – joiseyshowaa

Don’t trust your gut, run the test.

At first glance, it seems easy to run a good test, but nothing can be further from the truth.

The first step is to define the idea/concept you want to validate or invalidate.  The best way is to complete one of these two sentences: I want to learn that [type your idea here] is true. Or, I want to learn that [enter your idea here] is false.

Next, ask yourself this question: What information do I need to validate (or invalidate) [type your idea here]?  Write down the information you need.  In the engineering domain, this is straightforward: I need the temperature of this, the pressure of that, the force generated on part xyz or the time (in seconds) before the system catches fire.  But for people-related ideas, things aren’t so straightforward. Some things you may want to know are: how much will you pay for this new thing, how many will you buy, on a scale of 1 to 5 how much do you like it?

Now the tough part – how will you judge pass or fail?  What is the maximum acceptable temperature? What is the minimum pressure? What is the maximum force that can be tolerated? How many seconds must the system survive before catching fire?  And for people: What is the minimum price that can support a viable business? How many must they buy before the company can prosper? And if they like it at level 3, it’s a go. And here’s the most importance sentence of the entire post:

The decision criteria must be defined BEFORE running the test.

If you wait to define the go/no-go criteria until after you run the test and review the data, you’ll adjust the decision criteria so you make the decision you wanted to make before running the test. If you’re not going to define the decision criteria before running the test, don’t bother running the test and follow your gut.  Your decision will be a bad one, but at least you’ll save the time and money associated with the test.

And before running the test, define the test protocol.  Think recipe in a cookbook: a pinch of this, a quart of that, mix it together and bake at 350 degrees Fahrenheit for 40 minutes.  The best protocols are simple and clear and result in the same sequence of events regardless of who runs the test.  And make sure the measurement method is part of the protocol – use this thermocouple, use that pressure gauge, use the script to ask the questions about price and the number they’d buy.

And even with all this rigor, good judgement is still part of the equation.  But the judgment is limited to questions like: did we follow the protocol? Did the measurement system function properly? Do the initial assumptions still hold? Did anything change since we defined the learning objective and defined the test protocol?

To create formal learning objectives, to write well-defined test protocols and to formalize the decision criteria before running the test require rigor, discipline, time and money.  But, because the cost of making a bad decision is so high, the cost of running good tests is a bargain at twice the price.

Image credit – NASA Goddard Flight Center

Leadership isn’t binary, and that’s why judgement is important.

100% of the people won’t like your new idea, even if it’s a really good one like the airplane, mayonnaise or air conditioning.

I don’t know the right amount of conflict, but I know it’s not 0% or 100%.

If 100% is good, 110% isn’t better. Percentages don’t work that way.

100% alignment is not the best thing. Great things aren’t built on the back of consensus.

100% of the problems shouldn’t be solved.  Sometimes it’s best to let the problem blossom into something that cannot be dismissed, denied or avoided.

Fitting in can be good, but not 100% of the time. Sometimes the people in power need to hear the truth, even if you know they’ll choke on it.

If the system is in the way, work the rule. Follow it 100%, follow it to the letter, follow it until it’s absurd. But, keep in mind the system isn’t in the way 100% of the time.

Following the process 100% eliminates intellectual diversity. And, as Darwin said, that leads to extinction.  I think he was onto something.

Trying to fix 100% of the problems leads to dilution. Solve one at a time until you’re done.

The best tool isn’t best 100% of the time. Here’s a rule: If the work’s new, try a new tool. You can’t cut a board with a hammer.

I don’t know how frequently to make mistakes, but I know it’s not 0% or 100% of the time.

As a sport, leadership isn’t binary. That’s why we’re paid to use our good judgement.

Image credit – Joe Dyer

The Duplicitous Relationship Between Time and Money

If you had a choice to make an extra year’s salary or live an extra year, which would you choose? If you had a choice to make an extra month’s salary or live an extra month, make the same choice? What about the trade between a week’s pay and a week of life? Does anything change when it’s a choice between ten years of salary and ten years of life? Does this thought experiment change anything for you? If not, no worries. It was a low-cost experiment.

If you decided you had enough money, how would you change your behavior? Would you spend more time with your kids? Would you take the time to decompress and enjoy what you have? Or would you spend more money so no longer had enough? What if next week you pretend you have enough money? Would things change? Is there a downside to spending more time with your family next week? Why not try it?

If every day you reminded yourself your lifespan was finite, would you live differently? If you reminded yourself every morning for the next week, would things change? It’s a low-cost experiment, and only the first two mornings are scary.  The experiment is free. Why not try?

What if you decided you didn’t want a promotion? Would you work differently? Would you use more judgment because the cost of failure is lower? Would you take more initiative? Would you say no more often? Or would you say yes more often? Would you choose to work on different projects? Why not try it for a week?  Who knows, you may get a promotion.

What if you decided you had enough stuff? What would you do with the extra money? Would give some to charity? Would you save up and buy more stuff? For the next week, why not remove one thing from your house and recycle it or give it away? You may teach yourself you have too much stuff; you may teach yourself your house looks better when it’s less cluttered, or you may feel good that your gift helped someone who didn’t have enough. There’s little downside to more pocket change, a decluttered house and helping others. Why not try it next week?

Every day we make trades between time and money, but we make them in a below-the-water-level way. And every day we choose between having enough or not, and, again, we make these choices in a less-than-fully-conscious way.  But these choices are far too important to make lightly.

Why not make some time every day to quiet yourself so you can be more aware of the day’s decisions?  It’s a low-cost experiment that could bring more clarity to your decision-making. Why not try it for a week?

image credit – Tax Credits

If you don’t know what to do, you may be on the right track.

What would you do if:

You had to push through your fear of being judged?

You had to break some rules to get an idea off the ground?

You had a concept that would displace your most successful product?

Your colleague tried to scuttle your best idea?

You knew it was time to stop judging yourself negatively?

Your colleague asked you to help with a hair-brained idea?

You were asked to facilitate a session to create new concepts, but no one could explain what would happen after the concepts were created?

You weren’t afraid your prototype would be a success?

You thought you knew what the customer wanted, but didn’t have the data to prove it?

You were asked to create patentable concepts you knew would never be commercialized?

Your prototype threatened the status quo?

You were asked to facilitate a session to create new concepts and told how to do it?

You were told “No.”

You saw a young employee struggling with a new concept?

You were blocking yourself from starting the right work?

You thought your idea had merit, but you needed help testing it in the market?

You were asked to follow a standard process but you knew there wasn’t one?

You were asked to come up with new concepts though there were five excellent concepts gathering dust?

You were told there was no market for your new-to-world prototype?

You had to bolster your self-confidence to believe wholeheartedly in your idea?

There is a name for what you would do. It’s called innovation.

 

image credit – UnknownNet Photography

Diabolically Simple Prototypes

Ideas are all talk and no action.  Ideas are untested concepts that have yet to rise to the level of practicality.  You can’t sell an idea and you can’t barter with them. Ideas aren’t worth much.

A prototype is a physical manifestation of an idea. Where ideas are ethereal, prototypes are practical. Where ideas are fuzzy and subject to interpretation, prototypes are a sledge hammer right between the eyes.  There is no arguing with a prototype. It does what it does and that’s the end of that. You don’t have to like what a prototype stands for, but you can’t dismiss it. Where ideas aren’t worth a damn, prototypes are wholly worth every ounce of effort to create them.

If Camp A says it will work and Camp B says it won’t, a prototype will settle the disagreement pretty quickly.  It will work or it won’t.  And if it works, the idea behind it is valid.  And if it doesn’t, the idea may be valid, but a workable solution is yet-to-be discovered.  Either way, a prototype brings clarity.

Prototypes are not elegant.  Prototypes are ugly. The best ones do one thing – demonstrate the novel idea that underpins them. The good ones are simple, and the best ones are diabolically simple. It is difficult to make diabolically simple prototypes (DSPs), but it’s a skill that can be learned.  And it’s worth learning because DSPs come to life in record time. The approach with DSPs is to take the time up front to distill the concept down to its essence and then its all-hands-on-deck until it’s up and running in the lab.

But the real power of the DSP is that it drives rapid learning.  When a new idea comes, it’s only a partially formed.  The process of trying to make a DSP demands the holes are filled and blurry parts are brought into focus.  The DSP process demands a half-baked idea matures into fully-baked physical embodiment.  And it’s full-body learning.  Your hands learn, your eyes learn and your torso learns.

If you find yourself in a disagreement of ideas, stop talking and start making a prototype. If the DSP works, the disagreement is over.

Diabolically simple prototypes end arguments. But, more importantly, they radically increase the pace of learning.

Image credit – snippets101

Learning at the expense of predicting.

john_william_waterhouse_-_the_crystal_ballWhen doing new things there is no predictability. There’s speculation, extrapolation and frustration, but no prediction. And the labels don’t matter.  Whether it’s called creativity, innovation, discontinuous improvement or disruption there’s no prediction.

The trick in the domain complexity is to make progress without prediction.

The first step is to try to define the learning objective.  The learning objective is what you want to learn. And its format is – We want to learn that [fill in the learning objective here].  It’s fastest to tackle one learning objective at a time because small learning objectives are achieved quickly with small experiments.  But, it will be a struggle to figure out what to learn.  There will be too many learning objectives and none will be defined narrowly.  At this stage the fastest thing to do is stop and take a step back.

There’s nothing worse than learning about the wrong thing.  And it’s slow. (The fastest learning experiments are the ones that don’t have to be run.) Before learning for the sake of learning, take the necessary time to figure out what to learn. Ask some questions: If it worked could it reinvent your industry? Could it obsolete your best product? Could it cause competitors to throw in the towel?  If the answer is no, stop the project and choose one where the answer is yes. Choose a meaningful project, or don’t bother.

First learning objective – We want to learn that, when customers love the new concept, the company will assign appropriate resources to commercialize it.  If there’s no committment up front, stop.  If you get committment, keep going. (Without upfront buy-in the project relies on speculation, the wicked couple of prediction and wishful thinking.)

Second learning objective – We want to learn that customers love the new concept.  This is not “I think customers will love it.” or “Customers may love it.” In the standard learning objective format – We want to learn that [customers love the new concept].  Next comes the learning plan.

What will you build for customers to help them understand the useful novelty of the revolutionary concept?  For speed’s sake, build a non-functional prototype that stands for the concept.  It’s a thin skin wrapped around an empty box that conveys the essence of the novelty.  No skeleton, just skin.  And for speed’s sake, show it to fewer customers than you think reasonable.  And define the criteria to decide they love it.  There’s no trick here. Ask “Do they love it?” and use your best judgement.  At this early stage, the answer will be no.  But they’ll tell you why they don’t love it, and that’s just the learning you’re looking for.

Use customer input to reformulate the learning objective and build a new prototype and repeat.  The key here is to build fast, test fast, learn fast and repeat fast.  The art becomes defining the simplest learning objectives, building the simplest prototypes and making decisions with data from the fewest customers.

With complexity and newness prediction isn’t possible. But learning is.

And learning doesn’t have to take a lot of time.

Image credit — John William Waterhouse

Sort By Importance

ships-engine-order-telegraphUrgency is important, but it’s not everything. It creates focus, but washes out the radical fringe. It’s easy to measure, but easy to measure doesn’t mean it’s the best thing to work on.

In the heat of the moment urgency is king. Frantic project managers take shortcuts to meet a deadline defined fourteen months ago; Lean Startup-ers ready-fire-aim their way from pivot to pivot; And resources flow to projects that are scheduled to finish soonest.

Urgency is attractive because it’s so clear cut, so objective, so easy to measure.

Due Date – Today’s Date = Urgency.

There’s always consensus on today’s date, everyone knows the due date and subtraction come easily.  There you go. No debate, no discussion.  This project has more urgency than that one.  Just do the math. But where did the due date come from? Did the work content define the due date?  If so, projects with the least work content, with their immanent due date, are the most urgent and resources should flow to the shortest projects.  Did the annual trade show set the due date?  If so, projects with earliest trade shows should get priority.  Did the CEO define the due date for reasons unknown to mere mortals?  If so, projects that finish before the declared date should get priority and projects that finish after the due date should get put on the back burner.

Project scope defines work content and start date plus work content equals due date.  For two projects with equal work content, the project that starts first has more urgency. Should projects start sooner to increase urgency? Should project plans pile on resources to pull in the completion date to increase urgency? Should project managers strip the sizzle out of projects so they finish sooner?

Urgency isn’t important. Importance is important.

The problem with importance is its subjective nature. Because there is no objective measure of importance, judgement is required.  The cold scoring systems to rank projects don’t work.  There are no scoring rubrics, no algorithms, no customized weighting factors that can objectively quantify importance.  It’s either important or it isn’t.  It’s important in the chest, or it’s not. It’s all about judgement.

The context defines what’s important. Market share has dropped five years in a row, some projects are more important than others. Market share has increased five years in a row, a different set of projects is important. Can’t make payroll, urgency-based project selection is best. Technology is long in the tooth, it’s important to fund projects that buy or build new technology. Which projects are most important? It depends.

The best way to sort projects by importance is to ask “Is this project important?” and have a discussion. Some projects will have more upside and others will have more certainty.  Some could create new markets and other will proved two percent growth in a guaranteed way. Which are most important? It depends.

Importance is relative. Use the “Is this project important?” methodology to force rank your projects by importance.  Once complete, take a step back and ask if the ranked list makes sense.  Reshuffle if needed.  Starting from the top, fully staff the most important project. For the next most important project, allocate the remaining resources and repeat the process project-by-project until the resources are gone.  This process ensures the most important projects on the list get the resources. But there’s a hole in the methodology.

What if our innate urgency bias keeps the most important projects off the list?

Image credit – Stephen Depolo

When doing new work, you’ll be wrong.

OOPSWhen doing something from the first time you’re going to get it wrong.  There’s no shame in that because that’s how it goes with new work. But more strongly, if you don’t get it wrong you’re not trying hard enough.  And more strongly, embrace the inherent wrongness as a guiding principle.

Take Small Bites. With new work, a small scope is better than a large one.  But it’s exciting to do new work and there’s a desire to deliver as much novel usefulness as possible.  And, without realizing it, the excitement can lead to a project bloated with novelty.  With the best intentions, the project team is underwater with too much work and too little time.  With new work, it’s better to take one bite and swallow than three and choke.

Ratchet Thinking. With new work comes passion and energy.  And though the twins can be helpful and fun to have around, they’re not always well-behaved.  Passion can push a project forward but can also push it off a cliff. Energy creates pace and can quickly accelerate a project though the milestones, but energy can be careless and can just as easily accelerate a project in the wrong direction.  And that’s where ratchet thinking can help.

As an approach, the objective of ratchet thinking is to create small movements in the right direction without the possibility of back-sliding.  Solve a problem and click forward one notch; solve a second problem and click forward another notch.  But, with ratchet thinking, if the third problem isn’t solved, the project holds its ground at the second notch.  It takes a bit more time to choose the right problem and to solve it in a way that cannot unwind progress, but ultimately it’s faster.  Ratchet thinking takes the right small bite, chews, swallows.

Zero Cost of Change. New work is all about adding new functions, enhancing features and fixing what’s broken.  In other words, new work is all about change. And the faster change can happen, the faster the product/service/business model is ready for sale.  But as the cost of change increases the rate of changes slows.  So why not design the project to eliminate the cost of change?

To do that, design the hardware with a bit more capability and headroom so there’s some wiggle room to handle the changes that will come.  Use a modular approach for the software to minimize the interactions of software changes and make sure the software can be updated remotely without customer involvement.  And put in place a good revision control (and tracking) mechanism.

Doing new work is full of contradictions: move quickly, but take the time to think things through; take on as much as you can, but no more; be wrong, but in the right way; and sometimes slower is faster.

But doing new work you must.

image credit – leasqueaky

Mike Shipulski Mike Shipulski
Subscribe via Email

Enter your email address:

Delivered by FeedBurner