App Needed: Addiction Manager

Hello, my name is Michael and I am an addict. 

My addiction is dopamine. 

My source of an unlimited supply of it is online in the form of "News". 

Other sources of this dopamine flood are facebook, instagram, etc.

Something is always happening somewhere that's gonna get me hooked and falling down the rabbit hole to a time suck while dosing myself with more juicy dopamine... More, more, more! 

I know it's a bad thing. I gotta stop. 

But it's so easy to get a hit, just a click away. 

How would James Clear (Atomic Habits) deal with this? 

Just a simple matter of eliminating a bad habit. 

Gotta look that up. 

My first (Virgo engineer) thought is to create an app that would filter all inputs according to user-set criteria. Why exercise self control when we can make an app for that? 

STOP NEWS ADDICTION. aka “DoomScrolling”

Limit number of news viewing events, and duration of each. For example, a limit of 3 news viewings per day and limit of 20 minutes per view. Describe the act of news viewing so heinous, so ridiculous and illogical that it would be inconceivable that anyone would spend their time doing such a thing. Rather like reading the National Enquirer or other tabloid. I want to remain an island of calm in a great calm sea, with storms barely noticeable out on the far horizon. Imagine the time that can be put to other good use instead of being dosed with dopamine because of some random ClickBait. It really is a lot like trolling for idiots who will snap at the next shiny object. Do not be that idiot. 

All media exists to produce addictive dopamine experiences.

All random events reduce planned productive bandwidth.

The unlimited variety of media, and increasingly sensational clickbait (headlines, graphics, etc) all indicate a growing need to manage bandwidth for certain activities.

Resolve to recognize the motives of the medium before allowing input to proceed. And then, also based on a variety of filters. For me this would delete any news of Kardashians, all of Hollywood actually, the music scene, politics, sports, religion, gambling, violent crime, and would favor news about local events...)

Use the medium (news) for what it can provide, but with portion controls, and other similar nutritional filters (which medium (podcast, url, etc), which subject matter keywords, etc.).

Here's a list of bandwidth limiter tools.

There seems some futility to delegating our self control to technology. 

We want the quick fix.

I want to know the way where the quick fix is automatic.

Mental.

Click on.

Click off.

A bad habit (addiction) can be attributed to having nothing better to do.
Find something more rewarding to do and the "addiction" falls away.

Habits: Autopilot for Living, Good or Bad

 Learn more on Amazon

In my years of flying, I often wished I had an Autopilot, but that would have taken the adventure out of the experience. It was a lot of work

All commercial airliners, business jets and most other aircraft have an Autopilot installed to relieve the human pilot of a lot of the busy work of staying on the proper compass heading, maintaining altitude, keeping the wings level, etc. These things consume a lot of mind-share while flying but when delegated to a robot who will perform tirelessly and perfectly, the pilot can focus on other important tasks such as communicating with air traffic controllers, looking out for traffic, dealing with checklists, etc.

Ordinary humans have an Autopilot feature too. It's called Habit.

Habit

an acquired behavior pattern regularly followed 

until it has become almost involuntary

Dictionary.com

After we have performed a task enough times, we can do it without thinking; it becomes a habit. Like riding a bike, or making a cup of coffee. The challenge with human habits is that it takes a lot of "programming" for a habit to be bulletproof. The Autopilot on airplanes comes already programmed and works flawlessly from the first time you use it.

We would probably like to have some rock solid habits such as exercise, meditation, getting enough sleep, being more organized and productive, etc.  Maybe we do exercise, but we are inconsistent and therefore miss a lot of the benefits.

Also, we probably have some bad habits we would like to drop, such as eating too much, eating the wrong foods, excessive drinking, staying up too late to watch TV, procrastination, disorganization, etc.

First we make our habits,

and then our habits make us.

John Dryden

Wouldn't it be great if we had the good habits that guarantee a good life and success in business?
It works best if we create good habits when we're younger, but here we are right now, a jumble of some good habits, hopefully, and a lot of bad habits we'd like to get rid of. That probably seems like a lot of work, almost impossible, right? That's what I thought, but I found a way that makes it a lot easier than you might imagine.

We get into the habit of living 

before we acquire the habit of thinking.  

Albert Camus

We are what we repeatedly do,

Excellence, then, is not an act, but a Habit.

Aristotle

Chains of habit are too light to be felt

until they are too heavy to be broken.

Warren Buffett

You'll never change your life until you change something you do daily.

The secret of your success is found in your daily routine.

John C. Maxwell

Motivation is what gets you going.

Habit is what keeps you going.

Jim Rohn

Watch your thoughts; they become words. 

Watch your words; they become actions. 

Watch your actions; they become habits. 

Watch your habits; they become character. 

Watch your character; it becomes your destiny

Lao Tzu

In the absence of clearly defined goals 

we become strangely loyal to performing daily trivia 

until ultimately we become enslaved by it.

Robert Heinlein

The strength of a man's virtue 

should not be measured by his special exertions, 

but by his habitual acts.

Blaise Pascal

Your net worth to the world is usually determined by 

what remains after your bad habits are subtracted from your good ones.

Benjamin Franklin

I love Client SS

He always has the best questions and now that he has an executive assistant I get the questions a day before our meetings so I can give his concerns a really good think and some research so when we meet I'm as helpful as I can be.

Wanted: A few good users

Do you:

Wish you could be more focused, less distracted, less stressed,

and get more of the important things done?

Want to be a part of something
that can truly change the world
one person at a time,
starting with you?

Are you:

First time CEO of a startup company
Student with intentions to start a business

If so, we have a great software product for you.
It's free right now.
All we ask is that you give it a try
and let us know what you think.

Simple. Easy. 

Tell me a bit about yourself.

Apply by email: mm@DBLM.com

Sleep

Sleep. Probably the most important thing you can do to be healthy and productive is to focus on your sleep. And, as the old management maxim states, you have to measure it to manage it. I use the app called Sleep Cycle to measure and report on my sleep stats.

Included in this post are just a few of the many stats that it gives me.

I really like the comparisons of my average bedtime with the USA and other countries.
I used to go to bed around midnight, like most people in the USA, but then I noticed I felt better if I got more sleep before midnight, and that squares with other research I've done.

This one less revealing than the others, but it shows that I'm keeping consistent even through the weekends:

While the Sleep Cycle app may not be perfect, and while they are a bit vague on how they calculate the nightly Sleep Score, at least it is consistently calculated so it's helpful in that regard.

An unexamined life is not worth living. (Plato)

What are you doing to examine and optimize your sleep?

Metcalf's Law

Metcalfe’s Law: Why big networks produce colossal winners

In 1980, Robert Metcalfe — one part of the duo behind Ethernet, a technology for connecting computers together — observed that communications networks increased in value in proportion to the number of users.

One telephone in a city was useless. Even a few hundred, dispersed across millions of inhabitants, wasn’t very useful. But once you had friends and family who owned telephones — and restaurants and movie theaters and stores all had telephones — it was suddenly very desirable to own one.

Metcalfe was working at 3Com, a computer network company he co-founded, when he came up with the idea. At the time, he was trying to understand why his company’s local area network (LAN) starter kits — which allowed 3 PC users to share a printer and a hard disk — weren’t selling.

What he found wasn’t necessarily that the cost was too high, but that 3 people didn’t constitute a sufficiently large network to justify the purchase.

Like early installations of the telephone, the cost of connecting the network initially exceeded the value generated — but there would also be a point of critical mass where the benefits of connecting did exceed the upfront investment.

HOW FACEBOOK LEVERAGED METCALFE’S LAW TO BECOME A SOCIAL MEDIA GIANT

When Facebook first launched at Harvard University in 2004, it was like a singular telephone: pretty useless. But it wasn’t useless for long. Within a month, 50% of the student body was on Facebook.

This was partly a case of pent-up demand: every year, Harvard released a physical “face book” that included every student and faculty member on campus, designed to help everyone at the school get to know one another. “TheFacebook,” as the social network was then known, was an attempt to digitize this already existing physical object and make frictionless the process of snooping on other people’s photos.

The effect, however, was this: with every new Harvard student that joined the platform, it became more valuable for other students to join too. Each new student promised new people to look at, learn about, and “poke.”

As Facebook grew, the company added features that were designed to tap into the “more is better” mechanics of Metcalfe’s Law. Photos, groups, likes, comments — they all leveraged this concept to bring users back into Facebook again and again. And the more people there were on Facebook, the more photos were uploaded and tagged, the more groups were created, and so on.

The non-linear effects of Metcalfe’s Law would also contribute to the long-term viability and success of Facebook’s advertising business. The more people on the platform, the more data and connections, the greater the revenue opportunity in targeted advertising.

Metcalfe himself acknowledged the impact of this law on Facebook’s growth, observing that if Facebook’s revenue was used as a proxy for its value, it was impossible to deny that the network’s value had risen exponentially compared to the steady linear growth of its user base.

DEATH SPIRAL: WHAT HAPPENS WHEN NETWORKS DON’T REACH CRITICAL MASS

According to Metcalfe, a network’s critical mass is a function of the cost of a new connection (e.g. the cost of acquiring a user), the number of users, and the value of each connection.

This approach describes a few mechanics key to network effects. The lower your cost per connection, for example, the lower the number of users that you’ll need to hit critical mass — and the same goes for a higher value per connection.

Andrew Chen, partner at Andreessen Horowitz, has written not only about how the mechanics of Metcalfe’s law are key to growth at companies like Facebook, Twitter, and Snap, but also how the law can work against these networks if user retention isn’t high enough.

In one scenario, each new user that comes to a platform makes the experience better for everyone else. Growth is self-perpetuating because not only are users encouraged to stick around, but there’s an increasing value proposition to entice new users at a steady clip.

In another, not-so-good scenario, new users may still be joining and helping generate the benefits of network effects (for a time), but the network’s retention isn’t great.

If a network starts losing too many users, it can get stuck in what he calls a “social network death spiral.” Because while the forces described by Metcalfe’s Law can help startups gain lots of users quickly, they can also cause those startups to lose users at the same pace. In other words, “as you lose users, the value of your network decays exponentially.”

What’s lacking in this reverse-network effect scenario is the value offered by joining the network. If that value is too low, retention will be low, and it becomes difficult to reach critical mass. Meanwhile, if the value is high, your retention will likely be high as well.

Chen’s death spiral provides a way of understanding what happens when social networks take off for a time but ultimately don’t give each new user sufficient value to stick around — a fate that has befallen prospective social networks from Ello to Path to Peach. These apps often launch with a bang, attract initial interest, and then rapidly lose their user base as the promise of the network fails to materialize.

TAKEAWAY

The telephone, the fax machine, and early LAN networks had what venture capitalists today call “network effects.” The more people that were on these networks, the more valuable it was for new users to join.

This is one of the most important dynamics for businesses in the 21st century, especially in tech. Many of the most valuable businesses of the last several decades, from Microsoft to Facebook to Airbnb to Uber, have succeeded in part thanks to the power of network effects.

While building a business through network effects was valuable before the internet, the internet has made it possible for companies to grow their user base at exponentially faster speeds, often building their entire business models on this growth.

souce: CBinsights

Consider this interesting example of Metcalfe's Law that happened to software I created before the internet existed: As the number of users of TeleMagic grew, it became easier to sell it because there were more people who were trained on the software and therefore easier to hire someone. And when a user left his/her employer for another similar job in another company, they would always recommend the product they knew best... TeleMagic! Other software products were left in the dust.

Smaller Teams = Better Results: The Two-Pizza Rule

The Two-Pizza Rule: Why small teams lead to big success

Jeff Bezos didn’t just leverage the basic insight of Gall’s Law to develop what has become Amazon’s fastest-growing internal unit — he is also responsible for popularizing one of his own tech rules.

In early 2002, Bezos decided that to reduce communication overhead and improve productivity, all of Amazon would be re-organized into so-called “two-pizza teams” — squads small enough that just two pizzas would be enough to fully feed them when working late in the office.

While this has also been interpreted as a rule for meetings — either capping the maximum size of meetings at Amazon or capping the size of meetings that Bezos himself will attend — the original formulation was an edict about team size.

WHY TWO-PIZZA TEAMS GAVE AMAZON A STRATEGIC ADVANTAGE

For analyst Benedict Evans, the two-pizza rule has been a crucial structural advantage for Amazon.

The root of the two-pizza team idea was Bezos’ attitude toward both centralization and communication. Bezos wanted Amazon to remain nimble even as it grew, and that started with encouraging independent decision-making rather than an over-reliance on hierarchy.

And Bezos hated the overhead created by excess communication. In “The Everything Store,” Brad Stone quotes Bezos as saying that “communication is a sign of dysfunction. It means people aren’t working together in a close, organic way. We should be trying to figure out a way for teams to communicate less with each other, not more.”

Source: Getty Images

The main advantage this conferred upon Amazon was simple: smaller and independent teams meant the ability to spin up new teams much faster, giving Amazon the power to scale more cheaply, explore new ideas easily, and ultimately ship more products to customers.

While many of the new initiatives spearheaded by these small teams have failed, some — like Prime, Kindle, and AWS — have become core businesses for Amazon.

For Bezos, it comes back to the idea of building a corporate structure that can generate the maximum amount of innovation for customers. Big, centralized teams maintain companies. Small, autonomous teams find new ideas.

“We have the good fortune of a large, inventive team and a patient, pioneering, customer-obsessed culture — great innovations, large and small, are happening every day on behalf of customers, and at all levels throughout the company,” he wrote in his 2013 shareholder letter. “[Decentralized] distribution of invention throughout the company — not limited to the company’s senior leaders — is the only way to get robust, high-throughput innovation.”

In other words, as Benedict Evans writes, “you don’t (in theory) need to fly to Seattle and schedule a bunch of meetings to get people to implement support for launching make-up in Italy, or persuade anyone to add things to their roadmap.”

There is a machine, and then there is a machine to build the machine, says Evans. And Amazon’s two-pizza rule ensures that the company, aside from being a ubiquitous tech leviathan, can operate a machine to build more Amazons.

SPOTIFY’S SQUADS COMBINE AUTONOMY WITH RESPONSIBILITY

The concept of small, autonomous teams has become extremely popular in the tech world over the years, and some of the biggest and most successful companies have adopted similar ideas to the two-pizza rule to help make their people more efficient and productive.

Spotify is one example of a company that abides by the smaller-is-better rule when it comes to organizational structure.

Source: Getty

The music streaming app organizes teams into 8-person squads, with the function of each squad determined autonomously, rather than being directed from above. Each squad functions as a mini-startup inside Spotify: cross-functional, self-sufficient, and sharing the same geographical location.

One unusual feature of Spotify’s squads is the lack of a designated leader or manager, with each squad member equally responsible for results. In the vein of autonomous operations, any leader of these squads emerges organically and informally. The company uses the squad structure to encourage greater innovation, disruptive thinking, and complete accountability, without the burden of excessive control.

Squads with similar functions across the organization are then grouped under tribes, chapters, and guilds. While tribes act as incubators and provide support for the development of squads, chapters connect employees based on specific skill sets such as web development and quality assurance. Guilds are a way to encourage knowledge sharing across the organization, irrespective of squad, function, or location.

This organizational structure is designed to support a bottom-up approach at Spotify. For example, best practices at the music streaming company only emerge after enough squads have adopted them.

Furthermore, by keeping teams highly autonomous, the structure “lowers the cost of failure” through ensuring that “failure has a ‘limited blast radius’ and affects only part of the user experience,” according to Michael Mankins and Eric Garton of the Harvard Business Review.

In the vein of Bezos’ idea of excessive communication being wasteful, Spotify looks to make communication more efficient by seating squads, guilds, and tribes that need to coordinate closer to each other.

NOT EVERYONE IS SATISFIED WITH TWO PIZZAS

According to organizational psychologist J. Richard Hackman, the more interconnections you have between people, the slower your decision-making and the higher the management costs for the organization.

As you add people to an organization, the number of communication links increases exponentially.

“The cost of coordinating, communicating, and relating with each other snowballs to such a degree that it lowers individual and team productivity,” writes blogger Janet Choi. Two-pizza teams solve this inherent scaling problem by artificially capping the number of links.

Despite the organizational clarity derived from the two-pizza team, not everyone at Amazon and in the wider tech world is a fan of the rule.

Some former Amazon employees and others believe the strategy was counterproductive, and some think that building products using two-pizza teams creates a disconnected user experience.

According to Brad Stone, the concept of two-pizza teams was unevenly applied throughout the Amazon. It took root most of all in engineering, while the idea barely touched the finance and legal departments.

Additionally, each team had to set up its own “fitness function” — some kind of quantitative, linear equation that could be used to judge whether that team succeeded or failed in its mission. For a marketing team, that might be the average email blast open rate multiplied by ensuing order value.

Yet, Stone writes, making some teams define this function for themselves was like “asking a condemned man to decide how he’d like to be executed.” For others, it was merely ineffective.

Kim Rachmeler, former VP at Amazon, said, “Being a two-pizza team was not exactly liberating. […] It was actually kind of a pain in the a**. It did not help you get your job done and consequently the vast majority of engineers and teams flipped the bit on it.”

Small, disconnected teams run the risk of producing disjointed products that don’t contribute to a seamless experience, according to product management consultant Matt LeMay.

For LeMay, the most important aspect of a product for a customer is not the individual features of a product, but how those features come together to deliver a cohesive experience.

Given the vast number of products that Amazon has put out over the years, and how cluttered many of its website’s menus can seem, it’s fair to say that Amazon’s drive for two-pizza teams has not been without its drawbacks.

TAKEAWAY

Jeff Bezos wanted small, autonomous teams that could be “independently set loose on Amazon’s biggest problems,” as Brad Stone writes. These teams wouldn’t have to waste cycles communicating with other teams, and they would each have all the resources and people necessary to launch new products. The result, Bezos thought, would be more creative offerings and faster results for customers.

Though not without its detractors, Bezos’ idea that over-communication between teams risks stoking inefficiencies is now commonly implemented at companies like Google and Spotify.

source: CBinsights

------------------------------

As for personal experience, I agree that the smaller team, in general, will produce a better product. The smallest team is ONE, and since I had the experience of developing TeleMagic completely alone for the first several years of its existence, and with only one other developer taking over for the next several years, there is no question in my mind that the smaller the team, the better the product. (Michael McCafferty)

The James Clear Newsletter

The James Clear Newsletter

The most wisdom per word of any newsletter on the web.

Free

Every Thursday. Short. Powerful. 

Click here


I have been a fan of James Clear for many years, 
and I only advertise products that I use myself,
and I do it for free.

Conway's Law: Corporate Structure Is Vital to Product Development

In 1967, the computer scientist Melvin Conway made a key observation about organizational structure.

The way that a team communicated and the design of that team’s products, Conway argued, were mirrored — one always reflected the other.

A droll illustration of Conway’s Law. Source: Manu Cornet, bonkersworld.net

In a simple explanation of Conway’s thesis, there are two pieces of software: software A and software B. If the developers of these two pieces of software don’t communicate, there’s no easy way for the software to integrate.

When communication between the developers occurs often and openly, on the other hand, the odds of a seamless experience are far greater.

HOW APPLE PRODUCES AN END-TO-END CUSTOMER EXPERIENCE

At Apple, teams are organized according to what’s called the Unitary Organizational Form. The basic idea — rooted in Conway’s Law — is that the company should be organized around functional expertise rather than products.

That means that instead of dedicated teams for products like the iPhone, the Mac, or the iPad, Apple has teams that work on design, teams that work on engineering, teams that work on marketing, and so on.

This structure encourages coordination between teams and helps Apple deliver a unified experience across products. No product is ever released that departs from the predominant Apple design, engineering, or operational paradigm. Even its credit card has an unmistakable Apple “feel.”

After the iPad first launched, Steve Jobs said this “post-PC device” needed to be “even easier to use than a PC” and “even more intuitive than a PC, where the software and the hardware and the applications need to intertwine in an even more seamless way than they do on a PC.  We think we have the right architecture not just in silicon but in our organization to build these kinds of products.”

Reorganizing Apple along functional rather than divisional lines was one of the first things Jobs did upon returning to Apple in 1997, and his successor at Apple, Tim Cook, still attributes the success of the company’s products to this move.

“We’ve found a way to make our products such that the experience is jaw-dropping,” Cook told Businessweek.

WHY GITHUB IS STRUCTURED LIKE AN OPEN-SOURCE PROJECT

GitHub provides an example of a company that obeys Conway’s Law while doing so in a remarkably different way from Apple.

Instead of integrating in order to promote an end-to-end experience, GitHub is intentionally structured like one of the open-source projects the service hosts: decentralized, autonomous, and asynchronous.

That structure reflects the kind of product GitHub has built — one designed for developers more than managers — as well as how that product works.

The GitHub tool is built for asynchronous collaboration: new code can be submitted anytime from anywhere, then reviewed at the responsible party’s leisure. Developers across the globe can use GitHub to collaborate on a project without having to deal with overlapping codebase changes or inconsistencies between their work.

The company itself is also built for asynchronous collaboration, with many of its basic organizational tenets ripped directly from the processes of open source development.

There are no codified standards about what time to come into the office, and most work is completely self-directed. “If you’re interested in working on something, then work on it,” wrote Zach Holman, one of the first engineers at GitHub.

Members of the team are spread out across the world, there are no daily stand-up meetings, and most of the communication they have with their colleagues happens asynchronously, over chat or email.

Collaborating asynchronously to the extreme is a way for the team at GitHub to stay close to one of the biggest problems they want to solve with the company: the difficulty of collaborating asynchronously when working on software projects. One of the ways they take on this problem is through “open, easy-to-use platforms” — precisely what GitHub itself is trying to build.

Apple, in other words, uses an integrated organization in order to build products that give the customer a seamless, end-to-end experience. GitHub uses an organization structured like an open-source project because its goal is to give its user base of developers a collaboration platform that allows distributed, decentralized teams to build great products.

TAKEAWAY

Conway’s Law helps explain not just how companies operate — and how their structures enable or hinder business activity — but also how they are managed.

As computer scientist Fred Brooks (we were at IBM in the mid '60s) has pointed out, for an organization that provides some good or service, the structure that it naturally takes on as it grows is unlikely to be the ideal system for delivering that offering. Remaining flexible is essential to the organization’s structure.

The people that run companies, in other words, must consider organizational design on a similar level as operations, R&D, and products. Much of what we attribute to the latter is rooted in the former.

source: CBinsights

Gall's Law: Why Simplicity Rules

Gall's Law, Free for Kindle at Amazon

Gall’s Law: Why the best products are built from simple systems

In 1975, the American author and pediatrician Robert Gall made an observation about systems that would go on to become hugely influential in computing.

“A complex system that works is invariably found to have evolved from a simple system that worked,” he wrote. “A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.”

This idea, originating in his book “General Systemantics,” would eventually become known as Gall’s Law. Since then, it has become one of the most important and foundational ideas in tech, especially when it comes to the design of new products.

HOW GALL’S LAW FOSTERS PRODUCTS THAT PEOPLE ACTUALLY WANT TO USE

One concept that can help illuminate the power of Gall’s Law is the idea of emergence: the notion that complex systems possess properties that the individual constituents of the system do not.

Powerful technologies can be built when users can manipulate and recombine individual pieces in order to create something of greater value.

Twitter, for example, was founded without reply or retweet functions. All users could do was post 140-character messages to their feeds.

Then Chris Messina proposed the idea of using a hashtag to collect all tweets relating to a single topic, and not long after, hashtags were added into the Twitter platform itself.

Replies and retweets followed later as the Twitter team realized that their users were trying to approximate these actions within their constrained set of possible behaviors.

Source: Getty Images

Twitter could have predicted that users of a public broadcasting app would want some way to share content with their followers, reply to other people’s messages, and even organize information along topical lines.

But cultivating an openness to what users actually did, rather than assuming they knew exactly what to build, was key to how Twitter developed into the product it would become. As co-founder Evan Williams put it, it wasn’t even clear “what [Twitter] was” in those early days, and the product took several turns before settling on what it is now.

This kind of emergence-friendly development process is more or less conventional wisdom in Silicon Valley today, with the creation of a “minimum viable product” (MVP) being standard practice within product businesses.

The thinking behind the MVP is simple and echoes the development processes followed both by Amazon in inventing AWS and by the team at Twitter: build a version of your product with just enough functionality that it can engage your core users. Roll that initial version out and start gathering data and feedback. Then, use that data and feedback to chart the path forward. When done right, the result is what Gall’s Law predicts: a complex system that has arisen from the organic growth of a much simpler system.

HOW AMAZON FOLLOWED GALL’S LAW TO DOMINATE CLOUD SERVICES

The development of Amazon Web Services (AWS) from an internal data storage service to a crucial backbone of the internet encapsulates the power of Gall’s Law.

AWS emerged from a relatively simple desire: Amazon needed a more modular system for its internal engineering work.

Every time a team at Amazon wanted to build out a new web feature, whether for internal use or for a retail partner, Amazon developers would end up building everything — from databases to computing power to storage — from scratch.

That’s when the idea emerged to build out each one of these functions as a modularized service. For one, the team had become highly competent at working on these functions. For another, the Amazon team was operating at a unique scale, being one of the biggest early internet companies.

It soon became clear that Amazon had an equally unique opportunity to make databases, computing, and storage easier for other companies and other developers to use.

“We tried to imagine a student in a dorm room who would have at his or her disposal the same infrastructure as the largest companies in the world,” Andy Jassy, head of AWS, told Brad Stone, author of “The Everything Store.” “We thought it was a great playing-field leveler for startups and smaller companies to have the same cost structure as big companies.”

Source: Flickr

While AWS today appears to be an intimidatingly complex system, it emerged from the interaction of a very simple set of modules designed for Amazon to use internally.

The concept was heavily inspired by the 2003 book “Creation,” written by game designer Steve Grand. Grand’s design approach had centered around building simple creatures, then sitting back and “watching surprising behaviors emerge.” For Amazon CEO Jeff Bezos, this idea proved perfectly applicable to computing.

On the influence of “Creation” across Amazon’s leadership, Brad Stone writes,

“If Amazon wanted to stimulate creativity among its developers, it shouldn’t try to guess what kind of services they might want; such guesses would be based on patterns of the past. Instead, it should be creating primitives — the building blocks of computing — and then getting out of the way. In other words, it needed to break its infrastructure down into the smallest, simplest atomic components and allow developers to freely access them with as much flexibility as possible.”

Today, Amazon Web Services drives most of Amazon’s operating profit and about 15% of its overall revenue.

FEATURE BLOAT: WHAT HAPPENS WHEN COMPANIES FLOUT GALL’S LAW

Tech history is full of products that failed because they went the opposite way of Twitter and Amazon: they built over-engineered products, bloated with features, that lacked enough simple utility for users.

One of the classic examples of feature bloat bringing a product down is ICQ, the once-popular instant messaging client. In a 2007 blog post, Robert Scoble attributed the service’s sudden decline mainly to over-engineering: “It got too cluttered and stopped being developed.”

At one point, ICQ had been the king of instant messaging. In 1998, AOL bought the company behind ICQ for $287M upfront and $120M in performance-related payments. The service had more than 100M accounts registered around the time it peaked in 2001.

For Scoble, that’s where the decline, and the clutter, started. ICQ started branching out from its core utility by adding features around shopping, music, games, and even careers, resulting in a busy interface that felt removed from the purpose of the product.

At the same time, new products like Facebook were emerging that allowed people to more organically connect with their friends outside the constraints of a messenger.

“Feature bloat is how most consumer web and desktop products suffocate themselves,” Dropbox co-founder and CEO Drew Houston has said. “ICQ became so comically bloated that they released an ‘ICQ Lite’ version, but by then they were already on the decline.”

Releasing a “lite” version of a product might make sense if you’re differentiating it from a “premium” version that serves an audience with more complex needs, but ICQ and ICQ Lite were the same basic product for the same basic target user.

The release of a “lite” version, in this case, could be seen as a way to actually offer a superior product — an attempt to cut the feature bloat that had crept in over the years.

TAKEAWAY

Today, with free trials, SaaS, and subscription business models in vogue, it’s more sensible than ever to produce a minimum viable product (MVP) and iterate on it based on user feedback.

While companies should avoid feature bloat, aiming for a gradual evolution from simple functionality is a way to build a growing product that actually reflects users’ needs.

And according to Gall’s Law, products that start small — as simple, effective systems — stand the best chance of becoming powerful businesses built on high-functioning, complex systems.

source: CBinsights