The big news in our neck of the woods this week is the launch of Facebook’s Instant Articles. Although the handwringing about the open web and the future of publishing is important, there’s a tangential discussion going on in the web community that I find particularly interesting. It’s about the focus Facebook puts on the speed of the feature. It starts with the name Instant, and continues to play a big role in their marketing materials:

Articles load instantly, as much as 10 times faster than the standard mobile web.

Even the phrase “standard mobile web” is an interesting choice of words, and a subtle shot across the bow with a clear message: the web is sloooooooowwwwwww. Well, the web community took notice, and is gearing up for a fight. Here’s Jason Grigsby:

You can make your sites load faster or you can give complete ownership of your content to Facebook which doesn’t share your interests. Hmm…

— Jason Grigsby, ☁4 (@grigs) May 13, 2015

Tim Kadlec followed up with a great post called Choosing performance:

[The web is so slow at the moment] not because of any sort of technical limitations. No, if a website is slow it’s because performance was not prioritized. It’s because when push came to shove, time and resources were spent on other features of a site and not on making sure that site loads quickly.

This goes back to what many have been stating as of late: performance is a cultural problem.

I agree with them that this is the heart of the matter. Focusing on the instant aspect of the articles is a brilliant marketing move by Facebook. They looked at all the giant, slow, over-designed sites out there, saw an opportunity, and went for it. Let’s admit it: they won this round.

The big question now is: how are we going to respond? I think our best response is to fight fire with fire. Instead of trying to kill Instant Articles with the wrath of a righteous anger, let’s rather do something we should have done ages ago: prioritize performance. And Lara Hogan’s Designing for Performance is an excellent place to start.

Shaun McCormick describes Why the way we look at technical debt is wrong:

Technical debt is ok, and often a solid product strategy. The importance is getting to market. When launching a new system or feature, focus your effort and time on areas of the product that need to be agile, and move quickly through areas that don’t. Later, if the product proves that it can drive revenue, you can revisit those areas and improve if they need to scale.

This is an excellent sentiment, and I agree 100% in theory. The problem is that in most organizations, “later” = “never.” Or as Jeff Gothelf puts it, the biggest lie in corporate america is Phase 2.

That’s why I really like Henrik Kniberg’s concept of a “technical debt ceiling.” Read his post Good and Bad Technical Debt (and how TDD helps) for the whole explanation, but here’s a diagram that explains his point:

Source: Henrik Kniberg

This forces teams to pay attention to technical debt, and make a conscious effort to reduce it when it becomes a problem.

“Mobile first” is more about progressive enhancement and making important design hierarchy decisions than it is about thinking about small screens, so I don’t agree with the “outdated” bit in Paul Adams’s Why ‘mobile first’ may already be outdated. That said, he makes a good point about enterprise software:

Many businesses being advised to go all in on mobile screens, should consider how often they are accessed while people are at work. Software that people probably shouldn’t, but do, look at on their work computer: news, sports, social, messaging, personal email. The large screen matters.

Now imagine that you actually build software specifically for people to use at work. This may be software for getting work done, such as Google Docs, Intercom, Slack, Basecamp, Trello, etc. The likelihood now is that the larger screen is the most important one. The large screen app is more important than the mobile app. The mobile app plays a different role to the large screen app, and in many cases a supporting role.

I see this is in our user research all the time. If we do usability testing on our mobile apps, one of the first questions is always, “Will I be able to use this on my desktop”? For software that gets used mostly at work, focusing on desktop — as unsexy as it might sound — is still hugely important.

Emily Badger wrote a very interesting article on the politics of sunlight and shade in urban design. From In the shadows of booming cities, a tension between sunlight and prosperity:

For cities, shadows present both a technical challenge — one that can be modeled in 3-D and measured in “theoretical annual sunlight hours” lost — and an ethereal one. They change the feel of space and the value of property in ways that are hard to define. They’re a stark reminder that the new growth needed in healthy cities can come at the expense of people already living there. And in some ways, shadows even turn light into another medium of inequality — a resource that can be bought by the wealthy, eclipsed from the poor.

Andrew Thompson in Engineers of Addiction, a fascinating profile on the psychology of slot machines:

Game [slot machine] designers are charged with somehow summoning the ineffable allure of electronic spectacle — developing a system that is both simple and endlessly engaging, a machine to pull and trap players into a finely tuned cycle of risk and reward that keeps them glued to the seat for hours, their pockets slowly but inevitably emptying.

In other words, their job description is to make people win just enough so that they come back long enough to lose big. I just can’t wrap my head around that.

Thomas Schranz writes in Product / Market Fit is a Trap:

Obsessing about product/market fit is a huge waste of your time. Yes … waste of your time. There … I said it again. […]

As I said above you don’t want to focus on product/market fit. You want to focus on building a great product and on getting it into the hands of your customers.

First, let’s talk about tone. I’m pretty averse to absolute language like “it’s a trap” and “it’s a waste of time.” Things are rarely that dramatic, but I guess nuance doesn’t play very well on the internet. This is also the problem I have with proclaiming that “flat design is evil.” A good designer won’t let an aesthetic trend get in the way of affordance and visual hierarchy. A good designer will work within the constraints of a particular aesthetic to accomplish their (and their users’) goals.

But I digress. On to the substance of the post…

If you read Marc Andreeessen’s entire post on Product/Market fit, you’ll see that Thomas and Marc’s views are not in conflict at all. Marc might use slightly different language, but his definitions of product and market are very similar to what Thomas proposes above (my emphasis added):

The quality of a startup’s product can be defined as how impressive the product is to one customer or user who actually uses it: How easy is the product to use? How feature rich is it? How fast is it? How extensible is it? How polished is it? How many (or rather, how few) bugs does it have?

The size of a startup’s market is the the number, and growth rate, of those customers or users for that product.

Marc is using VC terms, but his meaning is clear: build a great product, try to get more people to use it (or as Thomas puts it elsewhere in his post: focus on product and distribution). It is up to us as product designers and product managers to figure out how to make that happen. Jobs to be Done, Personas etc. are fantastic ways to do that. But those methods are not opposing theories of startup success, as Thomas suggests. They’re a continuation (the how) of Marc’s Product/Market fit framework.

Steven Hoober has some great guidelines for touchscreen design in Fingers, thumbs, and people:

Most of all, within what you can control: Always design for hands, fingers, and thumbs.

And remember: You don’t design for iPhone or Android, for cars or kiosks, for Web or apps, but for people. Have empathy for users and respect their choices, their ways of working. Account for the limits of their lives, their environments and their abilities.

Even when your implementation is constrained by technology, avoid designing for pixels or code; always consider what effects your work will have in the real world, when people look at, hold, and touch the screen.

An interesting counter-argument to the #noestimates movement—and a call for reasonable software development estimates—on the Clever PM blog¹. From In Defense of Estimates:

From a business perspective, some level of estimation is absolutely required, so that judgment calls can be made as to priorities of execution and communications within the company and to customers. We need to have some level of understanding of whether something is “bigger than an elephant or smaller than a breadbox” so that we can deploy other parts of the organization appropriately. “It takes as long as it takes” is not useful for tactical or strategic planning within any organization.