My summary of the key characteristics as described in the article:

• Discussing issues by citing evidence and experience rather than mere educated guesses
• Expressing opinions in a transparent way, and giving forthright feedback to anyone else in the organization
• Removing the emotional reaction to mistakes so people understand clearly why they happened and can logically discuss how to avoid them next time

And one quote from Dalio:

What we’re trying to have is a place where there are no ego barriers, no emotional reactions to mistakes…. If we could eliminate all those reactions, we’d learn so much faster.

If you like the list, please Like it.

Developing a mental model of this equation (particularly the more volatile variables) and designing with that equation in mind is a fun part of managing a product. Maybe writing it down and posting it on the wall would be an educational tool for the team?

The successful pitches hit on these points:

• Who I/we are
• What problem we solve
• How we solve it
• How we sell it
• Status of business & funding
• Our industry experience

The Readability folks recently amp’d the feature into a business. They added the ‘read later’ function of Instapaper/Evernote, and most notably a subscription revenue model from which they pay 70% to the content creators or publishers to compensate them for the ads Readability sucked out.

There’s a lot I like here, from their reader-first philosophy to the fine folks they’ve chosen as advisors (a few are friends of mine). But I can’t help thinking it’s not going to work. My doubts:

• They’re competing with ads. Large organizations that depend on ad revenue have huge investments in ad serving and tracking. Readability to asking publishers to give that up for what Readability gives them. 70% sounds generous, until you do the math and realize 70% of not much is not much (see They’re small below)
• They’re competing with free in the form of their free Read Now offering, the open source version, and Evernote. And Evernote is very, very good.
• They’re small, so besides the fact that what they pay publishers won’t be much, they haven’t revealed any way to scale to the size necessary to make a material difference in how the publishing industry works. They have an API for developers, but they need to focus on the publisher side of the equation.
• They’re not giving publishers control. Sophisticated ad serving systems let publishers tweak ad buys based on calculations of page views, content costs, clicks, etc. Readability simply offers a set percentage. And Readability is hoping publishers will do the work of coming to the Readability site to sign up, just to get the deal Readability dictates.
• The legality is questionable. If I’m an asshole publisher (you can be sure they exist) I only see someone who is stripping out my revenue stream as a threat to my livelihood, and I call my lawyers for their opinion. Chances are the big media houses have more lawyers than Readability.
• 30% is expensive. Apple takes 30%, but has gorgeous devices and stores and the iTunes marketplace and credit card numbers galore. Publishers can bitch about Apple, but they offer a lot for their 30%. The value that Readability adds is small in comparison.

I could be wrong, there could be a huge infusion of this function into every reading tool. And once it gains a critical mass of readers the publishers get on board. But I don’t think the product is quite positioned for that yet. Here’s an alternate business model leading the same, and sometimes better customer experience:

Readability develops an ad network-facing API and partners with the biggest ad serving networks to integrate the API. When a publisher serves a page, the ad network checks the visitor’s machine for a cookie and if present serves a ‘clean’ page to Readability subscribers and a normal page to everyone else. The impression is recorded and Readability pays the ad network who in turn pays the publisher. In this model publishers don’t have to configure anything new and get paid automatically, the ad networks get paid and get a new revenue stream, Readability gets paid, and Readability subscribers get beautiful, clean pages often with zero clicks.

Here’s how it might happen: we first create this standard and find ways for people to voluntarily start using it. Perhaps a pro-consumer organization takes on the role of applying it, and consultancies provide testing services. Maybe that’s enough, or maybe industry organizations formally adopt it, and legislators make it mandatory in certain cases.

What does a universal usability test look like? Here’s a sketch:

1. The basics of the process and the results are simple enough for the average consumer to understand, in the same way as the UL mark or the Consumer Reports harvey balls. As a standard, the results should simply indicate the product has met the standard or not.
2. The standard is described in terms of the user’s experience:
1. Time: there’s a maximum amount of time* designated to a task. Seven random people from the product’s user population are asked to complete the task and all must successfully do so in the time allotted.
2. Emotion: each test participant rates their emotion using the product using a standard measure of feeling like the Wong-Baker Facial Grimace Scale. If the total score of the seven participants exceeds 25 the product fails the test.

* How do we determine the maximum allowable time? I haven’t figured that out yet.

Lately I’m also perusing Stephen Johnson’s thoughts on Where Do Good Ideas Come From. In this context it’s interesting to read here and here about Twitter co-founder Jack Dorsey’s years of experience creating software to dispatch messages, and how this interest goes back to his childhood, so in Johnson’s terminology, the idea for Twitter looks like a slow hunch not a eureka moment, typical of many good ideas in Johnson’s view.

Here’s his sketch from 2000 showing key parts of the user interface:

Fast forward to 2006 via Dom Sagolla:

“Rebooting” or reinventing [Odeo, the struggling podcasting startup] started with a daylong brainstorming session where we broke up into teams to talk about our best ideas. I was lucky enough to be in @Jack’s group, where he first described a service that uses SMS to tell small groups what you are doing. We happened to be on top of the slide on the north end of South Park. It was sunny and brisk. We were eating Mexican food. His idea made us stop eating and start talking.

I remember that @Jack’s first use case was city-related: telling people that the club he’s at is happening. “I want to have a dispatch service that connects us on our phones using text.” His idea was to make it so simple that you don’t even think about what you’re doing, you just type something and send it. Typing something on your phone in those days meant you were probably messing with T9 text input, unless you were sporting a relatively rare smartphone. Even so, everyone in our group got the idea instantly and wanted it.

This telling from an Odeo developer helpfully points out that this session was one of several:

When it became clear that Odeo was not going to become a huge success in the podcasting space, there was a period of soul searching and hack days. One of those hack days, Jack, Noah, and Florian (another rails dev at Odeo), created Twitter. The initial version seemed interesting, Noah, Jack, and Florian kept working on it for several months, while the rest of the team stayed focused on Odeo.

This interview with Dorsey shows he really did have the essence of the idea years before, and had to wait for technology to catch up:

We were limited until 2005-2006 when SMS took off in this country and I could finally send a message from Cingular to Verizon. And that just crystallized — well, now’s the time for this idea. And we started working on it.

and again:

At that time, one of my co-workers introduced me to SMS (short message service), which I had never seen before. She used it all the time. Once I saw that, I’m like, ‘Whoa, this is awesome!’ This communication blew my mind, and the way she was using it blew my mind. I thought, What if we simply set status, archive it on the Web, use SMS to do it, and it all happens in real time? We all kind of went into a corner, wrote out a bunch of user scenarios, and started inviting co-workers in. They fell in love with it. We knew we had something.

A prototype was built in two weeks and Twitter was publicly launched almost four months later.

There’s a few lessons here for anyone creating product or service concepts. One is that slow hunches are slow and take time to evolve. Two, sometimes technology needs to catch up to ideas. Three, nurturing company environments like Odeo help these concepts take shape.

Four, obviously Twitter is a very emergent concept and less goal-oriented than even many startups would attempt; it feels more like a demo you’d see on a Labs page, except it just wouldn’t work on a Labs page. And it’s different than how we usually create concepts that require making money; the New York Times profile states, They freely acknowledged that they had no idea how people would use it or how it would make money. But they thought it had potential…

Click for a larger version…