Shipulski On Design

Archive for the ‘Constraints’ Category

A prototype moves us from “That’s not possible.” to “Hey, watch this!”

A prototype moves us from “We don’t do it that way.” to “Well, we do now.”

A prototype moves us from “That’s impossible.” to “As it turns out, it was only almost impossible.”

A prototype turns naysayers into enemies and profits.

A prototype moves us from an argument to a new product development project.

A prototype turns analysis-paralysis into progress.

A prototype turns a skeptical VP into a vicious advocate.

A prototype turns a pet project into top-line growth.

A prototype turns disbelievers into originators of the idea.

A prototype can turn a Digital Strategy into customer value.

A prototype can turn an uncomfortable Board of Directors meeting into a pizza party.

A prototype can save a CEO’s ass.

A prototype can be too early, but mostly they’re too late.

If the wheels fall off your first prototype, you’re doing it right.

If your prototype doesn’t dismantle the Status-Quo, you built the wrong prototype.

A good prototype violates your business model.

A prototype doesn’t care if you see it for what it is because it knows everyone else will.

A prototype turns “I don’t believe you.” into “You don’t have to.”

When you’re told “Don’t make that prototype.” you’re onto something.

A prototype eats not-invented-here for breakfast.

A prototype can overpower the staunchest critic, even the VP flavor.

A prototype moves us from “You don’t know what you’re talking about.” to “Oh, yes I do.”

If the wheels fall off your second prototype, keep going.

A prototype is objective evidence you’re trying to make a difference.

You can argue with a prototype, but you’ll lose.

If there’s a mismatch between the theory and the prototype, believe the prototype.

A prototype doesn’t have to do everything, but it must do one important thing for the first time.

A prototype must be real, but it doesn’t have to be really real.

If your prototype obsoletes your best product, congratulations.

A prototype turns political posturing into reluctant compliance and profits.

A prototype turns “What the hell are you talking about?” into “This.”

A good prototype bestows privilege on the prototyper.

A prototype can beat a CEO in an arm-wrestling match.

A prototype doesn’t care if you like it. It only cares about creating customer value.

If there’s an argument between a well-stated theory and a well-functioning prototype, it’s pretty clear which camp will refine their theory to line up with what they just saw with their own eyes.

A prototype knows it has every right to tell the critics to “Kiss my ass.” but it knows it doesn’t have to.

You can argue with a prototype, but shouldn’t.

A prototype changes thinking without asking for consent.

Image credit — Pedro Ribeiro Simões

When the fate of your company rests on a single project, who are the three people you’d tap to drag that pivotal project over the finish line? And to sharpen it further, ask yourself “Who do I want to lead the project that will save the company?” You now have a list of the three most important people in your company.  Or, if you answered the second question, you now have the name of the most important person in your company.

The most important person in your company is the person that drags the most important projects over the finish line.  Full stop.

When the project is on the line, the CEO doesn’t matter; the General Manager doesn’t matter; the Business Leader doesn’t matter.  The person that matters most is the Project Manager.  And the second and third most important people are the two people that the Project Manager relies on.

Don’t believe that? Well, take a bite of this. If the project fails, the product doesn’t sell. And if the product doesn’t sell, the revenue doesn’t come. And if the revenue doesn’t come, it’s game over. Regardless of how hard the CEO pulls, the product doesn’t launch, the revenue doesn’t come, and the company dies.  Regardless of how angry the GM gets, without a product launch, there’s no revenue, and it’s lights out.  And regardless of the Business Leader’s cajoling, the project doesn’t cross the finish line unless the Project Manager makes it happen.

The CEO can’t launch the product. The GM can’t launch the product. The Business Leader can’t launch the product.  Stop for a minute and let that sink in.  Now, go back to those three sentences and read them out loud. No, really, read them out loud.  I’ll wait.

When the wheels fall off a project, the CEO can’t put them back on. Only a special Project Manager can do that.

There are tools for project management, there are degrees in project management, and there are certifications for project management.  But all that is meaningless because project management is alchemy.

Degrees don’t matter. What matters is that you’ve taken over a poorly run project, turned it on its head, and dragged it across the line. What matters is you’ve run a project that was poorly defined, poorly staffed, and poorly funded and brought it home kicking and screaming. What matters is you’ve landed a project successfully when two of three engines were on fire. (Belly landings count.) What matters is that you vehemently dismiss the continuous improvement community on the grounds there can be no best practice for a project that creates something that’s new to the world. What matters is that you can feel the critical path in your chest. What matters is that you’ve sprinted toward the scariest projects and people followed you. And what matters most is they’ll follow you again.

Project Managers have won the hearts and minds of the project team.

The Project manager knows what the team needs and provides it before the team needs it. And when an unplanned need arises, like it always does, the project manager begs, borrows, and steals to secure what the team needs.  And when they can’t get what’s needed, they apologize to the team, re-plan the project, reset the completion date, and deliver the bad news to those that don’t want to hear it.

If the General Manager says the project will be done in three months and the Project Manager thinks otherwise, put your money on the Project Manager.

Project Managers aren’t at the top of the org chart, but we punch above our weight. We’ve earned the trust and respect of most everyone. We aren’t liked by everyone, but we’re trusted by all. And we’re not always understood, but everyone knows our intentions are good. And when we ask for help, people drop what they’re doing and pitch in. In fact, they line up to help. They line up because we’ve gone out of our way to help them over the last decade. And they line up to help because we’ve put it on the table.

Whether it’s IoT, Digital Strategy, Industry 4.0, top-line growth, recurring revenue, new business models, or happier customers, it’s all about the projects. None of this is possible without projects. And the keystone of successful projects?  You guessed it.  Project Managers.

Image credit – Bernard Spragg .NZ

When there’s a big problem, the first step is to define what’s causing it. To do that, based on an understanding of the physics, a sequence of events is proposed and then tested to see if it replicates the problem. In that way, the team must understand the system as it is before the problem can be solved.

Seeing things as they are. The same logic applies when it’s time to improve an existing product or service. The first thing to do is to see the system as it is. But seeing things as they are is difficult. We have a tendency to see things as we want them or to see them in ways that make us look good (or smart). Or, we see them in a way that justifies the improvements we already know we want to make.

To battle our biases and see things as they are, we use tools such as block diagrams to define the system as it is. The most important element of the block diagram is clarity.  The first revision will be incorrect, but it must be clear and explicit. It must describe things in a way that creates a singular understanding of the system. The best block diagrams can be interpreted only one way.  More strongly, if there’s ambiguity or lack of clarity, the thing has not yet risen to the level of a block diagram.

The block diagram evolves as the team converges on a single understanding of things as they are. And with a diagram of things as they are, a solution is readily defined and validated. If when tested the proposed solution makes the problem go away, it’s inferred that the team sees things as they are and the solution takes advantage of that understanding to make the problem go away.

Seeing things as they may be. Even whey the solution fixes the problem, the team really doesn’t know if they see things as they are. Really, all they know is they see things as they may be. Sure, the solution makes the problem go away, but it’s impossible to really know if the solution captures the physics of failure.  When the system is large and has a lot of moving parts, the team cannot see things as they are, rather, they can only see the system as it may be. This is especially true if the system involves people, as people behave differently based on how they feel and what happened to them yesterday.

There’s inherent uncertainty when working with larger systems and systems that involve people.  It’s not insurmountable, but you’ve got to acknowledge that your understanding of the system is less than perfect. If your company is used to solving small problems within small systems, there will be little tolerance for the inherent uncertainty and associated unpredictability (in time) of a solution.  To help your company make the transition, replace the language of “seeing things as they are” with “seeing things as they may be.”  The same diagnostic process applies, but since the understanding of the system is incomplete or wrong, the proposed solutions cannot not be pre-judged as “this will work” and “that won’t work.”  You’ve got to be open to all potential solutions that don’t contradict the system as it may be. And you’ve got to be tolerant of the inherent unpredictability of the effort as a whole.

Seeing things as they could be. To create something that doesn’t yet exist, something does things like never before, something altogether new, you’ve got to stand on top of your understanding of the system and jump off.  Whether you see things as they are or as they may be, the new system will be different. It’s not about diagnosing the existing system; it’s about imagining the system as it could be. And there’s a paradox here. The better you understand the existing system, the more difficulty you’ll have imagining the new one. And, the more success the company has had with the system as it is, the more resistance you’ll feel when you try to make the system something it could be.

Seeing things as they could be takes courage – courage to obsolete your best work and courage to divest from success. The first one must be overcome first. Your body creates stress around the notion of making yourself look bad. If you can create something altogether better, why didn’t you do it last time? There’s a hit to the ego around making your best work look like it’s not all that good. But once you get over all that, you’ve earned the right to go to battle with your organization who is afraid to move away from the recipe responsible for all the profits generated over the last decade.

But don’t look at those fears as bad. Rather, look at them as indicators you’re working on something that could make a real difference.  Your ego recognizes you’re working on something better and it sends fear into your veins. The organization recognizes you’re working on something that threatens the status quo and it does what it can to make you stop. You’re onto something. Keep going.

Seeing things as they can’t be. This is rarified air. In this domain you must violate first principles. In this domain you’ve got to run experiments that everyone thinks are unreasonable, if not ill-informed. You must do the opposite. If your product is fast, your prototype must be the slowest. If the existing one is the heaviest, you must make the lightest. If your reputation is based on the highest functioning products, the new offering must do far less.  If your offering requires trained operators, the new one must prevent operator involvement.

If your most seasoned Principal Engineer thinks it’s a good idea, you’re doing it wrong. You’ve got to propose an idea that makes the most experienced people throw something at you. You’ve got to suggest something so crazy they start foaming at the mouth. Your concepts must rip out their fillings. Where “seeing things as they could be” creates some organizational stress, “seeing things as they can’t be” creates earthquakes. If you’re not prepared to be fired, this is not the domain for you.

All four of these domains are valuable and have merit. And we need them all. If there’s one message it’s be clear which domain you’re working in. And if there’s a second message it’s explain to company leadership which domain you’re working in and set expectations on the level of uncertainty and unpredictability of that domain.

Image credit – David Blackwell.

There’s a useful trick when you want to do new work. It has some of the characteristics of procrastination, but it’s different. With procrastination, the problem solver waits to start the solving until it’s almost impossible to meet the deadline. The the solver uses the unreasonable deadline to create internal pressure so they can let go of all the traditional solving approaches.  With no time for traditional approaches, the solver must let go of what worked and try a new approach.

The heart of the IBE is the Design Challenge, where a team with diverse perspective is brought together by a facilitator to solve a problem in five minutes. The unreasonable time constraint generates all the goodness that comes with procrastination, but, because it’s a problem solving exercise, there’s no drama.  And like with procrastination, the teams deliver unimaginable results within an unrealistic time constraint.

If you want things to change, you have two options. You can incentivize change or you can move things out of the way that block change. The first way doesn’t work and the second one does.  For more details, click this link at it will take you to a post that describes Danny Kahneman’s thoughts on the subject.

And, also from Kahneman, to move things out of the way and unblock change, change the environment.

Change-blocker 1. Metrics. When you measure someone on efficiency, you get efficiency. And if people think a potential change could reduce efficiency, that change is blocked.  And the same goes for all metrics associated with cost, quality and speed. When a change threatens the metric, the change will be blocked. To change the environment to eliminate the blocking, help people understand who the change will actually IMPROVE the metric. Do the analysis and educate those who would be negatively impacted if the change reduced the metric. Change their environment to one that believes the change will improve the metric.

Change-blocker 2. Incentives. When someone’s bonus could be negatively impacted by a potential change, that change will be blocked. Figure out whose incentive compensation are jeopardized by the potential change and help them understand how the potential change will actually increase their incentives.  You may have to explain that their incentives will increase in the long term, but that’s an argument that holds water. Until they believe their incentives will not suffer, they’ll block the change.

Change-blocker 3. Fear. This is the big one – fear of negative consequences. Here’s a short list: fear of being judged, fear of being blamed, fear of losing status, fear of losing control, fear of losing a job, fear of losing a promotion, fear of looking stupid and fear of failing. One of the best ways to help people get over their fear is to run a small experiment that demonstrates that they have nothing to fear. Show them that the change will actually work. Show them how they’ll benefit.

Eliminating the things that block change is fundamentally different than pushing people in the direction of change. It’s different in effectiveness and approach. Start with the questions: “What’s in the way of change?” or “Who is in the way of change?” and then “Why are they in the way of change?” From there, you’ll have an idea what must be moved out of the way. And then ask: “How can their environment be changed so the change-blocker can be moved out of the way?”

What’s in the way of giving it a try?

Image credit B4bees

I’m all for stretch goals to help people grow.  “Hey, you did this last year but I think you can do ten percent more this year. And here’s why – [list three reasons here.]” This works. This helps people grow. This is effective. This is grounded in what happened last year. This is grounded in specific reasons why you think the stretch goal is possible. And when you do it this way, you are seen as credible.

Back in the day, when elite runners were running the mile in 4:04 their coaches said “Hey, you ran 4:04 last year but I think you can do it a little faster this year. I think you can run it in 3:59. And here’s why – your time has been decreasing steadily over the last three years, you have been working out with weights and you’re much stronger and there’s a small adjustment we can make to your stride that will help you be more efficient.

As an athlete, I believe this coach. It’s true, I did run 4:04 last year. It’s true, my time has decreased steadily over the last years. It’s true, I have been working hard in the weight room. And, because all these things are true, I believe the coach when she tells me she knows a way to help me run faster. This coach is credible and I will work hard for her.

Back in the day, when elite runners were running the mile in 4:04, their coaches did NOT say “Hey, as a stretch goal, I want you to run 2:59 next year. I know it’s a big improvement, but I want to set an arbitrary and unrealistic goal so I can get the most out of you.  And no, I don’t have any advice on how you can run 27% faster than last year. As the one doing the running, that’s your job. I’m just the coach.”

As an athlete, I don’t believe this coach. There’s no way in hell I will run 27% faster this year. It’s simply not physically possible.  The world record is 4:01 and I can’t break it by over a minute. The coach has no clue about how I can achieve the goal, nor did he build a bridge from last year’s pace to this silly target. This coach is not credible and I will not work hard for him.

As a leader you are credible when you set an improvement goal that’s grounded in the reality of how things have gone in the past. And you’re more credible when you give specific reasons why you think the improvement goal is possible. And you’re more credible when you give suggestions on how to achieve the goal. And you’re even more credible when you tell people you will actively support them in the improvement effort. When you do it this way, people think better of you and they’ll work hard for you.

Here’s a rule: if the goal isn’t believable it’s not achievable.

As a leader, when you set an improvement goal that’s out of line with reality you are NOT credible. When you declare an improvement goal that’s disrespectful of history, it’s not a stretch goal. It’s an arbitrary edict designed to trick people into working too hard. And everyone can spot these “goals” at twenty paces. Your best people will give you the courtesy of calling you on your disingenuous behavior, but most people will just smile and quietly think less of you.  And none of them will work hard for you.

When the improvement goal isn’t credible, neither are you.  Think twice before you ask your people to drink the company Kool-Aid.

Image credit – Andy

The race for productivity is on. And to take productivity to the next level, set limits.

To reduce the time wasted by email, limit the number of emails a person can send to ten emails per day. Also, eliminate the cc function. If you send a single email to ten people, you’re done for the day.  This will radically reduce the time spent writing emails and reduce distraction as fewer emails will arrive. But most importantly, it will help people figure out which information is most important to communicate and create a natural distillation of information. Lastly, limit the number of word in an email to 100. This will shorten the amount of time to read emails and further increase the density of communications.

If that doesn’t eliminate enough waste, limit the number of emails a person can read to ten emails per day.  Provide the subject of the email and the sender, but no preview.  Use the subject and sender to decide which emails to read.  And, yes, responding to an email counts against your daily sending quota of ten.  The result is further distillation of communication. People will take more time to decide which emails to read, but they’ll become more productive through use of their good judgement.

Limit the number of meetings people can attend to two per day and cap the maximum meeting length to 30 minutes. The attendees can use the meeting agenda, meeting deliverables and decisions made at the meeting to decide which meetings to attend. This will cause the meeting organizers to write tight, compelling agendas and make decisions at meetings. Wasteful meetings will go away and productivity will increase.

To reduce waiting, limit the number of projects a person can work on to a single project.  Set the limit to one. That will force people to chase the information they need instead of waiting. And if they can’t get what they need, they must wait. But they must wait conspicuously so it’s clear to leaders that their people don’t have what they need to get the project done. The conspicuous waiting will help the leaders recognize the problem and take action.  There’s a huge productivity gain by preventing people from working on things just to look busy.

Though harsh, these limits won’t break the system. But they will have a magical influence on productivity. I’m not sure ten is the right number of emails or two is the right number of meetings, but you get the idea – set limits.  And it’s certainly possible to code these limits into your email system and meeting planning system.

Not only will productivity improve, happiness will improve because people will waste less time and get to use their judgement.

Everyone knows the systems are broken. Why not give people the limits they need and make the productivity improvements they crave?

Image credit –  XoMEoX

With innovation, novel solutions pay the bills – a new solution provides new value for the customer and the customer buys it from you.  The trick, however, is to come up with novel solutions.  To improve the rate and quality of novel solutions, there’s usually a focus on new tools, new problem-solving methods and training on both. The idea is get better at moving from problem to solution.  There’s certainly room for improvement in our problem-solving skills, but I think the pot of gold is hidden elsewhere.

Because novel solutions reside in uncharted design space, it follows that novel solutions will occur more frequently if the problem-solvers are pointed toward new design space.  And to make sure they don’t solve in the tired, old design space of success, constraints are used to wall it off.  Rule 1 – point the solvers toward new design space. Rule 2 – wall off the over-planted soil of success.

The best way to guide the problems solvers toward fertile design space is to create different problems for them to solve. And this guide-the-solvers thinking is a key to the success of the IBE (Innovation Burst Event), where Design Challenges are created in a way that forces the solvers from the familiar. And it’s these Design Challenges that ARE the new problems that bring the new solutions.  And to wall off old design space, the Design Challenges use creatively curated constraints to make it abundantly clear that old solutions won’t cut it.

Before improving the back-end problem solving process, why not change the front- end problem selecting process?

Chose to solve different problems, then learn to solve them differently.

Image credit – Rajarshi MITRA

With process improvement, the existing process is refined over time.  With innovation, the work is new. You can’t improve a process that does not yet exist.  Process creation, yes.  Process improvement, no.

Standard work, where the sequence of process steps has proven successful, is a pillar of the manufacturing mindset.  In manufacturing, if you’re not following standard work, you’re not doing it right.  But with innovation, when the work is done for the first time, there can be no standard work. In that way, if you’re following the standard work paradigm, you are not doing innovation.

In a well-established manufacturing process, problems are tightly scoped and constrained. There can be several ways to solve it and one of the ways is usually better than the others. Teams are asked to solve the problem three or four ways and explain the rationale for choosing one solution over the other. With innovation it’s different.  There may not be a solution, never mind three.  With innovation, it’s one-in-a-row solution.  And the real problem is to decide which problem to solve.  If you’re asked to use Fishbone diagrams to solve the problem three or four ways, you’re not doing innovation. Solve it one way, show a potential customer and decide what to do next.

With manufacturing and product development, it’s all about Gantt charts and hitting dates.  The tasks have a natural precedence and all of them have been done before.  There are branches in the plan, but behind them is clear if-then logic.  With innovation, the first task is well-defined.  And the second task – it depends on the outcome of the first.  And completion dates?  No way. If you can predict the completion date, you’re not doing innovation.  And if you’re asked for a fully built-out Gantt chart, you’re in trouble because that’s a misguided request.

Systems in manufacturing can be complicated, with lots of moving parts.  And the problems can be complicated. But given enough time, the experts can methodically figure it out. But with innovation, the systems can be complex, meaning they are not predictable.  Sometimes parts of the system interact strongly with other parts and sometimes they don’t interact at all. And it’s not that they do one or the other, it’s that they do both.  It’s like they have a will of their own, and, sometimes, they have a bad attitude. And if it’s a new system, even the basic rules of engagement are unknown, never mind the changing strength of the interactions.  And if the system is incomplete and you don’t know it, linear thinking of the experts can’t solve it.  If you’re using linear problem solving techniques, you’re not doing innovation.

Manufacturing is about making one thing a million times. Innovation is about choosing among the million possibilities and making one-in-a-row, and then, after the bugs are worked out, making the new thing a million times.  But one-in-a-row must come first.  If you can’t do it once, you can’t do it a million times, even with process improvement, standard work, Gantt charts and Fishbone diagrams.

Image credit jacinta lluch valero

There are two domains – what is and what isn’t. We’re most comfortable in what is and we don’t know much about what isn’t. Neither domain is best and you can’t have one without the other. Sometimes it’s best to swim in what is and other times it’s better to splash around in what isn’t.  Though we want them, there are no hard and fast rules when to swim and when to splash.

Improvement lives in the domain of what is. If you’re running a Six Sigma project, a lean project or a continuous improvement program you’re knee deep in what is. Measure, analyze, improve, and control what is. Walk out to the production floor, count the machines, people and defects, measure the cycle time and eliminate the wasteful activities. Define the current state and continually (and incrementally) improve what is. Clear, unambiguous, measurable, analytical, rational.

The close cousins creativity and innovation live in the domain of what isn’t. They don’t see what is, they only see gaps, gulfs and gullies. They are drawn to the black hole of what’s missing. They define things in terms of difference.  They care about the negative, not the image. They live in the Bizarro world where strength is weakness and far less is better than less. Unclear, ambiguous, intuitive, irrational.

What is – productivity, utilization, standard work. What isn’t – imagination, unstructured time, daydreaming. Predictable – what is. Unknowable – what isn’t.

In the world of what is, it’s best to hire for experience.  What worked last time will work this time. The knowledge of the past is all powerful.  In the world of what isn’t, it’s best to hire young people that know more than you do. They know the latest technology you’ve never heard of and they know its limitations.

Improving what is pays the bills while creating what isn’t fumbles to find the future. But when what is runs out of gas, what isn’t rides to the rescue and refuels. Neither domain is better, and neither can survive without the other.

The magic question – what’s the best way to allocate resources between the domains? The unsatisfying answer – it depends. And the sextant to navigate the dependencies – good judgement.

Image credit – JD Hancock

When companies want to innovate, there are three things they can change – products, services and business models. Products are usually the first, second and third priorities, services, though they have a tighter connection with customer and are more lasting and powerful, sadly, are fourth priority.  And business models are the superset and the most powerful of all, yet, as a source of innovation, are largely off limits.

It’s easy to improve products. Measure goodness using a standard test protocol, figure out what drives performance and improve it. Create the hard data, quantify the incremental performance and sell the difference.  A straightforward method to sell more – if you liked the last one, you’re going to like this one. But this is fleeting. Just as you are reverse engineering the competitors’ products, they’re doing it to you. Any incremental difference will be swallowed up by their next product. The half-life of your advantage is measured in months.

It’s easy for companies to run innovation projects to improve product performance because it’s easy to quantify the improvement and because we think customers are transactional. Truth is, customers are emotional, not rational. People don’t buy performance, they buy the story they create for themselves.

Innovating on services is more difficult because, unlike a product, it’s not a physical thing. You can’t touch it, smell it or taste it.  Some say you can measure a service, but you can’t. You can measure its footprints in the sand, but you can’t measure it directly. All the click data in the world won’t get you there because clicks, as measured, don’t capture intent – an unintentional click on the wrong image counts the same a premeditated click on the right one. Sure, you can count clicks, but if you can’t count the why’s, you don’t have causation. And, sure, you can measure customer satisfaction with an online survey, but the closest you can get is correlation and that’s not good enough.  It’s causation or bust.  You’ve got to figure out WHY they like your services. (Hint – it’s the people who interface directly with your customers and the latitude you give them to advocate on the customers’ behalf.)

Where services are difficult to innovate, the business model is almost impossible. No one is quite sure what the business model actually is an in-the-trenches-way, but they know it’s been responsible for the success of the company, and they don’t want to change it. Ultimately, if you want to innovate on the business model, you’ve got to know what it is, but before you spend the time and energy to define it, it’s best to figure out if it needs changing.  The question – what does it look like when the business model is out of gas?

If you do what you did last time and you get less in return, the business model is out of gas.

Successful models are limiting. Just like with the Prime Directive, where Captain Kirk could do anything he wanted as long as he didn’t interfere with the internal development of alien civilizations, do anything you want with the business model as long as you don’t change it. And that’s why you need external help to formally define the business model and experiment with it. The resource should understand your business first hand, yet be outside the chain of command so they can say the sacrilegious things that violate the Prime Directive without being fired.  For good candidates, look to trusted customers and suppliers.

To define the business model, use a simple block diagram (one page) where blocks are labelled with simple nouns and arrows are labelled with simple verbs. Start with a single block on the right of the page labelled “Customer” and draw a single arrow pointing to the block and label it.  Continue until you’ve defined the business model.  (Note – maximum number of blocks is 12.)  You’ll be surprised with the difficulty of the process.

After there’s consensus on the business model, the next step is to figure out how the environment changed around it and to identify and test the preferred evolutionary paths. But that’s for another time.

Image credit – Steven Depolo