Shipulski On Design

Startups are good at making something work in the lab for the first time. However, startups are not good at moving their one-in-a-row prototypes to the manufacturing floor.  But if startups are to scale, that’s exactly what they must do.  For startups to be successful, they must continually change the design to enable the next level of production volume.

To do that, I propose a 10, 100, 1000 approach.

After the one-in-a-row prototypes, how will you make 10?  Can the crude assembly process produce 10 prototypes?  If so, use the same crude assembly process.  The cost of the prototypes is not a problem at this stage, so there’s no need to change the manufacturing processes to reduce the cost of the components.  And at these low volumes, it’s unlikely the existing assembly process is too labor intensive (you’re only making 10) so there’s likely no need to change the process from a “time to build” perspective. But if the variation generated by the assembly process leads to prototypes that don’t function properly, the variation of the assembly process must be controlled with poke-yoke measures.  Add only the controls you need because that work takes money and time which you don’t have as a startup.  Otherwise, build the next 10 like you built the first one.

After the first 10, how will you make the next 100?  Building 100 units doesn’t sound like a big deal, but 100 is a lot more than 10.  Do you have suppliers who will sell you 100 of each part?  Do you have the factory space to store the raw materials?  Do you have the capability and capacity to inspect the incoming material? Do you have the money to buy all the parts?  If the answer to all these questions is yes, it’s time to ask the difficult questions.

The cost of the units is likely still not a problem because the volumes are still small.  There’s likely no need to change the manufacturing process (e.g., moving from machining to casting) to reduce the cost of the units.  And it’s unlikely the time to build the units is becoming a problem because a super long build time isn’t all that problematic when building 100 units.  So it’s not time to reduce the number of parts in the product (product simplification through part count reduction – aka, Design for Assembly).  But it’s likely time to reduce the variation of the assembly process and eliminate the rework-inspect-test loop that comes when each unit that emerges from the production process is different.  It’s time for assembly instructions, assembly fixtures, dedicated tools at each workstation, measurement tools to inspect the final product, and a group of quality professionals to verify the product is built correctly.

After the first 100, how will you make the next 1000? If you can, avoid changing the design, the manufacturing processes, or the assembly process.  Keep everything the same and build 1000 units just as you built the first 100.  But that’s unlikely because the cost will be too high and the assembly time will be too long. For the most expensive parts, consider changing the manufacturing process to one that can support higher volumes at a lower cost.  You likely will have to buy the parts from another supplier who specializes in the new process and for that, you’ll need a purchasing professional with a quality background.  To reduce build time, do Design for Assembly (DFA) to eliminate parts (fasteners and connectors).  And for the processes that generate the highest rework times and scrap, add the necessary process controls to reduce variation and eliminate defects.  Do the minimum (lowest investment dollars and design time) to achieve the appropriate cost and quality levels and declare success.

After 1000 units, it’s time to automate and move to new manufacturing processes.  For the longest assembly processes, change the design (the parts themselves) to enable automated assembly processes. For the highest cost parts, change the parts (the design itself) to enable the move to manufacturing processes with lower cost signatures.  The important idea is that the design and its parts must change to automate and enable lower-cost manufacturing processes.  You’ll need new suppliers and purchasing professionals to bring them on board.  You’ll need quality professionals to verify the quality of the incoming parts and the output of the assembly process.  You’ll need manufacturing and automation engineers to simplify and automate the manufacturing processes.

The 10, 100, 1000 process is rather straightforward but it’s difficult because it requires judgement.  At what production volume do you move to higher volume manufacturing processes to reduce costs?  At what production volumes do you change the design to automate the assembly process to reduce assembly time?  At what point do you add assembly fixtures to reduce variation?  Which assembly processes do you improve and which do you leave as-is?  When do you spend money on improvements and when do you buckle down and grind it out without making improvements?

The answer to all these questions is the same – hire a pro who has done it before.  Hire a pro who knows when (and how) to do Design for Manufacturing and when to keep the design as it is.  Hire a pro who knows when (and how) to add poke-yoke solutions and when to keep the assembly process as it is and rework the defects because that’s the lowest cost and fastest way to go. Hire a pro who knows when to change the design to reduce assembly time (Design for Assembly) and when to change the design and invest in automated assembly.  Hire a pro who knows how (and when) to implement a full-blown quality system.

When it’s time to move from the lab to the factory floor, it’s time to hire a pro.

Image credit — Jim Roberts Gallery

Be successful, but be yourself.

Accept people for who they are and everything else gets better.

Tell the truth, even if it causes stress.  In the short term, it is emotionally challenging but in the long term, it builds trust.

Disagree, yes.  Disappoint, yes.  Disavow, no.

Be effective, but be yourself.

If your actions cause pain, apologize. It’s that simple.

It’s easier to accept others as they are when you can do the same for yourself.

Judging yourself is the opposite of accepting yourself as you are.

When someone needs help, help them.

Be skillful, but be yourself.

If there’s an upside to judging yourself, I don’t know it.

When you’re true to yourself, people can disagree with your position but not your truthfulness.

When you help someone, it’s like helping yourself twice.

There are plenty of people who will judge you.  There’s no need to join that club.

When you stand firmly on emotional bedrock, your perspective is unassailable.

When you’re true to yourself, it’s easier for others to do the same.

Be yourself especially when it’s difficult.  Your courage will empower others.

If there’s no upside to judging yourself, why do it?

Some questions for you:

How would things be different if you stopped judging yourself? Why not give it a try tomorrow?

Wouldn’t you like to be unassailable? Why not stand on your emotional bedrock tomorrow?

Over the next week, how many people will you help?

Over the next week, how many times will you demonstrate courage?

Over the next week, how many times will you be true to yourself, even when it’s difficult?

Image credit – _Veit_

If you don’t believe in the project, the team will sense it; energy will drain from the project; and no one will want to work the project.

If you don’t believe in the project, you can’t make yourself believe in the project.

If you don’t believe in the project, you can’t fool people and make them believe you believe in the project.  Your disbelief will flow from your pores like a bad smell.

If you don’t believe in the project, your disbelief will weaken an already weak project.

If you don’t believe in the project, your disbelief can twist a good project into a bad one.

If you don’t believe in the project, it may not be the right project, but you are not the right person to run it.

If you don’t believe in the project, but the company still wants you to run it, the worst thing for the project is for you to run it; the worst thing for the company is for you to run it; and the worst thing for your career is to refuse to run it.

If from the start you think the project will fail, tell the right people why you think it will fail. If after telling them why you think the project will fail, they then ask you to run the project, you have a problem and a choice.  Your problem is you’re the wrong person to run the project.  Your choice is to run the project into the ground or take the lumps for not running it into the ground.

My choice is to give someone else an opportunity to run the project.  I think life is too short to run a project you don’t believe in.

Image credit — Bennilover

We wait because we don’t have enough information to make a decision.

We wait until the decision makes itself because no one wants to be wrong.

We wait for permission because of the negative consequences of being wrong.

We wait to use our judgment until we have evidence our judgment is right.

We wait for support resources because they are spread over too many projects.

We wait for a decision to be made because no one is sure who makes it.

We wait to reduce risk.

We wait to reduce costs.

We wait to move at the speed of trust.

We wait because too many people must agree.

We wait because disagreement comes too slowly.

We wait for disagreement because we don’t subscribe to “clear is kind.”

We wait when decisions are unmade.

We wait because there is insufficient courage to stop the bad projects.

We wait to stop things slowly.

We use waiting as a slow no.

We wait to reallocate resources because even bad projects have momentum.

We wait when we dislike the impending outcome.

We wait for the critical path.

We wait out of fear.

Image credit — Sylvia Sassen

Software may be eating the world, but the hardware elements of a startup’s work define when lunch is served.

Hardware takes longer than software.  With hardware, after the product and its parts are designed, companies are vetted/selected to make the parts; contracts are signed to make the parts; the parts are made; the parts are shipped; the parts are received; the parts are inspected; and the parts are put in their locators.  Then, the manufacturing process is defined, the manufacturing tooling is designed and purchased; the manufacturing documentation is created; the final test system is designed and built; and the parts are assembled into the product. Then, the product is run through final test and tested for robustness.  After it’s learned the manufacturing process created too much variation and the insufficient robustness manifests, the manufacturing process and its documentation are changed to reduce variation; the parts that failed are redesigned, purchased, made, shipped, and received; and the next iteration of the product is built and tested.  This process is repeated until the product is robust and the manufacturing process is repeatable.  This is why hardware takes longer than software.

If the software is done but the hardware isn’t, the software must wait for the hardware and the customer must wait for the finished product. To get the hardware done faster, recognize that redesign loops are part of the game and invest in the capability to iterate quickly.  Line up the suppliers to make parts quickly; keep utilization low on the support resources so they can jump on the work when it arises (think fire stations who can respond quickly when there’s a fire); and avoid part-time resources on the critical path.  There may be other things to focus on, but only after taking care of these three.

Software may be eating the world, but the hardware elements of a startup’s work govern the cost of getting to the dinner table.

Hardware costs more to make than software.  Hardware is made of steel, aluminum, injection molded plastics, and rare earth elements, all of which cost money.  And because startups do things that have not been done before, the materials can be special (costly).  And unlike software, the marginal cost of an incremental unit is non-zero.  With hardware, if you want to make another one you’ve got to buy more of the materials; you have to pay people to make it; you have to buy/build the manufacturing system; you have to buy the measurement systems and engineering infrastructure; and you have to pay people to break-test-fix the product until it’s ready.

What’s a startup to do?

To do hardware faster, focus on learning.  And to do hardware more cost-effectively, focus on learning.

For both time and money, learning efficiency is a good starting point.  The most efficient learning is the learning you don’t have to do, so be ruthless in how you decide what you DON’T learn. Where possible, declare all but the most vital problems as annoyances and save them for later. (Annoyances don’t require learning.)  This will concentrate your precious resources on fewer problems, improve your learning rate, and keep costs to a minimum.

Here’s a good test to decide if the learning is worth learning.  Ask yourself “If we accomplish this learning objective, how will the customer benefit?”  If there is low or no customer benefit, say no to the learning objective.  If there is medium customer benefit, say no to the learning objective.  If there is significant customer benefit, do the learning.

For those learning objectives that make it through the gauntlet, learn what you need to learn, but no more.  To do this, create a formal learning objective: “We want to learn [enter learning objective here].”  With learning objectives, the tighter the better. And define the criteria for decision making: “If the result of the test is [define objective measurement here], we will decide [enter decision here].” With decision criteria, the clearer the better.

Learn effectively, not elegantly.  Be bold, rough, and crude with how you learn.  Design tests that take advantage of the resources you have on hand so you can learn quickly.  If you can run a crude test in one hour and the perfect test will take a week, run three crude tests and be done by the end of the day.

Learn with less confidence and more judgment.  If a wrong decision can be overcome quickly and with low cost, be less confident and use more judgment.

Whether driven by hardware, software, or the integration of both, project completion is governed by the critical path.  And with longer time constants, it’s more likely that the hardware defines the critical path.  The total cost of the project is the sum of the three costs: software, hardware, and integration.  And because hardware requires expensive materials, factories, engineering labs, people to run the tests, and people to make the products, hardware is likely a large percentage of the project costs.

Image credit — Günter Hentschel

Do the project right or do the right project – which would you choose?

If you improve time to market, the only thing that improves is time to market.  How do you feel about that?

Customers pay for things that make their lives easier.  Time to market doesn’t do that.

There’s no partial credit with new product development projects.  If the product isn’t 100% ready for sale, it’s 0% ready.

If you made 1/8^th progress on 8 projects, you made zero progress. But you did consume valuable resources.

If you made 100% progress on one project, you made progress.

When you have too many projects, you get too few done.

If you don’t know how many projects your company has, you have too many.

Would you rather choose the right project and run it inefficiently or choose the wrong project and run it efficiently?

When you choose the wrong project but run it efficiently, that’s called efficient ineffectiveness.

You can save several weeks making sure you choose the right project by starting the project too soon and running the wrong one for two years.

If your projects are slow, it’s likely the support functions are too highly utilized.  Add capacity to keep their peak utilization below 85%.

When shared resources are sized appropriately, they’re underutilized most of the time.  Think fire station and firefighters – when there’s a fire they respond quickly, and when there’s no fire they improve their skills so they can fight the next one better than the last.

If your projects are slow, check to see if you have resources on the critical path that work part-time.  Part-time resources support multiple projects and don’t work full-time on your project.  And you can’t control when they work on your project.  There’s no place for that on the critical path.

If you’re thinking about using part-time resources on the critical path, don’t.

Know where the novelty is and work that first.  And before you can work on the novelty you’ve got to know where it is.

You can have too little novelty, meaning the new product is so much like the old one there’s no need to launch it.  Mostly, though, projects have too much novelty.

If you are working on a clean-sheet design, there is no such thing.  There are no green-field projects.  All projects are brown-field projects. It’s just that some are browner than others.

Novelty generates problems and problems take three times longer to solve than anyone thinks.  To reduce the number of problems, declare as many as possible as annoyances.  Unlike problems, annoyances don’t have to be solved by the project.  Remember, it’s okay to save some work for the next project.

Even though you have a product development process, that process is powered by people.  People make it work and people make it not work.  If you get one thing right, get the people part right.

Image credit – claudia gabriela marques

If you try to change what you cannot, your trying will not bring about change. But it will bring about 100% frustration, 100% dissatisfaction, 100% missed expectations, 0% progress, and, maybe, 0% employment.

Here’s a rule: If success demands you must change what you cannot, you will be unsuccessful.

If you try to change something you cannot change but someone else can, you will be unsuccessful unless you ask them for help.  That part is clear.  But here’s the tricky part – unless you know you cannot change it and they can, you won’t know to ask them.

If you know enough to ask the higher power for help and they say no but you try to change it anyway, you will be unsuccessful.  I don’t think that needed to be said, but I thought it important to overcommunicate to keep you safe.

Here’s the money question – How do you know if you can change it?

Here’s another rule: If you want to know if you can change something, ask.

If the knowledgeable people on the project say they cannot change it, believe them.  Make a record of the assessment for future escalation, define the consequences, and rescope the project accordingly.  Next, search the organization (hint – look north) for someone with more authority and ask them if they can grant the authority to change it.  If they say no, document their decision and stick with the rescoped project plan.  If they say yes, document their decision and revert to the original project plan.

If you do one thing tomorrow, ask your project team if success demands they change something they cannot.  I surely hope their answer is no.

Image credit — zczillinger

When you do something for a long time, the physical and mental muscles you exercise get stronger and you get better at that activity.  But where the muscles you use get stronger, the ones you don’t use atrophy and you get worse at all the other things.

When you do something for a long time, people see you as someone who does that one thing.  And because it’s easy for everyone, that same old work lands on your desk and the system reinforces the problem.  The company knows it will get done quickly and well, and because you’ve done it before, it’s easy for you.  But what’s good and easy in the short term may not be so good and easy in the long term.  When you do what you did last time, you get stale and you don’t grow. It’s the same for your career.  When they see only one slice of you, there’s a long-term downside

When you look at the same old problems for a long time, you see only the same old solutions.  And more troubling, you’re blind to your blindness.  If you’ve solved the same family of problems for the last decade, you won’t see the new solutions made possible by developments in new areas.  And more troubling, you won’t see that it’s time to solve new problems because the same old problems find your desk.

What’s a dinosaur to do?

Pair up with a younger person who wants to learn and teach them how to solve problems.  Their energy will rub off on you and your smarts will contaminate them.  A fair trade for both.  Teach them how to understand the situation as it is – both in the problem space and political space.  Teach them how to read the tea leaves and hear what’s unsaid.  You’ll learn you know far more than you thought and you’ll get to show your whole self to your younger partner in crime.

Put them in a position to succeed and take pride in their success.  Give them credit and revel in their development. Help them stretch and protect them from breaking. Keep them safe and help them live dangerously.  Provide air cover as only you can, and do it with plausible deniability.  You will get great joy (and energy!) from this.

When you’re low on energy, help people. When you’re down in the dumps, take someone to lunch and listen to them.  When you’re tired of the same old work, help people do new work.  And when you want to feel good about what you know, teach people.

At this point in your career, you have all you need and plenty to spare.  Ground yourself in your abundance and give it away.  Everyone will be better for it, including you.

Image credit — Steve Walker

When you catch someone doing good work, do you praise them?  If not, why not?

Praise is best when it’s specific – “I think it was great when you [insert specific action here].”

If praise isn’t authentic, it’s not praise.

When you praise specific behavior, you get more of that great behavior.  Is there a downside here?

As soon as you see praise-worthy behavior, call it by name. Praise best served warm.

Praise the big stuff in a big way.

Praise is especially powerful when delivered in public.

If praise feels good when you get it, why not help someone else feel good and give it?

If you make a special phone call to deliver praise, that’s a big deal.

If you deliver praise that’s inauthentic, don’t.

Praise the small stuff in a small way.

Outsized praise doesn’t hit the mark like the real deal.

There can be too much praise, but why not take that risk?

If praise was free to give, would you give it?  Oh, wait.  Praise is free to give.  So why don’t you give it?

Praise is powerful, but only if you give it.

Image credit — Llima Orosa

If you have nothing to say, be the person that doesn’t say it.

If you’re not the right person to do it, you’re also the right person not to do it.  Why is it so difficult for to stop doing what no longer makes sense?

If it made sense to do it last time, it’s not necessarily the right thing to do this time, even if it was successful last time.  But if it was successful last time, it will be difficult to do something different this time.

If we always standardize on what we did last time, mustn’t this time always be the same as last time? And musn’t next time always be the same as this time?

If it’s new, it’s scary.  And if it’s scary, it’s bad.  And we don’t like to get in trouble for doing bad things. And that’s why it’s difficult to do new things.

Deming said to “Drive out fear.” But that’s scary.  What are the attributes of the people willing to face the fear and demonstrate that fear can be overcome?  At your company are they promoted? Do they stay? Do they leave?

Without someone overcoming their internal fear, there can be no change.

If a new thing is blocked from commercialization because it wasn’t invented here, why not reinvent it just as it is, declare ownership, and commercialize it?

If prevention is worth a pound of cure, why do people that put out forest fires get the credit while those that prevent them go unnoticed? Does that mean your career will benefit it you start small fires in private and put them out quickly for all to see?

If you always do what’s best for your career, that’s not good for your career.

When you do something that’s good for someone’s career but comes at the expense of yours, that’s good for your career.

Why not say nothing when nothing is the right thing to say?

Why not say no when no is the right thing to say?

Why not do something new even though it’s different than what was successful last time?

Why not demonstrate fearlessness and break the trail for others?

Why not be afraid and do it anyway?

Why not build on something developed by another team and give them credit?

Why not do what’s right instead of doing what’s right for your career?

Why not do something for others?  As it turns out, that’s the best thing to do for yourself.

Image credit — Steve Hammond

The Idealized Future State (IFS) is all the rage these days.  The idea behind it is the team defines the IFS so it can then define the steps needed to achieve it.  The IFS is just what it says it is – a description of the perfect state of our future affairs.  It defines what things will look like and how things will go when the system evolves in the best imaginable way.  It describes a future perfection.  Some troubling questions should come to mind.  Here are some.

How is “best” defined? What if there is disagreement on multiple bests? Whose best becomes bestest? Once the best best is chosen, can’t it be bested by a better best?

If there were two IFSs at a social event, what would you ask them to figure out which one was an almost-IFS and which was the ideal-IFS?  And if both were imposter-IFSs, how could you tell?

Since the IFS is supposed to predict the future and we can’t predict the future, why do we think it’s a good idea to ask people to predict the future?

If it takes imagination to create an IFS and imagination is not bound by reality, isn’t it likely that an imagined idealized future is not possible to achieve?  And won’t a project that must achieve an impossible future likely to run long and miss its launch window?

Wouldn’t an Achievable Future State (AFS) be a little less bad?  But who gets to choose what is achievable and what is not?  And how could they know?

Instead of fixating on an IFS as the ultimate destination, why not agree on the situation as it is and locate yourself within that context?  Why not start the journey with a sense of direction?*

Why not understand the situation as it is and do the next right thing?*

Why not run small experiments in parallel and do more of what works and less of what doesn’t?*

*Thanks to Dave Snowden for this language.