notebook

Say "no"

2012-01-16T09:49:17-08:00

I recently read an interesting collection of Steve Jobs quotes assembled by Bruce Temkin. One in particular caught my attention;

"And it comes from saying no to 1,000 things to make sure we don’t get on the wrong track or try to do too much. We’re always thinking about new markets we could enter, but it’s only by saying no that you can concentrate on the things that are really important."

This notion is perhaps the hardest concept to implement for many organizations. Focusing on what is really important is hard because it requires groups of people to prioritize opportunities, and further to define the criteria for deciding about what is important. More how we structure decisions like this.

Why don't more executive teams focus on "things that are really important?" In our experience, this kind of focus tends to constrain their future options. They prefer to have all their "balls in the air" at once to improve the chances that some will succeed. Or at least this is what they tell us. This way, one can't be accused of making the wrong choices. The logic continues, "Why limit my options?" Yet all those "options" suck up valuable resources and distract focus.

Steve Jobs was proven correct; he said no, killed projects, focused finite resources on a few things, and achieved results against "unreasonable" goals. It was in fact a portfolio strategy that worked.

Related

Get rid of the crappy stuff

Steve Jobs best quotes (WSJ)

Converge

2011-12-15T15:07:35-08:00

Knowing when to converge is the trick. Converge too soon and you may end up with the wrong product, wait too long to converge and you run the risk of delivering too late.

In order to deliver the right product at the right time, best practice is to permit divergence for about 1/3 of the overall development time frame. By divergence I mean this is the time where you define the problem you are trying to solve and explore all the possible solutions, with no limitations — the goal is to define the killer product during this time frame.

Some try to avoid convergence in order to keep all their options open, and fear convergence on the wrong thing… these projects also tend to miss their target windows since finite resources are never focused on delivering the highest value functionality. In an attempt to do all they achieve none.

At about 1/3 of the available time you must force focus — in other words… convergence. The best vehicle, especially in start-ups or where processes are being developed, is that first customer. The optimal condition is to identify the customer that represents 80% of the requirements in a given segment. These are usually the tier 1 customers, since they drive market trends as others follow them.

When there is no customer focus, technologists tend to diverge, since they are excited by the infinite possibilities of the technology -- convergence is boring, while divergence is exciting. Good for a University Research department, bad if you are trying to run a business. When requirements are allowed to constantly change, people diverge, projects slip… it usually requires further divergence in order to adjust to new requirements caused by being late and now non-competitive… the diverge/converge cycle can be endless. It’s one of the root causes of products missing market windows.

Converge in 1/3 of the time, get to market, generate revenue and then iterate further technology generations. This is one of the core principles of fast-time-to-market best practices.

Related

Roughly right/diminishing returns

What does it cost you to be late?

Why accelerate?

2011-12-02T16:28:22-08:00

It seems odd to ask this question (Why accelerate?), since it’s obvious in the technology business that you die if you don’t release new products faster than your competition. Fast teams know this reality and communicate the “need for speed” to the engineering teams. In slow environments, this critical information is insulated from the technical teams and only reserved for marketing, finance, and leadership forums.

Fast teams understood the economics of delay and used this to create urgency well in advance of the projected market window. They knew that if they entered at the front of the curve, they could maximize revenue and profit margin. The longer they waited, the lower the market share would be and the more fierce their competition would be.

When we studied failed projects, we observed that late entry usually resulted in less market share, less revenue, lower margins, and higher development cost due to the extended development time frame. We’ve seen late entry actually kill companies completely.

We built an economic model to quantify time in terms of money in order to make the “time asset” more important. We use it with teams to determine the cost of delay for each day the project is late. We develop a simplified business case with the full team, data which is typically hidden in detailed financial models and rarely exposed to engineering teams. We use this tool with development teams to connect them with the economics of being on time.

In this example, we forecasted unit sales, average selling price, and costs to develop and make the product. To simplify the example, I’ve removed marketing/SG&A expense. You can seen the sum of each category below.

This project generates a 3x return on investment. We’ve worked in some environments where anything less than a 10x ROI would not get funded, but in this case a 3x is a very good return for this market.

Based on this business case, we’ve estimated the impact of a 3 month delay in the project. We assumed that we would take a 10% hit on our sales by entering the market late. We could have also looked at this by year, percent by year, or a simple shift to the right in the sales curve. Delay costs us $877,000 in lost profit per day.

This is not uncommon in Silicon Valley, where most projects we work on have delay values of between $200 and $800k per day.Earlier I made the point that schedule was king and time to market had the greatest impact on profitability. This model clearly illustrates the impact schedule has on profitability. In this example, schedule is twice as important than the next most important factor driving profitability, which is ASP. A 1% change in R&D expenses has little impact compared to an equivalent change in schedule.

The model reflects a common pattern for new technology-based products… if get to market faster, you improve your chances of profitability. Of course this assumes it is the “right product” you are getting to market, but this is another discussion. So being fast to market is obviously not the only determinant of success, since the wrong product at the right time can fail just as well as the right product at the wrong time.

Another advantaged of the model is to use it to make trade-offs during the project. We constantly see budgets restricted or cut to reduce burn rate or save money, without consideration for the impact the resource reduction would have on time to market.
Lets turn it around and “spend to save a day” (one of the best practices of fast teams) and see what happens to the model. Increasing the budget by 30% to accelerate the schedule by 4 months gives me a net benefit of about $37M. I increased and accelerated PBT, but I took a hit on my return. I may decide that acceleration has a greater cost-benefit.

Lets do another interesting study… I have found a way to increase my selling price by adding functionality customers value, while at the same time I found a way to reduce the manufacturing costs through automation efficiencies. This effort requires more time from engineering, so my budget increased by 25%. This effort also required 4 more months of time, which is reflected as delay. Still the benefit out weighs the costs. We are still ahead on PBT with this decision.

The point is that time and money are connected. Go faster and your chances are better you will achieve higher share, margin, and a longer revenue cycle. The other opportunity cost not reflected here is the accelerated learning you get when you get to market faster — the faster you push, the faster you fail, and the faster you learn.

And for start-ups, the longer you wait to get to market, the fewer learning cycles you get with the cash you have in the bank. The trick to winning in this world is fast cycle-time and many cycles of learning. Accelerate learning cycle-time and you get the solution faster.

More on the modeling tool we developed called npdCalc.

Execution

2011-11-28T10:04:57-08:00

"There falls a shadow between the conception and the creation. In the annals of innovation, new ideas are only part of the equation. Execution is just as important."

T.S. Eliot quote from Walter Isaacson's biography of Steve Jobs

Is "Reality Distortion" misunderstood?

2011-11-21T14:44:26-08:00

Since Steve Jobs died, many have tried to retrospectively discover what made him successful… what were the special things he did differently than those “mere mortals” driving around in Silicon Valley in fancy cars?

One in particular concerns the “Reality Distortion Field” which apparently was his trick of getting "10 pounds of flour to fit into a 5 pound sack." In other words, to get people to do impossible things in a shorter period of time than they believed was possible.

With his passing, this super-hero skill has been built up into an almost magical power. I don’t buy the “magic” part.

Rather, I believe he was able to use the voice-of-the-customer (VOC) and his innate understanding of market conditions to know when to, ”Drive a stake in the ground.” This timing is effectively the optimal market window for a given technology specification, and when missed, results in lower share/margin and possible death for start-ups (read more).

Often the “stake in the ground” is confused with the real time that is needed to get there, given the list of deliverables that are supposed to be done. The gap is rarely reconciled, and you will see in the example below (NeXT's first product) that it wasn’t.

Mr. Jobs was able to maintain a focus on the market window, which is very hard to do when pushing the development of advanced technology at a competitive price point. He also knew what was needed, at the expected time of introduction. His minimalist skills served him well in being able to narrow product specifications in order to hit a window in time. The myth was that he somehow magically distorted time and space to create time-to-market mericles.

It is not magic, but rather good management when it is done right.

We observed contemporaries of Jobs in Silicon Valley, at about same time as NeXT (early 1990’s), doing the same thing as Jobs later did at Apple after his return. Scott McNealy (Sun) and Ed McKracken (SGI) were also very good at knowing the optimal entry point/time frame for new products. We called it Fast-Time-To-Market (FTTM) practices in a later study about these fast teams at Sun and SGI, and at other successful places in the valley.

They did what Jobs was able to do; they were able to make a technology-driven team understand “why” what they were doing had to be done by a certain time. We find that teams that miss their window rarely knew why they were trying to hit it, while the ones that made it in time clearly understood the implications of failure — they knew the “why for.”

Let me explain using a video that was recently forwarded to me. It came from a series called “Entrepreneurs,” about the NeXT project, the company Jobs formed after leaving Apple the first time. There is more on TNW (The Next Web) along with some other interesting videos of Jobs during the NeXT timeframe.

At 10:31 of the video, Joanna Hoffman pushes back on the Spring 1987 target market entry date, calling it “Reality Distortion.”

Then at 12:22; Jobs responds, “What I want is probably irrelevant… I mean there are certain realities here, both physiological and market, that are going to come into play in my own personal judgement, and I think this is a window that we’ve got, we’ve been given it, and thank God we’ve been given it, nobody else has done this, it's a wonderful window, we have 18 months… So I don’t think we have a company, if we don’t do this…”

Steve Jobs is explaining the rationale for his 18 month schedule. At that time in Silicon Valley, everyone was trying to break the 2 year development cycle time barrier. The fast teams were developing new products in 12 and 18 months, so Jobs was simply stating the obvious; that to be best in class (and stay in business) one had to be in the market in 18 months.

His small team was telling him, that given the scope of what was to be delivered in 18 months, that it was impossible. Further, that they had never done it before (which I’m sure is a reference to the failures at Apple to get the second generation Macintosh platform and software to market in time, due to "scope creep" and poor organization they had recently experienced at Apple).

The team was describing what we would call the “real schedule.” The “what” and the “when” were simply not aligned or “reconciled” in this example. The “18 month stake” Mr. Jobs set would be called a “target” in our language, and the total duration of the things they needed to release in 18 months would be called the “schedule.”

I happen to know they didn’t have a “bottoms-up” schedule, so so they were not able to realistically argue the gap between what they thought they could do and what he (Mr. Jobs) was expecting them to do, within the 18 months.

When we studied fast teams, we learned that they would align what was wanted with when it was needed (the “stake in the ground”). They did it by walking back the critical path (which pre-supposes teams have a realistic schedule in the first place) to determine where and when innovations were needed in order to close the gap. They made the trade-offs necessary to achieve alignment of “what” and “when,” without compromising what customers really valued.

That NeXT team in the video could have used a schedule to make their point, but they missed the chance (lacking a real schedule) and could only make theoretical arguments against a very powerful and persuasive person. Of course they lost, but both sides actually lost the opportunity to close the gap by identifying the root causes, while they still had time (i.e., 18 months).

So I don’t think Mr. Jobs had some special power to get that extra 5 pounds into that bag, rather he had a special gift for connecting a group of technology-focused engineers with the outside reality of when and what was needed to be successful with a new product. Not magic, but it is a skill that every fast team we’ve studied possesses in one form or another — they knew the window and they used it to drive early trade-offs needed to hit the window on time. They in fact achieved the impossible, not by magic tricks, but rather by logic and a focus on reality.

Interestingly, the first NeXT computer they were debating in this video was actually released in 1988, a year later than Mr. Jobs “18-month stake in the ground.” They were both right; the team said it was 2 1/2 year project and Jobs was right that they needed to hit the market in 18 months with the spec they had targeted.” They also missed the price-point by about 100%. NeXT was clearly a breakthrough product, but they failed to achieve success with their expensive and under-powered unix box that would also didn't run industry standard scientific applications becuase of its unique operating system. By the early 1990’s, NeXT competors like Sun, DEC, HP, and IBM were producing much more powerful “engineering workstations” at a lower cost and which could run industry standard Unix applications.

Full disclosure; I met Steve Jobs in about 1990 in their Redwood City office, a few years after this video was made. The topic of our meeting was to determine if NeXT would participate in our best-practice study. We already had agreements from Sun, SGI, and IBM and we hoped to convince Mr. Jobs to participate in the study, with the promise that what we learned about being fast to market would be anonymously shared with the study participants.

The meeting was very short; if my memory serves me, I think it was less than five minutes before Steve, leaning back in his chair, hands behind his head, feet on the conference table and looking into the ceiling tiles, said, “I’m not interested in your study, since there is nothing I want to learn from any of these companies.” With this declaration, he wished us luck and made a quick exit.

NeXT stayed in business for another 6 years after our brief meeting, before being acquired by Apple. The investors made money in the exit and NeXT’s OS formed the basis for both Sun and Apple’s future success.