Benedict Evans wrote a characteristically brilliant analysis in What does Google need on mobile? Here’s a taste of his conclusion about Google’s challenge going forward:

The key change in all of this, I think, is that Google has gone from a world of almost perfect clarity—a text search box, a web-link index, a middle-class family’s home—to one of perfect complexity—every possible kind of user, device, access and data type. It’s gone from a firehose to a rain storm. But on the other hand, no-one knows water like Google. No-one else has the same lead in building understanding of how to deal with this. Hence, I think, one should think of every app, service, drive and platform from Google not so much as channels that might conflict but as varying end-points to a unified underlying strategy, which one might characterize as ‘know a lot about how to know a lot’.

Don’t miss this article, the whole thing is great.

Marty Cagan continues his excellent product autonomy series by discussing what happens when teams get large enough to split up their code bases. In Autonomy vs. Ownership he describes his preferred way of dealing with the situation where a team needs a change in a different codebase to get one of their features implemented:

The alternative model is informally known as the “open source” model although to be clear this is not about open sourcing your code, it’s just called that because this is how much of the open source community operates. In this model, if the drivers team needs a change to the riders team’s code, then they could either wait for the riders team to do it, or they can actually make the change themselves, and then request that the riders team review the change, and include it if they’re okay with it (known as a “pull request”). This means that you are telling the software management system that you’ve made a change to the software, but the owner of that software needs to review the changes before they are actually approved and incorporated.

I’m a long-time Pinboard fan, and from the moment I became a paid user I couldn’t shake the feeling that it is one of the most underrated services out there. It’s basically the center of my personal internet. I have years of articles tagged and cached, and available immediately whenever I need to remember something. For me, it represents the best of what technology has to offer as an “external brain”¹.

But it’s even more powerful than that. I recently started wondering if Pinboard could become more central in my blogging workflow as well. My flow when I find an article I want to write about used to be two steps: (1) save to Pinboard, and then (2) start a new text file (with an excerpt from the article) and start writing.

Since I don’t always have time to write immediately after I read something, the disjointedness of these two steps means that I forget to post articles sometimes — or that I can’t remember which part I want to write about. So I needed a way to save Pinboard links for later, in a way that lets me pick up writing whenever I have time.

The solution I came up with isn’t rocket science, but it has made such a big difference to the way I write that I wanted to share it here. The key is a simple IFTTT recipe that takes any new link I save to Pinboard and creates a Markdown-formatted text file that I can use to start writing whenever I want to.

Here is a link to the IFTTT recipe: Post any new Pinboard link to a new text file in Dropbox.

And this is what it does:

I always put a pull quote in the “Description” field when I save a Pinboard link, so the recipe creates a text note with a Markdown-formatted URL, the pull quote, and space for me to add a title, slug, and excerpt once I’m ready to post to the site. Putting the note in a Dropbox folder means I can continue typing and editing on any device — I use Editorial on iOS and nvALT on Mac.

As for posting… I still haven’t found a mobile blogging platform that works for me, so even though I write many posts on my iPhone or iPad, I still post exclusively from MarsEdit. So I also went one step further and made a Keyboard Maestro macro (download here) that transfers the text from nvALT to MarsEdit as soon as I’m ready to post.

You know, the internet is pretty cool sometimes.

Interesting thoughts from Steven Levy in What the Apple Watch Means for The Age of Notifications:

Done right, notifications are a wonderful Feed of Feeds, weeding out the stuff you really need to see from all the usual chaff in the stream.

But it’s hard to do this right when every single app wants to send you notifications. Even given that the system will limit itself to notices worthy of instant notice there are just too many notifications elbowing their way into what should be a narrow passage labeled, “Stuff I absolutely need to see.”

This decreases the value of all notifications.

Gmail has tried, but no one has really figured out the algorithms required to figure out what qualifies as “Stuff I absolutely need to see.” This is the holy grail of notifications at the moment.

Jason Kottke wrote what I guess can be described as a review of Apple Watch reviews. He makes a particularly interesting point about the common assertion that we’ll start using our phones less because of the watch. From Apple Watch and the induced demand of communication:

In the entire history of the world, if you make it easier for people to do something compelling, people don’t do that thing less: they’ll do it more. If you give people more food, they eat it. If you make it easier to get credit, people will use it. If you add another two lanes to a traffic-clogged highway, you get a larger traffic-clogged highway. And if you put a device on their wrist that makes it easier to communicate with friends, guess what? They’re going to use the shit out of it, potentially way more than they ever used their phones.

He also quotes from the same article I had a visceral reaction to in The Apple Watch won’t save you time. In that article I made a similar point:

I’m not saying the Apple Watch won’t be wildly successful, or that I don’t want one — I definitely want one. I just don’t think we should fool ourselves into thinking it will somehow give us more time because we might look at our phones less. If history teaches us anything, it’s that we’ll find a way for the watch to fill up our “saved” time in other ways — and then some.

My daughters love the Toca Boca apps—especially Robot Lab. Ingrid Simone’s article on their approach to gender is great. From Gender in Play: How Toca Boca Creates Apps for All Kids:

Toys have a large impact on how kids play together and relate to other kids. But kids of today are fostered into watching different shows and playing with different toys according to their gender.

We know that when a toy reaches a child a choice has already been made for them, someone has picked a blue or pink toy, an action figure or a doll. We believe this is limiting to kids, not to be able to decide on your own what your interests are, and that gender-targeted toys create an unnecessary barrier between girls and boys. And we believe that girls and boys, brothers and sisters want to play together!

And on the redesign of Robot Lab specifically:

Since the robot theme has historically been so targeted towards boys, we felt like we, as many before us, had somehow fallen in the trap of using conventional “boyish” colors, shapes and attributes. And we really wanted to see if we could make the app more appealing to both boys and girls.

Alina Senderzon defends realignment strategies in Resist the Redesign:

Yet, designers are quick to jump on redesign opportunities—after all, it’s exciting to start anew. In reality, however, a redesign isn’t always the right solution to the problem. The roadblock for users may lie in the pricing of your product, which could be discovered through customer development. Or your messaging isn’t compelling and could be saved by some clever copywriting. Or maybe customers feel compelled to convert, but the checkout process is too long and needs to be streamlined. Any number of changes could generate dramatic value for the business, and though they likely involve some design decisions, they rarely require a clean slate.

This is similar to the approach I wrote about a couple years ago in The Data-Pixel Approach To Improving User Experience.

If I link to a listicle, it has to be good enough to overcome my unnaturally strong negative feelings about those types of article. Alas, Mike Fishbein’s 4 steps to make experimentation a repeatable process in your business is that good. It’s a great overview of the importance of hypothesis testing over “requirements gathering” in product management:

Most new products fail, and most frequently because they do not meet user needs. Running experiments helps product managers validate customer demand for a product concept earlier in the product lifecycle.

By running experiments instead of launching a minimum viable product, product managers in large organizations can gain more autonomy, limit risk and brand exposure, and gain user insights even earlier in the product lifecycle. With this speed to user insight, product managers become better informed to build successful products.

I also especially liked this bit:

In the next evolution of product management, the product leader’s role shifts from making bold assumptions to fostering a culture that encourages learning in an efficient and effective way.