Shipulski On Design

Archive for the ‘One Page Thinking’ Category

When the work is new, it can’t be defined and managed like work that has been done before.

Sometimes there’s a tendency to spend months to define the market, the detailed specification and the project timeline and release the package as a tidal wave that floods the organization with new work.  Instead, start with a high-level description of the market, a rough specification and the major project milestones, all of which will morph, grow and inform each other as the team learns.  Instead of a big batch, think bite-sized installments that build on each other. Think straw-man that gets its flesh as the various organizations define their learning objectives and learn them.

Instead of target customer segments and idealized personas, define how the customers will interact with the new product or service. Use the storyboard format to capture sequence of events (what they do), the questions they ask themselves and how they know they’ve done it right. Make a storyboard for the top three to five most important activities the customers must do.  There’s good learning just trying to decide on the top three to five activities, never mind the deep learning that comes when you try to capture real activities of real customers. [Hint – the best people to capture real customer activities are real customers.]

Instead of a detailed list of inputs and outputs, fill in the details of the storyboards.  Create close-ups of the user interfaces and label the dials, buttons and screens.  When done well, the required inputs and outputs bubble to the surface.  And define the customer’s navigation path, as it defines the sequence of things and where the various inputs come to be and the various outputs need to be.  What’s nice is learning by iteration can be done quickly since its done in the domain of whiteboards and markers.

Instead of defining everything, just define what’s new and declare everything else is the same as last time.

The specification for the first prototypes is to bring the storyboards to life and to show the prototypes to real customers.  Refine and revise based on the learning, and rinse and repeat, as needed.

As the design migrates toward customer value and confidence builds, it’s then time to layer on the details and do a deep dive into the details – specs, test protocols, manufacturing, sales and distribution.

At early stages of innovation work, progress isn’t defined by activity, it’s defined by learning.  And it can look like nothing meaningful is happening as there is a lot of thinking and quiet time mixed in with infrequent bursts active activity.  But that’s what it takes to answer the big questions of the front end.

When in doubt, answer the big questions at the expense of the details.  And to stay on track, revisit and refine the learning objectives. And to improve confidence, show it to real customers.

And rinse and repeat, as needed.

Image credit – Jason Samfield

The trouble with innovation is it’s risky.  Sure, the upside is nice (increased sales), but the downside (it doesn’t work) is distasteful. Everyone is looking for the magic pill to change the risk-reward ratio of innovation, but there is no pill.  Though there are some things you can do to tip the scale in your favor.

All problems are business problems.  Problem solving is the key to innovation, and all problems are business problems.  And as companies embrace the triple bottom line philosophy, where they strive to make progress in three areas – environmental, social and financial, there’s a clear framework to define business problems.

Start with a business objective.  It’s best to define a business problem in terms of a shortcoming in business results. And the holy grail of business objectives is the growth objective.  No one wants to be the obstacle, but, more importantly, everyone is happy to align their career with closing the gap in the growth objective.  In that way, if solving a problem is directly linked to achieving the growth objective, it will get solved.

Sell more.  The best way to achieve the growth objective is to sell more. Bottom line savings won’t get you there.  You need the sizzle of the top line. When solving a problem is linked to selling more, it will get solved.

Customers are the only people that buy things.  If you want to sell more, you’ve got to sell it to customers. And customers buy novel usefulness.  When solving a problem creates novel usefulness that customers like, the problem will get solved.  However, before trying to solve the problem, verify customers will buy what you’re selling.

No-To-Yes.  Small increases in efficiency and productivity don’t cause customers to radically change their buying habits.  For that your new product or service must do something new. In a No-To-Yes way, the old one couldn’t but the new one can. If solving the problem turns no to yes, it will get solved.

Would they buy it? Before solving, make sure customers will buy the useful novelty. (To know, clearly define the novelty in a hand sketch and ask them what they think.) If they say yes, see the next question.

Would it meet our growth objectives? Before solving, do the math. Does the solution result in incremental sales larger than the growth objective? If yes, see the next question.

Would we commercialize it? Before solving, map out the commercialization work. If there are no resources to commercialize, stop.  If the resources to commercialize would be freed up, solve it.

Defining is solving. Up until now, solving has been premature. And it’s still not time. Create a functional model of the existing product or service using blocks (nouns) and arrows (verbs). Then, to create the problem(s), add/modify/delete functions to enable the novel usefulness customers will buy.  There will be at least one problem – the system cannot perform the new function. Now it’s time to take a deep dive into the physics and bring the new function to life.  There will likely be other problems.  Existing functions may be blocked by the changes needed for the new function. Harmful actions may develop or some functions will be satisfied in an insufficient way.  The key is to understand the physics in the most complete way.  And solve one problem at a time.

Adaptation before creation. Most problems have been solved in another industry. Instead of reinventing the wheel, use TRIZ to find the solutions in other industries and adapt them to your product or service.  This is a powerful lever to reduce innovation risk.

There’s nothing worse than solving the wrong problem.  And you know it’s the wrong problem if the solution doesn’t: solve a business problem, achieve the growth objective, create more sales, provide No-To-Yes functionality customers will buy, and you won’t allocate the resources to commercialize.

And if the problem successfully runs the gauntlet and is worth solving, spend time to define it rigorously.  To understand the bedrock physics, create a functional of the system, add the new functionality and see what breaks.  Then use TRIZ to create a generic solution, search for the solution across other industries and adapt it.

The key to innovation is problem solving. But to reduce the risk, before solving, spend time and energy to make sure it’s the right problem to solve.

It’s far faster to solve the right problem slowly than to solve the wrong one quickly.

Image credit – Kate Ter Haar

If you don’t have a problem, there’s no problem. There are no resources without a problem and certainly no focus or momentum.  If you don’t know your problem, stop.  Take time to define your problem using a single page.  Make a sketch or make a block diagram but make it clear.  Make it so the problem description stands on its own. After you’ve defined your problem and someone calls it an “opportunity”, walk away because they can’t help you.  Taking advantage of opportunities is optional, but solving problems is mission critical.  No one worth their salt works on opportunities.  Rock stars solve problems.

After you’ve gnawed on a problem for a month and it hasn’t given in, what do you do?  When you’ve thrown everything at a problem and it still stands tall, what do you do?  When you’ve tried all your tricks and the intractable problem is still blocking an already overdue product launch, what do you do?  What you do is find someone who is unafraid trade an intractable problem for a solvable one, someone who will courageously give ground with the hope of opening up new design space, someone who will unabashedly take an anti-conventional (and hopefully controversial) approach.  What you do is find a rock star.

Intractable problems are not usually intractable; rather, intractable problems are either poorly-defined problems or are the wrong problem altogether.  Either way, it takes someone with courage, usually an outsider, to redefine the problem or see it differently.  But because of pride, an outsider can be brought in only after the team has exhausted all other possibilities.  Unless there’s a problem with the problem solving team (they can’t solve the problem), there’s no problem.  And without a problem, the team won’t accept help from an outsider.

At the rodeo when the cowboy is bucked off the raging bull, the cowboy runs away from the bull but the rodeo clown runs toward the bull to distract it.  Like the rodeo clown, the problem solving rock star runs toward raging problems at full tilt.  The rock star puts it all on the line as she grabs the problem by the scruff of the neck, wrestles it to the ground and hog ties it.  There’s no shyness, just well-practiced technique wrapped in implicit knowledge.  With courage and a cloud of dust, it’s no-holds-barred problem solving until the problem gives it up. Nothing is sacred, no assumptions go unchallenged, and no details are too small to ignore.  Like rodeo clowns, rock stars know their work looks funny from the outside, but they don’t care.  All they care about is solving the problem at hand. Right here, right now.

Before your next intractable problem, take a minute to scan your organization for the special people who have the courage to run toward even the most difficult problems.  Don’t be fooled by titles, positional power or how they dress.  Look deeply because like rodeo clowns, your magical problem solvers may not look the part on the outside.

Image credit – Ed Schipul

That’s a best practice. Look, there’s another one. We need a best practice. What’s the best practice?  Let’s standardize on the best practice.  Arrrgh.  Enough, already, with best practices.

There are no best practices, only actions that have worked for others in other situations.  Yet we feverishly seek them out, apply them out of context, and expect they’ll solve a problem unrelated to their heritage.

To me, the right practices are today’s practices.  They’re the base camp from which to start a journey toward new ones.  To create the next evolution of today’s practices, for new practices to emerge, a destination must be defined. This destination is dictated by problems with what we do today.  Ultimately, at the highest level, problems with our practices are spawned by gaps, shortfalls, or problems in meeting company objectives.  Define the shortfall – 15% increase in profits – and emergent practices naturally diffuse to the surface.

There are two choices: choose someone else’s best practices and twist, prune, and bend them to fit, or define the incremental functionality you’d like to create and lay out the activities (practices) to make it happen. Either way, the key is starting with the problem.

The important part – the right practices, the new activities, the novel work, whatever you call it, emerges from the need.

It’s a problem hierarchy, a problem flow-down.  The company starts by declaring a problem – profits must increase by 15% – and the drill-down occurs until a set of new action (new behaviors, new processes, new activities) is defined that solves the low level problems. And when the low level problems are solved, the benefits avalanche to satisfy the declared problem – profits increased by 15%.

It’s all about clarity — clearly define the starting point, clearly define the destination, and express the gaps in a single page, picture-based problem statements.  With this type of problem definition, you can put your hand over your mouth, with the other hand point to the picture, and everyone understands it the same way. No words, just understanding.

And once everyone understands things clearly, the right next steps (new practices) emerge.

With manufacturing change is easy – lean this, six sigma that, more with less year-on-year. With engineering, not so much. Why?

Manufacturing is about cost, waste, efficiency, and yield (how to make it), and engineering is about function (what it does) – fundamental differences but not the why. The consequence of failure is the why. If manufacturing doesn’t deliver, the product is made like last year (with a bit more waste and cost than planned), but the product still sells. With engineering, not so much. If engineering mistakenly designs the Fris out of the Frisbee or the Hula out of the Hoop, no sales. That’s the why.

No function, no sales, no company, this is fear. This is why it feels dangerous to push on engineering; push on engineering and the wheels may fall off. This why the organization treads lightly; this is why the CEO does not push.

As technical leaders we are the ones who push directly on engineers. We stretch them to create novel technology that creates customer value and drive sales. (If, of course, customers value the technology.) We spend our days in the domain of stress, strain, printed circuit boards, programming languages, thermal models, and egos. As technologists, it’s daunting to push effectively on engineering; as non-technologists even more. How can a CEO do it without the subject matter expertise? The answer is one-page thinking.

One-page thinking forces engineers to describe our work in plain English, simple English, simple language, pictures, images. This cuts clutter and cleans our thinking so non-technologists can understand what’s happening, what’s going on, what we’re thinking, and shape us in the direction of customer, of market, of sales. The result is a hybrid of strong technology, strong technical thinking, and strong product, all with a customer focus, a market focus. A winning combination.

There are several rules to one-page thinking, but start with this one:

Use one page.

As CEO, ask your technical leaders (even the VP or SVP kind) to define each of their product development (or technology) projects on one page, but don’t tell them how. (The struggle creates learning.) When they come back with fifteen PowerPoint slides (a nice reduction from fifty), read just the first one, and send them away. When they come back with five, just read the first. They’ll get the idea. But be patient. To use just one page makes things remarkably clear, but it’s remarkably difficult.

Once the new product (or technology) is defined on one page, it’s time to reduce the fear of pushing on engineering – one-page thinking at the problem level. First, ask the technical leaders for a one-page description of each problem that must be overcome (one page per problem and address only the fundamental problems). Next, for each problem ask for baseline data (test data) on the product you make today. (For each problem they’ll likely have to create a robustness surrogate, a test rig to evaluate product performance.) The problem is solved (and the product will function well) when the new one out-performs the old one. The fear is gone.

When your engineers don’t understand, they can’t explain things on one page.  But when they can, you understand.

Companies pursue lots of ideas; some turn out well and some badly. Since we can’t tell with 100% certainty if an idea will work, bad ones are a cost of doing business. And it makes sense to tolerate them. The cost of a few bad ones is well worth the upside of a game-changer. It’s like the VC model.

However, there’s a class that must be avoided at all costs: the dumb-ass idea – an idea we should know will not work before we try it. It’s not a bad idea,  it’s beyond stupid, it’s deadly.

A dumb-ass idea violates fundamentals.

What’s so scary is today’s ready, fire, aim pace makes us more susceptible than ever. Our dumb-ass antibodies need strengthening. We need an immunization, a filter to discern if we’re respecting the fundamentals. We need a dumb-ass filter.

To immunize ourselves it’s helpful to understand how these ideas come to be. Here are some mutant strains:

Local optimization – We improve part of the system at the expense of the overall system. Chasing low cost labor is a good example where labor savings are dwarfed by increased costs of logistics, training, quality, and support.

A cloudy lens – We come up with an idea based on incomplete, biased, or inappropriate data. A good example is financial data which captures cost in a most artificial way. Overhead calculation is the poster child.

Cause and effect – We don’t know which is which; we confuse symptom with root cause and correlation with causation. Expect the unexpected with this mix up.

Scaling – We assume success in the lab is scalable to success across the globe. Everything does not scale, and less scales cost effectively.

Fear – We want to go fast because our competition is already there; we want to go slow because were afraid to fail.

What’s the best dumb-ass filter? It’s a formal and simple definition of the fundamentals. Use one page thinking – fundamentals one page, lots of pictures and few words. There’s no escape.

How to go about it? Settle yourself. Catch your breath. Let your pulse slow. Then, create a one pager (pictures, pictures, pictures) that defines the fundamentals and run it by someone you trust, someone without a vested interest, someone who has learned from their own dumb-ass thinking. (Those folks can spot it at twenty paces.) Defend it to them. Defend it to yourself. Run yourself through the gauntlet.

What are the fundamentals? Do they apply in this situation? How do you know? Answer these and you’re on your way to self-inoculation.

Your best engineer walks into your office and says, “I have this idea for a new technology that could revolutionize our industry and create new markets, markets three times the size of our existing ones.” What do you do? What if, instead, it’s a lower caliber engineer that walks into your office and says those same words? Would you do anything differently? I argue you would, even though you had not heard the details in either instance. I think you’d take your best engineer at her word and let her run with it. And, I think you’d put less stock in your lesser engineer, and throw some roadblocks in the way, even though he used the same words. Why? Trust.

Innovation is largely a trust-based sport. We roll the dice on folks that have already put it on the table, and, conversely, we raise the bar on those that have not yet delivered – they have not yet earned our trust. Seems rational and reasonable – trust those who have earned it. But how did they earn your trust the first time, before they delivered? Trust.

There is no place for trust in the sport of innovation. It’s unhealthy. Ronald Reagan had it right:

Trust, but verify.

As we know, he really meant there was no place for trust in his kind of sport. Every action, every statement had to be verified. The consequences so cataclysmic, no risk could be tolerated. With innovation consequences are not as severe, but they are still substantial. A three year, multi-million (billion?) dollar innovation project that returns nothing is substantial. Why do we tolerate the risk that comes with our trust-based approach? I think it’s because we don’t think there’s a better way. But there is. What we need is some good, old-fashioned verification mixed in with our innovation.

When the engineer comes into your office and says she can reinvent your industry, what do you ask yourself? What do you want to verify? You want to know if the new idea is worth a damn, if it will work, if there are fundamental constraints in the way. But, unfortunately for you, verification requires  knowledge of the physics, and you’re no physicist. However, don’t lose hope. There are two simple tactics, non-technical tactics, to help with this verification business.

First – ask the engineers a simple question, “What conflict is eliminated with the new technology?” Good, innovative technologies eliminate fundamental, long standing conflicts. These long standing conflicts limit a technology in a way that is so fundamental engineers don’t even know they exist. When a fundamental conflict is eliminated, long held “design tradeoffs” no longer apply, and optimizing is replaced by maximizing. With optimizing, one aspect of the design is improved at the expense of another. With maximizing, both aspects of the design are improved without compromise. If the engineers cannot tell you about the conflict they’ve eliminated, your trust has not been sufficiently verified. Ask them to come back when they can answer your question.

Second – when they come back with their answer, it will be too complex to be understood, even by them. Tell them to come back when they can describe the conflict on a single page using a simple block diagram, where the blocks, labeled with everyday nouns, represent parts of the design intimately involved with the conflict, and the lines, labeled with everyday verbs, represent actions intimately involved with the conflict. If they can create a block diagram of the conflict, and it makes sense to you, your trust has been sufficiently verified. (For a post with a more detailed description of the block diagrams, click on “one page thinking” in the Category list.)

Though your engineers won’t like it at first, your two-pronged verification tactics will help them raise their game, which, in turn, will improve the risk/reward ratio of your innovation work.

There is a healthy tension between level of improvement, or level of innovation, and time to market. Marketing wants radical improvement, infinitely short project schedules, and no change to the product. Engineers want to sign up for the minimum level of improvement, project schedules sufficiently long to study everything to death, and want to change everything about the new product. It’s healthy because there is balance – both are pulling equally hard in opposite directions and things end up somewhere in the middle. It’s not a stress-free environment, but it’s not too bad. But, sometimes the tension is unhealthy.

There are two flavors of unhealthy tension. First is when engineering has too much pull; they (we) sandbag on product performance and project timelines and change the design willy-nilly simply because they can (and it’s fun). The results are long project timelines, highly innovative designs that don’t work well, a lack of product robustness, and a boatload of new parts and assemblies. (Product complexity.) Second is when Marketing has too much pull; they ask for radical improvement in product functionality with project timelines too short for the level of innovation, and tightly constrain product changes such that solutions are not within the constraints. The results are long project timelines and un-innovative designs that don’t meet product specifications. (The solutions are outside the constraints.) Both sides are at fault in both scenarios. There are no clean hands.

What are the fundamentals behind all this gamesmanship? For engineering it’s technical risk; for marketing it’s schedule risk. Engineering minimizes what it signs up for in order to reduce technical risk and petitions for long project timelines to reduce it. Marketing minimizes product changes (constraints) to reduce schedule risk and petitions for short project timelines to reduce it. (Product development teams work harder with short schedules.) Something’s got to change. Read the rest of this entry »

Everyone laughs at the person who says “We don’t have problems, we have opportunities.”  Why do we say that?  We know that’s crap.  We have problems; problems are real; and it’s okay to call them by name.  In fact, it’s healthy.  Problems are good.  Problems focus our thinking.  There is a serious and important nature to the word problem, and it sets the right tone.  Everyone knows if the situation has risen to the level of a problem it’s important and action must be taken.  People feel good about organizing themselves around a problem – problems help rally the troops.

In a previous post on innovation, I talked about the tight linkage between problems and innovation.  In the pre-innovation state there is a problem; in the post-innovation state there is no problem.  The work in the middle is a good description of the thing we call innovation.  It could also be called problem solving.

Behind every successful product launch is a collection of solved problems.  The engineering team defines the problems, understands the physics, changed the design, and makes problems go away.  Behind every unsuccessful product launch is at least one unsolved problem.  These unsolved problems disrupt product launches – limiting product function, delaying launches, and cancelling others altogether.  All this can be caused by a single unsolved problem. Read the rest of this entry »

Like you, I have been thinking a lot about the recession.  We all want to know how to move ourselves to the other side, where things are somewhat normal (the old normal, not the new one).  Like usual, my mind immediately goes to products.  To me, having the right products is vital to pulling ourselves out of this thing.  There is nothing novel in this thinking;  I think we all agree that products are important.  But, there are two follow-on questions that are important.  First, what makes products “right” to move you quickly to the other side?  Second, do you have the capability to engineer the “right” products?

The first question – what makes products “right” for these times?  Capacity is important to understanding what makes products right.  Capacity utilization is at record lows with most industries suffering from a significant capacity glut.  With decreased sales and idle machines, customers are no longer interested in products that improve productivity of their existing product lines because they can simply run their idle machines more.  And, they are not interested in buying more capacity (your products) at a reduced price.  They will simply run their idle machines more.  You can’t offer an improvement of your same old product that enables customers to make their same old products a bit faster and you can’t offer them your same old products at a lower price.  However, you can sell them products that enable them to capture business they currently do not have.  For example, enable them to manufacture products that their idle machines CANNOT make at all.  To do that means your new products must do something radically different than before; they must have radically improved functionality or radically new features.  This is what makes products right for these times.

On to the second question – do you have the capability to engineer the right products?  Read the rest of this entry »

Leading, shaping, and guiding technology work is hard, even for technologists who spend all day doing it.  So, it seems the all-too-busy CEOs don’t stand a chance at effectively shaping their companies’ technical work.  And it’s not just the non-technologist CEOs who have a problem; the technologist CEOs also have a problem, as they don’t have sufficient time to dig deeply into the details or stay current on the state-of-the-art.  So, as a CEO, technologist or not, it is difficult to meaningfully lead, shape, and guide technical work.

So why is this technology stuff so hard to shape and guide?  Well, here are a few reasons: technologies have their own set of arcane languages, each with many dialects (and no dictionary); they have their own technology-centric acronyms that technologists mix and match as they see fit; and they are full of long-forgotten formulae.  And these formulae are composed of strange math shapes and symbols.  And, as if to elevate confusion to stratospheric levels, the math symbols are Greek letters.  So, literally, this technology stuff is written in Greek.  So what’s an all-too-busy CEO to do?  Read the rest of this entry »