Shipulski On Design

Archive for the ‘Technology’ Category

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

When you see good work, say so.

When you see exceptional work, say so in public.

When you’ve had good teachers, be thankful.

When you’ve had exceptional teachers, send them a text because texts are personal.

When you do great work and no one acknowledges it, take some time to feel the pain and get back to work.

When you do great work and no one acknowledges it, take more time to feel the pain and get back to work.

When you’ve done great work, tell your family.

When you’ve done exceptional work, tell them twice.

When you do the work no one is asking for, remember your time horizon is longer than theirs.

When you do the work that threatens the successful business model, despite the anguish it creates, keep going.

When they’re not telling you to stop, try harder.

When they’re telling you to stop it’s because your work threatens.  Stomp on the accelerator.

When you can’t do a project because the ROI is insufficient, that’s fine.

When no one can calculate an ROI because no one can imagine a return, that’s better.

When you give a little ground on what worked, you can improve other dimensions of goodness.

When you outlaw what worked, you can create new market segments.

When everyone understands why you’re doing it, your work may lead to something good.

When no one understands why you’re doing it, your work may reinvent the industry.

When you do new work, don’t listen to the critics. Do it despite them.

When you do work that threatens, you will be misunderstood.  That’s a sign you’re on to something.

When you want credit for the work, you can’t do amazing work.

When you don’t need credit for the work, it opens up design space where the amazing work lives.

When your work makes waves, that’s nice.

When your work creates a tsunami, that’s better.

When you’re willing to forget what got you here, you can create what could be.

When you’re willing to disrespect what got you here, you can create what couldn’t be.

When your work is ignored, at least you’re doing something different.

When you and your work are derided, you’re doing it right.

Image credit — Herry Lawford

If you have more features, I will beat you with fewer.

If you have a broad product line, I will beat you with my singular product.

If your solution is big, mine will beat you with small.

If you sell across the globe, I will sell only in the most important market and beat you.

If you sell to many customers, I will provide a better service to your best customer and beat you.

If your new projects must generate $10 million per year, I will beat you with $1 million projects.

If you are slow, I will beat you with fast.

If you use short term thinking, I will beat you with long term thinking.

If you think in the long term, I will think in the short term and beat you.

If you sell a standardized product, I will beat you with customization.

If you are successful, I will beat you with my hunger.

If you try to do less, I will beat you with far less.

If you do what you did last time, I will beat you with novelty.

If you want to be big, I will be a small company and beat you.

I will beat you with what you don’t have.

Then, I will obsolete my best work with what I don’t have.

Your success creates inertia. Your competitors know what you’re good at and know you’ll do everything you can to maintain your trajectory.  No changes, just more of what worked.  And they will use your inertia. They will start small and sell to the lowest end of the market. Then they’ll grow that segment and go up-scale. You will think they are silly and dismiss them. And then they will take your best customers and beat you.

If you want to know how your competitors will beat you, think of your strength as a weakness.  Here’s a thought experiment to explain.  If your success is based on fast, turn speed into weakness and constrain out the speed. Declare that your new product must be slow. Then, create a growth plan based on slow.  That growth plan is how your competitors will beat you.

Your growth won’t come from what you have, it will come from what you don’t have.

It’s time to create your anti-product.