Shipulski On Design

Archive for the ‘How To’ Category

When I want to understand a large system, I make a map.  If the system is an ecosystem, I combine Wardley Maps by Simon Wardley with Wide Lens / Winning The Right Game by Ron Adner.  On Wardley maps, activities and actors are placed on the map, and related elements are connected. On the left are infant and underdeveloped elements, and on the right are fully developed / commodity elements.  It’s like an S-curve that’s been squished flat.

Wide Lens prompts you to consider co-innovation (who needs to innovate for you to be successful) and adoption (who needs to believe your idea is a good one).  Winning The Right Game makes you think through the sequence of attracting partners like a visual time-lapse of the ecosystem’s evolution.  This is a killer combination that demands you put the whole system on one page – all the players/partners, all the activities sorted by maturity, all the interactions, and the evolution of the partner network and maturity of the system elements.  This forces a common understanding of the ecosystem.  There’s no way out.  Did I say it must fit on one page?

When the large system is a technological system, I make a map.  I use the best TRIZ book (Innovation On Demand) by Victor Fey.  A functional analysis is performed on the system using noun-verb pairs that are strung together to represent how the system behaves.  If you want to drive people crazy, this is the process for you.  It requires precise words for each noun (element) and verb (action) pair, and the pairs must hang together in a way that represents the physical system.  There can be only one description of the system, and the fun and games don’t stop until the team converges on a single representation of the system. It’s all good fun until someone loses an eye.

When I want to understand a business/technology/product/service offering that has not been done before (think startup), I use Lean Canvas by Ash Maurya.  The Lean Canvas requires you to think through all elements of the system and forces you to put it on one page. (Do you see a theme here?) Value proposition, existing alternatives, channel to market, customer segments, metrics, revenue, costs, problems, and solutions – all of them on one page.

And then to blow people’s minds, I combine Wardley Maps, Wide Lens, Winning The Right Game, functional analysis of TRIZ, value in action, and Lean Canvas on one page.  And this is what it looks like.

Ash’s Lean Canvas is the backplane.  Ron’s Wide Lens supports 6 (Channel), forcing a broader look than a traditional channel view. Ron’s Winning The Right Game and Simon’s Wardley Map are smashed together to support 2 (Existing Alternatives/Problems).  A map is created for the existing system with system elements (infants on the left, retirees on the right) and partners/players, which are signified by color (red blob).  Then, a second map is created to define the improvements to be made (red circles with arrows toward a more mature state).  Victor’s Functional Analysis/System diagram defines the problematic system, and TRIZ tools, e.g., Separation Principles, are used to solve the problem.

When I want to understand a system (ecosystem or technological system), I make a map.  And when I want to make a good map, I put it on one page.  And when I want to create a new technological system that’s nested in a new business model that’s nested in a new ecosystem, I force myself to put the whole universe on one page.

Image credit – Giuseppe Zeta

Good teachers change your life.  They know what you know and bring you along at a pace that’s right for you, not too slowly that you’re bored and not too quickly that your head spins. And everything they do is about you and your learning.  Good teachers prioritize your learning above all else.

Chris Brown taught me Axiomatic Design.  He helped me understand that design is more than what a product does.  All meetings and discussions with Chris started with the three spaces – Functional Requirements (FRs) what it does, Design Parameters (DPs) what it looks like, and Process Variables (PVs) how to make it. This was the deepest learning of my professional life.  To this day, I am colored by it.  And the second thing he taught me was how to recognize functional coupling.  If you change one input to the design and two outputs change, that’s functional coupling.  You can manage functional coupling if you can see it.  But if you can’t see it, you’re hosed.  Absolutely hosed.

Vicor Fey taught me TRIZ. He helped me understand the staggering power of words to limit and shape our thinking.  I will always remember when he passionately expressed in his wonderful accent, “I hate words!” And to this day, I draw pictures of problems and I avoid words.  And the second thing he taught me is that a problem always exists between two things, and those things must touch each other.  I make people’s lives miserable by asking – Can you draw me a picture of the problem?  And, Which two system elements have the problem, and do they touch each other? And the third thing he taught me was to define problems (Yes, Victor, I know I should say conflicts.) in time.  This is amazingly powerful.  I ask – “Do you want to solve the problem before it happens, while it happens, or after it happens?” Defining the problem in time is magically informative.

Don Clausing taught me Robust Design.  He helped me understand that you can’t pass a robustness test.  He said, “If you don’t break it, you don’t know how good it is.”  He was an ornery old codger, but he was right.  Most tests are stopped before the product fails, and that’s wrong.  He also said, “You’ve got to test the old design if you want to know if the new one is better.”  To this day, I press for A/B testing, where the old design and new design are tested against the same test protocol.  This is much harder than it sounds and much more powerful.  He taught me to test designs at stress levels higher than the operating stresses.  He said, “Test it, break it, and improve it.  And when you run out of time, launch it.”  And, lastly, he said, “Improve robustness at the expense of predicting it.”  He gave zero value to statistics that predict robustness and 100% value to failure mode-based testing of the old design versus the new one.

The people I work with don’t know Chris, Victor, or Don. But they know the principles I learned from them.  I’m a taskmaster when it comes to FRs-DPs-PVs.  Designs must work well, be clearly defined by a drawing, and be easy to make.  And people know there’s no place in my life for functional coupling.  My coworkers know to draw a picture of the problem, and it better be done on one page.  And they know the problem must be shown to exist between two things that touch.  And they know they’ll get the business from me if they don’t declare that they’re solving it before, during, or after.  They know that all new designs must have A/B test results, and the new one must work better than the old one.  No exceptions.

I am thankful for my teachers.  And I am proud to pass on what they gave me.

Image credit — Christof Timmermann

With new product development projects, there is no partial credit.  If you’re less than 100% done, there are zero sales.  90% done, zero sales.  95% done, zero sales. We all understand the concept, but our behavior often contradicts our understanding.  You have too many projects, and our focus on efficiency is to blame.

Under the banner of efficiency, we run too many projects in parallel, and our limited resources become spread too thinly over too many projects.  Project timelines grow, launch dates are pushed out, and revenue generation is delayed.  And because there’s a shortfall in revenue, we start more projects to close the gap.  That’s funny.

In short, we’ve morphed Start, Stop, Continue into Start, Start, Start.

Here’s a process to help you stop starting and start finishing.

Open a spreadsheet and list all your projects for the year.  At the top of the column, list the projects you’ve completed.  Below the completed projects, list your active projects, and below them, list your future (not yet started) projects.  Highlight the completed projects and the active projects, and set the print area.  Then, select “print on both sides of the page.”  When you print the file, the future projects will be printed on the back of the page.  This will help you focus on the completed and active projects and block you from trying to start a project before finishing one.

Now, go back to the top of the spreadsheet and select the completed projects and change the font to “strike through.”  This will allow you to read the project names and remind yourself of the projects you completed.  You can use this list to justify a strong performance rating at your upcoming performance review.

Skip down to the active projects and categorize them as fully staffed or partially staffed.  Change the font color to red for the partially staffed projects and move them to the second page with the future projects.  Print out the spreadsheet.

The completed projects will be at the top of the page in strike-through font, and the short list of fully staffed projects is listed below them in normal font.  On the back of the page, the partially staffed projects are listed in red, and the future projects are listed below them. And now you’re ready to realize the power of the two-sided printout.

Step 1. Ignore the projects on the back of the page (under-staffed and yet to be started projects).  They’re still on the do-do list, but they’ll wait patiently on the back of the page until resources are freed up and allocated.

Step 2. Finish the fully staffed projects on the front page.

Step 3. When you finish a project, change the font to “strike-through” and create a list of the freed-up resources.

Step 4. Flip to the back of the page, allocate the freed-up resources to one of the projects, and move the fully staffed project to the front of the page.

Step 5. Proceed to Step 2.

This is a straightforward process, but it requires great discipline.

Here’s a mantra to repeat daily –  I will finish a project before I start the next one.

Image credit — iggyshoot

For the past two decades, I’ve actively developed engineering leaders.  A good friend asked me how I do it, so I took some time to write it down.  Here is the curriculum in the form of How Tos:

How to build trust.  This is the first thing.  Always.  Done right, the trust-based informal networks are stronger than the formal organization chart. Done right, the informal networks can protect the company from bad decisions.  Done right, the right information flows among the right engineers at the right time so the right work happens in the right way.

How to decide what to do next. This is a broad one.  We start with a series of questions: What are we doing now?  What’s the problem? How do you know? What should we do more of?  What should we do less of?  What resources are available? When must we be done?

How to map the current state.  We don’t define the idealized future state or the North Star, we start with what’s happening now.  We make one-page maps of the territory.  We use drawings, flow charts, boxes/arrows, and the fewest words. And we take no action before there’s agreement on how things are.  The value of GPS isn’t to define your destination, it’s to establish your location.  That’s why we map the current state.

How to build momentum. It’s easy to jump onto a moving steam train, but a stationary one is difficult to get moving.  We define the active projects and ask – How might we hitch our wagon to a fast-moving train?

How to start something new. We start small and make a thought-provoking demo.  The prototype forces us to think through all the elements, makes things real, and helps others understand the concept. If that doesn’t work, we start smaller.

How to define problems so we can solve them easily. We define problems with blocks and arrows, and limit ourselves to one page.  The problem is defined as a region of contact between two things, and we identify it with the color red.  That helps us know where the problem is and when it occurs. If there are two problems on a page, we break it up into two pages with one problem.  Then we decide to solve the problem before, during, or after it occurs.

How to design products that work better and cost less. We create Pareto charts of the cost of the existing product (cost by subassembly and cost by part) and set a cost reduction goal.  We create Pareto charts of the part count of the existing product (part count by subassembly and part count by individual part number) and define a goal for part count reduction.  We define test protocols that capture the functionality customers care about. We test the existing product and set performance improvement goals for the new one.  We test the new product using the same protocols and show the data in a simple A-B format. We present all this data at formal design reviews.

How to define technology projects. We define how the customer does their work.  We then define the evolutionary history of our products and services, and project that history forward.  For lines of goodness with trajectories that predict improvement, we run projects to improve them.  For lines of goodness with stalled trajectories, we run projects to establish new technologies and jump to the next S-curve.  We assess our offerings for completeness and create technologies to fill the gap.

How to file the right patents.  We ask these questions: How quickly will the customer notice the new functionality or benefit? Once recognized, will they care? Will the patent protect high-volume / high-margin consumables? There are more questions, but these are the ones we start with.  And the patent team is an integral part of the technology reviews and product development process.

How to do the learning.   We start with the leader’s existing goals and deliverables and identify the necessary How Tos to get their work done. There are no special projects or extra work.

If you’re interested in learning more about the curriculum or how to enroll, send me an email mike@shipulski.com.

Image credit — Paul VanDerWerf

Business is about the effective allocation of resources.  Companies win when they do that better than their competitors.  Full stop.  If you believe that, the question is how to allocate resources effectively.  To me, everything starts with a map of the territory – a single-page map of today’s projects, the people you have, and the tools/infrastructure you have.  In short, before you can reallocate resources, map how you allocate them now.

Let the mapping begin.

The first step is to create a one-page summary (a map) of the resources on hand and the projects they work on (how they are allocated).  A simple spreadsheet is the way to go.  At the top, running left to right, list the names of all the people. Give each person their column.  On the left, running top to bottom, list the active projects, one project per row.  For each project, move left to right and ask if the person works on the project.  Put an X in their column if they contribute to the project in any way.  If they work on the project 2% of their time or more, X marks the spot.  You will be reluctant to do this, but the process is more meaningful if you do.

No fancy formats, no extra text, no headings, no footers, just columns of people against rows of projects.  And it MUST fit one page. MUST. Reduce the font size and the margins to fit it on one page. And if that doesn’t work, set the print area and choose the setting that scales the print area to fit on one page.  Put it on 11 by 17 paper if you must, but you must put it on one page.  You’ll have to squint to read the font when you do it right.

When you look at the one-page printout, the first thing you will notice is that you have too many rows because you have too many projects. (And, yes, you should list the quiet projects no one knows about.) The second thing you will notice is that everyone has too many Xs because they work on too many projects.  The third thing is some people have far more Xs than everyone else’s too many Xs.  All the project managers want them on the projects because they are good at getting projects done.

Let the culling begin.

It’s time to stop.  The best way to stop is to set a maximum time threshold to deliver the first dollar of revenue.  Any project that cannot deliver revenue sooner than the threshold should stop.  The threshold method is crude, fast, and effective.  It’s a great way to do the first pass culling.  For those projects that are difficult to stop due to political factors, don’t stop them but, rather, strongly pause them.  Then, use the reallocation process (described later) to move resources to better projects and let the politically charged projects die a slow death.  Good process beats bad projects.

Strike the cancelled projects from the record, eliminate their rows, and reprint the one-page map.  If you have the right number of projects and they’re fully staffed (this is unlikely), execute the projects that made the cut.  If you have too few projects, the next step is to come up with a set of new projects that deliver revenue sooner than the culled projects.  If you still have too many projects (too many people with too many Xs), it’s time to thin the herd again.  Sort the projects by the revenue they will generate over the threshold period plus three years.  The best projects will bubble to the top, and the bad ones will sink to the bottom.

Let the reallocating begin.

Now, delete all the Xs from the spreadsheet so none of the projects are staffed and no one has a project.  Start with the top row (your best project), move left to right, and place an X in the columns until the project is fully staffed.  Allocate the resources to your best project and get after it right now. Because your best project was understaffed, incremental will flow to the project. This will increase the probability you will hit the launch date or even pull it in.

Next, move down one row to your second-best project and repeat the process.  Add Xs left to right until the project is fully staffed.  But this time there’s a constraint – each column can contain only one X.  Because the people are now fully allocated to and actively working on your best project, they cannot work on the second-best project.  With all the Xs in place and your second-best project fully staffed, work the project hard with the reallocated resources.  Pull in the timeline if you can.

Repeat the process project by project until you can no longer fully staff a project.  And here’s where the game gets interesting. Don’t work a project you cannot staff fully.  There.  I said it.  With new product development projects, there is no partial credit. They’re either 100% done or 0% done.  A project that’s 80% done delivers 0% of the revenue.  But it’s worse than that.  Making “progress” on a project that won’t launch because it’s understaffed consumes functional support resources and will slow down your most important projects.  Don’t do that. Don’t run the project. Just don’t.  You’re better off paying the people to stay home so they don’t consume functional resources needed by the more important projects.

Instead of paying the people to stay home, try to add them to the active projects so you can launch those sooner.  In theory, those projects are fully staffed, but old behaviors die hard, and you probably didn’t fully staff the most important projects.  For the people who still don’t have a project (they cannot speed up the projects), train them on the skills/tools they’ll need for the next round of projects.  This will help you do the next projects better and faster.  Or, they could start on more forward-looking projects that don’t consume resources needed by the more urgent projects.

The process to allocate people to the most important projects is the same for resources like infrastructure for reliability testing or product validation.  With the same fully-staff-the-project approach, allocate the infrastructure resources to the most important projects.  Once there is no more infrastructure capacity, don’t run an under-resourced project.  If you run the lesser project, it will consume those precious infrastructure resources and slow down your most important projects.

You likely won’t be able to staff projects such that each person works on a single project.  The concept is more directional than literal.  Working on three projects is better than working on four, and two is better than three.

I did not describe how to estimate the project revenues, how to create new projects that deliver more revenue sooner, or how to create the right mix of projects – short, medium, and long.  But in a first-things-first way, I suggest you start with a singular focus – reallocate resources to your best projects (and, likely, fewer of them), so those projects effectively deliver revenue your company needs.

I think more focus will bring you more effectiveness.

Image credit — Charlie Wales

Supply chains have taken it on the chin, first from COVID-19 and now from tariffs (or the threat of them).  For the second time in several years, we have objective evidence there is more to a supply chain than implementing the lowest-cost way to meet predictable demand. Tariffs have highlighted the cost of an inflexible supply chain because we can quantify the savings from moving parts to countries with lower tariffs.

With tariffs, Lean’s mantra of “make it where you sell it” has sharper teeth.

At the most fundamental level, supply chains are governed by the parts.  Big parts, big factories; small parts, small machines; high part volume, high volume processes; low part volume, low volume processes; specialized coatings on the parts, specialized suppliers; parts with proprietary materials, sole source supplier.  The supply chain is defined by its parts.  And when you try to move the manufacture of parts from one country to another, these part-based constraints are the very thing that creates supply chain inflexibility.  Said another way, if you want to improve a supply chain’s flexibility, you’ve got to start with the parts.  If you want to reduce the tariffs of your supply chain, start with the parts.

All the parts in the supply chain are important but with tariffs, some parts are more important than others.  You can make significant improvements in your supply chain’s tariff signature if you know the handful of parts that will deliver the largest tariff reduction.  For each part within your supply chain calculate

(material cost x volume x tariff percentage)

and sort the product from largest to smallest.  For the top ten parts assess the part-specific constraints that governed the original decision of the supplier and country.  For each part identify a country with lower tariffs and pair it with the part-specific constraints.  You now have a list of the top ten opportunities to reduce the tariff signature, what must change in the design to move to a lower tariff location, and the entitlement savings.  The DFM-based tariff savings for each part is

(part cost x volume x difference in tariff percentage).

Take your top ten list to the product owner and show them the potential savings and ask to meet with the design community so you can explain how each part must change so it can move to a lower tariff country.  And tell them how much the company will save if those constraints are overcome.  This is like classic Design for Manufacturing (DFM) where the part is changed to reduce the cost to make the part, but, instead, the part is changed to reduce the cost of tariffs.

You now have a playbook for the top ten parts, the estimated tariff savings, and the work required to realize those savings.  You don’t have to implement the playbook, but you can.  And you can repeat the process for the next ten most important parts (11-20).  Now you have a playbook for twenty parts and the estimated savings.  You can continue the process as needed and step through the list ten parts at a time.

The process I describe is a good way to reduce the cost of tariffs. But to make a dent in the universe, there’s a much better way.  It’s called Design For Assembly, or DFA, which is all about product simplification through part elimination.  35% reductions in the number of parts are typical.  With DFA, high-tariff parts aren’t changed, they’re eliminated.  But where classic DFA prioritizes eliminating the highest-cost parts, tariff-based DFA prioritizes eliminating parts with the highest tariff costs.  The calculations to prioritize DFA-based tariff reduction are similar to those for DFM, but the savings are far more severe – the entire tariff and the part cost are saved.  The DFA savings are

(part cost x volume x tariff percentage) + (part cost x volume)

Run the calculation for the parts in your supply chain and sort the results from largest to smallest.  Take the list of the top ten to the design community and show them how much they can save if they eliminate the parts.  Tell them they’ll be the Heros of the Company if they pull it off.  Tell them you help them get the tools and training they’ll need.  Repeat for the second group of the ten most important parts (11-20).

DFM and DFA are wildly profitable and with the added savings of tariffs, the savings are beyond wild.  If there was ever a time to do DFM and DFA, it’s is now.

Image credit — Derell Licht

Clarity.  People will know why they dislike (or like) your position, have good ideas on improving it, and appreciate your clarity.  Well, at least they’ll recognize you’re communicating differently.

Brevity.  Make it short.

Visual.  When you draw a picture of the situation, people will understand the main system elements and how they interact.  Use arrows to describe how the system changes over time.  Even better, create a series of snapshots in a time series so you can decide to solve the problem before, during, or after. Words constrict. Use images to create space for divergent perspectives.

Distilled.  When you converge on the most important theme, the discussion is focused on the most important thing.  And when it strays it’s easy to recognize and put it back to importance. To distill, limit yourself to one page and limit the number of words to twelve.  This is unnatural and requires confidence through practice.

Know what you want to communicate.  Use fewer and simpler words.  Decide what to leave out. Use images and cartoons. Make it clean.

Less is more.

Image credit —  Charlie Wales

It doesn’t take much to make a difference, but if you don’t recognize the need to make one, you won’t make one.

When you’re in a meeting, watch and listen. If someone is quiet, ask them a question. My favorite is “What do you think?” Your question says you value them and their thinking, and that makes a difference. Others will recognize the difference you made, and that may inspire them to make a similar difference at their next meeting.

When you see a friend in the hallway, look them in the eyes, smile, and ask them what they’re up to.  Listen to their words but more importantly watch their body language.  If you recognize they are energetic, acknowledge their energy, ask what’s fueling them, and listen.  Ask more questions to let them know you care.  That will make a difference.  If you recognize they have low energy, tell them, and then ask what that’s all about.  Try to understand what’s going on for them.  You don’t have to fix anything to make a difference, you have to invest in the conversation.  They’ll recognize your genuine interest and that will make a difference.

If you remember someone is going through something, send them a simple text –  “I’m thinking of you.”  That’s it.  Just say that.  They’ll know you remembered their situation and that you care.  And that will make a difference.  Again, you don’t have to fix anything.  You just have to send the text.

Check in with a friend.  That will make a difference.

When you learn someone got a promotion, send them a quick note.  Sooner is better, but either way, you’ll make a difference.

Ask someone if they need help.  Even if they say no, you’ve made a difference.  And if they say yes, help them.  That will make a big difference.

And here’s a little different spin.  If you need help, ask for it.  Tell them why you need it and explain why you asked them.  You’ll demonstrate vulnerability and they’ll recognize you trust them.  Difference made.  And your request for help will signal that you think they’re capable and caring.  Another difference made.

It doesn’t take much to make a difference.  Pay attention and take action and you’ll make a difference.  But really, you’ll make two differences. You’ll make a difference for them and you’ll make a difference for yourself.

Image credit — Geoff Henson

When planning a project, we usually start with a traditional left-to-right schedule. On the left is the project’s start date, where tasks are added sequentially rightward toward completion. When all the tasks are added and the precedence relationships shift tasks rightward, the completion date becomes known. No one likes the completion date, but it is what it is until we’re asked to pull it in.

I propose a different approach – a reverse schedule.  Instead of left to right, the reverse schedule moves right to left.  It starts with the completion date on the right and stacks tasks backward in time toward today. The start date emerges when all the tasks are added and precedence relationships work their magic.  Where the traditional schedule tells us when the project will finish, the reverse schedule tells us when we should start.  And, usually, the reverse schedule says we should have started several months ago and the project is already late.

There are some subtle benefits of the reverse schedule.  It’s difficult to game the schedule and reduce task duration to achieve a desired start date because the tasks are stacked backward in time. (Don’t believe me?  Give it a try and you’ll see.)  And because the task duration is respectful of the actual work content, the reverse schedule is more realistic.  And when there’s too much work in a reverse schedule, the tasks push their way into the past and no one can suggest we should go back in time and start the project three months ago.  And since the end date is fixed, we are forced to acknowledge there’s not enough time to do all the work.  The beauty of the reverse schedule is it can tell us the project is late BEFORE we start the project.

Here’s a rule: You want to know you’re late before it’s too late.

The real power of the reverse schedule is that it creates a sense of urgency around starting the project.  In the project planning phase, a delay of a week here and there is no big deal. But, when the start date slips a day, the completion date slips a day.  The reverse schedule clarifies the day-for-day slip and helps the resources move the project sooner so the project can start sooner.  And those of us who run projects for a living know this is a big deal.  What would you pay for an extra two weeks at the end of a project that’s two weeks behind schedule?  Well, if you started two weeks sooner, you wouldn’t need the extra time.

The project doesn’t start when the project schedule says it starts.  The project starts when the resources start working on the project in a full-time way.  The reverse schedule can create the sense of urgency needed to get the critical resources moved to the project so they can start the work on time.

Image credit — Steve Higgins

Tariffs.  Economic uncertainty.  Geopolitical turmoil.  There’s no time for elegance.  It’s time for the art of the possible.

Give your sales team a reason to talk to customers.  Create something that your salespeople can talk about with customers.  A mildly modified product offering, a new bundling of existing products, a brochure for an upcoming new product, a price reduction, a program to keep prices as they are even though tariffs are hitting you.  Give them a chance to talk about something new so the customers can buy something (old or new).

Think Least Launchable Unit (LLU). Instead of a platform launch that can take years to develop and commercialize, go the other way.  What’s the minimum novelty you can launch? What will take the least work to launch the smallest chunk of new value?  Whatever that is, launch it now.

Take a Frankensteinian approach. Frankenstein’s monster was a mix and match of what the good doctor had scattered about his lab.  The head was too big, but it was the head he had.  And he stitched onto the neck most crudely with the tools he had at his disposal.  The head was too big, but no one could argue that the monster didn’t have a head.  And, yes, the stitching was ugly, but the head remained firmly attached to the neck.  Not many were fans of the monster, but everyone knew he was novel.  And he was certainly something a sales team could talk about with customers.  How can you combine the head from product A with the body of product B?  How can you quickly stitch them together and sell your new monster?

Less-With-Far-Less. You’ve already exhausted the more-with-more design space.  And there’s no time for the technical work to add more.  It’s time for less.  Pull out some functionality and lots of cost.  Make your machines do less and reduce the price.  Simplify your offering and make things easier for your customers.  Removing, eliminating, and simplifying usually comes with little technical risk.  Turning things down is far easier than turning them up.  You’ll be pleasantly surprised how excited your customers will be when you offer them slightly less functionality for far less money.

These are trying times, but they’re not to be wasted. The pressure we’re all under can open us up to do new work in new ways.  Push the envelope. Propose new offerings that are inelegant but take advantage of the new sense of urgency forced.

Be bold and be fast.

Image credit — Geoff Henson

Anyone can create a presentation with thirty slides, but it takes a rare bird to present for thirty minutes with a single slide.

With thirty slides you can fully describe the system.  With one slide you must know what’s important and leave the rest.  With thirty slides you can hide your lack of knowledge.  With one slide it’s clear to all that you know your stuff, or you don’t.

With one slide you’ve got to know all facets of the topic so you can explain the interactions and subtleties on demand.  With thirty slides you can jump to the slide with the answer to the question. That’s one of the main reasons to have thirty slides.

It’s faster to create a presentation with thirty slides than a one-slide presentation.  The thirty slides might take ten hours to create, but it takes decades of experience and study to create a one-slide presentation.

If you can create a hand sketch of the concept and explain it for thirty minutes, you will deliver a dissertation.  With a one-slide-per-minute presentation, that half hour will be no more than a regurgitation.

Thirty slides are a crutch.  One slide is a masterclass.

Thirty slides – diluted.  One slide – distilled.

Thirty slides – tortuous.  One slide – tight.

Thirty slides – clogged.  One slide – clean.

Thirty slides – convoluted.  One slide – clear.

Thirty slides – sheet music.  One slide – a symphony.

With fewer slides, you get more power points.

With fewer slides, you get more discussion.

With fewer slides, you show your stuff more.

With fewer slides, you get to tell more stories.

With fewer slides, you deliver more understanding.

If you delete half your slides your presentation will be more effective.

If you delete half your slides you’ll stand out.

If you delete half your slides people will remember.

If you delete half your slides the worst outcome is your presentation is shorter and tighter.

Why not reduce your slides by half and see what happens?

And if that goes well, why not try it with a single slide?

I have never met a presentation with too few slides.

Image credit — NASA Goddard