Maybe not so much with the “optimization”

miniviewer-sidebarIn the quest for optimization, A/B tests, metrics, and funnels, we’re in danger of losing the fun and value of creative work.

When we demand overwhelming customer outcry before committing to the slightest product change, we’re in danger of losing the value of creating a cool feature that takes too much effort but people just love.

When we do the minimum necessary to get the job done, we’re efficient but not thrilling. We’re “lean” but we’re not stirring hearts. We’re effective but not playful.

I’m as excited as everyone else about Lean principles gaining traction, and sure most companies are erring on the side of too little objective feedback rather than too much. Still, every article I read turns the creative process of business and product design into Vulcanian objectivity.

Sometimes, you should do something just because it’s cool.

Look at this incredible display of affection IHumanable has for his computer:

This is one of the reasons I love my new iMac, it’s just a beautiful magic floating screen filled with win.

You couldn’t ask for a stronger endorsement. This is even better than “It saved me $725,231.” This is beyond utility — this is love.

Does love come from feature bullet points? Do you earn love through A/B tests and implementing features off the top of GetSatisfaction? Or is this something else, something deeper, something less incremental, less data-driven, more gut feel, more emotional?

My first product at Smart Bear had a non-optimal, floating-in-win invention called the “mini-viewer.” Here’s its story.

Code Historian was my first product. It was the first file difference viewer with built-in support for version control systems, letting you view various historical versions of a file side-by-side. You could switch between which versions you were comparing with one click:

sidebyside-view-50

The thing to focus on is that user interface element in the bottom-right corner. That’s the “mini-viewer,” and in every measurable sense it’s a terrible business decision.

The mini-viewer summarized the modifications — the lines added, changed, and removed — so the user could easily see how many changes there were and where they’re located. Sounds useful, right?

Right, except it’s a really wasteful, expensive way to do it. Many competitors used a different technique I call “boogers,” because to me it looks like someone shot snot rockets all over the screen, and also because it’s fun to deride competitors, because it feels good to make fun of other people who (appear to) have more revenue than you do.

But don’t you agree they look like boogers?

boogers-on-side

The boogers are placed next to the scrollbar, indicating where you’d need to scroll to see differences between the two versions of the file.

Now by all of the usual arguments for Lean, Agile, and minimimalism, I should have used boogers too:

  1. Boogers were already semi-standardized. User interfaces should follow the principle of “least surprise” — if people are used to a certain metaphor, icon, or behavior, you should honor that so people understand your product immediately. No one else had a mini-viewer.
  2. Boogers occupy minimal screen real-estate. It’s just a thin strip no wider than a scrollbar; in fact some products put the boogers on top of the scrollbar. The mini-viewer is not only larger, it has significant width, which means you have to occupy the rest of the right side of the screen with other crap.
  3. Boogers appear right next to the scrollbar, which is where you look anyway when navigating the file.
  4. Boogers take less effort to compute than the algorithm for determining color variations in the mini-viewer.
  5. Boogers take less effort to draw. Boogers are drawn on the screen once, and don’t change unless the window is resized — an infrequent operation. The mini-viewer however indicates your current scroll position in the file (those black brackets) so when you’re scrolling around the file the speed at which you can recompute and redraw the mini-viewer matters. If you draw directly on the screen it will flicker, so you need off-screen buffering. In short, the mini-viewer is a lot more programming effort with a lot more chance for bugs.
  6. The mini-viewer doesn’t convey more information than boogers do.

And yet, everyone loved the mini-viewer. People sent emails saying they used Code Historian just because of the mini-viewer. Some developers wrote in asking how I was able to render it so efficiently. It was always a high point in product reviews.

The mini-viewer was wasteful, but fun. It wasn’t optimal and had no measurable benefit to usability, but it was “filled with win.”  It took extra effort but it was endearing — an important attribute not easily captured with metrics and spreadsheets.

Now sure, there are many of aspects of business and product development where it’s best to stop obsessing and just cut corners. Often we can and should accept 80% of the benefit if it means 20% of the effort. Customers generally prefer the right features over more features.

But sometimes it’s your job to fill the screen with joyous win.

What are your thoughts on balancing intelligent business choices with fun, wasteful, but rewarding projects? Leave a comment and join the conversation.

, , , , ,

  • http://www.chrismower.com Chris Mower

    Joyous win = WIN.
    .-= Chris Mower’s latest blog post: Construction in Progress =-.

  • http://www.bidsketch.com Ruben

    Yes! You’re exactly right about the need to at least add one or two really cool features into a slim product. When I launched my product, I purposely took a little extra time to do exactly that. I dropped a couple of features that some people said were necessary (but not enough people), to make time for something people would be excited about. I’ll admit, the implementation wasn’t exactly clean, and I’m now having to rewrite a portion of it, but people love that damn feature!

    By all means, launch a slimmed down version of your product to get something out the door. But don’t forget to add something that makes it easier to market, and gets people excited about using it.
    .-= Ruben’s latest blog post: This Simple Change Will Win You More Proposals =-.

  • http://scottbellware.com Scott Bellware

    My concern with the Lean Startup school and movement is that it will try to see the immense body of work and understanding that is Lean product development, and see only the ideology and even orthodoxy that is accreting around “Lean Startups”.

    I have a hard time believing that anyone who came to lean through a vector other than Eric’s work or Steve’s work would agree that incessant split testing is part of Lean Product Development.

    In fact, there are great examples – and well-documented – of Lean Product Development leaders making critical design decisions based on their own visceral feel for customers, and in doing so, on some occasions, they have blatantly gone against the results of customer inquiries, including panel groups, extensive split tests, market and customer research, and exhaustive interaction with customers and sellers during product inception.

    This A/B testing thing – at least the way it’s done in the “Lean Startup” movement isn’t a Lean principle at all. An essential aspect of Lean Development and Lean Production is the shape of the organization doing the Lean work. Lean organizations are hierarchical, and they have a chief designer at the head who is empowered to draw on decades of experience in product development in the sector within which he works. Lean Development is characterized by having people in-play who already know what the customer wants, because they have been empowered to go where the customer is and learn from them. The Chief Engineer role, for example, is a role that can choose to ignore the data coming in from things like split tests.

    That said, if a product developer doesn’t have a visceral sense of what the customer wants, they he’d better do things to learn. But then, if a product developer doesn’t know what the customer wants, we should be asking ourselves whether he should be doing the product development work at all – at least in a product design decision-making capacity.

    I really hope that as the Lean Startup meme spreads that people will look into the body of work and study that informed the leaders of the Lean Startup movement so that the Lean Startup lessons can be learned in context of all the informative assumptions that come from 50 years of Lean Development practice and study.

    If Lean Startup enthusiasts fail to complete their study and practice and draw only on one-removed representations of Lean, I think it will inevitably end up being as watered down by mindless orthodoxy and ineffectual cargo cult behavior as Scrum was, and its new practitioners will end up as disillusioned with Lean as new Scrum practitioners became disillusioned with Agile, or Agile-in-name-only as is often the case with Scrum adoption and use.

    I’ve learned a lot from the Lean Startup perspective, but I feel not just a bit trepidatious for people who are coming into Lean through such a narrow specialization of Lean, and such a young interpretation of it.

    Thanks!

    Scott Bellware
    Lean Software Product Development
    Ampersand GT
    http://ampgt.com

  • http://blog.olegkokorin.com Oleg Kokorin

    I don’t agree that “usual arguments for Lean, Agile, and minimimalism” call for copying someone else’s work and not doing any innovations. If the mini-viewer was not essential part of the product, then it should have been excluded from the minimum viable product. But since all the systems had boogers, apparently you had to had something like that.

    To me, the mini-viewer does convey more information than boogers. It’s a shrinked image of the listing, as opposed to the boogers that are just color-coded stripes. That’s why people loved mini-viewer – it’s more natural. But then I’m not an expert in code reviewing systems, so I might be wrong.
    .-= Oleg Kokorin’s latest blog post: Evernote gains traction =-.

  • PJ

    >balancing intelligent business choices with fun, wasteful, but rewarding projects?

    If it’s fun and rewarding, it’s not wasteful! Keeping up developer morale by adding such ‘fun and rewarding’ features is important, too! Developers are often people who like unique challenges, so telling one to ‘add boogers just like X million other apps’ isn’t near as interesting to them as telling them to add something new and quirky and fun.

  • Pingback: uberVU - social comments

  • Q

    I think you’re mistaken to attribute the popularity of the mini-viewer to some mystical “filled with win” quality. A quick analysis:

    The mini-viewer *does* display more information than the boogers — you not only see where the code has been changed, but also the shape of the text where the changes are. If you’re relatively familiar with the visual layout of code, you can make educated guesses about what parts have been changed, if not how. With the boogers there is no immediate mapping from the green blocks to the precise text that has been altered — no way to know if code has been changed or white space added, for example.

    Second, the boogers are an abstraction of the changes which requires mental work to process. The mini-viewer is a representation of the changes, which requires much less mental work to process. It’s appealing because it *resembles* what it’s representing, whereas the boogers *symbolizes* that. It’s the difference between ‘bang’ and ‘the sound a gun makes when it’s shot’.

    I would say the mini-viewer is creatively optimized for comprehension :).

  • http://pentalogic.net Clare

    Completely right – I think the rules of Lean – though very useful in lots of situations – are probably quite contrary to the rules of, invention, innovation or fun.

  • http://blog.syedrayhan.com Syed Rayhan

    Jason, I agree with you on acting on gut-feel. That’s what make us entrepreneurs. However, I don’t see any conflict between that and doing A/B testing. Certain % of features should come from our vision for the product, and not driven by customer-pull. That is how we will innovate and differentiate from our competitors. In your case, that is exactly what you did. And it seems like you got your “validation” of your “mini-browser” feature through +ve customer feedback in a “qualitative” form. So, I wouldn’t say it was a ‘waste” from “lean” perspective. Wouldn’t you agree?
    .-= Syed Rayhan’s latest blog post: Iterative funding of startups- an entrepreneur’s perspective =-.

    • http://blog.asmartbear.com Jason

      The “validation” didn’t come immediately, no. It was months of time before it was clear that it was actually helping to sell people on the product. Not at all like A/B testing where you try variants and attempt to get feedback ASAP.

      It’s hard to measure fuzzy stuff like this. If a customer says they like it but 10 are confused and uninstall without even talking to you, would you know it? Would you just look at the people who liked it and decide it was wise?

      Of course there’s no conflict between being methodical with some things and cavalier on others; indeed at the end of the article I said being careful is probably what you should do most of the time, but I rarely hear anyone from the Lean camp talking about doing things that are more gut than measured. Sometimes that’s good too.

  • http://blog.syedrayhan.com Syed Rayhan

    Jason, couldn’t you have done A/B test with mini browser too? Customers “without mini-B” against “with mini-B.” And if you have some sort of tracking in place for things like who are uninstalling after the rollout of mini-B, you could at least try and get feedback from them at the time of uninstall process? I am not sure I understand why you couldn’t do A/B test your pet feature. It is OK to implement pet features, but we still need to do A/B test those features. Even if it takes 2 months or more to determine the impact of the pet feature.
    .-= Syed Rayhan’s latest blog post: Iterative funding of startups- an entrepreneur’s perspective =-.

    • http://www.ashmaurya.com Ash Maurya

      I’ll second Syed’s line of reasoning. In the lean startup world, you don’t get a star for listening to your customers or following the proven path but for learning from customers.

      There is nothing wrong with building “differentiated features” based on a vision/gut feeling. What’s important is validating that it does move the needle in a macro sense over time (which you did prove in your case). There is really no prescribed time window for that. The longest “still running” experiment at IMVU (via Timothy Fitz), for instance, is in the order of 18 months.

      I agree closing the “validated learning” loop isn’t always straightforward and I feel it’s best balanced not just with quantitative but also qualitative metrics. When I build one of these “love” features, I always reach out to existing customers or highlight them to new customers during a demo/usability test as a better way of doing X and gauge their reaction. In parallel, I continue to collect the quantitative metrics, but usually the qualitative feedback is all I need for the initial validation.
      .-= Ash Maurya’s latest blog post: Bootstrapping a Lean Startup =-.

  • http://softwareprototyping.net John Clark

    Interesting article, Jason. Business motivations aside, a lot of what you are describing strikes me as ‘interface’ – i.e. how your customer works with your product.

    Rather than leave something like this to chance, I personally believe that interactive prototyping can allow a designer/developer to quickly identify these highly desirable ‘love’ features by incorporating user feedback into the product design stages.

    Though this is no guarantee of ‘user love’ (ahem), it’s certainly one way to increase your chances of at least a little ‘user affection’ for your product. After all, what matters is invariably your users (who are probably your customers as well) – and so, giving them an influencing stake in the design at an early stage certainly has a direct causal influence on the acceptance and suitability of the end design.

    But then, I would say that as I’m biased (my blog, see link above, is all about software prototyping and how it can improve the chances of successful project delivery) – apologies for a slightly shameless plug!

    By the way: I have a feeling that the new iPad is going to be choc-a-bloc with ‘win’ and generate a load of ‘user love’. So, it’s probably a great time to pay a lot of attention to this emergent, new category platform…
    .-= John Clark’s latest blog post: Review: iShowU HD Pro =-.

  • http://www.easyessayhelp.com Cutom Thesis

    Interesting article, Jason. Business motivations aside, a lot of what you are describing strikes me as ‘interface’ – i.e. how your customer works with your product.

  • http://www.customessayhelp.com Custom Essay

    Completely right – I think the rules of Lean – though very useful in lots of situations – are probably quite contrary to the rules of, invention, innovation or fun.

  • Joe

    Good article Jason. I think the phrase “Penny wise, pound foolish” is applicable here. I see this quite often in in the company I work for and many companies I work with especially in a downturn economy. Some spread themselves so thin to save money that they fail to clinch the big deal.

  • Pingback: Uncommon Interview: Howard Mann puts the fun back in business | Igniting Startups - nPost

  • http://www.rosshudgens.com Ross Hudgens

    The bottom line: The A/B testing on your website might prove that B converts 30% more users to your call to action, but what if A results in more long term growth, viral marketing, word of mouth, and boundless traffic that far outweighs the initial 30?
    .-= Ross Hudgens’s latest blog post: How to Identify a Narcissist on Twitter =-.

  • Pingback: Profitable Start up Growth with DropBox and Hubspot | Texas Entrepreneur Networks

  • Pingback: It’s a torturous chaos until it isn’t | A Smart Bear

  • Pingback: It’s a torturous chaos until it isn’t | 曹志士

  • Pingback: “Because that’s the way it’s done” — should a founder listen? by @ASmartBear

  • Pingback: 真正的门槛优势

  • Pingback: Why startup biz dev deals almost never get done by @ASmartBear

  • Pingback: Why startup biz dev deals almost never get done - XTBlog!