Posts Tagged ‘Lessons Learned’

How To Design

What do they want? Some get there with jobs-to-be-done, some use Customer Needs, some swear by ethnographic research and some like to understand why before what.  But in all cases, it starts with the customer.  Whichever mechanism you use, the objective is clear – to understand what they need.  Because if you don’t know what they need, you can’t give it to them.  And once you get your arms around their needs, you’re ready to translate them into a set of functional requirements, that once satisfied, will give them what they need.

What does it do? A complete set of functional requirements is difficult to create, so don’t start with a complete set.  Use your new knowledge of the top customer needs to define and prioritize the top functional requirements (think three to five).  Once tightly formalized, these requirements will guide the more detailed work that follows.  The functional requirements are mapped to elements of the design, or design parameters, that will bring the functions to life.  But before that, ask yourself if a check-in with some potential customers is warranted.  Sometimes it is, but at these early stages it’s may best to wait until you have something tangible to show customers.

What does it look like? The design parameters define the physical elements of the design that ultimately create the functionality customers will buy. The design parameters define shape of the physical elements, the materials they’re made from and the interaction of the elements.  It’s best if one design parameter controls a single functional requirement so the functions can be dialed in independently.  At this early concept phase, a sketch or CAD model can be created and reviewed with customers.  You may learn you’re off track or you may learn you’re way off track, but either way, you’ll learn how the design must change. But before that, take a little time to think through how the product will be made.

How to make it? The process variables define the elements of the manufacturing process that make the right shapes from the right materials. Sometimes the elements of the design (design parameters) fit the process variables nicely, but often the design parameters must be changed or rearranged to fit the process.  Postpone this mapping at your peril!  Once you show a customer a concept, some design parameters are locked down, and if those elements of the design don’t fit the process you’ll be stuck with high costs and defects.

How to sell it? The goodness of the design must be translated into language that fits the customer.  Create a single page sales tool that describes their needs and how the new functionality satisfies them.  And include a digital image of the concept and add it to the one-pager.  Show document to the customer and listen.  The customer feedback will cause you to revisit the functional requirements, design parameters and process variables.  And that’s how it’s supposed to go.

Though I described this process in a linear way, nothing about this process is linear. Because the domains are mapped to each other, changes in one domain ripple through the others.  Change a material and the functionality changes and so do the process variables needed to make it.  Change the process and the shapes must change which, in turn, change the functionality.

But changes to the customer needs are far more problematic, if not cataclysmic.  Change the customer needs and all the domains change. All of them.  And the domains don’t change subtly, they get flipped on their heads.  A change to a customer need is an avalanche that sweeps away much of the work that’s been done to date.  With a change to a customer need, new functions must be created from scratch and old design elements must culled.  And no one knows what the what the new shapes will be or how to make them.

You can’t hold off on the design work until all the customer needs are locked down. You’ve got to start with partial knowledge.  But, you can check in regularly with customers and show them early designs.  And you can even show them concept sketches.

And when they give you feedback, listen.

Image credit – Worcester Wired

Is your tank empty?

Sometimes your energy level runs low.  That’s not a bad thing, it’s just how things go. Just like a car’s gas tank runs low, our gas tanks, both physical and emotional, also need filling.  Again, not a bad thing. That’s what gas tanks are for – they hold the fuel.

We’re pretty good at remembering that a car’s tank is finite.  At the start of the morning commute, the car’s fuel gauge gives a clear reading of the fuel level and we do the calculation to determine if we can make it or we need to stop for fuel.  And we do the same thing in the evening – look at the gauge, determine if we need fuel and act accordingly.  Rarely we run the car out of fuel because the car continuously monitors and displays the fuel level and we know there are consequences if we run out of fuel.

We’re not so good at remembering our personal tanks are finite. At the start of the day, there are no objective fuel gauges to display our internal fuel levels.  The only calculation we make – if we can make it out of bed we have enough fuel for the day. We need to do better than that.

Our bodies do have fuel gages of sorts.  When our fuel is low we can be irritable, we can have poor concentration, we can be easily distracted.  Though these gages are challenging to see and difficult to interpret, they can be used effectively if we slow down and be in our bodies.  The most troubling part has nothing to do with our internal fuel gages.  Most troubling is we fail to respect their low fuel warnings even when we do recognize them.  It’s like we don’t acknowledge our tanks are finite.

We don’t think our cars are flawed because their fuel tanks run low as we drive.  Yet, we see the finite nature of our internal fuel tanks as a sign of weakness. Why is that? Rationally, we know all fuel tanks are finite and their fuel level drops with activity. But, in the moment, when are tanks are low, we think something is wrong with us, we think we’re not whole, we think less of ourselves.

When your tank is low, don’t curse, don’t blame, don’t feel sorry and don’t judge.  It’s okay.  That’s what tanks do.

A simple rule for all empty tanks – put fuel in them.

Image credit – Hamed Saber

The people part is the hardest part.

The toughest part of all things is the people part.

Hold on to being right and all you’ll be is right.  Transcend rightness and get ready for greatness.

Embrace hubris and there’s no room for truth.  Embrace humbleness and everyone can get real.

Judge yourself and others will pile on.  Praise others and they will align with you.

Expect your ideas to carry the day and they won’t. Put your ideas out there lightly and ask for feedback and your ideas will grow legs.

Fight to be right and all you’ll get is a bent nose and bloody knuckles.  Empathize and the world is a different place.

Expect your plan to control things and the universe will have its way with you.  See your plan as a loosely coupled set of assumptions and the universe will still have its way with you.

Argue and you’ll backslide.  Appreciate and you’ll ratchet forward.

See the two bad bricks in the wall and life is hard.  See the other nine hundred and ninety-eight and everything gets lighter.

Hold onto success and all you get is rope burns.  Let go of what worked and the next big thing will find you.

Strive and get tired. Thrive and energize others.

The people part may be the toughest part, but it’s the part that really matters.

Image credit — Arian Zwegers

The Slow No

When there’s too much to do and too few to do it, the natural state of the system is fuller than full.  And in today’s world we run all our systems this way, including our people systems.

A funny thing happens when people’s plates are full – when a new task is added an existing one hits the floor.  This isn’t negligence, it’s not the result of a bad attitude and it’s not about being a team player.  This is an inherent property of full plates – they cannot support a new task without another sliding off.  And drinking glasses have this same interesting property – when full, adding more water just gets the floor wet.

But for some reason we think people are different.  We think we can add tasks without asking about free capacity and still expect the tasks to get done.  What’s even more strange – when our people tell us they cannot get the work done because they already have too much, we don’t behave like we believe them.  We say things like “Can you do more things in parallel?” and “Projects have natural slow phases, maybe you can do this new project during the slow times.”  Let’s be clear with each other – we’re all overloaded, there are no slow times.

For a long time now, we’ve told people we don’t want to hear no.  And now, they no longer tell us.  They still know they can’t get the work done, but they know not to use the word “no.”  And that’s why the Slow No was invented.

The Slow No is when we put a new project on the three year road map knowing full-well we’ll never get to it.  It’s not a no right now, it’s a no three years from now.  It’s elegant in its simplicity.  We’ll put it on the list; we’ll put it in the queue; we’ll put it on the road map.  The trick is to follow normal practices to avoid raising concerns or drawing attention.  The key to the Slow No is to use our existing planning mechanisms in perfectly acceptable ways.

There’s a big downside to the Slow No – it helps us think we’ve got things under control when we don’t.  We see a full hopper of ideas and think our future products will have sizzle.  We see a full road map and think we’re going to have a huge competitive advantage over our competitors. In both situations, we feel good and in both situations, we shouldn’t.  And that’s the problem. The Slow No helps us see things as we want them and blocks us from seeing them as they are.

The Slow No is bad for business, and we should do everything we can to get rid of it.  But, it’s engrained behavior and will be with us for the near future.  We need some tools to battle the dark art of the Slow No.

The Slow No gives too much value to projects that are on the list but inactive.  We’ve got to elevate the importance of active, fully-staffed projects and devalue all inactive projects.  Think – no partial credit.  If a project is active and fully-staffed, it gets full credit.  If it’s inactive (on a list, in the queue, or on the road map) it gets zero credit.  None.  As a project, it does not exist.

To see things as they are, make a list of the active, fully-staffed projects. Look at the list and feel what you feel, but these are the only projects that matter.  And for the road map, don’t bother with it.  Instead, think about how to finish the projects you have.  And when you finish one, start a new one.

The most difficult element of the approach is the valuation of active but partially-staffed projects.  To break the vice grip of the Slow No, think no partial credit. The project is either fully-staffed or it isn’t   And if it’s not fully-staffed, give the project zero value.  None.  I know this sounds outlandish, but the partially-staffed project is the slippery slope that gives the Slow No its power.

For every fully-staffed project on your list, define the next project you’ll start once the current one is finished.  Three active projects, three next projects.  That’s it.  If you feel the need to create a road map, go for it.  Then, for each active project, use the road map to choose the next projects.  Again, three active projects, three next projects.  And, once the next projects are selected, there’s no need to look at the road map until the next projects are almost complete.

The only projects that truly matter are the ones you are working on.

Image credit – DaPuglet

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

A Barometer for Uncertainty

Novelty, or newness, can be a great way to assess the status of things.  The level of novelty is a barometer for the level of uncertainty and unpredictability.  If you haven’t done it before, it’s novel and you should expect the work to be uncertain and unpredictable. If you’ve done it before, it’s not novel and you should expect the work to go as it did last time. But like the barometer that measures a range of atmospheric pressures and gives an indication of the weather over the next hours, novelty ranges from high to low in small increments and so does the associated weather conditions.

Barometers have a standard scale that measures pressure.  When the summer air is clear and there are no clouds, the atmospheric pressure is high and on the rise and you should put on sun screen.  When it’s hurricane season and super-low system approaches, the drops to the floor and you should evacuate.  The nice thing about barometers is they are objective. On all continents, they can objectively measure the pressure and display it. No judgement, just read the scale. And regardless of the level of pressure and the number of times they measure it, the needle matches the pressure.  No Kentucky windage.  But novelty isn’t like that.

The only way to predict how things will go based on the level of novelty is to use judgement.  There is no universal scale for novelty that works on all projects and all continents.  Evaluating the level of novelty and predicting how the projects will go requires good judgement. And the only way to develop good judgment is to use bad judgment until it gets better.

All novelty isn’t created equal. And that’s the trouble.  Some novelty has a big impact on the weather and some doesn’t.  The trick is to know the difference.  And how to tell the difference? If when you make a change in one part of the system (add novelty) and the novelty causes a big change in the function or operation of the system, that novelty is important. The system is telling you to use a light hand on the tiller. If the novelty doesn’t make much difference in system performance, drive on. The trick is to test early and often – simple tests that give thumbs-up or thumbs-down results.  And if you try to run a test and you can’t get the test to run at all, there’s a hurricane is on the horizon.

When the work is new, you don’t really know which novelty will bite you. But there’s one rule: all novelty will bite you until proven otherwise.  Make a list of the novel elements of the and test them crudely and quickly.

Allocating resources as if people and planet mattered.

Business is about allocating resources to achieve business objectives.  And for that, the best place to start is to define the business objectives.

First – what is the timeframe of the business objectives? Well, there are three – short, medium and long.  Short is about making payroll, shipping this month’s orders and meeting this year’s sales objectives.  Long is about the existence of the company over the next decade and happiness of the people that do the work along the way. And medium – the toughest – is in-between.  It’s neither short nor long but bound by both.

Second – define business objectives within the three types: people, planet and profit.

People. Short term: pay them so they can eat, pay the mortgage and fund their retirement, provide healthcare, provide a safe workplace, give them work that fits their strengths and give them time to improve their community. Medium: pay them so they can provide for their family and fund their retirement, provide healthcare, provide a safer workplace, give them work that requires them to grow their strengths and give them time to become community leaders. Long: pay them so they can pay for their kids’ college and know they can safely retire, provide the safest workplace, let them choose their own work, and give them time to grow the next community leaders.  And make it easy.

Planet. Short term: teach Life Cycle Assessment,  Buddhist Economics and TRIZ and create business metrics for them to flourish. Medium: move from global sourcing to local sourcing, move to local production, move from business models based on non-renewable resources to renewable resources. Long: create new business models that are resource neutral. Longer: create business models that generate excess resources. Longest: teach others.

Profit. Short, medium and long – focus on people and planet and the profits will come. But also focus on creating new value for new customers.

For business objectives, here’s the trick on timeframe – always work short term, always work long term and prioritize medium term.

And for the three types of business objectives, focus on people, planet and creating new value for new customers.  Profits are a result.

Image credit – magnetismus

Make It Easy

When you push, you make it easy for people resist. When you break trail, you make it easy for them to follow.

Efficiency is overrated, especially when it interferes with effectiveness.  Make it easy for effectiveness to carry the day.

You can push people off a cliff or build them a bridge to the other side. Hint – the bridge makes it easy.

Even new work is easy when people have their own reasons for doing it.

Making things easier is not easy.

Don’t tell people what to do.  Make it easy for them to use their good judgement.

Set the wrong causes and conditions and creativity screeches to a halt.  Set the right ones and it flows easily. Creativity is a result.

Don’t demand that people pull harder, make it easier for them to pull in the same direction.

Activity is easy to demonstrate and progress isn’t.  Figure out how to make progress easier to demonstrate.

The only way to make things easier is to try to make them easier.

Image credit – Richard Hurd

 

 

How to wallow in the mud of uncertainty.

Creativity and innovation are dominated by uncertainty. And in the domain of uncertainty, not only are the solutions unknown, the problems are unknown. And yet, we still try to use the tried-and-true toolbox of certainty even after it’s abundantly clear those wrenches don’t fit.

When wallowing in the mud of uncertainty and company leaders ask, “When will you be done?”, the only real answer is a description of the next thing you’ll try to learn. “We will learn if Step 1 is possible.” And then the predicted response, “Well, when will you be done with that?”  The only valid response is, “It depends.”  Though truthful, this goes over like a lead balloon.  And the dialog continues – “Okay, then, what is Step 2?”  The unpalatable answer, “It depends. If Step 1 is successful, we’ll move onto Step 2, but if Step 1 is unsuccessful, we’ll step back and regroup.” This, too, though truthful, is unsatisfactory.

When doing creative work, there’s immense pressure to be done on time. But, that pressure is inappropriate. Yes, there can be pressure to learn quickly and effectively, but the expectation to be done within an arbitrary timeline is ludicrous.  Managers don’t know this, but when they demand a completion date for a task that has never been done before, the people doing the creative work know the manager doesn’t know what they’re doing.  They won’t tell the manager what they think, but they definitely think it. And when pushed to give a completion date, they’ll give one, knowing full well the predicted date is just as arbitrary as the manager’s desired timeline.

But learning objectives can create common ground. Starting with “We want to learn if…”, learning objectives define what the project team must learn. Though there’s no agreement on when things will be completed, everyone can agree on the learning objectives. And with clearly defined learning objectives and measurable definitions of success, the project can move forward with consensus. There is still consternation over the lack of hard deadlines for the learning objectives, but there is agreement on the sequence of events, tests protocols or analyses that will be carried out to learn what must be learned.

Two rules to live by: If you know when you’ll be done, you’re not doing innovation. And if no one is surprised by the solution, you’re not doing creative work.

Image credit – Michael Carian

Wisdom Within Dichotomy

To create future success, you’ve got to outlaw the very thing responsible for your past success.

Sometimes slower is faster and sometimes slower is slower. But it’s always a judgement call.

We bite the bullet and run expensive experiments because they’re valuable, but we neglect to run the least expensive thought experiments because they’re too disruptive.

There’s an infinite difference between the impossible and the almost impossible. And the people that can tell the difference are infinitely important.

If you know how to do it, so does your competition. Do something else.

We want differentiation, but we can’t let go of the sameness of success.

People that make serious progress take themselves lightly.

If you can predict when the project will finish, you can also predict customers won’t be excited when you do.

If you don’t have time to work on something, you can still work on it a little a time.

Perfection is good, but starting is better.

Sometimes it’s time to think and sometimes it’s time to do. And it’s easy to decide because doing starts with thinking.

When your plate is full and someone slops on a new project, there may be a new project on your plate but there’s also another project newly flopped on the floor.

New leaders demand activity and seasoned professionals make progress.

Sometimes it’s not ready, but most of the time it’s ready enough.

There’s no partial credit for almost done. That’s why pros don’t start a project until they finish one.

In this age of efficiency, effectiveness is far more important.

Image credit — Silentmind8

To improve innovation, use fewer words.

Everyone knows innovation is difficult, but there’s no best way to make it easier. And everyone knows there’s plenty of opportunities to make innovation more effective, but, again, there’s no best way.  Clearly, there are ways to improve the process, and new tools can help, but the right process improvements depend on the existing process and the specific project.  And it’s the same for tools – the next tool depends on the existing toolbox and the new work required by the project.  With regard to tools and processes, the right next steps are not universal.

But with all companies’ innovation processes, there is a common factor – the innovation process is run by people. Regardless of process maturity or completeness, people run the process.  And this fundamental cuts across language, geography and company culture.  And it cuts across products, services, and business models.  Like it or not, innovation is done by people.

At the highest level, innovation converts ideas into something customers value and delivers the value to them for a profit. At the front end, innovation is about ideas, in the middle, it’s about problems and at the back end, it’s about execution. At the front, people have ideas, define them, evaluate them and decide which ones to advance. In the middle, people define the problems and solve them. And at the back end, people define changes to existing business process and run the processes in a new way.

Tools are a specialized infrastructure that helps people run lower-level processes within the innovation framework. At the front, people have ideas about new tools, or how to use them in a new way, define the ideas, evaluate them, and decide which tools to advance. In the middle, people define problems with the tools and solve them. And at the back end, they run the new tools in new ways.

With innovation processes and tools, people choose the best ideas, people solve problems and people implement solutions.

In order to choose the best ideas, people must communicate the ideas to the decision makers in a clear, rich, nuanced way. The better the idea is communicated, the better the decision. But it’s difficult to communicate an idea, even when the idea is not new. For example, try to describe your business model using just words. And it’s more difficult when the idea is new. Try to describe a new (untested) business model using just your words. For me, words are not a good way to communicate new ideas.

Improved communication improves innovation. To improve communication of ideas, use fewer words. Draw a picture, create a cartoon, make a storyboard, or make a video.  Let the decision maker ask questions of your visuals and respond with another cartoon, a modified storyboard or a new sketch.  Repeat the process until the decision maker stops asking questions.  Because communication is improved, the quality of the decision is improved.

Improved problem solving improves innovation. To improve problem-solving, improve problem definition (the understanding of problem definition.) Create a block diagram of the problem – with elements of the system represented by blocks and labeled with nouns, and with actions and information flow represented by arrows labeled with verbs. Or create a sketch of the customer caught in the act of experiencing the problem.  Define the problem in time (when it happens) so it can be solved before, during or after. And in all cases, limit yourself to one page. Continue to modify the visuals until there’s a common definition of the problem (the words stop.)  When the problem is defined and communicated in this way, the problem solves itself. Problem-solving is seven-eighths problem definition.

Improved execution improves innovation. To improve execution, improve clarity of the definition of success.  And again, minimize the words. Draw a picture that defines success using charts or graphs and data. Create the axes and label them (don’t forget the units of measure). Include data from the baseline product (or process) and define the minimum performance criterion in red.  And add the sample size (number of tests.) Use one page for each definition of success and sequence them in order of importance. Start with the work that has never been done before.  And to go deeper, define the test protocol used to create the data.

For a new business model, the one-page picture could be a process diagram with new blocks for new customers or partners or new arrows for new information flows. There could be time requirements (response time) or throughput requirements (units per month). Or it could be a series of sketches of new deliverables provided by the business model, each with clearly defined criteria to judge success. When communicated clearly to the teams, definitions of success are beacons of light that guide the boats as the tide pulls them through the project or when uncharted rocks suddenly appear to starboard.

Innovation demands communication and communication demands mechanisms. In the domain of uncertainty, words are not the best communicators.  Create visual communication mechanisms that distill and converge on a common understanding.

A picture isn’t worth a thousand words, it gets rid of a thousand.

Image credit – Michael Coghlan

Mike Shipulski Mike Shipulski
Subscribe via Email

Enter your email address:

Delivered by FeedBurner