MVP, done, and working

Recently at SalesCrunch we had an interesting discussion of what MVP (minimum viable product), done and working means for our web application. Like all startups, we've run into growing pains with our app's feature set, reliability and performance, some self-inflicted and some external (Apple disabling Java by fiat and killing lots of functionality on the web overnight), and I wanted to reduce the non-productive frustration and tension we  often fall into ("the app is broken!") by pointing out that unless you define and agree on specifics, every participant will have different expectations. Different expectations are bad, so it's important to always make it clear what it means for a feature to be done and working--no assumptions.

So my main goal was to make sure every product build process includes an explicit conversation about what it means for that product to be done (i.e. it has all the features/use cases/user-error protection we want) and working (the SLA it needs to meet). That discussion must happen between all the people involved in the build--product, design, business, engineering, and maybe even the end-user (or at least the end-user should have a way to provide feedback so the company can adjust their criteria for "done" and "working" in case we got it wrong).

We got to a good place with that conversation, but it was a little abstract. Then I tried to make coffee, and was given a great real-world example of what the discussion and thought process could be.

I went to make espresso. Turned on the machine, put the cup under the espresso spout, and started the brew.

My cup promptly filled with high-pressure hot water, because I had forgotten to put the coffee basket in.

You may say "well that's dumb, the brew shouldn't be able to start if there's no brewing basket, since you're never gonna get coffee". That's what I thought, briefly.

But that requires an extra feature (a sensor or switch that blocks the brew switch if the basket is missing), meaning more moving parts, build and integration time, testing, higher costs, more expensive retail price, etc.

It's likely somebody at Mr Coffee had a conversation about this and decided a distracted/stupid/sleepy person forgetting to put the brew basket in before turning on the machine wasn't likely and/or dangerous enough to warrant the extra time, complexity and cost for a machine built for the sub-$100 price point.

Until this incident, I had no issues with the machine. Today, I used it, and didn't get coffee out of it. So one could argue the machine is not done (missing a sensor), or it's not working (it's allowed to function without producing coffee).

But does the machine work? Is it done? Until yesterday I had no issues with it. Today the circumstances have changed: I did something dumb I'd never done before, and had a failed coffee-making experience. So maybe my criteria for done and working have changed as a result: today I may decide to buy a different machine, looking for an error prevention feature. But the machine I have hasn't changed.

The main message here is:

1. don't assume done and working are defined the same for everyone
2. it's ok for done and working to change meaning with new circumstances
3. if those change, then the product needs to change in response to it
4. frustration, hand-wringing and pain can be avoided by being aware of 1-3 and not judging a product that was built on old done/working criteria against the new criteria

Personalize like it's 1995

This is what I see on Hulu when I'm not logged in:

And this is what I see when I am logged in:

Notice the difference? Me neither. I've never watched Cougar Town or any of the other shows on the home page. I never watch clips--only full-length episodes. And I only ever watch one show on Hulu--Law and Order SVU. Nothing else, ever. Personalizing my home page to my tastes would be completely trivial: just add a link to the last show I watched. They don't need a $1M recommendation algorithm to pull shows I may want to watch--just a list of shows I've watched in the past would be nice.

I wonder what Hulu's engagement metrics look like. I know every web site has priorities to juggle, and maybe recommendations aren't at the top of that list. But engagement and stickiness are crucial to all ad-supported sites, and especially media sites. So why isn't Hulu trying a little harder to get me to engage with their site by giving me ways to get to the shows I want?

Overloaded 404 part deux

I just noticed Backpack by 37Signals also 404s when you access a page you need to be logged in to view.

STOP THE MADNESS!

And of course, if I tell them it's bad UX, they're likely to tell me to go f*** myself.

This is why Apple wins, part II

Last night, I was enticed by an Android tablet edition of This Old House magazine, which is available free for print subscribers. I'm trying to ditch paper everywhere I can, and thought "yay!". So I set about getting This Old House for my tablet.

What I expected:

1. go to Android market
2. download This Old House app
3. install This Old House app
4. sign in with my print subscription info
5. read

What actually happened:

1. go to Android market
2. fail to find the This Old House app (WTF #1)
3. Google for "This Old House android app"
4. look at 2-3 search results and fail to find the This Old House app (WTF #2)
5. go to Amazon
6. find the This Old House app listing, which is free
7. look for a "download" link, to no avail (WTF #3)
8. find the "enter your email address and we'll send you a link to download the Amazon App Store" box (WTF #4)
9. enter my email address and wait
10. fail to receive email, go back to Amazon home page (WTF #5)
11. enter my email address again
12. view the Amazon App Store app install instruction
13. follow instructions (go to settings > applications > allow unknown sources) (WTF #6)
14. receive email and click link
15. download Amazon App Store app
16. install Amazon App Store app
17. find Amazon App Store app (no icon added to the home screen) (WTF #7)
18. sign in with my Amazon account
19. search for and fail to find the This Old House app (WTF #8)
20. load browser, go to This Old House web site, and find Android app ad
21. click Android app ad, read instructions and go to nextissue,  the This Old House app provider
22. find nextissue app download link and download
23. install nextissue app
24. find next issue app and start it (no icon added to the home screen) (WTF #9)
25. create nextissue account (WTF #10)
26. go back to This Old House site and enter my print subscription information to get free access to the Android app
27. create a This Old House account (WTF #11)
28. go back to nextissue app on my tablet
    
29. sign into nextissue app (WTF #12)
30. look for This Old House in nextissue app, to no avail (no search function) (WTF #13)
31. scroll through the available selections and finally find This Old House, next to last
32. tap This Old House
33. see This Old House listing and tap "install"
34. tap This Old House to run it (after install)
35. enter my print subscription information to allow free access to the magazine (WTF #14)
36. see latest issue and tap on it to download
37. wait for issue to download
38. wait for issue to install (WTF #15--why show me two progress bars, one for download, one for install? why do you have to install an issue? just show me one progress bar)
39. tap issue
40. read

I wish I were making this up.

I was not trying to circumvent anything, hack anything, jailbreak or root anything, or steal content. I was just trying to read This Old House on my tablet, after the magazine itself prompted me to try out its tablet app in an expensive full-page ad.

This Old House magazine: do you realize how much money you're wasting on an ad and an app that my gut says maybe 5% of eligible users can actually set up and use?

Design trends suck

How exactly is this trendy font effect cool, unless hard to read is cool?

Why I like early-stage startups

Early-stage startups aren't for everyone, but they're certainly for me. There's always more to do than you have time for. Some find that overwhelming and frustrating ("I always fail to achieve the goals I set for myself!"), because they look at it this way:

I prefer to look at it this way: 

Every single day, every single hour even, you can point to something you did that didn't exist before.

Progress isn't measured relative to what goals you set for yourself so much as how much is there that wasn't there an hour ago.

And that's awesome.

Leverage this

Slashdot post says (emphasis mine):

long-standing complaints about fraudulent purchases that leverage Apple's popular online music store

People seriously need to stop verbing that noun and start using normal words instead of trying to sound hip or edumacted.

The internets: you're doing it wrong

You can now rent Amazon Kindle books from your local library.

Does anyone else think this is completely absurd?

The Roggr Rule

Idly chatting on IRC with other nerds, and reading stories about failed startups, this particular quote got me thinking:

• Problem 1: Founders

We are two founders (business oriented). In a very short time, we ended up 6 people with various business areas of expertise (web marketing, communication, finance, legal, etc.) but no tech person. Wrong. Each one of my co-founders was a kick ass guy/girl in their own area of expertise but every tech/web startup needs a tech person. This tech person is actually the core of any startup, everyone else is expendable (early stage).
Mistake #1: Assemble a small (2, 3) team. Get a tech co-founder.

My first reaction was "duh", which is a little glib and facile. But then, looking back at my previous startups, I came up with the following completely baseless, arbitrary, unsubstantiated, and therefore awesome, rule of startups, which I modestly named The Roggr Rule:

Any Web startup that doesn't have 2-3x as many techies as business people until it has 15+ heads will fail

Expect to read abundant case studies in best-selling business school textbooks soon.

Devs need to stop being such pampered whiners

The 37signals people are smart and have a lot of interesting ideas to make software development better.

The "Boycott A Meeting" movement, however, is bullshit and idiotic groupthink at its worst.

Bad, pointless meetings are bad and pointless and should be avoided.

Gatherings where people discuss features, ideas, implementations, etc. with a clear agenda at the beginning ("let's decide how to build X") and actionable outcomes ("you do this and that, I do this and that, we'll use technology A and B, and will have a prototype out by next Friday") are one of the best ways to foster good ideas, code quality, camaraderie, and productivity.

It's hip to be a contrarian and spout off against-the-grain blanket generalizations as facts, but when your blanket statements are complete bullshit, you lose a lot of your credibility and just come off as an arrogant opinionated mollycoddled sniveling little whiner. Being a self-centered opinionated impatient whining bratty know-it-all is not a requirement for cranking out lots of high-quality software.