Shipulski On Design

Archive for the ‘Technology’ Category

Demoing something for the first time is difficult, but doing it for the second time is easy.  And when you demo a new solution the first time, it (and you) will be misunderstood.

What is the value of this new thing?  This is a good question because it makes clear they don’t understand it. After all, they’ve never seen it before.  And it’s even better when they don’t know what to call it. Keep going!

Why did you do this?  This is a good question because it makes clear they see the demo as a deviation from historically significant lines of success.  And since the lines of success are long in the tooth, it’s good they see it as a violation of what worked in the olden days.  Keep going!

Whose idea was this? This is code: “This crazy thing is a waste of time and we could have applied resources to that tired old recipe we’ve been flogging for a decade now.”  It means they recognize the prototype will be received differently by the customer.  They don’t think it will be received well, but they know the customer will think it’s different.  Keep going!

Who approved this work? This is code: “I want to make this go away and I hope my boss’s boss doesn’t know about it so I can scuttle the project.”  But not to worry because the demo is so good it cannot be dismissed, ignored, or scuttled. Keep going!

Can you do another demo for my boss?  This one’s easy.  They like it and want to increase the chances they’ll be able to work on it.  That’s a nice change!

Why didn’t you do this, that, or the other? They recognized the significance, they understood the limitations, and they asked a question about how to make it better. Things are looking up!

How much did the hardware cost? They see the new customer value and want to understand if the cost is low enough to commercialize with a good profit margin.  There’s no stopping this thing!

Can we take it to the next tradeshow and show it to customers?  Success!

Image credit — Bennilover

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

When new ideas come from the outside, they are dismissed out of hand.  The technical term for this behavior is Not Invented Here (NIH).  Because it was not invented by the party with official responsibility, that party stomps it into dust.  But NIH doesn’t stomp in public; it stomps in mysterious ways.

Wow!  That’s a great idea!  Then, mysteriously, no progress is made and it dies a slow death.

That’s cool! Then there’s a really good reason why it can’t be worked.

That’s interesting!  Then that morphs into the kiss of death.

We never thought of that.  But it won’t scale.

That’s novel!  But no one is asking for it.

That’s terribly exciting! We’ll study it into submission.

That’s incredibly different!  And likely too different.

When the company’s novel ideas die on the vine, they likely die at the hands of NIH. If you can’t understand why a novel idea never made it out of the lab, investigate the crime scene and you may find NIH’s fingerprints.  If customers liked the new idea yet it went nowhere, it could be NIH was behind the crime. If it makes sense, but it doesn’t make progress, NIH is the prime suspect.

If a team is not receptive to novel ideas from the outside, it’s because they consider their own ideas sufficiently good to meet their goals.  Things are going well and there’s no reason to adopt new ideas from the outside.  And buried in this description are the two ways to overcome NIH.

The fastest way to overcome NIH is to help a new idea transition from an idea conceived by someone outside the team to an idea created by someone inside the team.  Here’s how that goes.  The idea is first demonstrated by the external team in the form of a functional prototype.  This first step aims to help the internal team understand the new idea.  Then, the first waiting period is endured where nothing happens.  After the waiting period, a somewhat different functional prototype is created by the external team and shown to the internal team.  The objective is to help the internal team understand the new idea a little better.  Then, the second waiting period is endured where nothing happens.  Then, a third functional prototype is created and shown to the internal team.  This time, shortcomings are called out by the external team that can only be addressed by the internal team.  Then, the last waiting period is endured.  Then, after the third waiting period, the internal team addresses the shortcomings and makes the idea their own.  NIH is dead, and it’s off to the races.

The second fastest way to overcome NIH is to wait for the internal team to transition to a team that is receptive to new ideas initiated outside the team.  The only way for a team to make the transition is for them to realize that their internal ideas are insufficient to meet their objectives.  This can only come after their internal ideas are shown to be inadequate multiple times.  Only after exhausting all other possibilities, will a team consider ideas generated from outside the team.

When the external team recognizes the internal team is out of ideas, they demonstrate a functional prototype to the internal team.  And they do it in an “informational” way, meaning the prototype is investigatory in nature and not intended to become the seed of the internal team’s next generation platform.  And as it turns out, it’s only a strange coincidence that the functional prototype is precisely what the internal team needs to fuel the next-generation platform.  And the prototype is not fully wrung out.  And as it turns out, the parts that need to be wrung out are exactly what the external team knows how to do.  And when the internal team needs expertise from the external team to address the novel elements, as it turns out the external team conveniently has the time to help out.

Not Invented Here (NIH) is real.  And it’s a powerful force. And it can be overcome.  And when it is overcome, the results are spectacular.

Image credit — Becky Mastubara

When you work in domains of high uncertainty, creating goals for the next year is exceptionally difficult.

When you try to do something that hasn’t been done before, things may blow up instantly, things may work out after two years of hard work, or things may never work.  So, how do you create the goal for that work? Do you give yourself one month to complete the work? And things haven’t worked out at the end of the month, do you stop the work or do you keep going?  If it blows up instantly, but you think you know why, do you keep going? Do you extend the due date for the goal?  At the start of the work, should the timeline have been set to one year instead of one month?  And who decides that?  And how do they decide?

When you have to create your goals for something that hasn’t been done before and the objectives of the work are defined by another team, yet that team hasn’t done the prework and cannot provide those objectives, what do you do? Do you create a goal for the other team to define the objectives? And what if you have no control over that team’s priorities and you don’t know when (or if) they’ll provide the needed information?  What does a goal look like when you don’t know the objectives of the work nor do you know when (or if) you’ll get that information.  Can you even create a goal for the work when you don’t know what that work is?  And how do you estimate a completion date or the resource requirements (both the flavor and quantity) when you don’t know the objectives?  What does that goal look like?

When you have to create your goals for a team of ten specialized people who each have unique skills, but you don’t know the objectives of the work, when that work can start, or when that work will finish, how do you cascade the team’s goals to each team members?  What do their goals look like?  Is the first goal to figure out the goal?  How many goals does it take to fill up their year when you don’t know what the work is or how long it will take?

When working in domains of high uncertainty, the goals go like this: define the system as it is, define something you want to improve, try to improve it, and then do the next right thing.  Unfortunately, that doesn’t fit well with the traditional process of setting yearly goals.

And your two questions should be: How do you decide what to improve? and How do you choose the next right thing?

Image credit — Rab Lawrence

It’s difficult to describe what an innovative company looks like, and there’s no singular recipe or direction that is right for all companies.  Here are some From: To: pairings that I hope will help you in your migration toward innovation.  You’re heading in the right direction as your company generates Tos and fewer Froms.

From:  No one is asking for that technology.

To:       What does this new technology stand for?

From:  How will the company benefit?

To:       How will the customer benefit?

From:  What’s the smallest improvement that will make a difference?

To:       How can we make the most significant difference?

From:  When will you be done?

To:       What will you learn?

From:  This might not work.

To:       How might this work?

From:  Start, Start, Continue.

To:       Stop, Start, Continue.

From: We’ve tried that before and it didn’t work.

To:      What’s changed since last time?

From:  What does perfect look like?

To:       How is the work done today and which elements can we improve?

From:  Defend and Defend the core.

To:       Extend and Defend the core.

From:  Define the idealized future state.

To:       Start with the work.

From:  That won’t work!

To:       Hey, watch this!

We use our previous experiences as context for decisions we make in the present.  When we have a bad experience, the experience-context pair gets stored away in our memory so that we can avoid a similar bad outcome when a similar context arises.  And when we have a good experience, or we’re successful, that memory-context pair gets stored away for future reuse. This reuse approach saves time and energy and, most of the time keeps us safe.  It’s nature’s way of helping us do more of what works and less of what doesn’t.

The system works well when we correctly match the historical context with today’s context and the system’s fundamentals remain unchanged.  There are two potential failure modes here.  The first is when we mistakenly map the context of today’s situation with a memory-context pair that does not apply.  With this, we misapply our experience-based knowledge in a context that demands different knowledge and different decisions.  The second (and more dangerous) failure mode is when we correctly identify the match between past and current contexts but the rules that underpin the context have changed.  Here, we feel good that we know how things will turn out, and, at the same time, we’re oblivious to the reality that our experience-based knowledge is out of date.

“If a cat sits on a hot stove, that cat won’t sit on a hot stove again. That cat won’t sit on a cold stove either. That cat just don’t like stoves.”  Mark Twain

If you tried something ten years ago and it failed, it’s possible that the underpinning technology has changed and it’s time to give it another try.

If you’ve been successful doing the same thing over the last ten years, it’s possible that the underpinning business model has changed and it’s time to give a different one a try.

“Hissing cat” by Consumerist Dot Com is licensed under CC BY 2.0.

If you know the right answer, you’re working on an old problem or you’re misapplying your experience.

If you are 100% sure how things will turn out, let someone else do it.

If there’s no uncertainty, there can be no learning.

If there’s no learning, your upstart competitors are gaining on you.

If you don’t know what to do, you’ve started the learning cycle.

If you add energy to your business model and it delivers less output, it’s time for a new business model.

If you wait until you’re sure you need a new business model, you waited too long.

Successful business models outlast their usefulness because they’ve been so profitable.

When there’s a project with a 95% chance to increase sales by 3%, there’s no place for a project with a 50% chance to increase sales by 100%.

When progress has slowed, maybe the informal networks have decided slower is faster.

If there’s something in the way, but you cannot figure out what it is, it might be you.

“A bouquet of wilting adapters” by rexhammock is licensed under CC BY-SA 2.0.

One of the best problems to solve for your customers is the problem they don’t know they have.  If you can pull it off, you will create an entirely new value proposition for them and enable them to do things they cannot do today. But the problem is they can’t ask you to solve it because they don’t know they have it.

To identify problems customs can’t see, you’ve got to watch them go about their business.  You’ve got to watch all aspects of their work and understand what they do and why they do it that way.  And it’s their why that helps you find the transparent problems.  When they tell you their why, they tell you the things they think cannot change and the things they consider fundamental constraints.  Their whys tell you what they think is unchangeable.  And from their perspective, they’re right.  These things are unchangeable because they don’t know what’s possible with new technologies.

Once you know their unchangeable constraints, choose one to work on and turn it into a tight problem statement.  Then use your best tools and methods to solve it.  Once solved, you’ve got to make a functional prototype and show them in person.  Without going back to them with a demonstration of a functional prototype, they won’t believe you.  Remember, you did something they didn’t think was possible and changed the unchangeable.

When demonstrating the prototype to the customer, just show it in action.  Don’t describe it, just show them and let them ask questions.  Listen to their questions so you can see the prototype through their eyes.  And to avoid leading the witness, limit yourself to questions that help you understand why they see the prototype as they do.  The way they see the prototype will be different than your expectations, and that difference is called learning.  And if you find yourself disagreeing with them, you’re doing it wrong.

This first prototype won’t hit the mark exactly, but it will impress the customer and it will build trust with them.  And because they watched the prototype in action, they will be able to tell you how to improve it.  Or better yet, with their newfound understanding of what’s possible, they might be able to see a more meaningful transparent problem that, once solved, could revolutionize their industry.

Customers know their work and you know what’s possible.  And prototypes are a great way to create the future together.

“Transparent” by Rene Mensen is licensed under CC BY 2.0.

Clean-sheet designs are fun, right up until they don’t launch.

When you feel the urge to do a clean-sheet design, go home early.

When you don’t know how to make it better, make it worse and do the opposite.

Without trying, there is no way to know if it will work.

Trying sometimes feels like dying.

But without trying, nothing changes.

Agreement is important, but only after the critical decision has been made.

When there’s 100% agreement, you waited too long to make the decision.

When it’s unclear who the customer is, ask “Whose problem will be solved?”

When the value proposition is unclear, ask ‘What problem will be solved?”

When your technology becomes mature, no one wants to believe it.

When everyone believes the technology is mature, you should have started working on the new technology four years ago.

If your projects are slow, blame your decision-making processes.

Two of the most important decisions: which projects to start and which to stop.

All the action happens at the interfaces, but that’s also where two spans of control come together and chafe.

If you want to understand your silos and why they don’t play nicely together, look at the organizational chart.

When a company starts up, the product sets the organizational structure.

Then, once a company is mature, the organizational structure constrains the product.

At the early stages of a project, there’s a lot of uncertainty.

And once the project is complete, there’s a lot of uncertainty.

“Toys Never Forget” by Alyssa L. Miller is marked with CC BY 2.0.

Creating new ideas is easy.  Sit down, quiet your mind, and create a list of five new ideas.  There.  You’ve done it.  Five new ideas.  It didn’t take you a long time to create them.  But ideas are cheap.

Converting ideas into sellable products and selling them is difficult and expensive. A customer wants to buy the new product when the underlying idea that powers the new product solves an important problem for them.  In that way, ideas whose solutions don’t solve important problems aren’t good ideas.  And in order to convert a good idea into a winning product, dirt, rocks, and sticks (natural resources) must be converted into parts and those parts must be assembled into products.  That is expensive and time-consuming and requires a factory, tools, and people that know how to make things. And then the people that know how to sell things must apply their trade.  This, too, adds to the difficulty and expense of converting ideas into winning products.

The only thing more expensive than converting new ideas into winning products is reusing your tired, old ideas until your offerings run out of sizzle. While you extend and defend, your competitors convert new ideas into new value propositions that bring shame to your offering and your brand.  (To be clear, most extend-and-defend programs are actually defend-and-defend programs.)  And while you reuse/leverage your long-in-the-tooth ideas, start-ups create whole new technologies from scratch (new ideas on a grand scale) and pull the rug out from under you.  The trouble is that the ultra-high cost of extend-and-defend is invisible in the short term. In fact, when coupled with reuse, it’s highly profitable in the moment.  It takes years for the wheels to fall off the extend-and-defend bus, but make no mistake, the wheels fall off.

When you find the urge to create a laundry list of new ideas, don’t.  Instead, solve new problems for your customers.  And when you feel the immense pressure to extend and defend, don’t.  Instead, solve new problems for your customers.

And when all that gets old, repeat as needed.

“Cave paintings” by allspice1 is licensed under CC BY-ND 2.0

Anonymous: What do you think we should do next?

Me: It depends.  How did you get here?

Anonymous: Well, we’ve had great success improving on what we did last time.

Me: Well, then you’ll likely do that again.

Anonymous: Do you think we’ll be successful this time?

Me: It depends.  If the performance/goodness has been flat over your last offerings, then no.  When performance has been constant over the last several offerings it means your technology is mature and it’s time for a new one.  Has performance been flat over the years?

Anon: Yes, but we’ve been successful with our tried-and-true recipe and the idea of creating a new technology is risky.

Me: All things have a half-life, including successful business models and long-in-the-tooth technologies, and your success has blinded you to the fact that yours are on life support.  Developing a new technology isn’t risky. What’s risk is grasping tightly to a business model that’s out of gas.

Anon: That’s harsh.

Me: I prefer “truthful.”

Anon: So, we should start from scratch and create something altogether new?

Me: Heavens no. That would be a disaster. Figure out which elements are blocking new functionality and reinvent those. Hint: look for the system elements that haven’t changed in a dog’s age and that are shared by all your competitors.

Anon: So, I only have to reinvent several elements?

Me: Yes, but probably fewer than several.  Probably just one.

Anon: What if we don’t do that?

Me: Over the next five years, you’ll be successful.  And then in year six, the wheels will fall off.

Anon: Are you sure?

Me: No, they could fall off sooner.

Anon: How do you know it will go down like that?

Me: I’ve studied systems and technologies for more than three decades and I’ve made a lot of mistakes.  Have you heard of The Voice of Technology?

Anon: No.

Me: Well, take a bite of this – The Voice of Technology. Kevin Kelly has talked about this stuff at great length.  Have you read him?

Anon: No.

Me: Here’s a beauty from Kevin – What Technology Wants. How about S-curves?

Anon: Nope.

Me: Here’s a little primer – Beyond Dead Reckoning. How about Technology Forecasting?

Anon: Hmm.  I don’t think so.

Me: Here’s something from Victor Fey, my teacher. He worked with Altshuller, the creator of TRIZ – Guided Technology Evolution.  I’ve used this method to predict several industry-changing technologies.

Anon: Yikes! There’s a lot here. I’m overwhelmed.

Me: That’s good!  Overwhelmed is a sign you realize there’s a lot you don’t know.  You could be ready to become a student of the game.

Anon: But where do I start?

Me: I’d start Wardley Maps for situation analysis and LEANSTACK to figure out if customers will pay for your new offering.

Anon: With those two I’m good to go?

Me: Hell no!

Anon: What do you mean?

Me: There’s a whole body of work to learn about. Then you’ve got to build the organization, create the right mindset, select the right projects, train on the right tools, and run the projects.

Anon: That sounds like a lot of work.

Me: Well, you can always do what you did last time. END.

“he went that way matey” by jim.gifford is licensed under CC BY-SA 2.0