Archive for the ‘Decisions’ Category

The primary responsibility of management is to allocate resources in the way that best achieves business objectives. If there are three or four options to allocate resources, which is the best choice? What is the time horizon for the decision? Is it best to hire more people? Why not partner with a contract resource company? Build a new facility or add to the existing one? No right answers, but all require a decision.

Rule 1 – Make decisions overtly. All too often, decisions happen slowly over time without knowledge the decision was actually made. A year down the road, we wake up from our daze and realize we’re all aligned with a decision we didn’t know we made. That’s bad for business. Make them overtly and document them.

Rule 2 – Define the decision criteria before it’s time to decide. We all have biases and left to our own, we’ll make the decision that fits with our biases. For example, if we think the project is a good idea, we’ll interpret the project’s achievements through our biased lenses and fund the next phase. To battle this, define the decision criteria months before the funding decision will be made. Think if-then. If the project demonstrates A, then we’ll allocate $50,000 for the next phase; if the project demonstrates A, B and C, then we’ll allocate $100,000; if the project fails to demonstrate A, B or C, then we’ll scrap the project and start a new one. If the decision criteria aren’t predefined, you’ll define them on-the-spot to justify the decision you already wanted to make.

Rule 3 – Define who will decide before it’s time to decide. Will the decision be made by anonymous vote or by a show of hands? Is a simple majority sufficient, or does it require a two-thirds majority? Does it require a consensus? If so, does it have to be unanimous or can there be some disagreement? If there can be disagreement, how many people can disagree? Does the loudest voice decide? Or does the most senior person declare their position and everyone else falls in line like sheep?

Think back to the last time your company made a big decision. Were the decision criteria defined beforehand? Can you go back to the meeting minutes and find how the project performed against the decision criteria? Were the if-then rules defined upfront? If so, did you follow them? And now that you remember how it went last time, do you think you would have made a better decision if the decision criteria and if-thens were in place before the decision? Now, decide how it will go next time.

And for that last big decision, is there a record of how the decision was made? If there was a vote, who voted up and who voted down? If a consensus was reached, who overtly said they agreed to the decision and who dissented? Or did the most senior person declare a consensus when in fact it was a consensus of one? If you can find a record of the decision, what does the record show? And if you can’t find the record, how do you feel about that? Now that you reflected on last time, decide how it will go next time.

It’s scary to think about how we make decisions. But it’s scarier to decide we will make them the same way going forward. It’s time to decide we will put more rigor into our decision making.

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.

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.

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.

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.

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?

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

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.

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

Urgency 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?