Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Why Big Companies Keep Failing: The Stack Fallacy (techcrunch.com)
408 points by walterclifford on Jan 18, 2016 | hide | past | favorite | 169 comments


From my experience the same (often random) reason that makes a company succeeds, then becomes their DNA, and finally can make them fail.

I saw this happen with Skype where I worked a couple of years. The company succeeded because of P2P: we grew with little infrastructure to reach 200M+ people. P2P became our DNA, rooted deep within (almost) every core component.

Then came the new wave of mobile messaging apps. We reacted... with a P2P messaging solution. It was obvious this wasn't working - you sent a message to someone from Skype for iPhone, and they got it... sometime.

We knew to have a chance against Whatsapp and other messaging apps we needed server based messaging, so we built it.

It took 3 years. Yes, it took this long to get rid of the P2P code from just the messaging components from the 20+ Skype products - we had 1,000+ engineers and 50+ internal teams by the end which significantly slowed things down. When we were done and popped the champagne - no one really cared.

And yes, the source code is still full of P2P references and workarounds to this date.


Not to mention, in the process they more or less broke the core functionality of Skype: video and audio conferencing. Skype is so bad it's difficult to believe it's not some sort of a practical joke.


I use Skype all the time. Occasionally it would work badly, which would cause to try something else (Hangouts, the apple facechat thing, facebook, some generic flavour of WebRTC). That something else would work much worse than skype under those network conditions.

I haven't experienced anything better, even if Skype obviously could be even better. With 300 mbit connections you would think we'd have somethin better.


Sococo had a product that worked much better than Skype! It was favored by enterprise organizations, so not a lot of coverage here.


I agree that Skype works pretty well, but it would be interesting to try and reproduce the network conditions you're describing.

I'm working with a "generic flavour of WebRTC" and they're still behind Skype and Hangouts, but they're getting better by leaps and bounds.


How do you mean? I've used Skype video calling at least a few times a week for the past ~5 years, and it's generally worked very well? Definitely well enough that it's never occurred to me to shop around.

(Skype IM is a joke, I agree)


The UI is an abomination, I have great difficulty doing anything. But as far video conferencing, in my experience the video and audio is grainy and brutal, you can call the very same person using Facetime and it is crystal clear. And when there is a temporary drop in bandwidth (I assume that is the cause), rather than dropping the high-bandwidth video resolution slightly, it seems to cut the low-bandwidth audio completely.


I'm not GP, but the few handful of times I've Skyped to other countries the experience has varied from kind-of-ok to horrible.

Maybe it's a location thing? I'm in Scandinavia..


I do Australia/UK regularly without problem. It seems to be very dependant on the participants network connections, not surprisingly. It doesn't seem to recover from temporary network issues fast enough.


>> "...Skype is so bad..."

Dude you should try Hipchat video conferencing, it makes Skype look like the future.


We used to have MSN messenger, microsoft killed it in favor of skype. Skype has been always awful for instant messaging. I don't remember I have ever used a skype client without some annoying bug.

Beside skype has terrible ui on Windows, current version has a bug causes wrong message ordering.

On android, I have experienced all those message delivery/notification bugs and it works slow.

I don't know how the experience is like in IOS and MacOs. Maybe I should all switch to Apple to have the best experience from a microsoft product?


Skype used to be great (this predates the MS switchover). They were the first major messaging network to get the multi-client use case right (i.e. sign in from your home desktop, your work desktop, and your phone at the same time - under skype this will just work).

Sadly the increasingly forced updates always made the UI/UX worse, the phone client was a resource hog, and they weren't quick enough with a user-friendly web client. Meanwhile Slack showed us all how it's done.

I'm genuinely trying to get my friends to switch to AIM - as far as I can tell that's the free option that comes closest to getting it right.


I'm going to have to strongly disagree that "slack showed us all how it's done." Trust me when I say, I am being forced to use Slack on a daily basis and I want nothing more for it to crash and burn.

Give me MSN Messenger and IRC again -- you know things that actually worked.


Slack on desktop is a resource hog. And connection hog.


If you can, give ScudCloud a look. While like the regular Slack desktop client, it's essentially a browser window, I've found that overall it works that bit better than the official client.


I believe you. But I have a surfeit of resources on my desktop. The slack mobile app performs well, which is where performance is important, and the desktop version is good enough.


>Skype used to be great (this predates the MS switchover).

It predates being bought by ebay too.


I believe Skype actually uses the former MSN Messenger servers and protocol behind the scenes for instant messaging now. Microsoft literally ripped Skype's IM support out and replaced it with MSN's.


Honestly, the Mac client had always been the best client for Skype and the Windows desktop by far and away the worst but as of Kate's bugs are creeping into both.


That's interesting. In our company the Mac users were always complaining about the app quality, while Windows users seemed to be rather happy, until all the ads came in at least.

No-one here uses Skype any more though. It's all Flowdock for messaging and Hangouts for conferencing.


The Mac clients not great but I really hate the Windows one and it feels inferior in just about every way.


Why was it hard to deliver messages to iphone using p2p? I mean I guess they couldn't open ports and listen for messages, but that should have been true for plenty of NATed systems too right?


The problem was the avalibity when the sender was offline. You send a message from your iPhone to your friend who has an Android. Your friend doesn't have reception, and after sending the message you kill Skype b/c of the battery drain (otherwise it is being part of the p2p network).

Your friend now gets reception and will get your message... between a minute and a couple of hours. Most likely when you turn your phone back on, as the p2p network was not designed to store and propagate offline messages.

Meanwhile someone at Whatsapp built a key value pair on a server and if you had reception, you got the messages immediately and reliably. Oh, yeah, because the read and unread message states in Skype also propagated via the p2p network and also got took a while to arrive...


I'm really surprised that Skype didn't just build a separate system for mobile. It seems even a simple evaluation of the facts (needing hundreds of engineers to alter an already stable product) pushes things more to the server side than the P2P side.


hindsight is 20/20. It would be quite easy for a team of developers and product managers to get together to discuss "how we take what we have and extend it to cover the new use case" rather than "what is the best approach for the new use case".


But even before reuse, the "DNA" point can't be overlooked, though. Success breeds a belief that "our differentiators" need to be considered and baked into subsequent products. More often than not, those constraints lead to situations where you're fitting a square peg into a round hole, as with Skype and P2P messaging.

What saves some companies from this is a core DNA that can be interpreted in a very liberal and malleable fashion. For instance, Amazon is about distribution--be it products, bits, computing power. Facebook is about social connection (not P2P or a particular narrowing of tech). Of course, maybe that's just survivorship bias...no one keeps a good directory of the graveyard of corporate DNA that was as similarly broad.

Now whether that is a function of articulating flexible DNA, or the flexibility of the decision makers...I don't know. Either way, fixed mindsets close down adaptivity to new opportunities.


We did acquire GroupMe with the same thinking: take that startup with a good group messaging product and integrate them into Skype.

Except this never happened, GroupMe is still a standalone app and pretty much a standalone team. I am not sure why we didn't or could't integrate them, the Microsoft aquisition of Skype, and the subsequent integrating with Lync (and the birth of Skype for Business) probably had higher priority.


Reusable components is a mantra within software engineering. People deciding on product direction want to reuse what's available and has been tested: known quantities increase confidence levels. Unfortunately, the reuse in the large vs. reuse in the small dilemma gets lost in the decision-making. At a certain job level, applications become components represented by geometric shapes on a whiteboard or electronic diagram. At that level, components look like good candidates for reuse.

Unfortunately "the devil is in the details". Reuse, in this case, hurt the messaging app because of a fundamental difference between connection and connection-less communication. I'm sure the engineers working on the messaging app understood the problems. But, they were most likely not a key part of the decision chain.


This whole Skype/P2P thread makes me feel very pleased and very optimistic about what we have built already and are building for release relatively soon.

You can do P2P on mobile and you can even do P2P with central server fallback without sacrificing reusable components and with standard network protocols. You just have to do the hard work at the lowest layers first and you have to think about the problem from an SDN perspective instead of an app-centric-P2P perspective.

(Intentionally cryptic response, yes. Grin.)


Guessing it was because both phones need to have the app open at the same time. Skype's main p2p tech was built for the real-time synchronous chat use-case (like AIM), as opposed to the chat-log in the cloud use-case (like Slack).


Exactly. In hindsight we should have just built a separate messaging layer with a server backend like everyone else was doing.

However Skype had no history of running servers. Just keeping the login servers up and running (a handful of them) was enough of a challenge.

Plus when the company's success and revenue was driven by the P2P team and they said the same layer will work for messages... there was no one strong enough to argue.

And when it was obvious that Skype messaging was sub par, the company just went in denial. "We aren't really competing with Whatsapp, because they don't do video" got us another year or two of not doing too much about the root cause.

It was after the Microsoft aquisition when some MS architects told the engineers upfront that p2p and realtime messaging - forget about it.


I hope everyone within Skype used it as your main communication tool. If you did, the problem would have been so obvious. Not so long ago, it was revolutionary to be able to send messages to someone even when they were offline. However, once someone implements it every other chat app had very little time to do that. IMHO, there is nothing inherent about big companies from reacting quickly. It usually boils down to the culture of the company that's the cause. Call it "Bias for action" or "Ask forgiveness, not permission" or whatever you want to call it - a company (big or small) that allows people to go quickly fix an issue or try another solution instead of talking endlessly about it, well aware that there is a chance for failure, is the one that's likely to succeed.


Of course we used it as our main communication tool. With each other and within the company.

The problem? We had it running 24/7 on work laptops and phones so the messaging issue was less obvious. The typical user started Skype on their desktop, and killed it after a video call. They also killed it from running in the background on their phone because it killed the battery. We just keep charging the phone.

And as we saw issues come up with Skype for our usage patterns, we did focus on those. Did you know that originally the limit of a group size was 300, a random constraint someone added in, and got hardcoded in all the apps? That size was basically chosen because we were pretty sure the largest company Skype group would not grow beyond it. Well, it did a couple years in and we spent more time and effort trying to solve this then a lot of the other stuff. I mean people could not get in to the Tallin office social chat channel and were missing the gossip!

Eating your own dogfood is a good thing - but it also leads to overusing your product and being less critical with it over time.

Also, on top of this the fact that our user base kept growing despite these flaws did give us a false sense of security.


>"They also killed it from running in the background on their phone because it killed the battery."

This probably compounded the issue. If the battery-drain never presented itself, users would have been more likely to not turn the application off.


Not really. Two more reasons to kill Skype immediately after use:

- Network drain - just how much data an app uses is nonobvious for most people, especially that it changes over time.

- System resources drain - low-to-mid-end Android phones are usually pretty underpowered; they can barely lift their OS. Any application running in the background makes using other applications more frustrating. Hence the popularity of auto-killers on Android.


What is the fix here that does not involve intermediate servers? The xmpp client conversations asks you to opt out the app from aggressive battery optimization in Android Lollipop. I tried saying no and killing the app. Messages took over two minutes to arrive while I was using the device (not the app). I don't think there is an easy fix. This is why Google Cloud Messaging makes sense but the problem is that now Android is coupled with Google services. :(


> Not so long ago, it was revolutionary to be able to send messages to someone even when they were offline.

How long ago was that exactly? From what I remember, ICQ had offline messaging around 1997.


I was one of the first 100k ICQ users. I was working on a similar idea at the time and so tried every chat client that I came across. I was really impressed with ICQ and somehow tracked down the phone number of one of the developers. I called him. He was an Israeli living with his sister in NYC. I think there were three other people involved, all developers. We chatted for a bit about the software and I remember telling him I was impressed.

Any, several couple months later they sold to AOL for something like $250 million. I was living in Chicago at the time and coincidentally the Hancock building had just sold for ~$280 million. I remember thinking that four guys had created as much value in a year as thousands of construction workers and real estate managers had created in three decades.


I actually talked to one of the developers recently thanks to an university course (Economics of Innovation).

Their story is very interesting :) , the founders were Arik Vardi, Yair Goldfinger, Sefi Vigiser and Amnon Amir.

We talked to Yair, from what he told us, they were using dial-up at the time, and they had to disconnect or use another phone line to know whether the others were online, and so they discovered a need for a tool to find if somebody was online, and enable communication between connected users.

They weren't very finance-savvy, fortunately for them one of their parents was, and he handled all the fundraising and stuff.


We used to have this technology called email which seemed pretty cool. You could even embed photos of your cat.


Did they ever fix the spammer problem on it?


Yes.


It's not realtime, though. You send your message and the other person gets it... in a few minutes.


Did the implementation depend on one or more intermediate servers always being online? If so, it isn't revolutionary.

All our email clients do is send it to our email servers. Try sending email out of your own machine. I doubt 10% would reach the destination inbox. The general assumption today is you don't run your own mail server. :(


It did. I remember wondering why all the "successors" didn't have that "basic" feature


I'm not sure if this story has been told this plainly elsewhere, but it probably should. I know plenty of people who got very paranoid of Skype after MS bought them.


I think the denial is the important lession here.

Plenty of people knew it didn't fly, and it couldn't have been that hard to fix it if you really wanted to do it, if you were prepared to drop p2p. But still it was a hard descision to make.

Why do you think it's like that?


I think it was denial that messaging itself would be more inportant then video calling.

Skype got massive because of video (and audio) calls. That was our main differentiator, and what helped us grow. P2P really excelled there.

Messaging was built as almost an afterthought and supporting feature, piggybacking on whatever infrastructure we already had in place.

And of course it didn't help that there was no one person or team in charge of the user experience who would call out that we have far inferior messaging experience then... any of our competitors, really.

Even when we did - and aquired GroupMe to do something about it - we then still had the false sense of security and not needing to hurry, because user numbers were still growing upwards. And when they slowed down, it was too late.


Thanks for sharing. I can definetly see how that happens.


We used Skype IM for a long time (inertia). It wasn't just the iPhone. Skype message delivery was erratic on all platforms. It got better, but even now there are occasional delivery delays when I chat with someone who hasn't switched over (we use Slack now).


Yes, there are still traces of the p2p code. Most of messaging has been migrated to server based back ends, but there are still some hybrid solutions in place.

Funny thing the company DNA, P2P is still haunting Skype.


The windows client still has funny bugs like:

1. You receive a message from someone.

(wait a few hours)

2. You open this tab/read the message

3. The number of unread messages counter doesn't update.


At least the windows client does something.

The linux client... well, for the longest time you could be lucky if it would even work. After years of not updating the bundled libraries, they stopped interfacing well with the ones in the system.

And then there was an update, which changed nothing, except for introducing ads on linux and disabling video chat for most cases.

The issue of skype might not be P2P, it sounds more like it was a lack of ability to provide a stable product of any kind. The Android app was also the worst app I had seen for many years. Who the hell seriously builds their own UI toolkit, and then makes it work worse than the one bundled with the OS?


I have to disagree .. I used the Linux client extensively between 2008 and 2013 and it was just fine. There was an issue that caused it to hang and use 100% of it's assigned CPU from time to time but I was able to write a little watchdog script for that (: Could be it fell apart more recently than that but I think that could have been said of Skype in general ...


That's been happening to me a lot lately. I've noticed that I have to right-click the conversation and click "Mark as read". Very annoying.


Your is a perfect example of the original posting and the comment you are replying to. People have such a hard time acknowledging what they don't know.


In hindsight it was a really bizarre decision to deliver tiny time critical messages via p2p in the first place. I guess because it "made sense" because you had no scalable server infrastructure in the early years, and because the main thing was voice anyway...


"Having got on well by adopting a certain line of conduct, it is impossible to persuade men that they can get on well by acting otherwise. It thus comes about that a man's fortune changes, when his circumstances change but he does not." Niccolò Machiavelli


Going off the tangent a bit but: did the original article actually talk about WhatsApp in the context of "going up/going down the stack"? Or, did it just appear in one of the subtitles?


The solution to stack fallacy is simple but really counter-intuitive. All of the mentioned examples, I mean every single one, indicate a business trying to force its way into the higher level through business channels. For example, when a business wants into a higher level they make it a business priority to create a new product and attempt to drive the priorities of this next level product through their business objectives. That is an epic fail.

It is important to instead concede that you don't know the needs of the consumers in the higher level, and if you think you do it is because you are guessing. The only way avoid the problem is to not attempt to move into the higher level, at least not intentionally and not through business priorities.

This is extremely counter-intuitive because there are generally fewer expenses and greater market frequency at each higher level, which means superior revenue potential. Businesses exist to make money and to ignore moving up to the higher level means denying this potential (vast) revenue source.

This doesn't mean you can't move into the higher level of the stack and be really good at it. It just means you cannot do so both intentionally and as a business objective.

The solution is to double-down on where you already are with what you are already good at and focus on product quality of your existing products. Continue to improve where you are already good. Improvements and enhancements to existing products can gradually yield the next level as the improvements progressively open new potential in an evolutionary fashion. While getting to the next level this way is much slower it is also risk reduced and continues to associate your brand with quality and consume satisfaction.

This will only work, though, if the goal is improving the current product and not acquiring revenue in that desired higher level. Think evolution and not revolution. It has to be a gradual, almost accidental, increase of capability based on meeting current consumer needs.


This is exactly what I (writer of the article) wanted to communicate. I wish I had said it as clearly.

I agree with you on the problem with moving up.

Not so sure about the gradual move up. Another path is to acquire and let them lead. Another is to appreciate the nuance and hire great product people.

You need to find customer problems that you understand and can solve, not chase markets up the stack because they are bigger and "look easy".


I don't think this works in practice.

I cannot see Oracle slowly adding extra features to its database until it becomes an actual CRM system. A CRM is not just a solution to a different business problem but also a logically different layer from a development perspective. You would have to build it as a product that sits on top of the database product.

But as a CRM system it has no value to the end customer unless it has a certain minimum level of functionality. So although you can add features gradually and evolve your CRM offering you will not have a single customer until you have actually added enough features that make it actually usable. Nobody will buy your gradually evolving system until several years have passed and it works for some actual customers. In which case you have already spend alot of money and effort.


But as a CRM system it has no value to the end customer unless it has a certain minimum level of functionality

This sounds a familiar argument - roughly what you're saying is that an eye cannot evolve, it has to be intelligently designed? :|


eh? I make no comparison between developing a minimum viable CRM product and claiming irreducible complexity in biological systems.


I made the comparison with the kind of argument, because you made the same kind of argument.

Nobody will buy your gradually evolving system until several years have passed and it works for some actual customer

The parent was assuming people were already buying Oracle as a database (for example), and continuing buying Oracle as a database, and gradually getting CRM features coming with it.

So people will always be buying the gradually evolving system, and it will always/increasingly usefully be working for some actual customer.

But as a CRM system it has no value to the end customer unless it has a certain minimum level of functionality.

"There's a minimum crew requirement"

"What's the minimum crew requirement?"

"Oh, er, one, I suppose".

It has value as long as it has any value at all, there isn't a certain minimum level of functionality unless you assume either 'absent' or 'broken' is involved. By the time a single shipping useful feature rolls into a production release, it has value to anyone who wants that function. Or, potential value, at least. Like a proto-eye that has value as soon as it's a light/shadow sensitive cell.

It wouldn't make sense to release one basic function as a CRM product - which is why the parent is talking about 'evolving' an existing product up to a higher stack layer, not trying to release a new product at a higher stack layer all at once.

So although you can add features gradually and evolve your CRM offering you will not have a single customer until you have actually added enough features that make it actually usable

Following the model where Oracle tries to build and launch a CRM product all at once, or Google try to build and launch a social network all at once - which is completely the opposite of the gradual improvement up to a higher level which the parent was suggesting. You're arguing "you can't gradually improve from where you are because that isn't releasing a finished product in one go", no it isn't, that's the point.


I don't buy the arguments in this article. For example, the whole part about why Google failed with Google+ is just wrong IMO. It wasn't that Google wasn't capable of building a good social network. If anything, I (and most people I know) preferred the design and interface of Google+. The problem was that Facebook already had a huge head start, and all your friends were already there. Facebook was "good enough", and there wasn't a big enough incentive to want to switch to Google+.

If anything, large companies often miss out on new trends and changes in business and technology, but it's not solely because building that one new layer "up the stack" is so technically hard or different.


Everyone you know thought Google+ was a better interface than Facebook? That seems quite a strong anecdotal statement, but I have a hard time accepting it at face value. Yes G+ had some nice aesthetics, mechanics, use of white space, etc, but conceptually and organizationally it was a mess.

To chalk it all up to network effects is to let them off the hook too easily, after all there is no reason you can't build other successful social networks concurrently with Facebook, you have your Twitters, Instagrams, Snapchats, etc.

The way I see G+ failing is because there was no soul or vision to the product, it was driven by a simple fear of Facebook, and it's implementation was a simple conglomeration of features that constituted a cool tech demo but was not shaped by real users or a real use case (Google does this often, see Wave, but at least in that case they were trying something novel). In short, G+ was not true to Google's DNA.

I think my view still supports your main point though—stacks simply are not the same for each company. Lower level stacks tend to be more similar, but at the top they are serving unique market segments, so they are simply not fungible.


> but conceptually and organizationally it was a mess.

Conceptually they had the core of a very good story, which was the idea I could have "Facebook where I segregated the people in my lives". It was even quite good timing, as it was mooted around the time people were starting to bubble up stories about "my boss started reading my Facebook and I got fired", "my family are upset by the politics my friends discuss" and so on.

The biggest problems with G+ from my perspective, around launch time, was other than Facebook's network effect, that the dribbling out of invites completely cut against the core success model for a social network, and the whole circles functionality ended up being one of those UI nightmares you get from Googlers who don't understand how normal humans actually work.


It may have been a nice story as viewed by some of us privacy-conscious people (I remember rooting really hard for it, and a couple of my most shy family members still use it), but it wasn't a viable strategy when trying to steal significant (>10%) market share from an incumbent, especially when the target audience was the general public.

G+ positioned itself against Facebook sort of like DuckDuckGo went against Google: we made the same product, but fixed X!!!, where X is some gripe about the incumbent's product that only a small percentage of the product's potential userbase cares about (privacy, in both of these cases).

That was (and is!) a fantastic strategy for DDG, for whom a fraction of a percent of all search traffic counts as massive, life-changing success. Google is not DDG, though. G+ would have needed a much larger share of the social networking market to be considered a win for Google, and the initial differentiation was not anywhere near clear enough to get there against a rival as strong as Facebook.

I also agree about the UI mess, and all that, of course, it was not a great product to use out of the gate.


> but conceptually and organizationally it was a mess.

Facebook annoyed many users each time a new update came. The privacy settings were constantly being reset. I do not believe facebook has a great UI to this day. Google+ is not great but it does not offend me the same way.


A product doesn't win in the market by not being offensive in some way, but by providing something people want. Google+ didn't commit many of the sins of Facebook, but it also didn't have a compelling use case other than "I hate facebook"

And I say that as someone that doesn't have Facebook account.


A tangent.

> The privacy settings were constantly being reset.

True. What privacy-minded Facebook critics often miss is that privacy settings seem to have been constantly reset towards "more private" mode. Hell, at this point Facebook is starting to get really annoying with those recurring reminders about visibility of my post. I post all-public because I like it that way, I hate the constant nagging about switching to more private mode.


Before a few years ago they were being reset to less private.


Yeah, head starts can be overcome. Especially with each generation. I thought MySpace was horrible but also unbeatable because of its reach.


One: Google+ was a terrible interface, in that it tried to force a "programmers" thought pattern on the user. Circles? OOP in disguise. It looked enough like Facebook that the different, and far more complex, behaviours were confusing to people. Switching would be painful. You may have liked it but most people did not.

Two: G+ kept trying to hook into everything Google did. My Youtube account with all my embarrassing 80s playlists and WoW videos and cats and ... WTF? NO I DON'T WANT TO SHARE THAT. Pretty much every time I logged in I had to say "No I really don't want to do that" until they finally snuck it through at some point. Many people just weren't interested in establishing a network with somebody who didn't understand privacy at all and kept changing the rules for existing services. Coupled with previous missteps, I'm looking at you Buzz, this was a deal breaker for many. Facebook has a bad reputation but at least they are not trying to surface embarrassing info from other sources.

Three: Google+ was tech heavy from the start, which meant it tended to drift "professional" and be considered "for the geeks". Friends and family were already connected to me on FB, G+ tended to be old colleagues who weren't close enough to be connected on Facebook. I just don't have much to share with those people that I'm not already sharing on LinkedIn. For a social network, geeky early adopters is NOT a recipe for success.

Four: Google+ started making other services worse. Youtube comments were a disaster and seriously broke content creators ability to have a dialog with their audience. Google Reader was gutted and eventually shutdown. New services were artificially hooked into G+ for no real reason. Basically, G+ became the punching bag for problems in it's other products.


You're making some valid points, however I do not agree with some of them.

For me Facebook is only useful for my personal life. Should I want to post about some programming stuff? Doesn't belong on FB. The reason is because FB ends up being a disaster if you combine your friends and personal interests with your professional network. It just doesn't work as it doesn't give you the tools to separate the two. And yes, I ended up silencing or unfriending folks for that reason as well, as an alternative to deleting the account altogether. And I have no acquaintances that use FB for non-personal stuff, unless they sell social media bullshit of course.

You're talking about circles being complicated. Not sure what it has to do with OOP, though those circles do represent a taxonomy. And they are complicated, but at least Google attempted solving the problem. The problem being that at home I'm a totally different person. And when I follow people I don't know, I follow them only to get stories on certain topics of interest and I don't really care about their personal life.

You're saying that G+ was tech heavy. I disagree because that's currently Twitter and G+ would have won if that were true. I don't know the reason, but my guess is that it had to do with shitty things like the real name policy. Or in other words, having FB's creepy restrictions without the network effect.


> Should I want to post about some programming stuff? Doesn't belong on FB.

That was kind of my point #3. You already had Facebook for your friends so G+ became your network for your geek friends and geek co-workers. If you're not a geek, you were already using LinkedIn for that purpose. That's a small market.

OO Programmers (and biologists) are the only people who naturally think in terms of complex taxonomy.

Agreed, their real name policy made it completely unattractive for many purposes, including Mashable trying to set up an account and needing to rename it to Pete Cashmore (if I remember right). But Twitter is not tech heavy, it's tech/startup/entrepreneur/media heavy, including tech but not strictly limited to it.


> Three: Google+ was tech heavy from the start, which meant it tended to drift "professional" and be considered "for the geeks". Friends and family were already connected to me on FB, G+ tended to be old colleagues who weren't close enough to be connected on Facebook. I just don't have much to share with those people that I'm not already sharing on LinkedIn. For a social network, geeky early adopters is NOT a recipe for success.

That, and during the brief window where G+ had the most hype and the best shot and getting mainstream, which also happened to be right when Facebook had just recently made some pretty egregious privacy fuckups and pissed everyone off... they very strictly limited who could get an account. I forget the exact timings but it was basically impossible for a typical prospective user to get G+ until around 6 months after they had actually rolled it out. What the fuck, guys?

Then when they finally opened up registration no one gave a shit anymore.

I guess maybe they were trying to mimic the thing with Facebook where you initially had to have a .edu email in order to get a Facebook account - but it's very debatable whether Facebook succeeded because of that or in spite of it.


I forgot about that! We were thinking of using it for a few things at work but then a few people in our office couldn't get in and ...


Google+ was a copy of Facebook, in that it didn't introduce really different new concepts or differentiators. I know, "What about circles?" Well, one big thing that people demand was privacy. That's why people built Diaspora & co and Snapchat. Google got Circles right, but one can't trust a social media which also owns your emails and Youtube comments, and they indeed screwed us with the Real Name Policy and the intrusion of G+ in all things Google.


There were plenty of people for me on Google+; nearly as many as on FB. But my FB friends' interests (for want of a better word) didn't pollute my YouTube recommendations, Google search results, etc. I mean Lord love 'em and all, but some of those people listen to and watch stuff that would make me long for deafness and blindness, have weird-ass hobbies I don't even want to think about, are heavily into alt-med, conspiracy crap, and UFOs, or are living in places that aren't even on the political spectrum anymore. The problem with G+ was that it was an all-inclusive package deal that touched all Google properties (except Gmail). I have an account because it's necessary to have one, but it's just a page in the middle of nowhere with no access, friendless, and looking forward to staying that way.


I think Facebook's huge head start was a big part of Google+ bombing, but I think there were other issues, too.

First of all, I think it really bothered a lot of people how they retroactively converted a bunch of pre-existing accounts into social networking accounts. Especially for things like Gmail, I don't think people had any idea they were signing up for a social network.

I also think tying together a dozen disparate sites and services under a single account login bothered people. Nobody really wants their search results, chats, video watching, picture sharing, and email all smashed together into a big social network. Especially not when it's unclear how those things are related and how clicking "Like" or "Share" on one site will show up on the others.

On the other hand, just being logged into Facebook doesn't implicitly log you into a dozen other sites and it's pretty clear that if I click a "Like" button, I'm liking it on Facebook.


Yeah, but for your Google+ example, isn't that another example of not understanding the customers' needs? In that case, Google failed to understand that the customers already had Facebook and were happy with it and that all their dumb friends were already on it so they didn't want to switch.

So maybe it's not customers' needs, as much as their wants, but close enough. The customers wanted Facebook (because of chicken-and-egg/first-mover advantage and also the good-enough factor), so a me-too competitor just didn't have much hope.

It was similar with Apple under Jobs: they knew what customers really liked and wanted, so they made tons of money even when there were technically superior alternatives to their products.


Except for a few niche markets, technology is never a product.

Many products - even corporate products - are chosen for their social signalling implications, not for rational reasons of performance, cost, or efficiency.

Remember "No ever got fired for buying IBM"?

G+ had the technology, but it had no ability to manage the social signalling.

Apple is all about social signalling. That's possibly its primary product. The hardware is just a signifier.

Facebook doesn't have social signalling - it is social signalling. Same with Twitter, and all the other social sites.

Google has never understood how this works. Even when it has a pin-sharp social marketing message represented by extremely attractive shiny people, somehow it never quite makes it stick for specific products in the way that other companies do.


> Apple is all about social signalling. That's possibly its primary product. The hardware is just a signifier.

It's so often repeated, but this is silly. Sure, Apple is fashionable, but that is hardly the only reason anyone buys their products. Apple products are good - or at least good enough for their customers - and that is why people like them.

Many programmers here on HN use MacBooks, for example. That's not just because it has a shiny apple silhouette on it.


>That's not just because it has a shiny apple silhouette on it.

Actually, in my experience, it's because that's what the company offers them to use at work, and most people just go with the default. I have been told many times "And you get a shiny new MacBook!" And I thank them and mention that I prefer to work on a Linux machine. It is almost comical how many blinking stares I have gotten. It fucking is about the shiny apple silhouette on it. It is 100% about image and not utility ("Sorry! I have work to do and I'm not allergic to the GPLv3!"). Especially because when you buy an Apple, you are paying so much for mediocre hardware at best. I have had better luck with late-model Thinkpads than I have had with MacBooks! They're not magical. Well, not magical beyond that shiny Apple silhouette.


So you don't like the MacBook therefore nobody could have any valid reason to like it?

Consider why these companies given employees MacBooks in the first place. (The answer is usually that Linux doesn't work well enough for them.)


No, the answer is that they don't have a lot of people that use Linux. You can't honestly tell me that Macs work better than Linux for most of the tasks a programmer or devops needs to do on a daily basis. I know it's true that they don't work as well as Linux machines because I have had to support both platforms over my twenty years in this industry. Here's a neat trick (and just one example): Set up LDAP authentication on a server and then try to get your MacBook's to work. Good luck!


> It wasn't that Google wasn't capable of building a good social network.

The the author doesn't dispute this. Building the site was "trivial," but determining what to build was the real challenge. And they failed at it, because they didn't understand the users' needs.

Users didn't need a "me-too" social network that was just a facade of the old social network with a fresh coat of paint. If you want to win over users, you'll generally need to either (a) provide something that users need and that the competitor has overlooked, or (b) provide a 10X-better version of something your competitor provides. Google+ didn't come close to doing either.


> because they didn't understand the users' needs

That's generous - users told them repeatedly and in no uncertain terms that they were extremely unhappy with numerous aspects of the platform. Google simply did not care if users liked the product. How they expected it to be a success with that attitude boggles the mind.


Alternately, perhaps Google cared more about making some of its internal divisions happy than about making customers happy, and that's what drove their definitions/metrics of "success".

For example, the "Real-name only" policy was never customer-focused at all, but an incestuous favor to the advertising/profiling panopticon.

Similarly, the "forced collapse of all credentials" into G+ (like Youtube identities) probably made some things easier for Google (especially pushing its adoption as an identity-provider) but did a lot of things existing users weren't happy with.


How does real names relate to advertising? G+ doesn't even have ads. Google already has your browsing history to know your shopping interests. G+ had real names because Facebook had real names.


A real name and DOB go a long way to cross-correlating with other information. I work at a market-research company, and we're doing some partnering to correlate with voter records...


Fairly simple - a belief that the users who were complaining did not represent the majority of the market.


I think the Apple Maps example is even more questionable. Apple didn't fail because moving "up the stack" meant they had no idea what consumers wanted from a mapping service; that's absurd. They didn't fail because they didn't have the expertise to write usable software either.

They failed because they didn't throw enough resources at something that wasn't that strategically important to them.

(cf. their entry into the music distribution business, a brand new "up the stack" market which was of huge strategic importance to them, where they ended up assessing customers' needs better than the existing players in that space)


I suppose it depends what you mean by "usable".

Apple Maps certainly had serious quality issues at launch. Whether they considered building a mapping app to be easier than building an OS, I have no idea. I am sure that many at Apple were under no such illusions. But it was a product made for purely corporate strategy reasons.


Google puts as much effort into their phones as Apple puts into their maps, and vice versa, with predictable results.


I (author) didn't say it's hard to move up from (only) engineering side. It's hard to move up from customer empathy perspective. Hence the emphasis on what to build. It's a product strategy question.


Also there is this thing called 'network effect' which plays a huge role for social networks.

EDIT: Why the downvote?


I didn't down vote you, but my guess it is the tone of your comment. You are of course 100% right that for a general social network there can only be one. Until Facebook messes up it won't be possible to build a new general social network - maybe News Corp will buy Facebook and an opening will arise.


I think this example adds truth to the author's argument in that there have been a few social media apps like Instagram and Snapchat that took off in ways the Google Plus never did. I do agree that there was little impetus to move to Google Plus from Facebook, but there could have been features that would have made it enough of a differentiator that people could have moved over to Google Plus. It's not like Google lacked the ability to scale out or provide such a service.


I would argue that Snapchat and Instagram occupy VERY different niches than Facebook. Most importantly, virtually everyone who uses Snapchat or Instagram also uses FB. Google thought they had enough clout to win the "general all purpose category" social network - they were trying to compete directly against FB.


> It wasn't that Google wasn't capable of building a good social network.

Like automatically creating a Google+ account for every google account without asking first? I can see millions of doormant accounts where you think you are following somebody when indeed there will never be an update from that account.


That's not true, Google+ accounts were not created automatically for Google accounts.



Perhaps initially. Now Google forces you to create one if you want to do various kinds of things. It's not quite automatic, true, but it's almost.


Correct, but many people were "coerced" into making an account that they never had any intention of using.


I think the problem with Google+ was that they couldn't decide what they wanted it to be. It was a social network, but it was also supposed to extend across the Google empire. It was difficult to get your head around it. Reminded me of an old Saturday Night Live fake ad - "it's a floor wax, it's a desert topping."

Now that they've split up the product and made Photos a standalone app, they've got something. It's not a social network, but rather a simple concept that people can easily understand. Now if they could make the relationship between Drive and Photos a little clearer, they'd really have something. :)


A lot of people here are focusing on network effects or feature comparisons between G+ and FB.

However, I think the biggest reason for G+'s failure was that the spirit that permeated it was corporatism and inauthenticity. It's frustrating, because it could have been a great opportunity to thoughtfully integrate Google's services.

G+'s phoneyness often manifested in overriding user preferences. E.g., unthinkably, Eric Schmidt thought it was a great vehicle to get people to start using their real names. Coupled with forced signups, butchered product integrations, destruction of Google Reader, awkward promotion by Black Eyed Peas, and Vic Gundotra constantly posting Youtube videos that were clearly meant to appeal to "regular people", it has been painful to watch.

The public is not oblivious to motive, especially when it comes to choosing a social network. FB's key to its early success was an air of Ivy League exclusivity. G+ had Google's relatively sterling technical reputation, respect for privacy, and credence in the "don't be evil" motto, but squandered it to desperately imitate Apple and FB.


Google Plus came out years after Facebook with a fraction of the features. No events, company profiles/fan pages or apps. No levity.


Well, MySpace had a headstart on Facebook but it didn't prevent Facebook from beating them.


It doesn't matter how "good" the product is if you're not talking to the users and uncovering their need for it. What you've said here doesn't contradict the point of the article - determining an unarticulated need and meeting it is the true measure of how a successful product is built. The fact that you can easily trivialize something successful's true purpose, without doing the legwork to find out what need it's meeting is the logical fallacy enforced by failing copycat products.


The article specifically says it's about knowing the customers needs and that technical skill can just be bought/acquired. How you got "we think companies struggle to move up the stack because of technical difficulty" from that, I have no idea.


It's about knowing how to build a rough copy. It's the ability to figure out what is going to work in terms of getting users and usage.


I don't even like Facebook much, but I still strongly preferred the design of it over Google+.

Not to mention Google+ was truly asinine about forcing users to merge their YT and G+ accounts (and even gmail, iirc), it was all just very confusing and obtuse. I don't want a SSO. I don't want a G+ account for every Gmail account.

I didn't want to have to fuck around with merging my accounts, tethering each YT channel to my social network, etc. I want -- and have business needs for -- a division between the sites I use. I frequently need several different usernames and identities on different sites, even if the sites are owned by the same company, as sometimes I am creating social accounts for clients.

Google was, IMHO, trying to be shady and act like every youtube comment was actually Google+ activity, simply so they could claim, "We have XXX million active G+ users each month!!" They weren't and you don't. I'm glad their shady network and backhanded business practices failed.


I don't want to be too dismissive because something about the article rang true to me, but I don't know that I buy the whole central conceit that the idea of a stack can apply as universally as this article needs it to.

Apple's networked services have often struggled. But are they really higher level than the things Apple succeeds at? Asking whether enormous distributed data stores are higher level than Mail.app just seems confused. It's different, and it brings new challenges, but are they part of the same stack? And is the data ingestion and sanitizing that Maps struggled with higher or lower level than the client that was basically ok? You can multiply these questions and I'm not sure you can get good answers.


I would argue that networking services, backend services, and apps are indeed much higher level than the things Apple succeeds at (hardware, industrial design, and operating system).

In fact, Steve Jobs never even wanted third-party apps on the iPhone (http://www.theguardian.com/technology/appsblog/2011/oct/24/s...). So, it's understandable why Apple has struggled with their networking services, backend services, and apps: such concerns weren't even remotely a part of Apple's DNA.


There was a brilliant essay by an Indian politician few years back after his party lost the elections. Later in lecture he explain why political parties and large companies have so much in common when it comes to failing.

His basic logic was that - Success depends on processes - Processes even though might be thought of as abstract in reality are function of people at top. - Company gets successful because some bright guy is the rebel, he questions status quo, persists and succeeds. - As time goes by, the rebellious ideas actually become conservative ideas. The rebel is now on top. As his ideas fade he struggles to stay on top. - He recruits people who see the world through him, he builds processes that enforce that vision. - This makes it difficult for the truth to be visible to the top management. - By the time failure is visible it is hard to turn around the ship. - IN SHORT: Companies/Nations fail because someone at top did not know when to quit. - In the end that rebel turned conservative becomes bitter. He thinks the world owed him something for what he achieved.

He explained who USSR examples. How a genetic scientist got promoted because his fake research re-enforced something that Stalin had said long back and his peers were scared to point out the fact because it might get perceived as anti-Stalin.

I observed Blackberry very closely and it resonated to me so much. The founders at one point blamed people for using iphone and not blackberry.

Best companies in the world are seem to be those where their top leaders quit at their peak to make way for their successor.


Would you agree with this generalization? - Best companies in the world keep redefining the central problem they are attacking.


Yes and that redefinition very often comes from a drastic change in top management. Ballmar was different from Gates and Satya is different from Ballmar.


This explanation feels like the explanation by someone else on this page for why Skype failed on mobile...good insight.


This article seems to have many correct pieces, but I don't think they coslesce to prove the point, or at least, not entirely.

I don't think that manufacturing semiconductors are comparable to building maps. Apple should have done a better job with maps, and even though they do complex manufacturing, likely should have done worse at chip manufacturing.

Iirc they brought in 3rd parties to help with the chip fab, and certainly spent more money building that core competency than maps.

I believe the author is correct that the issues is companies not fully understanding, and consequently underestimate, what it takes to be successful in a different arena putside their cc.

Google sees people as articles in a db. They dont understand people at all, they dont understand design as it relates to people, and they didn't understand that nobody needed another social network.

They probably underinvested (initially) in G+ and it was not a great product. It didnt achieve critical mass quickly, and thus had no chance of growing as a docial platform ever.

However, google is a lot more capable of creating something like this because they have all the core conpetencies down.

I guess my takeaway is that the companies can in fact take these arenas, but they underestimate the challenge. So to use a drug dealing analogy, they try to start moving bricks amd kilos, instead of working their way up learning the market pushing dimes and quarters.

They start too big, and when you fail big, you dont get the recovery of a smaller failure which affords small relaunches and features.

Tldr big companies try to enter at the top, cant recover from huge public failures, and either exit or buy in


"I guess my takeaway is that the companies can in fact take these arenas, but they underestimate the challenge."

Yes. And their core mistake is not understanding the real needs of the customer because they make assumptions in a familiar territory.


Apple is not vertically integrated - Wikipedia entries to the contrary notwithstanding. It is a grossly inaccurate statement. Up until very recently, Apple didn't own a single factory - how can one possibly claim that they are vertically integrated if they don't own their own means of production?

Apple is a fantastically successful software and industrial design company. The vast majority of their production is outsourced. This is not vertical integration.

Additionally, actually, Apple has tremendous amounts of hugely successful and popular software.

Though I dig the underlying point of this article, that product management is hard, I think the examples are less than good.


Where do you draw the line? If a company does own the factory that builds their widgets, do you claim they're not vertically integrated because they don't own the mines that get the materials, nor the transport network to get it to and from the factory? At the other end, do they need to own the bank with which they take payments from customers?

You don't need to own all elements in a vertical stack to be vertically integrated.


Apple sells iphones. Who makes the iphones? Not Apple.


Apple designs iPhones. They manage the fabrication of parts very closely and manage their assembly and QA more closely than most of their competitors (like, big enough to make demands of Foxconn or cause them to build specialized factories). Then they sell the phones directly to consumers. They are (literally) on the Wikipedia page as an example of a vertically integrated company: https://en.wikipedia.org/wiki/Vertical_integration

I'm not saying you're wrong... but it doesn't look like you're right.


You're playing fast and loose with the definition of 'make' there. 'Physically assemble' is not the only element of 'make'.


> Up until very recently, Apple didn't own a single factory...

Apple has operated a factory in Ireland since the '80s.



What is really the difference between operating a factory and buying out all of its demand?


It's particularly funny when the stack fallacy is held by database providers, because databases are the wrong tool for most of the jobs they get used for at the moment.

Current usage of the database uses it as a loose, adhoc, difficult-to-maintain, polling-based API between multiple applications.

The future perspective looks back on our time, shaking its head at the way people use databases for everything in the same way that we shake our heads at bloodletting.

Oracle's business model is (1) convincing people to use platforms they shouldn't be using and then (2) selling the victims ongoing hacks and services to work around the limitations of the model.

Amazon's software services won't be build on a database. They'll be built using a decentralised messaging platform.


> “Can we compete with Intel or SAP?”

Well for one thing we know that Intel spends several $billion to open a new semiconductor plant and has a dozen of them already. https://en.wikipedia.org/wiki/List_of_Intel_manufacturing_si...

Whereas SAP is, well, a lot of software. Which is something, but Intel needs to make a lot of software too, and chip designs are in some ways a specialized form of software.

So I think in some sense Intel is strictly more challenging to replicate than SAP. (But this is probably just my misunderestimation talking. :-)


You're actually quite right. Capital intensiveness is a barrier to entry. That's why software businesses rise rapidly and fall rapidly at a greater frequency than other types of businesses.


This stack fallacy sounds very familiar. Oh, we will just have a few system calls like open, close, read and write, some TTY and credentials related stuff, a bit of signal handling, process control with fork, exect and wait ... writing a shell language on top will practically just be a footnote.


Yes many open source projects suffer from this too. We as engineers (even former ones) often assume the what to build is "obvious". This is often not true, if ever.

The best open source projects are ones where engineers are the end users (customers).


Perhaps this is a feeling that, as experienced implementers, we have a big head start on the hard parts.

Maybe this is another form of the "solution looking for a problem" phenomenon.


An alternative (or maybe complimentary) theory is in Clayton M. Christensen's innovator's dilemma. Big companies build enormous revenue bases on certain types of technologies. Then they struggle to innovate because, by transitioning, they eat away at their existing revenue streams.


Actually, I don't remember that particular insight in TID; what you describe is what I personally call "the Blockbuster effect" -- the idea that a company can quite rationally refuse to adopt a disruptive innovation because its current financial structure is adapted to a particular size market with particular revenues, costs and liabilities. In Blockbuster's case, the risk was that aggressively taking on DVD-by-mail and later streaming would have eaten into its revenue structure (late fees); render operationally worthless its physical stores and thus sink their capital investment and liabilities underwater; and shift the market to a lower-revenue level that would not generate the cash flow necessary for Blockbuster's continued existence.

Of course, they did go out of business while flailing about wildly, but to my mind that simply underscores the importance of knowing how to gracefully exit a market. Ironically, perpetually-beleaguered Yahoo isn't a bad model for that.


I'd like some solid examples of what companies confirmed perceptions of competitors were in the same vertical, versus the reality.

Because even the author references competency-based views of competitive advantage, but for some reason ignores resource based views, and ignores the fact that companies might be aware of their competences. That is to say, I'm sure that large companies tend to mostly be aware of what their competences are based on the resources and knowledge that they have. If they don't have marketing departments that have analyzed the ERP market, sales teams with ERP training, tech departments with key HR, key knowledge etc etc, then I'm certain they are very well aware of this.

Maybe some companies have had marketing missteps and have made poor strategic and competitive decisions, however, but I really doubt that it's due to a lack of introspection or simple analysis as described.

Also, IBM didn't "think nothing much" of the software layer. They misunderstood the nature of power in the supply chain, and most importantly, didn't solidify their position within the supply chain while they were dominant.


They think they know their competencies (database systems in one case, virtualization in another) but often they misunderstand what customers really value up the stack - in this example, Workday customers really don't care if it runs Oracle or MySQL or non RDBMS at all. In AWS case, we don't care for kvm vs VMware wars.

(I am the author of the TechCrunch post.)


A lot of the examples and counter-examples in the threads here are great, but Microsoft in the Windows era is a great counter-example here: from operating system to Office dominance. How did they crush Lotus and WordPerfect again?


As a comment on TC says:

"What the article is referring to as stack fallacy is the work of Physics Nobel Laureate Philip Anderson: https://web2.ph.utexas.edu/~wktse/Welcome_files/More_Is_Diff...

Let's give credit where it due please."


This article is funny - twisting together the ideas that a company specializes in a product in a specific market and that other companies can use the products / tools of other companies to develop their own unique products for a specific market and market development and competition. The "up-the-stack" company building something using products from "down-the-stack" has already entered a market, gained market share, and specialized in a market in which the "down-the-stack" company has no presence. Now, the "down-the-stack" company sees an example of a successful product that uses their technology that they know so well, but their company is not specialized for this product, so it hubristically does low-hanging-fruit-snatching to try to enter the new market. "Big companies keep failing" because they are not being innovative based upon what's mentioned in this article; they see an easy out and enter a market that already has an incumbent(s).


I am the author. Happy to answer any questions about my post.


I think this could be turned into a book collating detailed case study in each of those cases where they failed with perhaps cases where companies have made it work like Google Fiber, Amazon's PAAS etc.


Nice observation. Another way to put it is that induction is harder than deduction.

A related factor is that larger companies tend to be more specialized (formalized processes, specialists, focused teams/departments, and so on), meaning they can be prematurely optimized with respect to new goals and poorly equipped to conduct the necessary roaming.


The author claims that "Stack fallacy is the mistaken belief that it is trivial to build the layer above yours", but then says that IBM was wrong when they "happily allowed Microsoft to own the OS market".

Wasn't IBM a classic case of not trying to build the layer above them on the stack?

The Wikipedia page on IBM PC DOS even claims that their "radical break from company tradition of in-house development was one of the key decisions that made the IBM PC an industry standard".



OS/2 was too little too late - by the time they realised what was going on, Microsoft was already a new major player.

Didn't stop Microsoft from going out of their way to sabotage them, though.


In fact, the history of 32-bit OS/2 is more complex than that, and involved MS a lot more than this. It used to be my favorite topic.


Why do people keep reading TC?

Here let me make an article... wait wait... ah... "Big Companies FAIL" that sounds like nice click bait. Now... hm, let's invent some stupid word to pad it out how about the 'Stack Fallacy'. Programmers will dig the 'stack' part. Yeah. Ship it!

Seriously, this article is content free.

People make products. Sometimes they work... sometimes they fail.

If you pretend you have some magical insight into why they fail or succesd with gems of wisdom like:

    found it very difficult to succeed in what looks like a 
    “trivial to build” app  — social networks.
and:

    The stack fallacy provides insights into why companies keep
    failing at the obvious things —  things so close to their 
    reach that they can surely build. The answer may be that the 
    what is 100 times more important than the how.
Then... wow. I don't even know what to say.

Really? What you build is important?

No kidding.

Why is the top of the list this morning?


A company should always focus on your strengths if not it'll be both overstretched and unsuccessful. Great read.


I do not think that's the correct conclusion. The conclusion should be that when venture into new areas, be sure to understand the market first.


Or, just because you understand the underlying technology doesn't mean you understand the market, and your previous experience will get in the way of actually understanding the market.

If you want to go down the tech stack, though, you might be successful because you're part of the market for that tech.


Exactly. When you go down the stack like Amazon did with AWS, you know your customer (often you). You also know the key pain points and gaps in the market. This is especially so in "as a service" markets.


This seems more than a bit flawed. It presumes companies or anyone else think these launches in to new markets are low risk. They are generally seen as anything but. There is hope that leveraging existing strengths will improve the odds, but only the idiots think they are certain to win.


Do big companies really keep failing? I'm failing to see the evidence of that assertion.


Failing to gain traction upstream, not failing to keep the lights on.


> The bottleneck for success often is not knowledge of the tools, but lack of understanding of the customer needs.

THIS! +1000! I would even leave out "often", or at least replace it with "usually".


True enough, but there are also companies that were designed from the beginning to have vertical integration and control much of their business from beans to buildings. And of course I am thinking of Starbucks. (People don't really understand the technological story of Starbucks, which has a lot to do with their introduction of the vacuum packs to get their coffee across the country, and overcoming the challenge of brewing coffee on passenger jets.) Mostly for the better, they decided long ago to own as much of the stack as they could.


Some insights perhaps, but the claim that this is "Why big companies keep failing" is way overblown


agreed. Its just hard to have title that says "Why some companies fail repeatedly".

All of us are competing with "17 people under 30"... listicles.


The counter example would be Apple when they introduced music players and music distribution. That was far away from their core business of PCs. The smartphone was less of a stretch, because it was a potential extension of the iTouch comunications computer.


Not so much stack as legacy. Have you seen legacy architectural decisions? They're impossible to get rid of. It's surprising how much the initial architecture can hinder change.


> Product management is the art of knowing what to build.

And in what order.


When reading the article I was reminded about Warren Buffets message re identifying and staying within your "circle of competence."


Peter Lynch writes about it in his book "One Up on Wall Street". He calls it 'Diworsification'.


That's why when I build a company, I'm going to use a hash table.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: