Shipulski On Design

Posts Tagged ‘Competitiveness’

If there is no problem, it is too soon for a solution.

But when there is consensus on a problem, it may be too late to solve it.

If a powerful protector of the Status Quo is to retire in a year, it may be too early to start work on the most important sacrilege.

But if the sacrilege can be done under cover, it may be time to start.

It may be too soon to put a young but talented person in a leadership position if the team is also green.

But it may be the right time to pair the younger person with a seasoned leader and move them both to the team.

When the business model is highly profitable, it may be too soon to demonstrate a more profitable business model that could obsolete the existing one.

But new business models take a long time to gestate and all business models have half-lives, so it may be time to demonstrate the new one.

If there is no budget for a project, it is too soon for the project.

But the budget may never come, so it is probably time to start the project on the smallest scale.

When the new technology becomes highly profitable, it may be too soon to demonstrate the new technology that makes it obsolete.

But like with business models, all technologies have half-lives, so it may be time to demonstrate the new technology.

The timing to do new work or make a change is never perfect.  But if the timing is wrong, wait.  But don’t wait too long.

If the timing isn’t right, adjust the approach to soften the conflict, e.g., pair a younger leader with a seasoned leader and move them both.

And if the timing is wrong but you think the new work cannot wait, start small.

And if the timing is horrifically wrong, start smaller.

Doing what you did last works well, right up until it doesn’t.

When you put 100% effort into doing what you did last time and get 80% of the output of last time, it’s time to do something different next time.

If it worked last time, but the environment or competition has changed, chances are it won’t work this time.

You can never step in the same river twice, and it’s the same with best practices.

Doing what you did last time is predictable until it isn’t.

The cost of trying the same thing too often is the opportunity cost of unlearned learning, which only comes from doing new things in new ways.

Our accounting systems don’t know how to capture the lost value due to unlearned learning, but your competition does.

Doing what you did last time may be efficient, but that doesn’t matter when it becomes ineffective.

Without new learning, you have a tired business model that will give you less year on year.

If you do what you did last time, you slowly learn what no longer works, but that’s all.

The best practice isn’t best when the context is different.

It’s not okay to do what you did last time all the time.

If you always do what you did last time, you don’t grow as a person.

If you do what you did last time, there are no upside surprises but there may be downside surprises.

Doing what you did last time is bad for your brain and your business.

How much of your work is repeating what you did last time? And how do you feel about that?

If you are tired of doing what you did last time, what are you going to do about it?

Might you sneak in some harmless novelty when no one is looking?

Might you conspire to try something new without raising the suspicion of the Standard Work Police?

Might you run a small experiment where the investment is small but the learning could be important?

Might you propose trying something new in a small way, highlighting the potential benefit and the safe-to-fail nature of the approach?

Might you propose small experiments run in parallel to increase the learning rate?

Might you identify an important problem that has never been solved and try to solve it?

Might you come up with a new solution that radically grows company profits?

Might you create a solution that obsoletes your company’s most profitable offering?

Might you bring your whole self to your work and see what happens?

Image credit – Marc Dalmulder

When you want to figure out what’s next, show customers what’s possible.  This is much different than asking them what they want.  So, don’t do that.  Instead, show them a physical prototype or a one-page sales tool that explains the value they would realize.

When they see what’s possible, the world changes for them.  They see their work from a new perspective. They see how the unchangeable can change.  They see some impossibilities as likely.  They see old constraints as new design space.  They see the implications of what’s possible from their unique context.  And they’re the only ones that can see it.  And that’s one of the main points of showing them what’s possible – for YOU to see the implications of what’s possible from their perspective.  And the second point is to hear from them what you should have shown them, how you missed the mark, and what you should show them next time.

When you show customers what’s possible, that’s not where things end.  It’s where things start.

When you show customers what’s possible, it’s an invitation for them to tell you what it means to them.  And it’s also an invitation for you to listen.  But listening can be challenging because your context is different than theirs.  And because they tell you what they think from their perspective, they cannot be wrong.  They might be the wrong customer, or you might have a wrong understanding of their response, but how they see it cannot be wrong.  And this can be difficult for the team to embrace.

What you do after learning from the customer is up to you.  But there’s one truism – what you do next will be different because of their feedback.  I am not saying you should do what they say or build what they ask for.  But I think you’ll be money ahead if your path forward is informed by what you learn from the customers.

Image credit —  Alexander Henning Drachmann

The projects you choose define the problems you solve.

The problems you choose to solve define the novel value delivered to the customer.

The people you choose to run the projects set the character of the projects.

The choice of the projects’ character defines how the people feel about working on the projects.

How people choose to feel about working on the projects influences the character of the projects.

The people on the projects choose how the problems are solved.

How people choose to solve problems defines how well the problems are solved.

The choice around how well problems are solved sets the level of goodness delivered to the customer.

The level of goodness you choose to deliver to the customer governs the incremental revenue you create.

It doesn’t seem right that the amount of incremental revenue is a choice.

But, when you choose the right projects and the right people to run them and you choose the right problems and the right people to solve them, incremental revenue becomes your choice.

image credit — officallychaz

Companies that are good at planning their projects create roadmaps spanning about three years, where individual projects are sequenced to create a coordinated set of projects that fit with each other.  The roadmap helps everyone know what’s important and helps the resources flow to those most important projects.

Through the planning process, the collection of potential projects is assessed and the best ones are elevated to the product roadmap.  And by best, I mean the projects that will generate the most incremental profit.  The projects on the roadmap generate the profits that underpin the company’s financial plan and the company is fanatically committed to the financial plan. The importance of these projects cannot be overstated.  And what that means is once a project makes it to the roadmap, there’s only one way to get it off the roadmap, and that’s to complete it successfully.

For the next three years, everyone knows what they’ll work on.  And they also know what they won’t work on.

The best companies want to be efficient so they staff their projects in a way that results in high utilization.  The most common way to do this is to load up the roadmap with too many projects and staff the projects with too few people.  The result is a significant fraction of people’s time (sometimes more than 100%) is pre-allocated to the projects on the roadmap.  The efficiency metrics look good and it may actually result in many successful launches.  But the downside of ultra-high utilization of resources is often forgotten.

When all your people are booked for the next three years on high-value projects, they cannot respond to new opportunities as they arise.  When someone comes back from a customer visit and says, “There’s an exciting new opportunity to grow the business significantly!” the best response is “We can’t do that because all our people are committed to the three-year plan.”.  The worst response is “Let’s put together a team to create a project plan and do the project.”.  With the first response, the project doesn’t get done and zero resources are wasted trying to figure out how to do the project without the needed resources.  With the second response, the project doesn’t get done but only after significant resources are wasted trying to figure out how to do the project without the needed resources.

Starting new projects is difficult because everyone is over-booked and over-committed on projects that the company thinks will generate significant (and predictable) profits.  What this means is to start a new project in this high-utilization environment, the new project must displace a project on the three-year plan.  And remember, the projects that must be displaced are the projects the company has chosen to generate the company’s future profits.  So, to become an active project (and make it to the three-year plan) the candidate project must be shown to create more profits, use fewer resources and launch sooner than the projects already on the three-year plan.  And this is taller than a tall order.

So, is there a solution?  Not really, because the only possible solution is to reduce resource utilization to create unallocated resources that can respond to emergent opportunities when they arise.  And that’s not possible because good companies have a deep and unskillful attachment efficiency.

Image credit — Bernard Spragg NZ

X: Of the pool of candidate new product development projects, which project should we do first?

Me: Let’s do the one that makes us the most money.

X: Which project will make the most money?

Me: The one where the most customers buy the new product, pay a reasonable price, and feel good doing it.

X: And which one is that?

Me: The one that solves the most significant problem.

X: Oh, I know our company’s most significant problem.  Let’s solve that one.

Me: No. Customers don’t care about our problems, they only care about their problems.

X: So, you’re saying we should solve the customers’ problem?

Me: Yes.

X: Are you sure?

Me: Yes.

X: We haven’t done that in the past. Why should we do it now?

Me: Have your previous projects generated revenue that met your expectations?

X: No, they’ve delivered less than we hoped.

Me: Well, that’s because there’s no place for hope in this game.

X: What do you mean?

Me: You can’t hope they’ll buy it.  You need to know the customers’ problems and solve them.

X: Are you always like this?

Me: Only when it comes to customers and their problems.

image credit: Kyle Pearce

What does work look like when you prioritize your happiness?

When it’s announced that open positions will not be backfilled to meet the practical realities of a recession, you reduce the scope of your projects and push out their completion dates to match the reduction in resources. And the impact on your career?  I don’t know, but the people that work for you and everyone else that knows how the work is done will move mountains for you.

Under the banner of standard work, you are given the same task as the one you just completed.  Sure, you can do it efficiently and effectively, but if you do that same work one more time, your brain will fall off.  So, instead of doing it yourself, you give the work to a lesser-experienced person who is worthy of investment and help them get the work done.  They get to learn new skills and the work is done well because you keep them on the straight and narrow. And you get to be a teacher and create a future leader that the company will need in a couple of years.  And the downside?  The work takes a little longer, but so what.

What does work look like when you prioritize your health?

When an extra-early meeting is scheduled because everyone’s regular day is already fully booked with meetings, you decline the meeting so you can get the recommended amount of sleep recommended by the health professionals.  And the negative consequences to your career progression?  Well, that’s a choice for your company.

When you get home from work, you disconnect your phone from the company network so you won’t be distracted by work-related interruptions.  Because you separated yourself from work, after dinner is cleaned up you can make a healthy lunch for tomorrow.  If there’s some downside risk to your career, find another company to work for.

What does work look like when you prioritize your family?

When an extra-late meeting is scheduled because everyone’s regular day is already fully booked with meetings, you decline the meeting so you can cook dinner and eat with your family.  The conversation with the kids is mundane and meaningful and ten years from now they’ll be better for it. And the negative consequences?  None, because tomorrow morning you can read the minutes of the meeting.

When you’re on your yearly holiday with your family and your boss calls your cell phone to ask you to come back to work early to deal with an emergency, you don’t answer the call and let it go to voicemail.  Then, when you get back to the office after vacation, you listen to the voicemail and check in with your boss.  And because you didn’t pick up the call, someone else had greatness thrust upon them and developed into someone who can solve emergencies.  Now there are two of you.  And the downside?  Well, I think that depends on your boss.

“Looking For Clues (188 / 365)” by somegeekintn is licensed under CC BY 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.

Before you decide which project to start, decide which project you’ll stop.

The best way to stop a project is to finish it.  The next best way is to move the resources to a more important project.

If you find yourself starting before finishing, stop starting and start finishing.

People’s output is finite. Adding a project that violates their human capacity will not result in more completed projects but will cause your best people to leave.

If people’s calendars are full, the only way to start something new is to stop something old.

If you start more projects than you finish, you’re stopping projects before they’re finished.  You’re probably not stopping them in an official way, rather, you’re letting them wither and die a slow death.  But you’re definitely stopping them.

When you start more projects than you finish, the number of active projects increases.  And without a corresponding increase in resources, fewer projects are completed.

The best way to reduce the number of projects you finish is to start new projects.

Make a list of the projects that you stopped over the last year.  Is it a short list?

Make a list of projects that are understaffed and under-resourced yet still running in the background.  Is that list longer?

A rule to live by: If a project is understaffed, staff it or stop it.

If you can’t do that, reduce the scope to fit the resources or stop it.

Would you prefer to complete one project at a time or do three simultaneously and complete none?

When it comes to stopping projects, it’s stopped or it isn’t.  There’s no partial credit for talking about stopping a project.

If you want to learn if a project is worthy of more resources, stop the project.  If the needed resources flow to the project, the project is worthy.  If not, at least you stopped a project that shouldn’t have been started.

People don’t like working on projects where the work content is greater than the resources to do the work.  These projects are a major source of burnout.

If you know you have too many projects, everyone else knows it too.  Stop the weakest projects or your credibility will suffer.

“Circus Renz Berlin, Holland 2011” by dirkjanranzijn is licensed under CC BY-ND 2.0.

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.

When choosing projects there are two competing questions: Is it big enough? And, is it small enough? The project must be big enough to generate the profits required by the company’s growth objectives.  Larger growth objectives require larger projects.  Yet the project has to be small enough to be completed within the time constraints defined by the growth objectives.  Tighter time constraints require smaller projects.

When the projected revenue generated by the candidate project is less than what’s needed to meet the growth objectives, the project is deemed “not big enough.”  But what if the candidate project is the largest project that the project team can imagine? Does that say something about the project team’s imagination or the growth objectives?  Open question: How do tell the difference between a project that is too small to meet the growth objectives and growth objectives that demand projects larger than the project team’s imagination?

When the projected launch date of the candidate project is later than the date of first revenue defined in the growth plan, the project plan is deemed “too long.”  The team is then asked to sharpen their pencils and return with a launch date that meets the revenue timeline.  And when the revised schedule also violates the revenue timeline, the project is deemed “too big.” Open question: How do you tell the difference between a project that is too big to meet the revenue timeline and a revenue timeline that is too stringent to allow a project of sufficient size?

Theoretically, there are candidate projects that are big enough to meet the growth objectives and small enough that their launch dates meet revenue timelines.  But in practice, candidate projects are either too small to meet growth objectives or too large to meet revenue timelines.  And, yes, I have seen candidate projects that are both too small and too large.  But this says more about the growth objectives, revenue timelines, and the number of projects that run concurrently (too few resources spread over too many projects).

Growth objectives are good, and so are projects that fit with the team’s capabilities to deliver.  Incremental revenue that comes sooner rather than later is good.  And so are project timelines that are governed by the work content, resources applied to the projects, and good product development practices.

Truth is, we need it all – projects that deliver the sizzle that sells and projects that launch sooner rather than later.  And year-on-year, we need to get better at delivering on all of it.  And the best way I know to do all that is to ritualistically invest in the people that do the work and the tools they use.

“Horse Yin and Yang” by onecog2many is licensed under CC BY 2.0.