AKF Partners

Abbott, Keeven & Fisher PartnersPartners In Hyper Growth

Archives from author » wabb

AKF Turns 10 – And It’s Still Not About the Tech

The caller ID was blocked but Marty had been expecting the call.  Three “highly connected” people – donors, political advisers and “inner circle” people –  had suggested AKF could help. It was October 2013 and Healthcare.gov had launched only to crash when users tried to sign up. President Obama appointed Jeffrey Zients to mop up the post launch mess. Once the crisis was over, the Government Accountability Office (GAO) released its postmortem citing inadequate capacity planning, software coding errors, and lack of functionality as root causes. AKF’s analysis was completely different – largely because we think differently than most technologists. While our findings indicated the bottlenecks that kept the site from scaling, we also identified failures in  leadership and a dysfunctional organization structure.  These latter, and more important, problems prevented the team from identifying and preventing recurring issues.

We haven’t always thought differently. Our early focus in 2007 was to help companies overcome architectural problems related to scale and availability. We’ve helped our clients solve some of the largest and challenging problems ever encountered – cyber Monday ecommerce purchasing, Christmas day gift card redemption, and April 15th tax filings. But shortly after starting our firm, we realized there was something common to our early engagements that created and sometimes turbocharged the technology failures. This realization, that people and processes – NOT TECHNOLOGY–  are the causes of most failures led us to think differently.  Too often we see technology leaders focusing too much on the technology and not enough on leading, growing, and scaling their teams.

We challenge the notion that technology leaders should be selected and promoted based on their technical acumen. We don’t accept that a technical leader should spend most of her time making the biggest technical decisions.  We believe that technical executives, to be successful, must first be a business executive with great technical and business acumen.  We teach teams how to analyze and successfully choose the appropriate architecture, organization, and processes to achieve a business outcome. Product effort is meaningless without a measurable and meaningful business outcome and we always put outcomes, not technical “religion” first.

If we can teach a team the “AKF way” the chance of project and business success increases dramatically. This may sound like marketing crap (did we mention we are also irreverent?), but our clients attest to it.  This is what Terry Chabrowe, CEO eMarketer, said about us:

AKF served as our CTO for about 8 months and helped us make huge improvements in virtually every area related to IT and engineering. Just as important, they helped us identify the people on our team who could move into leadership positions. The entire AKF team was terrific. We’d never have been able to grow our user base tenfold without them.

A recent post claimed that 93% of successful companies abandon their original strategy.  This is certainly true for AKF. Over the past 10 years we’ve massively changed our strategy of how we “help” companies. We’ve also quadrupled our team size, worked with over 350 companies, written three books, and most importantly made some great friendships. Whether you’ve read our books, engaged with our company, or connected with us on social media, thanks for an amazing 10 years. We look forward to the next 10 years, learning, teaching, and changing strategies with you.

1 comment

The Biggest Problem with Big Data

How to Reduce Crime in Big Cities

I’m a huge Malcolm Gladwell fan.  Gladwell’s ability to convey complex concepts and virtually incomprehensible academic research in easily understood prose is second to none within his field of journalism.  A perfect example of his skill is on display in the Tipping Point, where Gladwell wrestles the topic of Complexity Theory (aka Chaos Theory) into submission, making it accessible to all of us.  In the Tipping Point, Gladwell also introduces us to The Broken Windows Theory.

The Broken Windows Theory gets its name from a 1982 The Atlantic Monthly article.  This article asked the reader to imagine a building with a few broken windows.  The authors claim that the existence of these windows invite vandals to break still more windows.  A continuous cycle of expanding vandalism ensues, with squatters moving in, nearby buildings getting vandalized, etc.  Subsequent authors expanded upon the theory, claiming that the presence of vandalism invites other crimes and that crime rates soar in communities where unhandled vandalism is present.  A corollary to the Broken Windows Theory is that cities can reduce crime rates by focusing law enforcement on petty crimes.  Several high profile examples seem to illustrate the power and correctness of this theory, such as New York Mayor Giuliani’s “Zero Tolerance Program”.  The program focused on vandalism, public drinking, public urination, and subway fare evasion.  Crime rates dropped over a 10 year period, corresponding with the initiation of the program.  Several other cities and other experiments showed similar effects.  Proof that the hypothesis underpinning the theory is correct.

Not So Fast…

Enter the self-described “Rogue Economist” Stephen Levitt and his co-author Stephen Dubner – both of Freakonomics fame.  While the two authors don’t deny that the Broken Windows theory may explain some drop in crime, they do cast significant doubt on the approach as the primary explanation for crime rates dropping.  Crime rates dropped nationally during the same 10 year period in which New York pursued its Zero Tolerance Program.  This national drop in crime occurred in cities that both practiced Broken Windows and those that did not.  Further, crime rate dropped irrespective of either an increase or decrease in police spending.  The explanation therefore, argue the authors, cannot primarily be Broken Windows.  The most likely explanation and most highly correlated variable is a reduction in a pool of potential criminals.   Roe v. Wade legalized abortion, and as a result there was a significant decrease in the number of unwanted children, a disproportionately high percentage of whom would grow up to be criminals.

Gladwell isn’t therefore incorrect in proffering Broken Windows as an explanation for reduction in crime.  But the explanation is not the best one available and as a result it holds residence somewhere between misleading (worst case) and incomplete (best case).

What Happened?

To be fair, it’s hard to hold Gladwell accountable for this oversight.  Gladwell is not a scientist and therefore not trained in how to scientifically evaluate the research he reported.  Furthermore, his is an oft repeated mistake even among highly trained researchers.  And what exactly is that mistake?  The mistake made here is illustrated by the difference in approach between the Broken Windows researchers and the Freakonomics authors.  The Broken Windows researchers started with something like the following question “Does the presence of vandalism invite additional vandalism and escalating crime?”  Levitt and Dubner first asked the question “What variables appear to explain the rate of crime?”

Broken Windows started with a question focused on deductive analysis.  Deduction starts with a hypothesis – “Evidence of vandalism and/or other petty crimes invites similar and more egregious crimes”.   The process continues to attempt to confirm or disprove the hypothesis.  Deduction starts with a broad and abstract view of the data – a generalization or hypothesis as to relationships – and attempts to move to show specific relationships between data elements.  The Broken Windows folks started with a hypothesis, developed a series of experiments to test the hypothesis and then ultimately evaluated time series data in cities with various Broken Windows approaches to policing.  What they lacked was a broad question that may have developed a range of options indicating possible causes.

The Freakonomics authors started with an inductive question.  Induction is the process of moving from specific observations about data into generalizations.  These generalizations are often in the form of hypothesis or models as to how data interacts.  Induction helps to inform what questions should be asked of the data.  Induction is the asking of “What change in what independent variables seem to correspond with a resulting change in some dependent variable?”  Whereas deduction works from independent variable to dependent variable, induction attempts to work backwards from dependent variable to identify independent variable relationships.

So What?

The jump to deduction, without forming the right questions and hypotheses through induction, is the biggest mistake we see in developing Big Data programs and implementing Big Data solutions.   We all approach problems with unique experiences and unique biases.  The combination of these often cause us to race to hypotheses and want to test them.  The issue here is two-fold. The best case is that we develop an incomplete (and as a result partially or mostly incorrect) answer similar to that of The Broken Windows researchers.  The worst case is that we suffer what statisticians call a Type 1 error – confirming an incorrect answer.  The probability of type 1 errors increases when we don’t look for alternative or better answers for outcomes within our data sets.  Induction helps to uncover those alternative or supporting explanations.  Exploring the data to discover potential relationships helps us to ask the right questions and form better hypotheses and better models.  Skipping induction makes it highly probable that we will get an incorrect, misleading or substandard answer.

But it is not enough to simply ensure that we practice both induction and deduction.  We must also recognize that the solutions that support induction are different from those that support deduction.  Further, we must understand that the two processes while complimentary can actually interfere with each other when performed on the same system.  Induction is necessarily a very broad and as a result slow and tedious process.  Deduction, on the other hand, needs significantly less data and “prefers” to be faster in implementation.  Inductive systems are best supported by solutions that impose very few relations or structure on the data we observe.  Systems that support deduction, in order to allow for faster response times, impose increased structure relative to inductive systems.  While the two phases of discovery (Induction and Deduction) support each other, their differences suggest that they should be performed on solutions purpose built to their specific needs.

Similarly, not everyone is equally qualified to perform both induction and deduction.  Our experience is that the folks who tend to be good at determining how to prove relationships between variables are often not as good at identifying patterns and vice versa.

These two observations, that the systems that support induction and deduction should be separated and that the people performing these tasks may need to be different, have ramifications to how we develop our analytics systems and organize our Big Data teams.  We’ll discuss these ramifications and more in our next post, “10 Anti-Patterns within Big Data”.

Comments Off on The Biggest Problem with Big Data

Guest Post: Three Mistakes in Scaling Non-Relational Databases

The following guest post comes from another long time friend and business associate Chris LaLonde.  Chris was with us through our eBay/PayPal journey and joined us again at both Quigo and Bullhorn.  After Bullhorn, Chris and co-founders Erik Beebe and Kenny Gorman (also eBay and Quigo alums) started Object Rocket to solve what they saw as a serious deficiency in cloud infrastructure – the database.  Specifically they created the first high speed Mongo instance offered as a service.  Without further ado, here’s Chris’ post – thanks Chris!

Three Mistakes in Scaling Non-Relational Databases

In the last few years I’ve been lucky enough to work with a number of high profile customers who use and abuse non-relational databases (mostly MongoDB) and I’ve seen the same problems repeated frequently enough to identify them as patterns. I thought it might be helpful to highlight those issues at a high level and talk about some of the solutions I’ve seen be successful.

Scale Direction:

At first everyone tries to scale things up instead of out.  Sadly that almost always stops working at some point. So generally speaking you have two alternatives:

  • Split your database – yes it’s a pain but everyone gets there eventually. You probably already know some of the data you can split out; users, billing, etc.Starting early will make your life much simpler and your application more scalable down the road. However the number of people that don’t consider that they’ll ever need a 2nd or a 3rd database is frightening. Oh and one other thing, put your analytics some place else; the fewer things placing load on your production database from the beginning the better. Copying data off of a secondary is cheap.  
  • Scale out – Can you offload heavy reads or writes ?  Most non-relational databases ’s have horizontal scaling functionality built in (e.g. sharding in MongoDB).  Don’t let all the negative articles fool you, these solutions do work. However you’ll want an expert on your side to help in picking the right variable or key to scale against ( e.g shard keys in MongoDB ). Seek advice early as these decisions will have a huge impact on future scalability.

Pick the right tool:

Non-Relational databases are very different by design and most “suffer” from some of the “flaws” of the eventually consistent model.  My grandpa always said “use the right tool for the right job”  in this case that means if you’re writing a application or product that requires your data to be highly consistent you probably shouldn’t use a non-relational database. You can make most modern non-relational databases more consistent with configuration and management changes but almost all lack any form of ACID compliance   Luckily in the modern world databases are cheap; pick  several  and get someone to manage them for you, always use the right tool for the right job. When you need consistency  use an ACID  compliant database,   when you need raw speed  use an in-memory data store,  and when you need flexibility use a non-relational database .

Write and choose good code:

Unfortunately not all database drivers are created equal. While I understand that you should write code in the language you’re strongest in sometimes it pays to be flexible. There’s a reason why Facebook writes code in PHP, transpiles it to C++, and then compiles it into a binary for production. In the case of your database the driver is _the_ interface to your database, so if the interface is unreliable or difficult to deal with or not updated frequently, you’re going to have a lot of bad days.  If the interface is stable, well documented and is frequently updated,  you’ll have a lot time to work on features instead of fixes.  Make sure to take a look at the communities around each driver, look at the number of bugs reported and how quickly those bugs are being fixed.  Another thing about connecting to your database: please remember nothing is perfect so write code as if it’s going to fail. At some point in time some component, the network, the NIC, load balancer, a switch or the database itself crashing, is going to cause your application to _not_ be able to talk to your database. I can’t tell you how many times I’ve talked to or heard of a developer assuming that “the database is always up, it’s not my  responsibility” and that’s exactly the wrong assumption. Until the application knows that the data is written assume that it isn’t. Always assume that there’s going to be a problem until you get an “I’ve written the data” confirmation from the database, to assume otherwise is asking for data loss.   

These are just a few quick pointers to help guide folks in the right direction. As always the right answer is to get advice from an actual expert about your specific situation.

Comments Off on Guest Post: Three Mistakes in Scaling Non-Relational Databases

Guest Post – Effective CTOs

The following guest post comes from long time friend and former colleague Michael “Skippy” Wilson.  Michael was one of eBay’s first employees, and its first CTO.  He was responsible first for taking “eBay 1.0” (Pierre Omidyar’s PERL scripts) and converting them into the modern site written in C with which most people are familiar.  He and his architecture team subsequently redesigned the site with multiple service oriented splits (circa 2000) to enable it to scale to what was then one of the largest transaction sites on the internet.  There was no “playbook” back then for how to scale something as large as eBay.  Michael was one of the early CTOs who had to earn his internet PhD from the school of hard knocks.

Effective CTOs

The excellent blog post This is How Effective CTOs Embrace Change talks about how Twilio CTO Evan Cooke views the evolution of a CTO through a company’s growth.

While this article does an excellent job of identifying the root causes and problems a CTO can run into in– especially working with his fellow C-Level colleagues – I think there is another problem it does not address.

Ironically, one of a CTO’s biggest challenges is actually technology itself and how the CTO manages the company’s relationship to it. These challenges manifest themselves in the following ways:

Keeping appropriate pace with technological change

When a company is young, it’s agile enough to adopt the latest technologies quickly; in fact many companies change technologies several times over as they grow.

Later, when (as the article says) the CTO starts saying “No” to their business partners, they may also react to the company’s need for stability and predictability by saying “No” too often to technological change.  It only takes a good outage or release slippage, triggered by some new technology for the newly minted CTO to go from being the “Yes” man to the “No” man, sacrificing agility at the altar of stability and predictability.

The same CTO who advocated changing languages, database back ends, and even operating systems and hardware platforms while the company was growing finds himself saying “No” to even the most innocuous of upgrades. While the initial result may be more stability and predictability, the end result is far from that: the company’s platform ossifies, becomes brittle and is eventually unable to adapt to the changing needs of the organization.

For example, years ago, before the domination of open-source Unix variants like OpenBSD and Linux, many companies “grew up” on proprietary systems like Solaris, Microsoft, and AIX, alongside database counterparts like Oracle, and Sybase.  While they were “growing up” open source systems matured, offering cost, technology, and even stability benefits over the proprietary solutions. But, in many cases, these companies couldn’t take advantage of this because of the perceived “instability” of these crazy “Open Source” operating systems. The end result was that competitors who could remain agile gained a competitive advantage because they could advance their technology.

Another (glaring) example was the advent of mobile. Most established companies completely failed to get on the mobile bandwagon soon enough and often ended up ceding their positions to younger and more agile competitors because they failed to recognize and keep up with the shift in technology

The problem is a lot like Real Life ™. How do you continue to have the fun you had in your 20s and 30s later on, when things like career and family take center stage? Ironically, the answer is the same: Moderation and Separation.

Moderation means just what it says: use common sense release and deployment planning to introduce change at a predictable – and recoverable – rate. Changing to a new database, a new hardware platform, or even a new back end OS isn’t a big change at all, as long as you find way to do it in an incremental and recoverable matter. In other words, you can get out of it before anyone notices something went wrong.

Separation means you build into the organization the ability to experiment and advance all the time.  While you front end production systems may advance at a mature pace, you still need to maintain Alpha and Beta systems where new technologies can be advanced, experimented with and exposed to (willing) end users. By building this into your organization as a “first class” citizen, the CTO keeps the spirit of agility and technological advance alive, while still meeting the needs of stability and predictability.

Making sure Technology keeps pace with the Organization

The best way to describe this problem is through example: Lots of today’s start-ups are built on what are called “NoSQL” database platforms. NoSQL databases have the advantages of being very performant, in some cases very scalable, and, depending on who you ask, very developer friendly. It’s very clear that lots of companies wouldn’t be where they are without the likes of MongoDB and Couchbase.

But, as many companies have found out, not all NoSQL solutions are created equal, and the solution selected in the company’s early years may not be appropriate as the company grows and it’s needs change.

For example, as the organization matures, parts of the organization will start asking for reports, they may find that while their NoSQL solution worked well as an OLTP solution, it doesn’t work as well for OLAP or Data Warehousing needs. Or, a NoSQL solution that worked well for warehousing data, doesn’t work as well when you give your customers the ability to query it on-line, in an OLTP-like fashion.

This can occur when the CTO isn’t able to help guide the company’s technology forward fast enough to keep pace with the changing organizational needs. Unfortunately, if the problem reaches the “critical” stage because, for example, the organization can’t get reports, the solution may become a politically charged hack job instead of a well-planned solution.

Every organization – engineering, database administration, operations, etc, will want to “solve” the problem as quickly as possible – so while the end solution may solve the immediate problem, it probably won’t be the one you’d choose if you’d planned ahead.

The solution here is for the CTO to continuously engage with the Company to understand and anticipate its upcoming technology needs, and engage with Engineering organizations to plan for them. It’s actually better for the CTO to arrange to engage the stakeholders and engineering organizations together rather than serially: it encourages the stakeholders to work together instead of through the CTO.

Making sure Technology keeps pace with Security requirements

Today’s engineers have an amazing community of Open Source Developers and Tools to draw on to get their work done.

And when a company is growing, tools like NPM, grunt, brew, and Hadoop are amazing tools. In many cases, they enabled development to move exponentially more quickly than they could have otherwise.

Unfortunately, many of these tools are gigantic security risks.  When an engineer types “grunt install” (a node-related command), or “brew update”, do they really know exactly it is doing? Do they know where it’s getting the update? Do they know if the updates can be trusted?

They don’t. Let’s not even going to go into the horrors they’re inadvertently inviting behind your firewall.

The problem for the CTO is that they probably had a hand in introducing these tools and behaviors to the organization, and will now be faced with reining them in. “Fixing” them will probably make them harder for engineers to use, and feel like a hassle instead of a common-sense security measure.

The CTO can expect the same situation when charged with guiding the organization towards things like always-on HTTPS, better encryption-in-place of customer data, etc. Not only will they have to convince their engineering organizations it’s important, they may also have to convince the rest of the organization that these measures deserve a place in line along with other product features.

One solution to this is a backward-looking one: Security should be part of the product and company’s culture from Day 1.  Not just protecting the company’s assets from unauthorized access, but protecting the customer’s assets (data) just as vigilantly. A culture like that would recognize the two examples above and have either solved them, or be willing to solve them quickly and without easily without politics getting in the way.

If the CTO’s organization wasn’t built that way, their job becomes much harder, since they now need to change the company’s culture. Fortunately, recent events like the Sony hack and Snowden’s revelations make this much easier than it was 2 years, or even a year ago.


The effective CTO faces at least two challenges: Becoming a effective part of the company’s executive team (not an “outside advisor”), and an effective part of the company’s technology and product teams. The CTO can’t forget that their job is to continue to keep the company on the appropriate forefront changing technology – far enough ahead to keep pace, but not so far ahead as to be “bleeding edge”. Almost universally the way to do that is to make technological change part of the company’s culture – not a special or one-off event.

–Michael Wilson

Comments Off on Guest Post – Effective CTOs

Just for Fun – The Many Meanings of “I Don’t Disagree”

OK.  Who was the knucklehead who thought up the ridiculous corporatism of “I don’t disagree”?

Seriously.  What does this mouth turd even mean?

Does it mean that you simply don’t want to commit to a position?  Do you need more time to determine a position?  Is your ego too large to admit that someone else is right?  Do you really disagree but are too spineless to say it?  Were you not listening and needed to spout some statement to save face?

We owe it to each other to speak clearly, to engage in meaningful dialogue about important topics, and to convey our thoughts and positions.  When political correctness overrides fiduciary responsibility, we destroy stakeholder value.  Get rid of this piece of mouth trash from your repertoire.

Comments Off on Just for Fun – The Many Meanings of “I Don’t Disagree”

DevOps – Not Good Enough

DevOps is a grassroots movement born from the passions of practitioners dissatisfied with the cultural and functional deficiencies endemic to functionally oriented (aka silo’d) organizations. The tools these practitioners employed and developed including Chef, Vagrant, Juju, Hudson and Logstash (to name a few) codified their collective feelings of how development and operations could work better together. These pioneers in effect duct taped together the development and operations teams – covering a chasm characterized by differences in culture, goals, leadership, philosophies, and toolsets. This technological equivalent of a “redneck” fix has been successful, but it is also time to see it for what it really is: the treatment for a symptom of the underlying outdated organizational concepts. For all that DevOps provides it cannot treat the many other symptoms of suboptimal organization construction. These include low levels of innovation, higher than necessary levels of conflict, and slower than necessary time-to-market. Why continue to duct tape together a poorly designed system? It’s time to replace the broken system and its temporary repair with one that works.


A functionally aligned technology group is a biped with a foot planted in two disjointed pasts, neither of which have a future in modern online products. One “foot” is planted in the world of corporate IT, where hosting platforms and enterprise architectures were defined to allow heterogeneous third party systems to coexist in a single, cost effective and easy to manage environment. Because IT is typically considered a cost center, the primary driver year-on-year is to reduce cost on a per employee basis. One way to do this is to standardize on infrastructure and require that third party providers conform to corporate standards – shifting the burden of cost of integration to those third party providers. Hence was born the traditional infrastructure and operations groups found within today’s technology organizations. These organizations and their solutions are awesome if you are integrating third party solutions – they are the last nail on your coffin if you are developing a product.


The other “foot” is planted in the past of packaged or “on-premise” software providers. In this past (heavy emphasis on the past), the software developer was king. Job one was to produce software that customers would buy. Forget about running it – who cares – that’s someone else’s job. In this past there was no infrastructure team. We just eat requirements and poop software. Sales engineers and systems integrators are responsible for figuring out how to shoe horn generic software into a wide variety of customer environments. As archaic and dysfunctional as this approach sounds, it actually worked because there was alignment between what the producing company created (software) and what the purchasing company bought (software). But it doesn’t work anymore because no one buys software. Get over it.


Today customers buy SERVICES not software. The mindset shift necessary to be successful in this new world is that the raw materials comprising these services are equal parts software and hardware (infrastructure). If your team doesn’t combine these raw materials purposefully, the resulting service won’t be as good as it should be. Continuing to “produce” software and “host it” on infrastructure is a recipe for suboptimal results at best and a possibly a disaster.


It’s time to move on from both functional organizations (e.g. Operations, Infrastructure, Software, QA) and the DevOps solution that duct tapes them together to organizations that can more easily design, implement and deploy these services. Organize your teams into cross-functional, experientially diverse, autonomous teams that own distinct services within your product. Each team and service should be driven by business focused KPIs. These teams should be self-sufficient enough to develop, deploy, and support their service without having to rely on other teams.


We understand this leap isn’t easy, and we are here to help. To be successful you must evolve both your architecture and your organization such that the two are compatible. In so doing, our clients experience higher levels of innovation, faster time-to-market, and lower levels of conflict than those that adopt a DevOps only duct tape solution. We call this approach to organizing the “Agile Organization”.  To help our clients evolve to experientially diverse teams, we often introduce as a starting point a concept that we call “GrowthOps”.  GrowthOps differs from the traditional DevOps approach in that it starts with an understanding of the desired outcomes of a product in terms of business KPIs (key drivers of growth for instance).  Rather than trying to duct-tape organizations together, we start by aligning disparate organizational objectives and focusing on customer value creation.  We then add in all of the tools necessary to speed time to market and monitor core KPIs.  This unique approach establishes a firm foundation for a company to grow – be that growing from on-premise to SaaS, growing from collocation centers into the cloud, or growing because of customer demand – and allows for an easier subsequent transition to the Agile Organization.


We love duct tape as much as the next person but it’s time organizations stopped using these types of solutions and get to the real root-cause of the friction between development and operations. Only by embracing the true root causes and fixing the organizational issues can teams get out of their own way and grow effectively.  Implementing GrowthOps as a first step and ultimately transitioning to the Agile Organization is a proven recipe for success.


Comments Off on DevOps – Not Good Enough

5 Product Team Must Dos – the New (Old) Approach to Product

Want to create great products?  The path to success in this endeavor has more to do about how you think about value creation, think about your customers and organize your team than it does having brilliant ideas.  And here’s the kicker – while many of us think some of these concepts are brand new (including the founders of AKF who contributed to the primary research on the topic), the fact is that great companies have known these secrets for quite some time.  Here are 5 “Must Dos” for product teams to create great products:

1) Focus on customer value creation first!

In Peter Drucker’s “The Practice of Management” (1954) he wrote that “There is only one valid definition of a business purpose:  to create a customer.”  In later works he expanded on that notion by saying businesses must create AND keep customers and that profit was a necessity to stay in business, but not the sole purpose of a business.

Profit and shareholder value maximization are of course important to businesses.  Without profits, you can’t stay in business long.  Without creating shareholder value, you will be locked out of equity markets.  But by and large these are dependent variables outside of a firm’s control.  While we can control costs directly to effect profits, doing so may constrain our future growth.

If we instead focus on delighting the customer with the products we create, we can create internal and external enthusiasm for the product.  In doing so we grow revenues (part of profits) and excitement within the company.


2) Eliminate the “IT Mindset” and develop as a Product team

In the first edition of The Art of Scalability (2009), we cautioned teams away from the “IT Mindset”.  The IT Mindset is cost and efficiency focused versus the Product Mindset which is customer, market, product and revenue focused (in that order).  The IT Mindset envisions product development as a manufacturing plant, rather than the creative and innovative process it must be to be successful.  The IT Mindset has a purpose – to serve the needs of employee efficiencies – but should come with a “Do Not Use with Products” warning label.  This IT Mindset stifles innovation and kills product team morale.  Marty Cagan, one of the greatest product minds and consultants alive, and a longtime colleague and business partner, has more to say about this debilitating phenomenon here.


 3) Organize around the objective – not functions.

While performing academic research on why some teams in the same industry seem to have higher levels of innovation than others, we stumbled upon some interesting veins of tangential research.  All of them pointed to multi-disciplinary teams comprised of all the skills necessary to complete an objective and organizing around outcomes having higher levels of innovation and success than teams organized around functional boundaries (e.g. product management, software engineering, QA, operations, infrastructure, etc).  While we contributed to this research, we found out we weren’t the first to identify this phenomenon!  In fact, this Harvard Business Review article (1986) hints at the same philosophy.


4) Don’t listen to what customers WANT – watch them and identify what they NEED

We’ve all heard Jobs’ famous saying that customers don’t know what they want until you show them.  Developing a customer “want” is costly and can greatly miss the greater market opportunity.  As we point out in this post, product teams need to focus on the hypothesis for a market need, start small (MVP) and iterate their way to success to maximize the potential of a product to meet the true need.


5) Eliminate the concept of insular innovation

Forget the concept of a single great innovator running a company and generating great product idea after great product idea.  That concept is a myth perpetuated by marketing teams and egotistical executives.  The existing research on this topic is clear:  The teams with the highest levels of innovation source innovation from a diverse network of individuals inside and outside the company.  See slide 10 on network diversity in our scalable organizations presentation.  But don’t just take our word on it, Walter Isaacson comes to the same conclusion in his NY Times Bestseller “The Innovators”.  And yes, he debunks the notion that Jobs was the sole reason for Apple’s product success as well.

Comments Off on 5 Product Team Must Dos – the New (Old) Approach to Product

The Difference between “Want” and “Need”

We often hear Steve Jobs or Henry Ford quoted as reasons why companies should not listen to their customers.   People love to throw “Customers don’t know what they want until you show it to them” (Jobs) and “If I had asked people what they wanted, they would have said a faster horse” (Ford) as reasons why innovation should be a company run, insular, closed to the public process where a handful of smart employees define the future.

The problem with using these statements to defend insular, introverted innovation is two-fold.  First, such a position misunderstands both the context within which these statements were made and subsequently the point both innovators were attempting to make.  Second and most importantly, the position of supporting insular innovation simply isn’t supported and in fact is refuted by the extant research on the drivers of innovation.  The companies with the highest levels of innovation are and always have been outwardly focused and intent upon learning how customers interact with their products (see The Power of Customer Misbehavior and our research on innovation and scalable organizations).

Let’s tackle the misunderstanding of these statements first.  Both Jobs and Ford are identifying the difference between what customers want and what a given market needs.  Their point is that what a customer says they want is seldom what a market (a large group of customers) truly need – or at the very least that what customers want won’t be as good as identifying and meeting their true need. Specifying and fully developing a want is misguided by an untested hypotheses associating the to-be product with a desired outcome.  Because the specification isn’t guided and course-corrected by iterative testing against a market environment, the longer the program of development runs (and the larger the product), the more likely it is that the product will miss the maximum opportunity.  Waterfall development, while appropriate in some areas (such as negotiated contracts without room for testing against a real need), is all about developing a want codified within a product specification.

The alternative approach is to start with a necessary outcome (e.g. first digital encapsulated music player without removable mass storage media, or better transportation) and a hypothesis as to how to get there (hard drive for mass storage and software for transferal, 8 HP 2 speed engine and transmission with 2 or 4 seats).  In these cases, neither product took a long time to build (especially for “hardware”).  Instead, the companies looked to bring a product to market quickly and learn from it.  To show how quickly the teams were iterating and fixing the mistakes in their initial products, Apple released a new generation of their iPod or a new model every year for at least six straight years and corrected such initial deficiencies as not supporting Windows for the iTunes OS and not having a solution for digital music downloads (the iTunes store).  Ford produced 4 new car models (the Model AC, Model C, Model B and Model F) within the 4 years after initial Model A launch in 1903.  These vehicles addressed the engine being underpowered, overheating, weight limitations, etc.

The point here is that great product teams understand that the greatest value is derived from achieving the outcomes associated with a need, not the specifications of a want.  Needs are met by defining a measurable outcome, building a testable hypotheses (minimum viable product or MVP) as to what will partially fulfill that outcome and then iteratively and rapidly correcting the hypotheses (MVP) to achieve the desired results.

1 comment

How and Why the ALS Ice Bucket Challenge Works

Fish recently wrote about the ALS Ice Bucket Challenge, explaining the mathematical constructs behind viral growth.  If you read the article, you may have pondered how something like the Ice Bucket Challenge goes viral.  Ponder no more!  This article briefly explains our research into the drivers of viral growth.  For a deeper explanation, pick up a copy of our recently published book The Power of Customer Misbehavior.

First and foremost, for anything to go “viral”, it must be both be easy to use and useful to the user.  The ease with which one can use a cell phone to take and post video nearly anywhere fulfills the ease of use requirement.   Usefulness is also clearly fulfilled as a requirement as most people participating in the challenge see the value in contributing to a cause as worthy as ALS (commonly referred to as Lou Gehrig’s Disease).

These two requirements (ease of use and usefulness), while necessary, aren’t sufficient to trigger viral growth.  Think of all the things in your life that are both useful and easy to use but that have not gone “viral” or “exploded” in their adoption within some confined time period.  These may range from anything from the type of soap that you use to a brand of underwear that you wear.   Another example may be a particular type of tool that you like to use around the house.  Maybe it is a type of light bulb of which you are particularly fond, a skin care product that you use or a brand of toothbrush you commonly purchase.  Why don’t these things, which are incredibly useful and easy to use explode in their usage overnight?  There are lots of common answers, including commoditization of these particular products, price, etc.  But these answers alone don’t have statistically strong explanatory powers.

One reason we uncovered from our research is that these products don’t allow people to interact with them and co-create or co-produce value.  Co-creation is the commonly defined as an act of creating value through content contribution and co-production is the act of using a product in new and unforeseen ways.  The Ice Bucket challenge does both of these.  Individuals co-create by producing new content videos of them getting soaked (see Bill Gates or George W as examples).  As importantly, users can modify and extend the format (co-production) by changing the challenge in new and innovative ways.  Charlie Sheen is a perfect example of a move of co-production (note the tag line – “big twist” in the article).

Knowing that usefulness, ease of use, the ability to co-create and co-produce are key to viral growth is indeed useful.  But these examples may leave you wondering why one would co-create or co-produce in the first place?  We use the example of Harley Davidson in the Power of Customer Misbehavior to explain exactly this question.  Why do people purchase and then modify (co-produce and co-create) Harleys?  These beautiful rides certainly aren’t cheap!

The answer to this question is that people modify Harleys (think of the origination of the “chopper”) because of what it says about them.  “I’m a free spirit” or “I’m a rebel” or “I’m a badass biker dude who also happens to be an accountant”.  The act of creating something with their “hogs” says something unique about them while simultaneously helping them to identify with another group of people.  The same is true for why we might wear NFL football jerseys or collegiate “hoodies”.  These things are all part of our identity.  Participating in the Ice Bucket Challenge identifies us with our friends, family and others who are of a similar philanthropic mind.  We get to show to others that we care and in so doing affiliate ourselves with others who care.

The model below, from The Power of Customer Misbehavior, shows these relationships.  Briefly, the ALS Challenge works because it is useful (gives to a good cause), is easy to use (take a video and post), allows us to co-create and co-produce (add valuable content and modify/extend the content) and says something about us to others (identity).

POCM Model












If you enjoyed this article, please pick up a copy of the Power of Customer Misbehavior.  And please give to ALS.  It is a cause near and dear to our firm’s heart as historically military veterans represent a statistically disproportionately large share of people afflicted with this terrible disease.

Comments Off on How and Why the ALS Ice Bucket Challenge Works

Conflict and Innovation

Executives often complain to us about the level of conflict within their teams, or the abilities of their teams to resolve conflict.  Often, in the same session, they will wonder as to why they don’t achieve greater levels of innovation in their products.  Sometimes we hear things like “My team is too conflict avoidant – they won’t resolve their issues”, or “I simply don’t get why product and engineering won’t get along”, or “My engineers (or finance team, or team XYZ) simply won’t listen to the rest of the business teams”.  With respect to innovation, quotes range from “Why aren’t we more innovative” to “It seems like I’m the only one with ideas around here!”  Well guess what?  It’s YOUR FAULT!

The simple truth is that what we do and just as importantly, do not do as executive teams sets the stage for the creation and escalation of conflict and maximization or minimization of innovation within our teams.  Before I get into some of the drivers and results of both conflict and innovation, let me first spend some time trying to define some terms and clear up some fallacies surrounding the term “conflict”.

2 Types of Conflict

Psychologists and sociologists, especially those who study conflict, conflict resolution and innovation, recognize the following:

1)      Affective Conflict (sometimes termed Role Based) is “bad conflict”.  Affective conflict typically involves “who” should be responsible for doing something or “how” something should be done.  Any way you cut it, our jobs as leaders are to try to minimize this type of conflict and set up systems to reduce the probability that it happens.  Affective conflict is never good.

2)      Cognitive Conflict is “good conflict”.  This type of conflict deals with “what” should be done and “why” something should be done.  When handled properly, it helps increase strategic possibilities, open up new doors for innovation and drives teams to better answers.  When left unhandled by leaders, it will often escalate into affective conflict and be detrimental to overall performance.

I will just call these terms “bad conflict” and “good conflict”.

Outcomes (or consequences) of Conflict

Here we see why affective conflict is “bad” and cognitive conflict is “good”.

1)      High levels of bad conflict are highly correlated with lower morale, high rates of employee turnover within teams, slower time to market, lower levels of financial/business performance, and lower levels of perceived performance within teams.  Bad conflict minimizes and very often can completely eliminate innovation within a team.

2)      High levels of properly handled good conflict are highly correlated with higher morale, higher employee retention, higher levels of innovation, happier teams, faster time to market and higher levels of financial and business performance.

Put simply, you want lots of quickly resolved and properly facilitated good (“what and why”) conflict and very little bad (“who and how”) conflict.

Drivers of Bad Conflict

Research indicates that there are many drivers of “bad” conflict.  Here are some of the most frequent drivers:

1)      Team Alignment:  Without getting into the theoretical specifics, teams find themselves in conflict along team boundaries that are defined by organization structure and the resulting individual identities.  If you have an “engineering team” and a “product team” on your organization charts, the employees will identify with one or the other and sometimes conflict along those boundaries.

2)      Employee Tenure:  Research shows that employees also identify themselves along tenure boundaries.  These may be the “old guard” and the “new employees” or the “founding team” and the “new team”, etc.  While not codified within an org chart, this stratification of employee identities can lead just as much to conflict creation as an actual organization.

3)      Leadership Approach:  Engaging in quid-pro-quo management (“Do this for me, and I’ll do that for you”) is highly correlated with conflict creation.  Individuals think of themselves, rather than a team.

4)      Loosely Defined Responsibilities:  Chaos breeds conflict.  When people don’t understand the boundaries and expectations, they attempt to expand or define each for themselves which in turn increases strife.

Out with the Bad and In with the Good

Bad conflict is inversely correlated with good conflict.  The more bad conflict you have, the less good conflict you have.  Good conflict on the other hand correlates directly with innovation.  The higher the good conflict, the higher the level of innovation.  The fix to ending bad and promoting the good is to address each of the areas above.

1)      Team Alignment:  Create cross functional teams aligned around product or service initiatives – not functions or experiences.  Each team should have all the experience across all domains that it needs to be successful.

2)      Employee Tenure:  Eliminate old and new employees who cling to tenure based identities.  Ensure everyone understands there is one, and only one company identity (though there may be product identities within the company – but each of these has everything they need to be successful).

3)      Leadership Approach:  End quid pro quo leadership and talk about higher purposes and team accomplishments.  Make the job about something other than just the individual.  Eliminate people who are “in it for themselves” and won’t contribute to the higher cause.

4)      Loosely Defined Responsibilities:  A leader has many responsibilities and one of them is to eliminate uncertainty where possible.  Help people quickly resolve conflict with roles.  Don’t let employees come into conflict or stay in conflict about competing roles and responsibilities.