There was something in this article that really resonated with me.<p>I was talking with someone the other day about how confusing I find Facebook as a recent addition to the network and couldn't believe that it was so popular, given the fact that users are usually so overwhelmed by complexity.<p>In the same conversation, we discussed that, whilst someone can look at my relatively trivial application interface and be completely paralysed by it, the same people might have built up incredible complex patterns of behaviour on their own cobbling together functionality in Excel to achieve a goal that eclipses any complexity I could have built into an interface.<p>I realised in reading this article that not only do users understand complexity that they themselves create from non-complex components (or over time in reaction to very specific problems), but they also collectively understand complexity if they're on the journey of an application from the very beginning because the early adopters are there to <i>teach</i> everyone else.<p>If you release a complex product, even one less complex than Facebook is currently, but perhaps more complex than it was on day one, you're releasing into a world with no resources to handle that complexity. There are no blogs, no experts, no neighbours, friends or well wishers, no adult education courses on your product.<p>By the time Facebook got complex, there was so much community around it that people were able to cope.<p>I think this is an important part of the "customer development cycle" that I've never really heard explicitly discussed: not only is releasing early important to help you find the right customers, but it's also important to help you increase the complexity of your product over time without alienating your audience.<p>If you go too long without releasing a product, you get used to it and you're unable to adequately discern the complexity anymore, reducing your ability to explain it and help early adopters along on the journey.<p>The longer you take to release your first version and get your first customers, the bigger the barrier to entry and steeper the learning curve will be for those early adopters, so they're less likely to take up the cause of advocating and documenting your product's features, blogging about it with helpful hints, tutorials and recipes for using it, than they would if they had been on the journey with you since development began.
I'm not sure the author of the article is familiar enough with Arrested Development to draw the analogy. Most agree that AD's problem was marketing, not product. If you're familiar with the series, you know the story wasn't overtold. If anything, it was left hanging.<p>We didn't know about the show when it aired. Like many others, we caught up on Netflix much later, loved it, and were surprised they killed it off so early. Be careful not to assume a product problem when you're actually suffering from a marketing problem.<p>Fun fact that the author should have included: AD actually makes fun of "jumping the shark", using Henry Winkler's character no less.
If MS Office was distributed on a recurring billing basis (subscription or SaaS, for example), I wonder if there would be such a complete set of barely-used features. We've certainly found that it's beguiling to want to add all the feature requests in, but sticking to our guns and making our core features work even better has proven a good method for us. One of our rules is: can it be hacked together? (the request). If there exists a way to do it at all, we don't focus on it, rather we invent what isn't possible to do at all (or is currently very expensive to do). It keeps us sane and interested in our work.
Wow, this is a really weird analogy to make. I don't agree that software can jump the shark by over-telling a story. I think software is either focused and serves a well defined feature set, or it is chaotic and has several 1/2 defined features that are there only to check-off a bullet point in some marketing spec sheet.<p>For example:
People can argue that any one release of Adobe Photoshop has told its story, but yet Adobe continually adds new features to an application that's over 2 decades old.<p>Yes software does carry a lot of weight when it comes to visual design/art, but at the end of the day, it's a tool. Each successive revision should continue to evaluate meeting the needs of its users and adopt changes to meet the demand.<p>Microsoft Office includes tons of new features, but they refined the UI to the point that it upset users who took time learning the new UI. I think it was a step Microsoft needed to take and it worked out for them.<p>Apple's Final Cut Pro on the other hand, removed features to refine their app and upset their core audience. It was too complex for your pro-sumer, but too basic for the professional. That's what I call losing focus.<p>So my point is, software will be successful if it has the resources and focus to make it happen. It may take a long time to reach critical mass, but that's the beauty of a tool set, a nice long growth curve.<p>Entertainment on the other hand is a one-shot deal, either you like the performance and elements all work together, or you don't.
This article fails to make the distinction between technical product development (where one needs to invent/build new technologies in order to make the product come alive), and just general product development where your not actually overcoming major technical challenges.