Shipulski On Design

Archive for the ‘Top Line Growth’ Category

If you want your new product development projects to go faster, reduce the number of active projects.  Full stop.

A rule to live by: If the new product development project is 90% complete, the company gets 0% of the value.  When it comes to new product development projects, there’s no partial credit.

Improving the capabilities of your project managers can help you go faster, but not if you have too many active projects.

If you want to improve the speed of decision-making around the projects, reduce the number of required decisions by reducing the number of active projects.

Resource conflicts increase radically as the number of active projects increases.  To fix this, you guessed it, reduce the number of active projects.

A project that is run under the radar is the worst type of active project. It sucks resources from the official projects and prevents truth telling because no one can admit the dark project exists.

With fewer active projects, resource intensity increases, the work is done faster, and the projects launch sooner.

Shared resources serve the projects better and faster when there are fewer active projects.

If you want to go faster, there’s no question about what you should do.  You should stop the lesser projects to accelerate the most important ones.  Full stop.

And if you want to stop some projects, I suggest you try to answer this question: Why does your company think it’s a good idea to have far too many active new product development projects?

Image credit — JOHN K THORNE

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!

X: We need to decrease the time to market for our new products.

Me: So, you want to decrease the time it takes to go from an idea to a commercialized product?

X: Yes.

Me: Okay.  That’s pretty easy.  Here’s my idea.  Put some new stickers on the old product and relaunch it.  If we change the stickers every month, we can relaunch the product every month.  That will reduce the time to market to one month.  The metrics will go through the roof and you’ll get promoted.

X: That won’t work.  The customers will see right through that and we won’t sell more products and we won’t make more money.

Me: You never said anything about making more money.  You said you wanted to reduce the time to market.

X: We want to make more money by reducing time to market.

Me: Hmm.  So, you think reducing time to market is the best way to make more money?

X: Yes. Everyone knows that.

Me: Everyone?  That’s a lot of people.

X: Are you going to help us make more money by reducing time to market?

Me: I won’t help you with both.  If you had to choose between making more money and reducing time to market, which would you choose?

X: Making money, of course.

Me: Well, then why did you start this whole thing by asking me for help improving time to market?

X: I thought it was the best way to make more money.

Me: Can we agree that if we focus on making more money, we have a good chance of making more money?

X: Yes.

Me:  Okay.  Good.  Do you agree we make more money when more customers buy more products from us?

X: Everyone knows that.

Me:  Maybe not everyone, but let’s not split hairs because we’re on a roll here.  Do you agree we make more money when customers pay more for our products?

X: Of course.

Me: There you have it.  All we have to do is get more customers to buy more products and pay a higher price.

X: And you think that will work better than reducing time to market?

Me: Yes.

X: And you know how to do it?

Me: Sure do.  We create new products that solve our customers’ most important problems.

X: That’s totally different than reducing time to market.

Me: Thankfully, yes.  And far more profitable.

X: Will that also reduce the time to market?

Me: I thought you said you’d choose to make more money over reducing time to market. Why do you ask?

X: Well, my bonus is contingent on reducing time to market.

Me: Listen, if the previous new product development projects took two years, and you reduce the time to market to one and half years, there’s no way for you to decrease time to market by the end of the year to meet your year-end metrics and get your bonus.

X: So, the metrics for my bonus are wrong?

Me: Right.

X: What should I do?

Me: Let’s work together to launch products that solve important customer problems.

X:  And what about my bonus?

Me: Let’s not worry about the bonus.  Let’s worry about solving important customer problems, and the bonuses will take care of themselves.

Image credit — Quinn Dombrowski

X: Me: format stolen from @swardley.  Thank you, Simon.

Choose the right project. When you say yes to a new project, all the focus is on the incremental revenue the project will generate and none of the focus is on unrealized incremental revenue from the projects you said no to. Next time there’s a proposal to start a new project, ask the team to describe the two or three most compelling projects that they are asking the company to say no to.  Grounding the go/no-go decision within the context of the most compelling projects will help you avoid the real backbreaker where you consume all your product development resources on something that scratches the wrong itch while you prevent those resources from creating something magical.

Choose what to improve. Give your customers more of what you gave them last time unless what you gave them last time is good enough. Once goodness is good enough, giving customers more is bad business because your costs increase but their willingness to pay does not.  Once your offering meets the customers’ needs in one area, lock it down and improve a different area.

Choose how to staff the projects.  There is a strong temptation to run many projects in parallel.  It’s almost like our objective is to maximize the number of active projects at the expense of completing them.  Here’s the thing about projects – there is no partial credit for partially completed projects.  Eight active projects that are eight (or eighty) percent complete generate zero revenue and have zero commercial value.  For your most important project, staff it fully.  Add resources until adding more resources would slow the project.  Then, for your next most important project, repeat the process with your remaining resources.  And once a project is completed, add those resources to the pool and start another project.  This approach is especially powerful because it prioritizes finishing projects over starting them.

“Three Cows” by Sunfox is licensed under CC BY-SA 2.0.

Breaking up work into small chunks can be a good way to get things started.  Because the scope of each chunk is small, the cost of each chunk is small making it easier to get approval to do the work.  The chunk approach also reduces anxiety around the work because if nothing comes from the chunk, it’s not a big deal because the cost of the work is so low.  It’s a good way to get started, and it’s a good way to do a series of small chunks that build on each other.  But what happens when the chunks are successful and it’s time to scale up the investment by a factor of several hundred thousand or a million?

The scaling scenario.  When the early work (the chunks) was defined an agreement in principle was created that said the larger investment would be made in a timely way if the small chunks demonstrated the viability of a whole new offering for your customers.  The result of this scenario is a large investment is allocated quickly, resources flow quickly, and the scaling work begins soon after the last chunk is finished. This is the least likely scenario.

The more chunks scenario. When the chunks were defined, everyone was excited that the novel work had actually started and there was no real thought about the resources required to scale it into something meaningful and material.  Since the resources needed to scale were not budgeted, the only option to keep things going is to break up the work into another series of small chunks.  Though the organization sees this as progress, it’s not.  The only thing that can deliver the payout the organization needs is to scale up the work.  The follow-on chunks distract the company and let it think there is progress, when, really, there is only delayed scaling.

The scale next year scenario.  When the chunks were defined, no one thought about scaling so there was no money in the budget to scale.  A plan and cost estimate are created for the scaling work and the package waits to be assessed as part of the annual planning process.  And as the waiting happens, the people that did the early work (the chunks) move on to other projects and are not available to do the scaling work even if the work gets funded next year.  And because the work is new it requires new infrastructure, new resources, new teams, new thinking, and maybe a new company.  All this newness makes the price tag significant and it may require more than one annual planning cycle to justify the expense and start the work.

Scaling a new invention into a full-sized business is difficult and expensive, but if you’re looking to create radical growth, scaling is the easiest and least expensive way to go.

“100 Dollar Bills” by Philip Taylor PT is licensed under CC BY-SA 2.0.

If there’s a recurring problem, take the time to make sure the system hasn’t changed since last time and make sure the context and environment are still the same.  If everything is the same, and there are no people involved in the system, it’s a problem that resides in the clear domain.  Here’s a link from Dave Snowden who talks about the various domains.  In this video, Dave calls this domain the “simple” domain.  Solve it like you did last time.

If there’s a new problem, take the time to understand the elements of the system that surround the problem.  Define the elements and define how they interact, and define how they set the context and constraints for the problem.  And then, define the problem itself.  Define when it happens, what happens just before, and what happens after.  If there are no people involved, if the solution is not immediately evident, if it’s a purely mechanical, electromechanical, chemical, thermal, software, or hardware, it’s a problem in the complicated domain (see Dave’s video above) and you’ll be able to solve it with the right experts and enough time.

If you want to know the next evolution of the system, how it will develop and evolve, the situation is more speculative and there’s no singular answer. Still, the first step is the same – take the time to understand the elements of the system and how they interact.  Then, look back in time and learn the previous embodiments of the system and define its trajectory – how it evolved into its current state.  If there has been consistent improvement along a singular line of goodness, it’s likely the system will want to continue to evolve in that direction.  If the improvement has flattened, it’s likely the system will try to evolve along a different line of evolution.

I won’t go into the specifics of lines of evolution of technological systems, as it’s a big topic.  But if you want to know more, here’s a nice description of evolution along the line of adaptability by my teacher, Victor Fey – The best products know how to adapt.

If there are people involved with the system, it’s a complex system (see Dave’s video).  (There are complex systems that don’t involve people, but I find this a good way to talk about complex systems.) The first step is to define the system as it is, but because the interactions among the elements are not predictable, your only hope is to probe, sense, and respond by doing more of what works and less of what doesn’t.  Thanks to Dave Snowden for that language.

The first step is always to understand the system as it is.

“Space – Antennae Galaxies” by Trodel is licensed under CC BY-SA 2.0.

When you don’t know what to do, what do you do?  This is a difficult question.

Here are some thoughts that may help you figure out what to do when you really don’t know.

Don’t confuse activity with progress.

Gather your two best friends, go off-site, and define the system as it is.

Don’t ask everyone what they think because the Collective’s thoughts will be diffuse, bland, and tired.

Get outside.

Draw a picture of how things work today.

Get a good meal.

Make a graph of goodness over time.  If it’s still increasing, do more of what you did last time.  If it’s flat, do something else.

Get some exercise.

Don’t judge yourself negatively.  This is difficult work.

Get some sleep.

Help someone with their problem.  The distraction will keep you out of the way as your mind works on it for you.

Spend time with friends.

Try a new idea at the smallest scale. It will likely lead to a better one. Repeat.

Use your best judgment.

Image credit – Andrew Gustar

When you design something, you create a solution to a collection of problems.  But it goes far beyond creating the solution.  You also must create objective evidence that demonstrates that the solution does, in fact, solve the problems.  And the reason to generate this evidence is to help the organization believe that the solution solves the problem, which is an additional requirement that comes with designing something.  Without this belief, the organization won’t go out to the customer base and convince them that the solution will solve their problems.  If the sales team doesn’t believe, the customers won’t believe.

In school, we are taught to create the solution, and that’s it.  Here are the drawings, here are the materials to make it, here is the process documentation to build it, and my work here is done. But that’s not enough.

Before designing the solution, you’ve got to design the tests that create objective evidence that the solution actually works, that it provides the right goodness and it solves the right problems.  This is an easy thing to say, but for a number of reasons, it’s difficult to do.  To start, before you can design the right tests, you’ve got to decide on the right problems and the right goodness.  And if there’s disagreement and the wrong tests are defined, the design community will work in the wrong areas to generate the wrong value.  Yes, there will be objective evidence, and, yes, the evidence will create a belief within the organization that problems are solved and goodness is achieved.  But when the sales team takes it to the customer, the value proposition won’t resonate and it won’t sell.

Some questions to ask about testing. When you create improvements to an existing product, what is the family of tests you use to characterize the incremental goodness?  And a tougher question: When you develop a new offering that provides new lines of goodness and solves new problems, how do you define the right tests? And a tougher question: When there’s disagreement about which tests are the most important, how do you converge on the right tests?

Image credit — rjacklin1975

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

I like to help people turn complex situations into several important learning objectives.

I like to help people turn important learning objectives into tight project plans.

I like to help people distill project plans into a single-page spreadsheet of who does what and when.

I like to help people start with problem definition.

I like to help people stick with problem definition until the problems solve themselves.

I like to help people structure tight project plans based on resource constraints.

I like to help people create objective measures of success to monitor the projects as they go.

I like to help people believe they can do the almost impossible.

I like to help people stand three inches taller after they pull off the unimaginable.

I like to help people stop good projects so they can start amazing ones.

If you want to do more of what you like and less of what you don’t, stop a bad project to start a good one.

So, what do you like to do?

Image credit — merec0

Next year will be different, but we don’t know how it will be different. All we know is that it will be different.

Some things will be the same and some will be different.  The trouble is that we won’t know which is which until we do.  We can speculate on how it will be different, but the Universe doesn’t care about our speculation.  Sure, it can be helpful to think about how things may go, but as long as we hold on to the may-ness of our speculations.  And we don’t know when we’ll know. We’ll know when we know, but no sooner. Even when the Operating Plan declares the hardest of hard dates, the Universe sets the learning schedule on its own terms, and it doesn’t care about our arbitrary timelines.

What to do?

Step 1. Try three new things. Choose things that are interesting and try them.  Try to try them in parallel as they may interact and inform each other. Before you start, define what success looks like and what you’ll do if they’re successful and if they’re not.  Defining the follow-on actions will help you keep the scope small.  For things that work out, you’ll struggle to allocate resources for the next stages, so start small.  And if things don’t work out, you’ll want to say that the projects consumed little resources and learned a lot.  Keep things small.  And if that doesn’t work, keep them smaller.

Step 2. Rinse and repeat.

I wish you a happy and safe New Year.  And thanks for reading.

Mike

“three” by Travelways.com is licensed under CC BY 2.0