In WordPress: How It Came To Be And Where It’s Heading Alex Moss interviews Matt Mullenweg and Mike Little, the two cofounders of WordPress. The whole interview is interesting, but their approach to technical debt caught my eye in particular:

We rewrite or refactor about 10 to 15% of WordPress in most releases, so that we can keep users getting updates and new features quickly, while doing the “ground up rebuild” incrementally in the background, fixing bugs and getting feedback as we go.

This is, in my experience, the best way to handle technical debt: pay down a little bit of it in every release. To steal a slide from my Product Management course, here’s my general rule of thumb (and of course there will be exceptions) for balancing a product roadmap:

Take care of the people you love, and try to make yourself known and understood. Dial it down, work with your hands, keep it quiet, and share what you know.

— Frank Chimero, This One’s for Me

In 16 days our family will walk out of an empty house in Cape Town and get on a plane to Portland, OR. It will be a one-way journey. I’ve been searching for the words to write about it, but I haven’t quite found the right ones. So I guess these ones will have to do.

I started my first blog in 2004. It was hosted on Windows Live Spaces, and it was terrible. I called it Leave The Great Indoors (yes, because of the John Mayer song and we just moved countries and just roll with it ok?). I have no idea what I wrote about back then, but I must have felt that there was something to this writing thing, because a year later I moved it to Blogger (because more features!). It still exists, but please don’t tell anyone.

The writing thing kept growing on me, and a couple of months later I started a UX-focused blog called UX-SA (because User Experience, and I’m from South Africa, and yes it’s a stupid name for a blog). That one also still exists, but again, please don’t tell anyone.

It was only in late 2009 that I got serious about it, bought a domain name (I don’t know what I was thinking — no one can pronounce Elezea), installed WordPress, and got stuck in. I proceeded to go through several identity crises, which included a move from Silicon Valley to Cape Town, 2 kids, and realizing that I’ll never learn how to deal with angry comments so I should probably turn those off.

One day I wrote a post that got mildly popular, and Jim Dalrymple linked to it from The Loop. He also must have subscribed to my RSS feed, because he has linked to the site a few times since then — something I’m still surprised by and incredibly grateful for every time it happens.

Some time after that a guy I’d never met, who lives in Portland, started following me on Twitter. He’s a regular reader of The Loop, and he decided to check out this guy who has the same last name as he does (let’s call him Rudolph, because that’s his name). We started chatting a bit, and when he came to visit his extended family in Cape Town we caught up for coffee. We kept in touch, as like-minded people are prone to do.

Last August my wife and I went to San Diego for a family reunion. I also set up some interviews because we were strongly considering moving there. But we took one look at California and realized we won’t be able to live there again (Cape Town kind of gets you addicted to leafy mountain beauty, and well, California). On a whim I gave Rudolph a call, and asked him if he thinks we should move to Portland. I’d been following him on Instagram for a while, and it looked like a nice place.

So this random guy I met on the Internet went to work and helped us figure out if Portland might be the city for us. A few months later I started looking for jobs there. Since I’d never been to Oregon I took a one-week trip to check it out and speak to some people in person. Of course I stayed with Rudolph and his lovely family.

I talked to several companies in Portland, but the conversations that kept sticking in my mind were the ones I had with HealthSparq, a healthcare transparency company that’s part of Cambia Health Solutions. I never thought I’d work in the healthcare field, but the team’s passion and vision won me over. So on April 13th I’m starting at Healthsparq as a Director of Product. Healthsparq’s president, Scott Decker, wrote a post the other day that’s a pretty good summary of why I decided to join them. From Health Care Transparency: Opening Up the Market:

It’s important that these new transparency tools provide robust information that people want to know in a way they can make actionable. While more and more health care data is being generated and released — from personal tracking devices to government and payer data — the information won’t be useful unless it is understandable and easy to navigate. These new transparency tools should provide as complete a picture as possible of price and quality, from the moment a person begins receiving care for a specific condition to the time when they no longer require treatment.

That’s a tough UX problem, and a vision I can get behind. I’m excited about the move to a new city with new beginnings and new things to explore — and a product I can believe in.

Anyway, I’m telling you the strange story of how this all happened because I’m worried that we don’t always appreciate how cool the internet can be. My decision to start a crappy blog in 2004 eventually led to a bunch of connections with fantastic people who decided to give me a shot (remind me to tell you about the day that Francisco sent me a DM to ask if I’d like to write for Smashing Magazine). This move wouldn’t have happened if I hadn’t met Jim and Rudolph online, and if they weren’t such nice people, and I can’t quite get my brain around how great that is.

We give the internet a lot of crap, and yes, it can be a vile place sometimes. But we’re moving to Portland because of relationships that were started and cemented on the internet, so I’m going to remain in awe of this technology that has the power to help us make each other’s lives so much better.

Giff Constable makes the case for validation and learning in the product development process before you launch something. From You Are Spending 3x-5x More Than You Should:

Agile/lean has helped people debunk the “big upfront design” phase, but far too many replace it with nothing. I agree that waterfall-style, big-upfront-design is a waste of time and money. I do believe that getting into the market with a designer and an engineer and learning is a critical use of time.

Lee Hutchinson, who was a system administrator at Boeing at the time of the space shuttle Columbia disaster in 2003, looks back at that tumultuous time in a long but absolutely fascinating article for Ars Technica:

In August 2003, the Columbia Accident Investigation Board (CAIB) issued its final report. Behind the direct cause of the foam strike, the report leveled damning critiques at NASA’s pre- and post-launch decision-making, painting a picture of an agency dominated by milestone-obsessed middle management¹. That focus on narrow, group-specific work and reporting, without a complementary focus on cross-department integration and communication², contributed at least as much to the loss of the shuttle as did the foam impact. Those accusations held a faint echo of familiarity—many of them had been raised 17 years earlier by the Rogers Commission investigating Challenger’s destruction.

The report also asked a team at NASA to figure out what a rescue plan might have looked like:

To put the decisions made during the flight of STS-107 into perspective, the Board asked NASA to determine if there were options for the safe return of the STS-107 crew.

The rest of the article explains the possible rescue plan in detail. If you have any interest in science or space exploration this is a must-read.

I found the article particularly interesting because I had just finished reading my favorite novel of the year so far: The Martian by Andy Weir. The article echoed a lot of the concepts mentioned in the novel, which gave me a new appreciation for the story. I highly recommend this surprisingly plausible and funny book as well.

One of my favorite articles of the year so far is Zachary Crockett’s The Invention of the AeroPress:

The AeroPress was conceived at Alan Adler’s dinner table. The company was having a team meal, when the wife of Aerobie’s sales manager posed a question: “What do you guys do when you just want one cup of coffee?”

A long-time coffee enthusiast and self-proclaimed “one cup kinda guy,” Adler had wondered this many times himself. He’d grown increasingly frustrated with his coffee maker, which yielded 6-8 cups per brew. In typical Adler fashion, he didn’t let the problem bother him long: he set out to invent a better way to brew single cup of coffee.

It might sound like an article about coffee, but it’s more about entrepreneurship, product design, and the sheer tenacity of true inventors. Great read.

A few months ago I wrote about the forces at work when people choose a product. I discussed the Jobs-To-Be-Done concept of Progress-Making Forces, and shared this diagram to illustrate what happens when we try to get people to use our product instead of someone else’s:

In this article I want to discuss this framework in the context of a practical example: WhatsApp vs. Instagram Direct (now both owned by Facebook). I started thinking about this recently after MG Siegler wrote his post Going Against The Grain:

We’re seeing over and over again now that the behemoths can’t simply add a startup’s functionality into their own app as a feature and kill said startup. But it’s equally important to note that if you are able to establish your startup, especially those in app form, it may be hard to get your users to do anything other than what they originally came to do. Especially if the new functionality is against the grain in any way.

So, let’s consider this statement in the context of the Progress-Making Forces, and apply it to Instagram’s decision to add private photo sharing with Instagram Direct. First, let’s talk about existing photo sharing behavior. How do people currently send photos to each other? Facebook used to be the king of photos, but people are increasingly using messaging apps for this instead:

WhatsApp is processing 500 million images per day, compared to 400 million Snapchat (“snaps”) per day, which could include photos or videos. For its part, Facebook processes a comparatively paltry 350 million photos a day.

Enter Instagram Direct, a way for Facebook to try to claim back some of the private photo sharing pie. That’s the new behavior in the context of the the forces diagram. So the big question for Facebook is this: How do you get people to move their private photo sharing from WhatsApp (existing behavior) to Instagram (new behavior)? According to our framework, the progress-making forces need to be stronger than the progress-hindering forces, so let’s look at each force in turn:

• Push of the situation. Is there anything people are not able to do by sending photos through WhatsApp that they wish they could do? It doesn’t seem that way. Some of the biggest advantages of using WhatsApp for photos are that (1) it’s completely private, and (2) it ties into your phone’s camera roll, so you have access to any photo, not just the ones from a particular app.
• Pull of the new idea. Is there anything in Instagram Direct that could entice people away from WhatsApp? Again, it doesn’t look like it. Using Instagram Direct is simply more work than using WhatsApp for photos. If the photo isn’t in Instagram yet you have to import it. You have to apply a filter because that’s what you do in Instagram. Only then can you send it. But then the entire conversation is centered around photos. You still have to use WhatsApp for text messaging. So now you’re communication is fragmented, while it’s all seamlessly integrated in WhatsApp. There’s no pull here.
• Allegiance to current behavior. How strongly are people attached to their WhatsApp experience? Extremely. The benefits of having all conversations and photos centrally located in WhatsApp can’t be overstated. You’re not just sending photos, you’re talking about life. It becomes a timeline of your relationships, and everything is there.
• Anxiety of new solution. How worried are people that the shift would ruin their experience? Well, it seems there would be quite a bit of anxiety involved in moving to a product that doesn’t support the functionality you’re used to, and sits within a walled garden.

This analysis clearly shows that while the progress-making forces for moving people to Instagram Direct are relatively weak, the progress-hindering forces are extremely strong. This keeps people glued to WhatsApp, and it explains Instagram Direct’s apparent failure.

So what happened here? I think Facebook realized that they won’t be able to change people’s existing photo-sharing behavior. And that’s why they bought WhatsApp.

I really enjoyed Nick Stockton’s exploration of the space syntax concept in architecture in There’s a Science to Foot Traffic, and It Can Help Us Design Better Cities. He explains:

Space syntax [is] the science of how cities work. In the late 1970s, British architects Bill Hillier and Julienne Hanson hit on the idea that any space within a city — or the entire city itself — could be analyzed in terms of connectivity and movement. They reasoned that a city’s success depended largely on how easy it was for people to move about on foot.

This wasn’t a huge revelation. Studies reaching as far back as 1960s have shown walkable cities have higher property values, healthier residents, and lower crime. What set Hillier and Hanson’s ideas apart was the notion that a city’s geometry did more for movement than any other design factor. They argued that every other cog in a city’s engineering depends on the walkable grid. Cars, buses, trains, and bikes play a role, too, but only as much as they transport people to places where they then proceed to walk around.

There’s some great examples in the article, including a case study on the redesign of Trafalgar Square in London.

Peter Seibel discusses data-driven design at Etsy in his post Building websites with science. After going over the dangers of relying solely on A/B testing for product decisions, he concludes:

Ultimately the goal is to make great products. Great ideas from designers are a necessary ingredient. And A/B testing can definitely improve products. But best is to use both: establish a loop between good design ideas leading to good experiments leading to knowledge about the product leading to even better design ideas. And then allow designers the latitude to occasionally try things that can’t yet be justified by science or even things that my go against current “scientific” dogma.

This echoes Julie Zhuo’s thoughts in The Agony and Ecstasy of Building with Data:

You can’t A/B test your way into big, bold new strategies. Something like the iPhone is impossible to A/B test. If you had asked people or invited them to come into the lab to try some stuff out, they would have preferred a physical keyboard to a virtual one. If you had them use an early prototype of the touch screen where not every gesture registered perfectly, it would have felt bad and tested poorly. […]

Data and A/B test are valuable allies, and they help us understand and grow and optimize, but they’re not a replacement for clear-headed, strong decision-making. Don’t become dependent on their allure. Sometimes, a little instinct goes a long way.

This all relates back to the difference between variation (trying out different ideas) and iteration (small changes to improve an existing idea). A/B testing is great for iteration, but not for variation. For variation we need our brains, and lots of paper and pencils.