Archive for the ‘Assumptions’ Category
When doing new work, you’ll be wrong.
When 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
Diabolically Simple Questions
Today’s work is complicated with electronic and mechanical subsystems wrapped in cocoons of software; coordination of matrixed teams; shared resources serving multiple projects; providing world class services in seventeen languages on four continents. And the complexity isn’t limited to high level elements. There is a living layer of complexity growing on all branches of the organization right down to the leaf level.
Complexity is real, and it complicates things. To run projects and survive in the jungle of complexity it’s important to know how to put the right pieces together and provide the right answers. But as a leader it’s more important to slash through the complexity and see things as they are. And for that, it’s more important to know how ask diabolically simple questions (DSQ).
Project timelines are tight and project teams like to start as soon as they can. Too often teams start without clarity on what they’re trying to achieve. At these early stages the teams make record progress in the wrong direction. The leader’s job is to point them in the right direction, and here’s the DSQ to set them on their way: What are you trying to achieve?
There will likely be some consternation, arm waiving and hand wringing. After the dust settles, help the team further tighten down the project with this follow-on DSQ: How will you know you achieved it?
For previous two questions there are variants that works equally well for work that closer to the fuzzy front end: What are you trying to learn? and How will you know you learned it?
There is no such thing as a clean-sheet project and even the most revolutionary work builds on the existing system. Though the existing business model, service or product has been around for a long time, the project team doesn’t really know how it works. They know they should know but they’re afraid to admit it. Let them off the hook with this beauty: How does it work today?
After the existing system is defined with a simple block diagram (which could take a couple weeks) it’s time to help the project team focus their work. The best DSQ for the job: How is it different from the existing system? If the list is too long there’s too much newness and if it’s too short there’s not enough novelty. If they don’t know what’s different, ask them to come back when they know.
After the “what’s different” line of questioning, the team must be able to dive deeper. For that it’s time one of the most powerful DSQs in the known universe: What problem are you trying to solve? Expect frustration and complicated answers. Ask them to take some time and for each problem describe it on a single page using less than ten words. Suggest a block diagram format and ask them to define where and when the problem occurs. (Hint: a problem is always between two components/elements of the system.) And the tricky follow-on DSQ: How will you know you solved it? No need to describe the reaction to that one.
Though not an exhaustive list, here are some of my other favorite DSQs:
Who will buy it, how much will they pay, and how do you know?
Have we done this before?
Have you shown it to a real customer?
How much will it cost and how do you know?
Whose help do we need?
If the prototype works, will we actually do anything with it?
Diabolically simple questions have the power to heal the project teams and get them back on track. And over time, DSQs help the project teams adopt a healthy lifestyle. In that way, DSQs are like medicine – they taste bad but soon enough you feel better.
Image credit – Daniela Hartmann
How To Allocate Resources
How a company allocates its resources defines its strategy. But it’s tricky business to allocate resources in a way that makes the most of the existing products, services and business models yet accomplishes what’s needed to create the future.
To strike the right balance, and before any decisions on specific projects, allocate the desired spending into three buckets – short, medium and long. Or, if you prefer, Horizon 1, 2 and 3. Use the business objectives to set the weighting. Then, sit next to the CFO for a couple days and allocate last year’s actual spending to the three buckets and compare the actuals with how resources will be allocated going forward. Define the number of people who will work on short, medium and long and how many will move from one bucket to another.
To get the balance right, short term projects are judged relative to short term projects, medium term projects are judged relative to medium term projects and the long term ones are judged against their long term peers. Long term projects cannot be staffed at the expense of short term projects and medium term projects cannot take resources from long term projects. To get the balance right, those are the rules.
To choose the best projects within each bucket, clarity and constraints are more important than ROI. Here are some questions to improve clarity and define the constraints.
How will the customer benefit? It’s best to show the customer using the product or service or experiencing the new business model. Use a hand sketch and few, if any, words. Use one page.
How is it different? In the hand sketch above, draw the novel (different) elements in red.
Who is the new customer? Define where they live, the language they speak and how they get the job done today.
Are there regional constraints? Infrastructure gaps, such as electricity, water, transportation are deal breakers. Language gaps can be big problems, so can regulatory, legal and cultural constraints. If a regional constraint cannot be overcome, do something else.
How will your company make money? Use this formula: (price – cost) x volume. But, be clear about the size of the market today and the size it could be in five years.
How will you make, sell and service it? Include in the cost of the project the cost to overcome organizational capacity/capability constraints. If cost (or time) to close the gaps is prohibitive, do something else.
How will the business model change? If it won’t, strongly consider a different project.
If the investigations show the project is worthwhile, how would you staff the project and when? This is an important one. If the project would be a winner, but there is no one to work on it, do something else. Or, consider stopping a bad project to start the good one.
There’s usually a general tendency to move medium term resources to short term projects and skimp on long term projects. Be respectful of the newly-minted resource balance defined at the start and don’t choose a project from one bucket over a project from another. And don’t get carried away with ROI measured to three significant figures, rather, hold onto the fact that an insurmountable constraint reduces ROI to zero.
And staff projects fully. Partially-staffed projects set expectations that good things are happening, but they never come to be.
Image credit – john curley
Stop bad project and start good ones.
At the most basic level, business is about allocating resources to the best projects and executing those projects well. Said another way, business is about deciding what to work on and then working effectively. But how to go about deciding what to work on? Here is a cascade of questions to start you on your journey.
What are your company’s guiding principles? Why does it exist? How does it want to go about its life? These questions create context from which to answer the questions that follow. Once defined, all your actions should align with your context.
How has the business environment changed? This is a big one. Everything is impermanent. Change is the status quo. What worked last time won’t work this time. Your success is your enemy because it stunts intentions to work on new things. Define new lines of customer goodness your competitors have developed; define how their technologies have increased performance; search YouTube to see the nascent technologies that will displace you; put yourself two years in the future where your customers will pay half what they pay today. These answers, too, define the context for the questions that follow.
What are you working on? Define your fully-staffed projects. Distill each to a single page. Do they provide new customer value? Are the projects aligned with your company’s guiding principles? For those that don’t, stop them. How do your fully-staffed projects compare to the trajectory of your competitors’ offerings? For those that compare poorly, stop them.
For projects that remain, do they meet your business objectives? If yes, put your head down and execute. If no, do you have better projects? If yes, move the freed up resources (from the stopped projects) onto the new projects. Do it now. If you don’t have better projects, find some. Use lines of evolution for technological systems to figure out what’s next, define new projects and move the resources. Do it now.
The best leading indicator of innovation is your portfolio of fully-staffed projects. Where other companies argue and complain about organizational structure, move your best resources to your best projects and execute. Where other companies use politics to trump logic, move your best resources to your best projects and execute. Where other successful companies hold on to tired business models and do-what-we-did-last-time projects, move your best resources to your best projects and execute.
Be ruthless with your projects. Stop the bad ones and start some good ones. Be clear about what your projects will deliver – define the novel customer value and the technical work to get there. Use one page for each. If you can’t define the novel customer value with a simple cartoon, it’s because there is none. And if you can’t define how you’ll get there with a hand sketch, it’s because you don’t know how.
Define your company’s purpose and use that to decide what to work on. If a project is misaligned, kill it. If a project is boring, don’t bother. If it’s been done before, don’t do it. And if you know how it will go, do something else.
If you’re not changing, you’re dying.
Image credit – David Flam
Put your success behind you.
The biggest blocker of company growth is your successful business model. And the more significant it’s historical success, the more it blocks.
Novelty meaningful to the customer is the life force of company growth. The easiest novelty to understand is novelty of product function. In a no-to-yes way, the old product couldn’t do it, but the new one can. And the amount of seconds it takes for the customer to notice (and in the case of meaningful novelty, appreciate) the novelty is in an indication of its significance. If it takes three months of using the product, rigorous data collection and a t-test, that’s not good. If the customer turns on the product and the novelty smashes him in the forehead like a sledgehammer, well, that’s better.
It’s difficult to create a product with meaningful novelty. Engineers know what they know, marketers know what they market, and the salesforce knows how to sell what they sell. And novelty cuts across their comfort. The technology is slightly different, the marketing message diverges a bit, and the sales argument must be modified. The novelty is driven by the product and the people respond accordingly. And, the new product builds on the old one so there’s familiarity.
Where injecting novelty into the product is a challenge, rubbing novelty on the business model provokes a level 5 pucker. Nothing has the stopping power of a proposed change to the business model. Novelty in the product is to novelty in the business model as lightning is to lightning bug – they share a word, but that’s it.
Novelty in the product is novelty of sheet metal, printed circuit boards and software. Novelty in the business model is novelty in how people do their work and novelty in personal relationships. Novelty in the product banal, novelty in the business model is personal.
No tools or best practices can loosen the pucker generated by novelty in the business model. The tired business model has been the backplane of success for longer than anyone can remember. The long-in-the-tooth model has worn deep ruts of success into the organization. Even the all-powerful Lean Startup methodology can’t save you.
The healing must start with an open discussion about the impermanence of all things, including the business model. The most enduring radioactive element has a half-life, and so does the venerable business model, even the most successful.
Where novelty in the product is technical, novelty in the business model is emotional. And that’s what makes it so powerful. Sprinkling the business model with novelty is scary at a deeply personal level – career jeopardy, mortgage insecurity and family volatility are primal drivers. But if you can push through, the rewards are magical.
Your business model has shaped you into an organization that’s optimized to do what it does. You can’t create new markets and sell to new products to new customers without changing your business model. Your business model may have been your secret sauce, but the world’s tastes have changed. It’s time to put your success behind you.
Image credit — MandaRose
The cards don’t matter. What matters is how you play them.
What you think of yourself colors everything you do. When someone challenges your ideas, your response makes it clear how you see yourself. Regardless of your response, you tip your hand. Regardless of your response, everyone can see your cards.
When you have a terrible poker hand like, say, a king high, you can respond three ways. You can fold and let the challenger go unchallenged. You can check and kick the can down the road. Or you can bluff and go toe-to-toe with the challenger. With the fold you see things as they are and behave accordingly. The fold is an admission you have a lesser hand. And sometimes that’s difficult to do. The check says you don’t want others to know you have a terrible hand but you thing things will turn around. With the bluff you pretend things are different than they are and you pretend accordingly. You may fool the unseasoned player on your right, but make no mistake, the card shark on your left knows you’re bluffing. And deep down, you know too.
With a middle-of-the-road hand like the full house you have the same options. The fold is less likely because your hand is stronger. You fold only when you sense a strong challenge and the pot is large. No sense going head-to-head with a player with swagger when the stakes are high. There’s no harm in folding. The check says you’re not sure of yourself, or, you are and your hand is neither special nor terrible. The bluff is still risky but less so. If you think you can survive getting caught and are okay with the follow-on judgement, there’s a larger probability you’ll try.
With four aces you call the shots. The fold is reserved for those special situations where you want to preserve the status of players you care about. Or, when you have enough chips and you want others to get the glory. Either way it’s too little used. Few have the self-worth, generosity and thoughtfulness to play things that way. The check is equally generous. The check says you’re comfortable with your cards and how the hand is going. No need to flex your muscles. When you have the winning cards the bluff is counterproductive. Playing bigger than your hand pushes everyone away and they fold. You may with the pot, but next hand they’ll go after you. Embarrassing the other players is no way to play.
Really, though, your cards don’t matter. Regardless of your cards, don’t take a challenge personally. Regardless of your cards, respond like you hold all of them – all the aces, face cards, and all the wild cards.
It relatively easy to behave this way when the professional challenges your ideas because they don’t challenge you, they challenge your ideas. And you are not your ideas. Look deeply and honestly at the ideas and leave your self out of it. But it’s more difficult with the hack. Under the banner of challenging your ideas, the hack will try to challenge you. Here’s where you’ve got to hold onto a fundamental truth – no one can challenge you without your consent. Here’s where you’ve got to remember this truth applies to everyone – those with a four-of-a-kind, those with a full house, and those with a pair of twos. Here’s where you’ve got to remember that your cards don’t matter. The best way I know how to do that is to visualize your self as a screen door and let their hot air pass through you.
The challenges don’t matter and neither does the hand you were dealt. All that matters is your response. Respond with your heart’s best intentions and everyone will split the pot and they’ll want you to deal every hand.
Image credit – lawrence
Recalibrating Your Fear
Everyone is looking for that new thing, that differentiator, that edge. The important filtering question is: Has it been done before? If it has been done before it cannot be a new thing (that’s a rule), so it’s important to limit yourself to things that have not been done. Sounds silly to say, but with today’s hectic pace sometimes that distinction is overlooked.
Once your eyeballs are calibrated, it pretty easy to see the vital yet-to-be-done work. But calibration is definitely needed because things don’t look as they seem. Here are a few examples to help you calibrate.
“It can’t be done.” This really means is it was tried some time ago by someone who doesn’t work here anymore and we’ve forgotten why, but the one experiment that was run did not work. This a good indication of fertile ground. Someone a long time ago thought it was important enough to try and it still has not been done successfully. And, new materials and manufacturing processes have been created and opened up new design space. Give it a try.
“That will never work.” See above.
“You can’t do that.” This means you (and, likely your industry) have a policy that has blocks this new idea. It may not be the best idea, but since policy prohibits it, you have the design space all to yourself if you want it. (That is, of course, if you want to compete with no one.) Likely there are no physical constraints, just the emotional constraints you created with your policy. It’s all yours, if you try it.
“No one will buy that.” This means no one offers a product like that. It means your industry doesn’t understand it because you or your competitors don’t sell anything like it. Though Marketing knows the inherent uncertainty, they don’t know the market potential. But you know you’re onto something. Try it.
“That’s just a niche market.” This means there’s a market that’s buying your product even though you’ve spent no time or energy to develop that market. It’s an accidental market. It’s small because it’s young and because you (and your competition) haven’t invested in it nor have developed an unique new product for it. The growth is all yours if you try.
Organizations create blocking mechanisms and tricky language to protect themselves from the new-and-different because the new-and-different are scary. But organizations desperately need new-and-different. And for that they desperately need to do things that haven’t been done.
The first step is to recognize the fertile design space and untilled markets your fear has created for you.
Image credit — Jordan Oram
All Your Mental Models are Obsolete
Even after playing lots of tricks to reduce its energy consumption, our brains still consume a large portion of the calories we eat. Like today’s smartphones it’s computing power is too big for it’s battery so its algorithms conserve every chance they get. One of its go-to conservation strategies is to make mental models. The models capture the essence of a system’s behavior without the overhead of retaining all the details of the system.
And as the brain goes about its day it tries to fit what it sees to its portfolio of mental models. Because mental models are so efficient, to save juice the brain is pretty loose with how it decides if a model fits the situation. In fact the brain doesn’t do a best fit, it does a first fit. Once a model is close enough, the model is applied, even if there’s a better one in the archives.
Overall, the brain does a good job. It looks at a system and matches it with a model of a similar system it experienced in the past. But behind it all the brain is making a dangerous assumption. The brain assumes all systems are static. And that makes for mental models that are static. And because all systems change over time (the only thing we can argue about is the rate of change) the brain’s mental models are always out of date.
Over the years your brain as made a mental model of how your business works – customers do this, competitors do that, and markets do the other. But by definition that mental model is outdated. There needs to be a forcing function that causes us to refute our mental models so we can continually refine them. [A good mantra could be – all mental models are out of fashion until proven otherwise.] But worse than not having a mechanism to refute them, we have a formal business process the demands we converge on our tired mental models year-on-year. And the name of that wicked process – strategic planning.
It goes something like this. Take a little time from your regular job (though you still have to do all that regular work) and figure out how you’re going to grow your business by a large (and arbitrary) percentage. The plan must be achievable (no pie in the sky stuff), it should be tightly defined (even though everyone knows things are dynamic and the plan will change throughout the year), you must do everything you did last year and more and you have fewer resources than last year. Any brain in it’s right will fit the old models to the new normal and put the plan together in the (insufficient) time allotted. The planning process reinforces the re-use of old models.
Because the brain believes everything is static, it’s thinking goes like this – a plan based on anything other than the tried-and-true mental models cannot have certainty or predictability in time or resources. And it’s thinking is right, in part. But because all mental models are out of date, even plans based on existing models don’t have certainty and predictability. And that’s where the wheels fall off.
To inject a bit more reality into strategic planning, ignore the tired old information streams that reinforce existing thinking and find new ones that provide information that contradicts existing mental models. Dig deeply into the mismatch between the new information and the old mental models. What is behind the difference? Is the difference limited to a specific region or product line? Is the mismatch new or has it always been there? The intent of this knee-deep dissection is not to invalidate the old models but to test and refine.
There is infinite detail in the world. Take a look at a tree and there’s a trunk and canopy. Look at the canopy and see the leaves. Look deeper to see a leaf and its veins. In order to effectively handle all this detail our brains create patterns and abstractions to reduce the amount of information needed to make it through the day.
In the case of the tree, the word “tree” is used to capture the whole thing – roots and all. And at a higher level, “tree” can represent almost any type of tree at almost any stage in its life. The abstraction is powerful because it reduces the complexity, as long as everyone’s clear which tree is which.
The message is this. Our brain takes shortcuts with its chunking of the world into mental models that go out style. And our brain uses different levels of abstraction for the same word to mean different things. Care must be taken to overtly question our mental models and overtly question the level of abstraction used when statements of facts are made.
Knowing what isn’t said is almost important as what is said. To maintain this level of clarity requires calm, centered awareness which today’s pace makes difficult.
There’s no pure cure for the syndrome. The best we can do is to be well-rested and aware. And to do that requires professional confidence and personal disciple.
Slowing down just a bit can be faster, and testing the assumptions behind our business models can be even faster. Last year’s mental models and business models should be thought of as guilty until proven relevant. And for that you need to make the time to think.
In today’s world we confuse activity with progress. But really, in today’s dynamic world thinking is progress.
Image credit – eyeliam.
Solving Intractable Problems
Immediately after there’s an elegant solution to a previously intractable problem, the solution is obvious to others. But, just before the solution those same folks said it was impossible to solve. I don’t know if there’s a name for this phenomenon, but it certainly causes hart burn for those brave enough to take on the toughest problems.
Intractable problems are so fundamental they are no longer seen as problems. Over the years experts simply accept these problems as constraints that must be complied with. Just as the laws of physics can’t be broken, experts behave as if these self-made constraints are iron-clad and believe these self-build walls define the viable design space. To experts, there is only viable design space or bust.
A long time ago these problems were intractable, but now they are not. Today there are new materials, new analysis techniques, new understanding of physics, new measurement systems and new business models.. But, they won’t be solved. When problems go unchallenged and constrain design space they weave themselves into the fabric of how things are done and they disappear. No one will solve them until they are seen for what they are.
It takes time to slow down and look deeply at what’s really going on. But, today’s frantic pace, unnatural fascination with productivity and confusion of activity with progress make it almost impossible to slow down enough to see things as they are. It takes a calm, centered person to spot a fundamental problem masquerading as standard work and best practice. And once seen for what they are it takes a courageous person to call things as they are. It’s a steep emotional battle to convince others their butts have been wet all these years because they’ve been sitting in a mud puddle.
Once they see the mud puddle for what it is, they must then believe it’s actually possible to stand up and walk out of the puddle toward previously non-viable design space where there are dry towels and a change of clothes. But when your butt has always been wet, it’s difficult to imagine having a dry one.
It’s difficult to slow down to see things as they are and it’s difficult to re-map the territory. But it’s important. As continuous improvement reaches the limit of diminishing returns, there are no other options. It’s time to solve the intractable problems.
Image credit – Steven Depolo
To make the right decision, use the right data.
When it’s time for a tough decision, it’s time to use data. The idea is the data removes biases and opinions so the decision is grounded in the fundamentals. But using the right data the right way takes a lot of disciple and care.
The most straightforward decision is a decision between two things – an either or – and here’s how it goes.
The first step is to agree on the test protocols and measure systems used to create the data. To eliminate biases, this is done before any testing. The test protocols are the actual procedural steps to run the tests and are revision controlled documents. The measurement systems are also fully defined. This includes the make and model of the machine/hardware, full definition of the fixtures and supporting equipment, and a measurement protocol (the steps to do the measurements).
The next step is to create the charts and graphs used to present the data. (Again, this is done before any testing.) The simplest and best is the bar chart – with one bar for A and one bar for B. But for all formats, the axes are labeled (including units), the test protocol is referenced (with its document number and revision letter), and the title is created. The title defines the type of test, important shared elements of the tested configurations and important input conditions. The title helps make sure the tested configurations are the same in the ways they should be. And to be doubly sure they’re the same, once the graph is populated with the actual test data, a small image of the tested configurations can be added next to each bar.
The configurations under test change over time, and it’s important to maintain linkage between the test data and the tested configuration. This can be accomplished with descriptive titles and formal revision numbers of the test configurations. When you choose design concept A over concept B but unknowingly use data from the wrong revisions it’s still a data-driven decision, it’s just wrong one.
But the most important problem to guard against is a mismatch between the tested configuration and the configuration used to create the cost estimate. To increase profit, test results want to increase and costs wants to decrease, and this natural pressure can create divergence between the tested and costed configurations. Test results predict how the configuration under test will perform in the field. The cost estimate predicts how much the costed configuration will cost. Though there’s strong desire to have the performance of one configuration and the cost of another, things don’t work that way. When you launch you’ll get the performance of AND cost of the configuration you launched. You might as well choose the configuration to launch using performance data and cost as a matched pair.
All this detail may feel like overkill, but it’s not because the consequences of getting it wrong can decimate profitability. Here’s why:
Profit = (price – cost) x volume.
Test results predict goodness, and goodness defines what the customer will pay (price) and how many they’ll buy (volume). And cost is cost. And when it comes to profit, if you make the right decision with the wrong data, the wheels fall off.
Image credit – alabaster crow photographic
Prototypes Are The Best Way To Innovate
If you’re serious about innovation, you must learn, as second nature, to convert your ideas into prototypes.
Funny thing about ideas is they’re never fully formed – they morph and twist as you talk about them, and as long as you keep talking they keep changing. Evolution of your ideas is good, but in the conversation domain they never get defined well enough (down to the nuts-and-bolts level) for others (and you) to know what you’re really talking about. Converting your ideas into prototypes puts an end to all the nonsense.
Job 1 of the prototype is to help you flesh out your idea – to help you understand what it’s all about. Using whatever you have on hand, create a physical embodiment of your idea. The idea is to build until you can’t, to build until you identify a question you can’t answer. Then, with learning objective in hand, go figure out what you need to know, and then resume building. If you get to a place where your prototype fully captures the essence of your idea, it’s time to move to Job 2. To be clear, the prototype’s job is to communicate the idea – it’s symbolic of your idea – and it’s definitely not a fully functional prototype.
Job 2 of the prototype is to help others understand your idea. There’s a simple constraint in this phase – you cannot use words – you cannot speak – to describe your prototype. It must speak for itself. You can respond to questions, but that’s it. So with your rough and tumble prototype in hand, set up a meeting and simply plop the prototype in front of your critics (coworkers) and watch and listen. With your hand over your mouth, watch for how they interact with the prototype and listen to their questions. They won’t interact with it the way you expect, so learn from that. And, write down their questions and answer them if you can. Their questions help you see your idea from different perspectives, to see it more completely. And for the questions you cannot answer, they the next set of learning objectives. Go away, learn and modify your prototype accordingly (or build a different one altogether). Repeat the learning loop until the group has a common understanding of the idea and a list of questions that only a customer can answer.
Job 3 is to help customers understand your idea. At this stage it’s best if the prototype is at least partially functional, but it’s okay if it “represents” the idea in clear way. The requirement is prototype is complete enough for the customer can form an opinion. Job 3 is a lot like Job 2, except replace coworker with customer. Same constraint – no verbal explanation of the prototype, but you can certainly answer their direction questions (usually best answered with a clarifying question of your own such as “Why do you ask?”) Capture how they interact with the prototype and their questions (video is the best here). Take the data back to headquarters, and decide if you want to build 100 more prototypes to get a broader set of opinions; build 1000 more and do a small regional launch; or scrap it.
Building a prototype is the fastest, most effective way to communicate an idea. And it’s the best way to learn. The act of building forces you to make dozens of small decisions to questions you didn’t know you had to answer and the physical nature the prototype gives a three dimensional expression of the idea. There may be disagreement on the value of the idea the prototype stands for, but there will be no ambiguity about the idea.
If you’re not building prototypes early and often, you’re not doing innovation. It’s that simple.


Mike Shipulski