Every pundit under the sun has their theories about how the “world will change” post-Corona. Personally, I have never liked airy pronouncements about how “NOW it is different.” I prefer more measured responses, like Ben Thompson of Stratchery, who has said in his articles that the responses to Corona would accelerate existing trends. I do, however, think that one trend will reverse direction, and that has a major impact on markets: supply chains.

Inception When the cloud-native world really got under way, especially the open-source part of it, much of what we used to do (and, likely, most companies still do) in custom and proprietary ways became standardized: defining workloads defining storage defining dependencies defining policies defining placement defining replicas load balancing rollout strategies packaging status many other things The tool to do this, of course, began with docker, which addressed, primarily the packaging and workloads part, but grew to Kubernetes as a basis for the rest of it.

Thoughts on KubeCon North America 2019 In late November, I spent several days at KubeCon/CloudNativeCon, for the fourth or fifth time. It certainly has grown over the years; San Diego’s conference was oversubscribed at 12,000 attendees. In the somewhat snarky words of a friend from the Linux Foundation, “this feels a lot like the OpenStack conference at its peak.” I am hopeful that it doesn’t go down the same path.

Yesterday, I had the privilege of one of my many discussions on technology direction with Josh Mahowald. Our conversation turned towards why it is that so many interesting and enabling pieces of software have been built on top of Kubernetes. As Josh put it, there is an explosion of higher-level services and tooling. This will be the first in a series of posts examining what Kubernetes really is (ok, an API), where it fits in the history of technology, and why it has enabled this kind of “explosion”.

Why do I need both GitHub/GitLab/Bitbucket and JIRA/PivotalTracker/etc.? Over the last several years, while working with companies that regularly deliver software, I have seen three basic patterns in use: Git-All-In: These companies, normally founded by engineers, run all-in on git platforms like GitHub/GitLab/BitBucket. The Issues tracker and Pull Requests/Merge Requests (I will stick with “PR”, but no offense to GitLab) are the primary tool they use to track activity. As they grow some, they use the various “project”, “kanban” and other organizational features added to these platforms, but the primary method for interacting with daily work and knowing their state is the Git-based platform.

How do you run a great conference? I spent the first three days of this week, Monday March 4th through Wednesday March 6th, attending and speaking at QCon London. In my case, I spoke about LinuxKit, a toolkit for composing lightweight, minimal and optimized runnable operating system images. Those who know my focus on technology operations might wonder why I gave a talk on so deeply a technical subject as composing operating system images.

Serverless? Containers? Who will win??? In the week of aws reInvent, when 45,000 or so people are descending on Las Vegas, and two weeks before the big cloud-native conference in Seattle, the question of “which is the future, serverless or containers?” seems to be the “debate du jour”. For example, take last week’s debate: I am going to posit a different position, one which, in the true spirit of compromise, leaves everyone equally unhappy:

A few weeks back, I wrote an article on my observations on KubeCon/CloudNativeCon. A number of people asked that I follow up with similar observations about DockerCon. Last week, I had the unexpected pleasure of attending DockerCon in San Francisco. I say unexpected not because I did not expect to attend, but because I did not expect it to be so pleasurable. Indeed, I fully intended to cancel my ticket, until I was asked by several colleagues to attend with them.

What is Kubernetes? According to the home page: Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications. On that basis, Kubernetes has matured and evolved, becoming not just “an open-source system”, but the system for orchestrating containerized applications. By extension, it is the system for orchestrating any dynamic, self-healing, rapid deployment application. In October 2017, Docker threw in the towel on Docker Swarm and made Kubernetes its default (and apparently soon only) orchestration system.

Two weeks ago, I attended KubeCon/CloudNativeCon EU 2018 in Copenhagen. The sheer size of the conference was astounding. Over 4,000 people attended.. In addition to the sheer size, the professionalism of both the conference itself - audiovisual, presentation, organization and administration - and the sponsor booths was very impressive. I have always enjoyed Linux Foundation events, very warm and friendly, but a little, as they say in Yiddish, “heimish”. They contrasted with the professionally run conferences you could attend put on by other organizations.

Yesterday, I worked with a colleague to determine costing for their newly deployed kubernetes cluster on AWS (Walmart must not be a customer...). The math was mostly straightforward: Get cost of instance by size, multiply by number of instances and 720 hours per month; Add EBS block storage; Add ELBs; Add data traffic out; Add S3 storage. Repeat for each environment, and you have your answer. By far, the biggest cost line item is the first: instances.

Earlier today, I had the pleasure of speaking with Stuart Hasking, a colleague from my financial services IT days, and currently a strategic consultant at TESM. We were discussing the challenges in making changes in a technology environment, when he shared a great line that summarizes the issue perfectly: "It's about the carbon, not the silicon." Most people view technology - deploying servers, designing networks, writing software - and especially complex large-scale distributed technology, as hard.

In the technology world, selling new products is hard. Selling to enterprises is even harder. Small companies were (relatively) easy. They took a little bit of handholding to get your SaaS/software/hardware configured "just right" for them, but most of what they wanted pretty much fit into the offering anyways; it was "on the truck." As you expand up-market into larger customers, customization demands increase. They need: Integration with their (unique) login system Special compliance controls Unique flows and processes Added manual approval steps etc.

Yesterday, I published an article asking, "Did Docker Declare War on RedHat and CoreOS?" I received several responses pointing out market-related developments. A number of people said they know that Docker did not intend to "declare war" on CoreOS and RedHat. Docker simply was developing its tools that they needed anyways and advanced their market. With the change in CEOs this week at Docker, highly unlikely they would start a war immediately before changing.

Yesterday, at DockerCon, Docker Inc announced open-sourcing its LinuxKit toolkit to build Linux operating system images. LinuxKit (the platform that has been rumoured as Moby for over a year) provides a relatively easy-to-use toolkit for building immutable operating system distributions. Normally, an operating system is a platform that you change on a regular basis. Sure, the core itself - the kernel and modules and basic tools - are changed only when you upgrade or patch your operating system.

I find it interesting when the same conversation happens with two different people in the span of just a few days. In the past week, I had almost the exact same conversation twice, with two different people at two different companies, about culture and acquisitions. In both cases, they had initiated the topic of conversation. The following is a common pattern: Company Small is founded to bring a product to the market.

In my world of technology operations, two major themes recur again and again (redundantly): Incentives Litmus Tests I have written about incentives extensively on this blog. In short, as the saying goes, "you get what you measure." Don't expect extra customer handholding if you measure your support team by time spent on issues or minimizing average ticket time. Sure, you need to operate cost-effectively, but the key word is "

A few weeks ago, Amazon Web Services held its annual AWS re:Invent conference. Unsurprisingly, they announced, yet again, a slew of new services, all meant to ease adoption and management of technology services. Yet, something felt a little amiss: https://twitter.com/avideitcher/status/804418718994407424 Not only are SaaS firms getting nervous, but plenty of large firms, as well. As Benoit Hudzia pointed out, many on-premise software giants, including Oracle/PeopleSoft and SAP, should be getting nervous (but perhaps are not):

Last week in LinuxCon/ContainerCon Berlin, I attended a presentation by Luca Bruno of CoreOS, where he described how kubernetes, the most popular container orchestration and scheduling service, and rkt integrate. As part of the presentation, Luca delved into the rkt architecture. For those unaware - there are many, which is a major part of the problem - rkt (pronounced "rocket", as in this) is CoreOS's container management implementation. Nowadays, almost everyone who thinks containers, thinks "

Containers, the management and packaging technology for applications, are useful for many reasons: Packaging is simpler and self-contained Underlying operating system distribution becomes irrelevant Performance, therefore density, and therefore cost, is much better when working without a hypervisor layer To my mind, though, one of the most important elements in any technology is how it affects culture and incentives. For example, MVC development frameworks are helpful for many reasons, but the most important is that it encourages (and sometimes forces) a cleaner way of thinking about and building software.

It has become commonplace to forecast that Uber, Lyft and other ridesharing services are a strategic threat to car manufacturers. After all, if "everyone" uses Uber, why would they bother owning cars? The problem with that argument is that it assumes that "everyone" lives where Uber and Lyft are headquartered: in a dense urban area with very little parking, going to other places nearby where there is lots of traffic and very little parking.

Today, I had a very interesting discussion with Rich Miller, a consulting colleague who has been around the block more than a few times. One of the interesting points he raised is that Amazon's AWS pricing doesn't quite work for enterprises. Let's explore how it is a problem and why it is so. At first blush, Amazon's pricing is intuitive: use an hour of an m4.xlarge, pay $0.239; use 2 hours, pay $0.

Architecture determines capabilities. This is not new. Anyone who has planned and architected a new product, or has tried to retrofit capabilities for which a platform has not been architected, knows it first-hand. Yet, time and again, I come across products that have not been planned, and therefore architected, around reasonably expected capabilities. Sometimes I see these as a user. Last week, a client wanted to give me access to their Dropox Team account, so we could share information.

A lot of ink has been spilled (if that term still can be used in the digital age), on the coming driverless "revolution." Yet a much simpler "evolution" is long overdue for automative technology: the inside. Anyone who has replaced any component on a car - dashboard, door panel, side-view mirror, radio, engine part, or any component at all - is familiar with the swamp of wiring that snakes its way behind every panel on the car.

Serverless. Framework-as-a-Service. Function-as-a-Service. Lambda. Compute Functions. Whatever you call it, serverless is, to some degree, a natural evolution of application management. In the 90s, we had our own server rooms, managed our own servers and power and cooling and security, and deployed our software to them. In the 2000s, we used colocation providers like Equinix (many still do) to deploy our servers in our own cages or, at best, managed server providers like Rackspace.

What is the basic unit of application deployment? Two related trends have changed the answer to this question: DevOps Containers For many years, the tasks between engineer and operator were cleanly, if painfully, split: Engineer builds and delivers a package of files to deploy and run Operator deploys and runs those files in a production operating environment In the early years, the package of files consisted of a directory with a ream of paper and instructions.

For the last few weeks, I have been trying to unravel the connection between the value of talent and open-source. Inevitably, some products have a high level of importance but few people who truly understand it. This creates high demand with low supply, increasing the value of those people. But that isn't special to open-source; it is true for any product with high demand + low supply. These just happen to be open-source.

Why do customers agree to open-source work I do? In the past, we have discussed the benefits of open-sourcing your own software: Reputation Recruiting Contributions Recently, I had the pleasure of walking half an hour from a Tokyo train station with Matthew Garrett, who does some impressive work on core operating systems (pun intended; Mathew works at CoreOS). One of the thing I asked him is why a company open-sources its entire stack?

Earlier this week, a really smart architect and I were evaluating various methods for managing software code changes, bug fixes, releases and major features. We both were in agreement with the primary direction, a popular one in nimble companies. Have a primary "trunk" or "master" branch; Any commits to "master" automatically get built and tested and ready for production (and possibly deployed); Any changes occur on "feature branches", temporary parallels streams of development that eventually - hopefully sooner rather than later - merge into "

Sometimes I am amazed by open source software... even as I contribute to it. The largest repository of public open-source projects, GitHub, has over 35MM repositories in it. Granted, some large percentage of those are private, and therefore closed-source, but even if only half of those are public, and by all accounts it is much more heavily weighted towards open, the numbers are in the tens of millions. Add in other source hosting locations like BitBucket and sourceforge, as well as privately hosted sites like GNU Labs' git.

It seems every day there is another article about how "vulnerable" the Internet of Things (IoT) is. Here are two choice excerpts from the last year: "Hackers Remotely Kill a Jeep on the Highway," Wired, 21st July 2015 "Security Researcher Claims to have Hacked into Flight via Entertainment System," CNN, 19th May 2015 While these are major life-threatening issues - one cannot compare a malicious actor disabling your iPhone while you are on it with someone talking control of your car going 110 kmh down the highway, let alone a plane flying at 35,000 feet and 600 mph!

I loved the Tesla shareholders meeting, for the same reason I love it when VCs write posts about "all the investments we passed on and regretted later." Bessemer Venture Partners even has a page dedicated to its "Anti-Portfolio." Fortune magazine called the Tesla meeting, "Elon Musk Confessions: All the Stupid Things Tesla Has Done." In the meeting, Musk catalogued many "stupid" mistakes (his words), although at the time they probably appeared smart, if slightly crazy (a characteristic required by every entrepreneur).

From the Cambridge Dictionary of English: iota (n.) - an extremely small amount From the Wikipedia: Internet of Things (IoT) - the network of physical objects—devices, vehicles, buildings and other items—embedded with electronics, software, sensors, and network connectivity that enables these objects to collect and exchange data. As electronics get smaller and smaller, not just wearables like an Apple Watch, but even tiny full computers like the Raspberry Pi, the "

After more than twenty years working in many companies, many of them as a consultant often dramatically improving operations, I have received a blessing and a curse: Blessing: I see improvements and benefits potential almost everywhere. Curse: I see improvements and benefits missed almost everywhere. The other day, I spent six and half hours in a hospital emergency room (ER) with a family member. Fortunately, everything is fine, and they are healthy.

Over the last few month, I was reminded - twice, painfully each time - about the impacts of good vs. bad software design choices, especially the impact those choices can have downstream. Ironically, it is not only - or even mainly - the creators and primary users of the software who are impacted, but others unforeseen at design time. Installing an Operating System Anyone who has installed an operating system on their laptop or server - or even smartphone - is familiar with a series of questions, choices and answers, as they configure the operating system.

One of the most popular recent television shows is CBS's "The Big Bang Theory," broadcast on Thursday evenings. In addition, the most recent 5 shows are available online on cbs.com. As with the live CBS broadcast, commercials are interspersed in the show - based on what I can tell at the same places as when broadcast in its normal slot. For decades, the entire broadcast television (and radio) business was based on advertising.

In the last article on serverless, I referenced the old ad in the New York City subways for a trade school. Their tagline was similar to, "technicians will always be needed, because things always will break." We technologists are familiar - intimately - with fixing broken things. Sometimes, it is our own software, devices or infrastructure; other times, it is someone else's. Either we have become responsible for it, or we need it to work under certain circumstances where it simply fails.

A few days ago, I had a conversation with a friend of mine who told me something shocking: a particular cloud company's gross margins on cloud products are below -40%. That is not a typo, it is minus 40% or worse. Essentially, the company is doing one of: burning investor money; running down their own cash reserves; borrowing from banks or the market; or subsidizing from other business lines. Whatever the method they are using to stay afloat, they are burning quite a hole.

The great strength of technologists is that we innovate constantly, always looking for a better world. The great weakness is that we sometimes fall in love with the solution, the technology itself, without regards to its applicable value in the real world. How do we determine if a given solution really has a chance of being adopted? The two biggest determinants of a solution are usefulness and usability. Usefulness "

I used to hate taking long day flights. If I had to spend 12 hours in the air from New York to Tokyo, or Zurich to Bangkok, or Tel Aviv to Newark, I preferred overnight flights. Even since the advent of on-demand entertainment, personal video screens and portable devices like the iPad, those flights just seemed to last forever. So most of the time I would fly overnight. However, the timing didn't always work out, and overnight flights tend to be significantly more expensive than all-day flights, often much greater than 50% more.

Where will VMWare be in 5 years? For many years, VMWare was practically synonymous with virtualization. It provided multiple virtual servers on a single physical server, with a great feature set, good (for its time) management interface, and enterprise customer support. Lately, VMWare has been under threat, primarily due to 2 factors: Public Cloud: When deploying to the public cloud, customers don't just wash their hands of managing compute hardware, storage and network.

In the cellar of Westminster Abbey in London, lies a lovely little café called the Cellarium, with all of the architectural design and feel of the Abbey. Of course, as it is in the heart of London, it has good tea as well. Earlier this week I was privileged to have a fascinating and wide-ranging discussion with Adrian Colyer, which led to 2 provocative questions: Will Microsoft open-source Windows?

I love tech. Despite an MBA and a decade of consulting and running a start-up or two, deep down, I always will be an engineer. One of the most important lessons I learned as a young engineer 20 years ago at Morgan Stanley - courtesy of Guy Chiarello - is that the technology is only the means, not the end. Understand the finances, the market, even the politics if you want to do something with technology, even just inside a company, let alone outside.

This morning, I paid a visit to the American Citizen Services department of a US Embassy, for passport-related services. Anyone who has been there knows that this is not exactly an efficient experience. You need to make a reservation online in advance The security makes TSA look like a luxury hotel: no bags, no backpacks, no phones, no earphones, no Kindles, no food, no drink. You only are allowed your documents, wallet, keys and printed material.

There is an old (obviously) English saying, warning people not to be "penny-wise and pound foolish." As the main British currency is the pound, 1/100 of which is a penny, someone who is penny-wise and pound-foolish is someone who refuses to invest a small amount now, leading to a much greater cost later. No matter how often I come across companies being penny-wise and pound-foolish, I never cease to be surprised by it.

When at the Container Summit, I heard a great (if somewhat perverse) line from Jacob Groundwater of New Relic. I liked it so much, I tweeted it out immediately: If you want people to drive slower, don't give them an airbag; put a spike in their steering wheel! While a rather morbid image, Jacob hit on a core truth: if you make dangerous activities safer, people will do more dangerous things.

Yesterday, I had the pleasure of attending Container Summit NYC, arranged by the great folks at Joyent. The first speaker, Dave Bartoletti of Forrester, gave a broad overview of cloud computing - private and public - and container adoption. One of his themes was the methods by which companies adopt new technologies, particularly cloud and containers, and the benefits they gain. New technologies enable new ways of operating. While some technologies simply make it easier or cheaper to operate in the same way as before, most enable new methods, new processes, new ideas that previously were difficult or impossible.

A few weeks ago, a colleague showed me a technology that was fascinating in and of itself, but the strategic ramifications are even greater. For those of you who are technically inclined, look at these links: https://hub.docker.com/r/microsoft/dotnet/ https://hub.docker.com/r/microsoft/aspnet/ https://github.com/aspnet/home These are, respectively, the Linux docker images for running Microsoft .Net and ASP.Net apps, and the open-source repository. This is quite cool technically. After all, apps compiled for platform A, especially tightly closed platforms like Microsoft, usually aren't meant to run on platform B!

At the risk of kicking someone when they are down, let's look at... GoPro. GoPro recently reported slower than anticipated sales, laid off 7% of their staff, and had their stock hammered (down 14.5% in a day). BusinessInsider did a straightforward if nice job showing their absolute revenue and relative year-over-year growth for the last 5 years. While total sales numbers are nice, the growth numbers aren't pretty.  

Earlier this week, I had breakfast with a colleague of mine from Rancher. Rancher is a great "orchestrator" for Docker containers. I have recommended and used them in production environments. Containers - one of the hottest technologies in the last year - is a much more efficient form of virtualization than traditional "hardware" virtualization (think VMWare or Xen), while providing a superior application distribution model. The challenge is that while the native Docker tools are pretty good for managing individual servers with containers, managing more than a few containers, let alone across more than a few servers, becomes impossibly complex.

Since the dawn of software, more or less, companies wrote their software in a process that went something like this: Product defines the specifications. Architecture designs it. Engineering/R&D builds it. Quality Assurance (QA) tests it. If it passes, it is scheduled for release; if not, goto #3. The jobs of QA teams historically have been procedure-oriented. Whereas engineers tend to be more creative and inventive, QA teams provide the process and constraints (remember the term "

Poor founders and CEOs; we really should have some sympathy for them. The sheer amount of information they need to know is mind-boggling. Everyone starts out with one area of expertise. For most startup founders, it is technology; for some, it is product or marketing. You quickly need to learn sales, and technology, and marketing. Then comes HR - since you need people to grow - and finance becomes important very quickly.

Yesterday, we looked at how the market values Yahoo, and tried to understand why a company with $6.3BN in net assets, and another $31BN in a fairly liquid equity investment is valued only at... $31BN! Interestingly, Daniel Morris pointed out an article in CNBC from September which argued that the issue is taxes. Essentially, Yahoo's investment is encumbered by a potential tax bill. If an when they liquidate it, the tax bill will be enough to wipe out the rest of Yahoo's assets.

According to several articles I have seen today, notably this Wall Street Journal report, Yahoo's Board of Directors are considering a sale of Yahoo's core Internet business. For quite some time, Yahoo has been a troubled company. To many people, it doesn't matter. But to those of us who enjoyed it as one of the first major Internet search sites, it is very sad to see. Marissa Mayer was brought on board to fix the company.

What does selling clothes to Macy's have to do with selling software, and cloud services, to enterprises? Everything. Earlier today, I was speaking with my brother-in-law, entrepreneur and consultant Kevin Pearl. Before starting a firm to improve capture of billing time for attorneys, accountants and consultants; before serving as a turnaround consultant; before building a firm that sold software to manage venture capital portfolios; Kevin ran a firm that sold clothing to large well-known clothing retailers.

Steve Denning has a great short article in Forbes, referencing Peggy Noonan on what Steve Jobs had to say about why big companies fail. The article is worth reading - actually, the entire Isaacson biography of Jobs is a great read - but here is the money quote: The company does a great job, innovates and becomes a monopoly or close to it in some field, and then the quality of the product becomes less important.

In the last week, I have had several discussions with some really smart technologists, partially focused on what makes technology companies nimble and fast and, therefore, great. In the last article, we discussed hiring 10x people, and especially the way many great employees compound together to create up to 2 orders of magnitude faster companies. However, hiring really smart employees is necessary, but it is not sufficient. What these employees need is independence.

In a world full of email, then SMS, then Twitter-based abbreviations for everything - ttyl, afaik, iirc, rtfm - do good, clean, clear writing skills still matter? Yes. Unquestionably, and without a second's hesitation, writing certainly matters, not solely for the pedantic nitpickers. Good writing skills greatly affect your business success. Secret of Success I once asked a very successful executive what he thought was the single most important factor in his success.

I have no idea why it surprises everyone. Every time some technology goes through the "hype cycle", or the sector as a whole goes through a "we're not in a bubble" bubble, inevitably, when the hype dies down or the bubble bursts, people suddenly "discover" business fundamentals. Often, it is not the people discussing it who discover it. Rather, they are the ones reminding everyone that the fundamentals count.

What are the three biggest impediments, or roadblocks, to fast product cycles, especially in the cloud? Incomplete Testing. If you are not 100% confident that your testing covers every known use case, you will be fearful of releasing. Actually, fear of the risk of deployment often is the "canary in the coal mine" sign that your testing is incomplete. The other sign is infrequent releases, defined in the Internet era as less frequently than every few days.

A few weeks ago, "Lies, Damned Lies and Performance Tests," gave us a great example of how even a good performance test can be ruined through a few (seemingly) small mistakes. Today, let's revisit performance tests with an example of performance tests that I constructed on behalf of a client, as an example of how to do them correctly. Even good performance tests suffer from a paradox. On the one hand, you really want to understand how the product will perform in the real world, with all of its environmental conditions.

If you want to change technology that requires a change in process or, more seriously, culture, then you need to change the culture first. Get your people on board and then make the changes. Right? Perhaps not. Or at least not always. If your culture is flexible and open, people collaborate across groups and you are staying competitive, then, yes, change some of the culture to new ways of working, then adopt new technology that requires the different mindset.

Mark Twain attributed the phrase "Lies, Damned Lies and Statistics" to British Prime Minister Benjamin Disraeli, which suits the Prime Minister's known wit, although its provenance has been questioned. If Twain or Disraeli had lived in the days of computers and software, he probably would have coined the phrase as "Lies, Damned Lies and Performance Tests." Perhaps Twain's great novel of Americans touring the desolate Holy Land of the late 19th century might have been called, "

In a previous article, we invented "Conway's Corollary" - how design determines scale. Today, we will look at another case from the hottest technology of the last year: containers. When designing software - any piece of software - the most important criterion is not, "what features does it have," or "how well is it documented," although those are very important. It is not even, "how sexy is the user interface,"

When I went to business school, I worked closely with an incredibly smart woman with whom I shared a very similar method of thinking and mindset. When we would find the same responses to the same questions in the same manner, inevitably I would quote, "great minds think alike." She taught me that there is a corollary: "...but fools rarely differ." The great challenge in life often isn't to agree with someone, no matter how smart; it is to determine if you are both great minds thinking alike, or both fools who are not differing.

No, this is not about "White Hats" - security hackers who try to break into systems in order to strengthen them, as opposed to "Black Hats" - but really about what we can learn from white rats. In the last few weeks, I have helped solve a number of vexing problems on behalf of customers, both in technology and process. Each time I am asked how I do it, and each time the answer is the same.

With due respect to Manfred Mann's Earth Band, I just came across a great example of a business so blinded by their stale model that they cannot respond rationally to competitive threats: textbooks. Anyone involved in education, from students to professors to parents, knows that textbooks are exorbitant. There are several reasons for these prices: Market size: It is easier to sell 100MM Harry Potter hardcovers for $20 than a chemistry book that sells 20,000 copies.

Anyone who does Web-scale or information technology over the past two years knows containers. The primary reason is the success of docker in making not-so-new containers easy to build, deploy, manage and use. Personally, I think Docker containers are great. They provide a far more efficient level of isolation than VM virtualization, without sacrificing manageability. Docker itself, however, is a young company, and every now and then young companies, whose products are moving very quickly, make silly mistakes.

There is an old joke about a rabbi who goes golfing on Yom Kippur, although I am sure there are variants about an imam in ramadan or priest during Lent. It is such a beautiful day, and the rabbi never gets a chance on the links, so he skips synagogue and heads out. On the first hole, he swings... hole in one! He cannot believe it! He moves on to the second.

Is your user management an afterthought? For most companies building technology systems, how to manage users - the process of creating, managing, grouping and linking accounts - is bolted on later. After all, you fully expect your users to spend the bulk of their time using your service, not logging in to or managing your service! So you use some reasonably standard user management library, and when you have to worry about groups and organizations, you sort of bolt it on.

The Prisoner's Dilemma is a famous model in game theory. I am far from an expert in game theory - although I did have the pleasure of meeting Prof. Israel Aumann, nobel laureate in economics and world game theory expert - but I can grasp, and sometimes explain, some of the basics. The Prisoner's Dilemma describes a situation wherein if everyone cooperated, they would have the best outcome. However, because they are prisoners and cannot coordinate with others, they make independently rational decisions.

Infrastructure-as-a-Service, cloud servers, whatever you call them, have been around for years. Amazon is the clear leader in the pack (and, according to Simon Wardley, is likely to remain so for a long time), with others like Rackspace, Google Compute Engine, and Azure picking up much of the rest (fortunately for them, the market is plenty big enough). Digital Ocean, a company I mostly ignored for a while, takes kudos for speed and simplicity, and rapidly have become my go-to option for quick servers.

In earlier articles, we discussed How to Outsource and When to Outsource. Today, we turn to when not to Outsource. At first blush, we expect not to outsource when our candidate does not meet at least one of the criteria for outsourcing listed in When to Outsource. Better Results: Your outsourcers can get you better results, improving any one or more of quality + time-to-deliver + cost without negatively impacting the others.

Although the title for this article might imply suggestions for Proctor & Gamble's IT department, instead we will address how badly code can "smell" and how and when to prevent it. In business as in software, the concept of a "smell test" is a base instinct for if something is a bad idea or implementation: if something smells bad, it probably is. One of my favourite technology bloggers, Adrian Colyer, wrote a recent article about a fascinating analysis of open-source projects, primarily Apache, Eclipse and Android.

What do Heinz Ketchup, QR codes and adult Web sites have in common? Apparently, everything. QR codes are those two-dimensional barcodes you often see on ads or consumer products. Just like regular barcodes encode numeric information, QR codes encode full text. They often are used to reference Web addresses, or URLs. For example, the following QR code, when scanned with a mobile phone app, will link to this site:

Friday I had lunch with a friend who does marketing for a pharmaceutical company. He described to me the process by which he manages major ads. "Ads are very expensive," says he. "First you have to develop the concept, which can be $10,000 or more. Then the production costs for the real ad are $100,000 or more. Finally, the actual costs to air the commercials easily can run $500,000."

When does a personal technology - a computer, a smartphone, a watch - "grow up"? There is a slow but continuous process I have observed with every new personal computing technology. Stage 1 - Child: The new technology provides unprecedented flexibility. It allows you to do just a few new things, but its real appeal is allowing you to do old things on the go. It does so by being a mobile accessory to, or child of, existing "

For many years, business was assumed to be "staid" or "proper". Certain dress and behaviour was appropriate for outside the office, and never to be seen inside. While the distinction between professional and unprofessional behaviour (thankfully) still exists, businesses have begun to open up to the distinction between "inappropriate" and "just plain fun." Those businesses that do embrace their humourous and playful sides have begun to realize significant customer loyalty and even pricing benefits.

Pricing is one of the most important - and mysterious - parts of a business. Price too high, and you lose customers; price too low, and you leave lots of profit on the table. An entire price consulting industry exists, with great leaders like Patrick Campbell of Pricing Intelligently. One important rule of thumb is that input costs should almost never determine the price of a product. What your costs do is have two effects:

As Ecclesiastes said, "there is nothing new under the sun." Last week, we explored how much of the innovation in the tech business is just retooling existing processes, while much innovation exists in the technology itself, which enables those businesses. It turns out, even in technology itself, sometimes the newest and most innovative item really is nothing new under the Sun (capitalization intended). Back in the late 1990s and early 2000s, before the growth of Linux, commodity servers and Google, we used to buy a lot of very expensive computer hardware.

Following on our review of Mary Meeker's Internet Trends report, today we will look at the "Re-Imagining" section. On slides 28-44, the report looks at business processes and how they have changed over the last several decades. Here are some salient examples: Document signing - ink-and-paper to DocuSign Physical payments - cash registers to Square Benefits - paper files and brokers to Zenefits As exciting as the enterprise space is, not one process is new.

This week, Mary Meeker of KPCB has released her "Internet Trends" report. I look forward to the release of this report. While I rarely can sit through a nearly-200-slide presentation, the insights in here always are thought-provoking and make it worth my while. I remember Meeker back in my Morgan Stanley days - unfortunately, I never had the privilege of working directly with her. If you have anything to do with the technology business, read it.

In earlier articles, especially here, we have discussed why great product management is crucial to a company's success. It is the role that is responsible for a product as a whole, the only one that aligns what the product should do, what features it has, where to offer it, at what price points for which packages. Yet many companies seem to do just fine for an extended period of time without product management, especially in the technology sector.

I have been impressed with Heroku for a long time. Their simple to use platform-as-a-service (PaaS) has made it incredibly easy for software developers to deploy applications lightly and cheaply, and then easily scale them up to production scale. As an aside, the very design encourages them to develop their software in a well-architected fashion; see "The 12-Factor App." Just as Amazon Web Services infrastructure-as-a-service (IaaS) EC2 abstracts away hardware, so a PaaS abstracts away the operating system, allowing software managers to focus on software.

One of the hardest challenges in business is knowing when to use an interim solution and when to start over from scratch. From a pure financial perspective, interim solutions almost always win out. I see this regularly in the software industry. The progress looks something like this: You (i.e. your company) write a piece of software. It is successful and useful and sells and grows. Over time, you add more and more features and capabilities, leading to a more useful but more complex product.

Great technology companies have been built on advertising: Google, Facebook, Yahoo (in the old days), not to mention many a magazine, newspaper and television network. I have always loved the operational side of ad networks. They require building and managing a systems whose data throughput and reliability requirements rival a financial pricing and trading system. I have managed several of those, and the parallels are quite strong. What truly interests me in advertising, though, is the brilliance of great creativity.

For almost all of computing history, we have interacted with computing devices via keyboard for input and printer, then screen, for output. Computers are logical devices, and require clean, defined logical statements to interact. Thus, we use precise text. Human interactions, on the other hand, are less precise but much richer. We interact via touch, sound and sight - both the precise written word and visual pictures. For most of human history, the overwhelming majority of people, upwards of 99%, were illiterate.

Over the last week, I have had several discussions about the challenges to successful outsourcing. One person was dealing with manufacturing products in China; another was managing outsourced server maintenance and operations; yet a third had a financial technology management service provider. In all the cases, the question was the same: how do you know when it is good to outsource, and how do you make it succeed? Successfully outsourcing anything is far beyond the scope of a single article.

Normally, I dislike the phrase "soundbite". It implies a shallow, bite-sized saying that misses all of the depth, nuance and complexity that exists in the real world. Nonetheless, soundbites are successful precisely because they can convey - for better or for worse - a key idea in a short, memorable and often inspiring phrase. Earlier this week, Josh Bernoff, in his bluntly named blog, gave the "Parable of Ray's Helicopter Company"

In business, there are two benefits that accumulate to large or diversified companies: Economies of Scale Economies of Scope Economies of Scale are the benefits of from doing more of the same. If you make 10MM laptops a year, your cost per computer will be cheaper than if you make 100,000 laptops per year. These benefits come from a number of sources: Purchasing Power: Since you are buying components for 100x as many LCD screens, you can negotiate better prices.

TrueCrypt was a great open-source encryption program. It created files that, when opened by the program, looked to your computer like an additional drive. Any files placed in that drive would be encrypted and protected from prying eyes. Why would you do it? To keep files protected on your computer. To send files securely from one person to another. To protect files that you might store in the cloud, for example, on Dropbox.

I often notice the incredible value of great product management. Unfortunately, it is something many experienced people do not get, simply because it is the one area of a business, and especially a startup, that cuts across the company. Every other group has a clear line of responsibility: Engineering builds the product. Marketing defines who will buy it and drives awareness. Sales sells it. Customer support supports it. Finance manages the cash, P&L and balance sheet.

Sometimes, you build marketing collateral for a market that is completely unexpected. And while on the way, it teaches you, once again, why Steve Blank, Eric Ries and Co. are right: everything you rationalize and think about is only an opinion about the way the market will react to it; facts exist only in the real world. I have a friend who is a very experienced technology consultant, Reuven Lerner.

Last week, Flipkart, India's largest e-commerce firm, and its fashion subsidiary Myntra, announced that they shuttered their mobile Web sites. According to the article, which has a good analysis on zdnet, their desktop Web site is still active, but they are considering shutting that down as well. Indeed, if you go to flipkart.com or myntra.com from a desktop browser, the site works just fine. Change your User-Agent to iOS or Android, and you get a link to their platform-specific mobile app.

Yesterday, I read an article which claimed that 30% of people have never backed up, while the overwhelming majority are way behind on backups. In the early 1990s, about a year into my very first job out of college at a large global financial, I ran the server backups. Yes, in retrospect, I wonder what they were thinking giving that level of responsibility to the inexperienced kid I was. Either way, it was a great learning experience.

This morning, Adrian Colyer posted his morning paper on a "functional programming." Most readers of this blog are not deep into different programming paradigms, so I will give a very short layman's overview here. For those who are comfortable, jump ahead a few paragraphs. (For the real experts, please do not nitpick on the details; the point is only to give an overview, not to debate the fine points.)

Once in a while, we come across a perfect example of how everyday technology can improve our understanding. It is not radical new technology, like nanoparticles fighting cancer, but great usage of tools that are widely available. Understanding Math I earned my Bachelor of Science in Electrical Engineering many years ago. While I did well at my alma mater, like most people, I struggled with visualizing complex mathematical principles. Sine waves are easy to draw and see, but start doing more complex forms, then head into Fourier Transforms, and even the smartest get lost.

There is a belief in startup-land that you have to be younger than ___ to successfully innovate. To some extent, that is driven by the youth of the founders of a few highly successful companies like Facebook and Twitter, magnified by the adoring media coverage they get. And yet, even when I was back in my 20s and 30s, there was a nagging presence in my head that said, "

Passwords are insecure and annoying. I get that, I have written about it, and I experience it. So lots of companies and organizations are working on replacing passwords with something that is both more secure and more convenient. For example, Twitter's Digits service. Other approaches, like 1Password's password manager, make passwords easier to manage and auto-generate, so they simultaneously can be more secure and more convenient. Then there are "

Late last night, Hunter Walk, of HomeBrew Seed Stage VC, tweeted out the following: This shouldn't be too surprising; people and businesses buy the machine once, but the K-Cup refills are bought over and over again. This is why Keurig has been so intent on keeping machine users buying their coffee, by any means necessary. A year ago, I wrote how I found a mention in their annual report about digital rights management (DRM) to force Keurig machines to accept only "

Two months ago, I posted an article about a United Airlines series of failures that, if not so painful for their paying customers - and their employees too - would be laughable. Yesterday, I had the pleasure of reading an interview with the legendary Gordon Bethune, who turned around Continental Airlines in a single year, from a loss of $600MM in FY1994 to a profit of $225MM in FY1995.

Two weeks ago, we argued that, in the face of competition (and there is always competition), "Premium Pricing Just Doesn't Last." At the same time, there always will be premium priced products - Tesla and BMW, Apple Watch Edition, Oracle - but the question is how long these can maintain significant market share? A smart commenter, amelius, raised a fascinating point. Amelius compares premium pricing for substitutable products to restrictive licensing for software.

About five months ago, I looked into the "Not-So-Simple SIM Card." In short, I called for the abolition of the SIM-to-carrier-to-number tie. For those who never change carriers or travel, this doesn't matter much. You get your phone, you go to your carrier store - or a local retailer like RadioShack (RIP) or BestBuy - sign some paperwork, get a card, insert it into your phone... and never worry about it again.

After our article last week discussing the economics of moving into AWS vs. do-it-yourself (DIY), Jim Stogdill wrote an excellent follow-up about when enterprises aren't moving into the public cloud; Simon Wardley - whose strategic situational awareness mapping is in a category by itself and should be required reading for anyone responsible for strategy - continued with his input. In Jim's words, private clouds are like SUVs; they rarely make sense economically, but sometimes you buy them anyways because:

Do you have SLAs with your customers? Dirty little secret: they don't matter. All that matters is customer expectation in real time. You are running a service. You know that your enterprise customers are highly sensitive to availability, since they use your service to help them make money. Perhaps they even use you as part of their customer-facing platform. Nonetheless, you know you cannot provide 100% availability, even discounting planned maintenance.

If there is one truism in the technology market, it is that premium pricing just doesn't last. If you are first to succeed in a new market - which is distinct from first to a market - then you often have a premium price product because you are the "first" and often the "best". The problem is that it just doesn't last. No matter how good your IP (Intellectual Property, like patents, not Internet Protocol), eventually competitors catch up with "

It is oft-stated that most people really do not get statistics. Just say that word, "statistics," and most people's eyes glaze over. Confession from this engineer and MBA: I did horrifically in my undergrad stats course. (Fortunately, I did better in my MBA course, thanks to a big dose of good teaching from Bob Winkler, and a small dose of being a decade more mature). What does all of this have to do with Coca-Cola?

How did Lenovo do something so inane as fundamentally breaking their customers' laptop security by installing Superfish? What is Superfish, and what is wrong with it? I have often asked clients to consider, "what business are you in?" The right answer is not, "to make profits", or "shareholder return", because those are bland, meaningless statements. Every business wants to make profits and return value to their shareholders. Peter Drucker said, "

What does a great daily paper by a smart thinker have to teach about good product management? About a week ago, I came across Adrian Colyer's great "Morning Paper". I have no idea how I missed this before. The "Morning Paper" takes a look at some trend, research or paper in technology and investigates its impact on technology development and, of course, by extension, business. The Paper is not for the faint of heart or those without pretty deep technical background, at least from the editions that I have seen.

You are reading this blog on WordPress. It is not a secret; any technologist with experience managing WordPress can look at the page and see that it is run by WordPress. How does WordPress show you this page? Here is what WordPress does, simplified: Look at the requested address, showing right now in your browser's address bar. Translate that address into a specific article. Retrieve the text for that article from the database.

Continuing our series on cloud services, especially our most recent one, "How to Do True Cloud", we now turn to the technology that enables true cloud services. This article will go more in depth than the previous ones; after all, we are discussing technology services. However, it will not go so deep as to lose the business-side executives. Indeed, any great executive in technology needs to hold to two principles simultaneously:

Now that we understand what the cloud is, the types of cloud services, the difference between true cloud and hosting, why true cloud matters greatly, and how it makes you nimble, the inevitable question is, how do we get there? Or, to use our question from our last article, how do we get to say, "YES", to the customer who offers us $500,000 - or $5MM - if we are ready to run tomorrow?

In our most recent article, we explored why "true cloud" really matters: it has a significant impact on: Your gross margins Your speed As a company providing technology services, as opposed to products like software, you cannot get cloud-scale gross margins and speed - and therefore valuations - unless you are operating as a true cloud. Today, we will look at a different set of advantages to running your service as a true cloud: how nimble you can be.

In our previous articles, we discussed what cloud is, the types of cloud services, and the difference between true cloud and "market cloud", or hosting. The big question is, so what? You are a software provider offering a cloud solution. Does it really matter if it is "true cloud", or just hosted? Isn't it just a difference in architectural design, a matter for your engineers but not your customers or your bottom line?

Having looked at the definition (and misapplication) of cloud, its key characteristics, and the various categories of cloud services, or fill-in-the-blank-as-a-service (*aaS), we now turn our attention to the important difference between true cloud services and hosting services that are marketed as cloud. This is crucially important to vendors and customers! While it may seem, at first glance, as nitpicking, these are very important differences. They will impact a vendor's short-term and long-term profitability, viability and responsiveness, and a customer's ability to rely on a vendor.

In the previous article, we discussed what the (terribly overhyped) word "cloud" means. Before we start to delve into the difference between "true cloud" and "we just call it cloud", let's look at the different major categories of "cloud" services available. As we discussed previously, cloud services replace: Expertise with consumption Capex with opex Fixed costs with metered prices Unsurprisingly, you can use that model with any technology you consume.

Cloud seems to be the biggest buzzword in the last few years. Every technology provider, every services provider, if they aren't natively "in the cloud", they are providing a version of their offering "in the cloud." Although the term "cloud" seems pretty clear to marketers - personally, I am convinced many believe it means, "we can charge more for this if we slap the word 'Cloud' on it" - the majority of people with whom I speak, from engineers and support staff through executives, CEOs and especially customers, do not have a real understanding of what the cloud is, and why it matters.

What does "mind the gap" - familiar to anyone who has ridden the London Underground, a.k.a. "the Tube", have to do with coffee and power? It turns out, quite a bit. Starbucks' largest metropolitan deployment outside the US - and the largest in Europe by far - is in London, with ~250 stores. Starbucks has become a very familiar English site, indeed. On the technology front, Starbucks has always been an early adopter and even a driver of new technologies:

"The purpose of a business is to create and keep a customer." - Peter Drucker No matter how many times we say it, we forget it. We get caught up in operations, or competition, or marketshare, or share price. Yet a business, like a life, has a purpose: to create and keep a customer. I might add, "to keep that customer profitably satisfied." Earlier this month, a very well known Apple developer, one of the "

Years ago, a young man, let's call him D, with whom I had once gone to summer camp followed his dream and opened a meat restaurant. They had great big burgers, flaming wings, fresh onion rings and fries, a meat-lovers dream. Not only did I enjoy going there, but when a group of friends helped me move apartments before I got married, I took them there for a "thank-you" dinner.

Free Wi-Fi is coming! Well, perhaps not everywhere, but at every Hyatt hotel. I just received an email from Hyatt that they will offer free Wi-Fi for all guests in all rooms and lobbies worldwide, beginning 14 February 2015, just a month away. How did Hyatt come to that decision? Why wasn't it free before? What does it mean for their profits? Most important of all, what lessons can be learned for our businesses?

A year and a half ago, I wrote how Starbucks, early adopter and therefore, through its ubiquitous locations and preferred venue for professionals to work, a driver of adoption of WiFi, was driving adoption of "wireless" charging. Unfortunately, unlike WiFi, it wasn't truly wireless, "anywhere within a reasonable range" charging, but rather more like "plugless" or "contactless" charging, using PowerMatters Aliance (PMA) mats built into their tables. Put your phone on the table and it charges.

I expect this topic to get me a lot of flak. After all, everyone likes dumping on the airlines, including me. But hear me out. I fly a lot of miles every year, mostly in coach, sometimes in business. Most of the time, the journey is tiring and uneventful, sometimes it is annoying, and sometimes downright offensive. I regularly hear and read stories about the decline of comfort, service and value in air travel over the last 30 years.

It has been almost five years since I last addressed appliances. Yes, those drab, dreary every day appliances that solve everyday and boring problems, like washing your clothes or dishes. While they now all have fancy LED screens and digital controls and stainless steel surfaces, at heart, the job is unchanged. Unfortunately, most investment capital goes into "sexy" and exciting new ideas that can spread quickly at low cost, like games or social networks or online services.

I always get a kick when a long-storied company which is in decline tries to hook onto the latest, hottest market, thinking, "we will get into this market, and with our amazing brand, we will knock it out of the park!" This is the business equivalent of a Hail Mary pass... while throwing it off to the sides and into the stands, rather than down the field towards the goal line.

In yesterday's article, we discussed what product management is, and why it matters so much to companies. It also is important to early stage companies, who, at least in theory, cannot afford either the extra head count or the founder's time. Actually, seeing how crucial product management is to getting product-market fit - as Steve Blank would say, that is the very essence of a startup - it probably is more important for early stage firms, since they have little to no wiggle room.

This article is not a list of companies that have great products or product management, enlightening as it might be. It also is not a list of companies with terrible product management, although I could compose a very long such list, and the stories would be very entertaining! Instead, this is a discussion of why product management matters, and how you get great product managers. The genesis of this article is a number of conversations and interactions I have had with companies over the last year or so, several of which have had great product management, while others have been sorely lacking in the field.

A few months back, I looked at the growing tide of making movies on mobile phones. I was referring not only to the typical home videos that we used to capture on a large home video camera, now on our portable phones, but semi-professional and even professional films on your iPhone or Android. Specifically, I was concerned with what this trend means for high-end camera makers. This week, I saw a short - all of 1:22 - fantasy film called DragonBorne, which was done entirely on an iPhone 6.

Last week, I was having lunch with an old friend. We worked together many years ago building some pretty cool technology at a very large financial services firm. Each of us has over 20 years in the technology industry. He has continued to manage infrastructure, and is doing some pretty impressive advanced infrastructure management. Both of us have seen the big company and the startup, and both of us have experience a broad range of technologies - consumer and business and enterprise; infrastructure and applications; hardware and software - and we both truly love technology and the changes it brings to society.

Managing change is a process, something between a science and an art, taught in all respectable business schools and management courses. There really are 2 reasons for teaching it: Management: If you are managing a team, a division or a company, you need to understand the emotional and psychological blocks to change, and what it will take to get employees and partners to support change. Marketing: If you are responsible for marketing a product to consumers, or creating an entirely new product, you need to have a solid understanding of what inertia keeps customers in place and what it will take to change them.

One of the challenges customer support and sales agents face is the balance between efficiency and humanity. The more efficient methods of communication often are very impersonal, while the personal ones are expensive and inefficient. On the one hand, a business wants to provide its services as efficiently as possible. This usually boils down to 2 key elements: Cost: Having an agent at the customer's home or office is very expensive.

I used to love BusinessInsider, the Internet (and to a lesser extent general business) news site run by Henry Blodget. I am also impressed with how Blodget has reinvented his life. In 2003, he was charged with securities fraud by the infamous Client 9, a.k.a. then-New York State Attorney General Eliot Spitzer. Blodget settled for 2+2 ($2MM fine, $2MM disgorgment of "ill-gotten proceeds") and a lifetime ban from the securities industry.

Today, BusinessInsider - about whom I should write more, as their "Top Stories" have become more sales promotion and less news, and thus I look forward to receiving their updates less than I used to, but that is for another day - published a piece by Alyson Shontell about the future of mobile apps. In short, they see mobile apps migrating towards the Web, with native apps more like bookmarks or small content holders.

In the USA, when someone needs a medical device - wheelchair, crutches, etc. - one buys them from the local drugstore or supplier via insurance. Many of these can even be found on Amazon. With one-day delivery and Amazon Prime, it often pays to order from them rather than buy at the local supplier. When you are done with it, you sell it. Even though they don't market this are too heavily, eBay has 32,000+ active listings for wheelchairs alone!

Over the course of my travels, I had several interesting connections with beer. First of all, I saw several interesting micro-breweries in the Rockies and in Vancouver. More interestingly, at breakfast in the Vancouver hotel, I saw a man wearing a "Yuengling Ice Cream" hat. Yuengling Ice Cream? Isn't Yuengling beer? Apparently, it is both. During Prohibition in the 1920s, when manufacture of most alcohol was banned, the Yuengling family turned to running a dairy to support the family.

Every business tries very hard to find ways to serve the same number of customers at the same level of quality for the same (or lower) cost. After all, if I can sell you a book for $10, and my marginal cost is $6, or I can find a way to sell you the exact same book with the exact same shipping policies and the exact same experience for $5, well, my profit just went up.

Last week, I walked into Selfridges, the large department store on Oxford St in London. While I was after the Food Hall on the ground floor (conveniently, it has a kosher food stand) and the Starbucks on the 4th (whose WiFi did not work), in order to get through to them I needed to walk the primary sales area by the main entrance: cosmetics. Stores are very very careful in allocating floor space.

I recently had a conversation with the CEO of a company going through significant change. We discussed certain alternatives - some dramatic - to their business model. During our conversation, we focused on what it is that would make this company so much better, rather than "just another one." He pointed out certain key operational and back-office processes we could implement - many of which were already underway - that would make the newer competitor faster, nimbler, more modern.

When companies bring new products and services to market, they are addressing some unmet need. It might be an unserved or underserved market; it might be significantly lower costs - and therefore price to customer at the same margins - for a similar product; it might be a lighter and simpler product for a lower price; it might be one of myriad different ways that your company wants to differentiate itself.

It is a truism that engineers see the world rationally... too rationally. Everything has one or more defined answers, all you need is to find the right set of solutions. Because of that rationalist (using the term loosely) view, many engineers who have succeeded at product engineering, building the product, have failed at product development, designing and successfully marketing the product. The problem with product development, and especially new product development, is that you never really know if your market is ready for your solution, and even if they are ready, if they will accept the product/solution, if they will like and adopt the design, if they can and will pay a profitable price, if the packaging and channels are right.

Last week, Jonathan Baskin, a former executive at Blockbuster and now a brand consultant, wrote a fascinating insight in Forbes into the setting for the demise of his former employer. Baskin argues that Blockbuster and its executives early on failed to recognize that its primary value was not as they believed, convenience, "get a movie right in your neighbourhood!" Logically, if physical reach is your key value-add, then a strategy mixing new store expansion and existing store acquisition makes perfect sense.

Here is a radical thought: Microsoft should kill Windows. No, not the cash cow on laptops and desktops, nor the ones that give great views from their Redmond, WA campus. Rather, as Microsoft continually fights and loses to iOS and Android in the mobile space of tablets and smartphones, it should release an operating system that shares nothing with Windows, not even the name. Inside the walls of Microsoft headquarters, this idea is probably heresy.

Last week, Eugene Wei, a former Amazon employee, posted an excellent article called the "Amazon profitless business model fallacy." Eugene was debunking the prevalent belief that Amazon seems to be highly value despite its not making a serious profit. To my mind, however, Eugene isn't debunking the "profitless business model" fallacy, he is debunking the "pundits actually know what they are talking about" fallacy. There are actually three kinds of profit in business:

Yahoo released their newly revamped Yahoo Mail, or Ymail, in the last week. It is good to see Yahoo putting effort into bringing life and energy back to its products like Flickr and Yahoo Mail. The market for mail is fairly close. Gmail is in the lead with 425MM, Hotmail following with 325MM and Yahoo taking a close third at 289MM. How can Yahoo steal market share from the first and second place players?

SnapChat was supposed to be a safe way to share pictures or text for a short (and controlled) time. You take a picture or send a text with your smartphone, set an expiry on it, and only the recipient can see it only for the time you set. After that, it is gone, lost forever. A few months back, some smart engineers proved that snapchat doesn't actually delete the pictures, and you can retrieve them.

It always amazes me when a company tries to cheat, somehow expecting not to get caught. Yesterday, Ars Technica published a detailed takedown as to how Samsung tried to deceive the performance benchmark tests in its latest Samsung Galaxy Note 3. For the non-technical among the readers, benchmarks in the technical world are exactly what they are in the business world: standards-based tests that allow purchasers to compare multiple items.