I’ve been spending a lot of time thinking about how product design decisions aren’t neutral. The way we design a product has a direct effect on how people use it. This is obvious, but I think we often forget the real implication: Design wants something from its users. And we are the architects of those wants. We have a direct impact on user behavior, and we need to recognize the weight of that responsibility.

Let’s look at some recent product changes on Twitter as an example.

In October 2013, Twitter introduced more visual tweets, with photo previews within the timeline. It’s almost hard to imagine now, but before they introduced this you had to click on a link before you could see a photo.

This change had an immediate effect on how people used the product. I’m sure some of it was intentional — people began to tweet a lot more photos. Some of it was probably not intentional but still made sense: social media marketers caught on to the fact that if they attach a photo to an article tweet, they’ll get more attention since the tweet will take up more screen real estate. A little annoying, but ok, so far so good.

But then there was what must have been a fairly unexpected behavior change. People started to use screen shots of text to bypass Twitter’s 140 character limit. At first, only a few people did it. But then publishers and marketers started to notice, and it took off:

Yes, it’s crazy to share text as images on Twitter. But, look at the engagement increase: https://t.co/VRVglh6Bei https://t.co/ePo3pGtep0

— Chris Dixon (@cdixon) November 20, 2014

Some have even come up with guidelines for the best way to stand out in these “textshots”:

Following an exchange with MG Siegler a while back, I settled on a specific textshot style: sans-serif text with a sepia background pulled from Pocket. The idea of using the app’s sepia theme for these came from MG, who noticed that yellow screenshots had more contrast in Twitter’s native apps.

I’ll admit, the temptation to do this is strong. Earlier this week I used a textshot and it became my most retweeted tweet ever:

This post by @scottjenson on empathy in design is so good: “The Paradox of Empathy” - http://t.co/9mYXqWEVP0 pic.twitter.com/J3lekmt5DW

— Rian van der Merwe (@RianVDM) February 24, 2015

Nice, right? Win!

But wait… Let’s step back for a moment and have a look at the metrics on that tweet of mine:

Almost 25,000 impressions, with a 0.9% click-through rate. That’s worse than a crappy banner ad, and it’s the sum-total of the amount of traffic I sent to Scott’s excellent post. As Derek Thompson points out in The Unbearable Lightness of Tweeting:

Is the social web just a matrix of empty shares, of hollow generosity? As Chartbeat CEO Tony Haile once said, there is “effectively no correlation between social shares and people actually reading.” People read without sharing, but just as often, perhaps, they share without reading. […]

There used to be a vague sense that Twitter drives traffic, and traffic drives renown (or fame, or pride, or whatever word defines the psychic benefit of public recognition). Instead, the truth is that Twitter can drive one sort of renown (there are some people who are Twitter-famous), and traffic affords a different psychic currency. But they are nearly independent variables.

All of this culminated in Medium’s Text Shots announcement yesterday:

So there you have it. There is now a very real chance that most of our Twitter timelines will become nothing but screenshots of Medium articles that no one reads. That doesn’t help Medium, it doesn’t help authors, and it frankly doesn’t help us to experience and learn, which is kind of the point of reading. This trend does help Twitter, though. Quoting from The Unbearable Lightness of Tweeting again:

In the last month, I’ve created nearly 2 million impressions for Twitter. Whether that is good for my Twitter persona and my pride is a qualitative question whose answer resides outside the bounds of an analytics dashboard. But it is quantitatively not a good deal for The Atlantic. Something I already suspected has now been made crystal clear: 99 percent of my work on Twitter belongs to Twitter.

Twitter is a business, and impressions are how they make money, so this isn’t inherently evil or wrong. But Twitter is, if nothing else, not what we think it is. Not to get too curmudgeonly about “early Twitter”, but there was something amazing about the 140 character limit. Something about the constraint that brought out people’s creativity. And because it was all text, timelines were easy to scan. Now, all of that is different.

Putting all my personal feelings about this trend (and its implications on traffic and reading) aside, it’s time I get to the point. This fundamental change in the way Twitter is used can all be traced back to a single, fairly simple design decision back in 2013: expanding photos natively in the timeline. Without that change, none of this would have happened.

As designers we can’t possibly know how all the ways our decisions will affect behavior in a product. But we have to, at the very least, recognize that design has an opinion, and that it wants people to behave a certain way. I like the way Jared Spool phrases this:

Over the last year, we’ve started explaining design as “the rendering of intent.” The designer imagines an outcome and puts forth activities to make that outcome real.

We have a responsibility to do our best to ensure design wants things that are good for users as well as the business. We have to think ahead as much as possible, because what design wants is up to us. And once it wants the wrong things, it might be too late to change.

In my latest column for A List Apart I discuss our obsession with “managerial tracks” in career development, and propose something different. From Managing and Making: It Doesn’t Have to Be One or the Other:

I think we need a career system that encourages people to oscillate between individual contributor roles and manager roles. Maybe we provide “manager sabbaticals” where a manager becomes an individual contributor on a team for six to nine months. Maybe when a manager goes on vacation, an individual contributor takes on their role for a period of time (or for the duration of an entire project). I don’t know exactly what this looks like yet, but I think it’s important for us to figure it out.

I explain why in the article. I’d also like to point out that my original title for the piece was “Managing and Making: It Doesn’t Have To Be A Dirty Dance”, and it featured this photo:

I’m really glad my editor talked me out of it. It’s not good to make jokes that only people who grew up in the 80s will appreciate.

It’s a good joke, though.

Another possible origin is the president of Kal Kan Pet Food, who was said to eat a can of his dog food at shareholders’ meetings.

— Eating your own dog food on Wikipedia

In software circles dogfooding is usually encouraged — and for good reason. When companies force themselves to use their own products extensively it can have some great benefits. Since internal users visit even the darkest, most neglected corners of a product, bugs tend to be found and fixed much faster than waiting for reports from end users. Employees are also often the most critical users of their own products, so they are driven to make it better and will often have some fantastic ideas.

However, I’ve started to see a dangerous side effect of dogfooding that can sneak up and do huge damage to a product if we’re not careful. Here’s the problem. If we use our own products all the time we become such overly advanced users that we’re eventually unable to separate our own needs for the product from those of our target market.

Most users of our products don’t eat, sleep, and drink the ins and outs of the features we slave over every day. They dip in and out to buy something, or upload something, or quickly edit a photo. So in a really unfair and ironic turn of events, the more we use our own products the less we’re able to think like our users. It sucks, but it’s unfortunately the way it is.

We all repeat the mantra “I am not the user” to each other, but we tend to forget that the way to solve that particular problem is not to morph into advanced users, but to spend more time with actual users. It’s already so hard for us to put ourselves in the minds and shoes of our users. Dogfooding makes this even harder by lulling us into a false sense of security that maybe — just maybe — we are the user after all.

So, be careful. By all means use the crap out of your product — you wouldn’t be pouring your life into it if you didn’t love it. But once you start demanding features that would make your life easier, stop yourself. Be critical of your own motivations. Look at analytics and figure out if yours is a common use case or something reserved for the 1%. Contact your friendly neighborhood user researcher and ask them if they’ve validated the need for said feature. Hold on to your demand with open hands, and let it go if you realize it’s not something that would improve the product for target users.

In short, keep dogfooding — but don’t assume that all dogs will like the new flavors you’re proposing.

Paul Ford wrote a great post about the significance of the blue/green bubbles in the Messages app on iOS. From It’s Kind of Cheesy Being Green:

This spontaneous anti-green-bubble brigade is an interesting example of how sometimes very subtle product decisions in technology influence the way culture works. Apple uses a soothing, on-brand blue for messages in its own texting platform, and a green akin to that of the Android robot logo for people texting from outside its ecosystem. […]

There are all sorts of reasons for them to use different colors. (iMessage texts are seen as data, not charged on a per-text basis, and so the different colors allow people to register how much a given conversation will cost—useful!) However, one result of that decision is that a goofy class war is playing out over digital bubble colors. Their decision has observable social consequences.

This then turns into a post about product management, in a way that only Ford can do. Great stuff.

I’m as fascinated with Slack’s rise to prominence as most people, so I really enjoyed From 0 to $1B - Slack’s Founder Shares Their Epic Launch Strategy (no byline). It’s full of fantastic product strategy advice, including on the importance of user feedback:

As much information as Slack put out to customers, they learned even more themselves. Butterfield and his cofounders are voracious readers of user feedback, and they attribute much of the company’s rapid traction to this skill. From the get-go, Slack made sure that users could respond to every email they received, and approached every help ticket as an opportunity to solidify loyalty and improve the service. As they listened to their ever-growing flock of users, the Slack team iterated accordingly.

And also remember that sometimes people are going to use a product differently than what you had in mind:

“Sometimes you will get feedback that is contrary to your vision,” Butterfield says. “You may be trying to drive in a particular direction that people don’t necessarily understand at first. In our case, we knew the users we had in mind for this product. So in the early days, we looked at our customers, really just testers at that point, and we paid extra attention to the teams we knew should be using Slack successfully.”

It’s worth reminding ourselves that @-mentions and hashtags on Twitter were user inventions, not something the company came up with themselves. Always follow your loyal users…

There is so much wisdom in Paul Adams’ Lessons learned from scaling a product team, but my favorite part is the clear articulation of accountability. All companies should have something like this:

• If the analysis of the problem to be solved is incorrect, it’s on the PM. Ensure appropriate research is done.

• If the design doesn’t address the problem, it’s on the Designer. Ensure you understand the research and problem.

• If the design solves the problem, but doesn’t fit with Intercom, deliver best practices, or is otherwise weak, it’s on the Designer. Ensure you understand our beliefs, patterns and principles.

• If engineering doesn’t deliver what was designed, or delivers it late, it’s on the Eng Lead. Ensure you understand the problem being solved and design, plan appropriately and accurately before writing code.

• If it goes out with too many bugs and broken use cases it’s on the PM. Ensure the team test realistic usage and edge cases.

• If the team is spending too much time on fixing bugs and not adding new value per our roadmap, it’s on the Eng Lead. Ensure each project improves overall code quality.

• If we don’t know how it performed, it’s on the PM. Ensure success criteria are defined and instrumented.

• If it doesn’t solve the problem, it’s on the PM. Ensure there is a plan to improve product changes that don’t fully solve the problem.

In other words, the buck mostly stops with Product Management…

I just posted another excerpt from Making It Right to Medium. It’s called How to avoid building products that fail, and it’s all about starting the product development process at the right place:

When it comes to building products, the starting point is — always—needs. Not what we assume would be cool, but what users or the business need to be successful. […] One of the biggest mistakes we can make in product development is jumping to execution before an appropriate planning cycle has been completed, so we need to give planning the attention it deserves.

There are a few controversial ideas in Benjamin Sandofsky’s You Can’t Go Home Again, in which he basically says that Agile methodologies shouldn’t be used in mobile app development. I did find this perspective on QA interesting in our increasingly post-QA world:

Sit down with a software engineer from anywhere but the web, and ask them about QA. Tell a game developer you don’t need it, they’ll tell you you’re nuts. Maybe these agile people have been burned by bad QA, but a great QA team is far from a bunch of monkeys clicking buttons all day.

Formal QA provides a counterpoint to “move fast and break things.” Their job isn’t to say, “No.” It’s perfectly fine to ship bugs– otherwise software would never ship. You need someone who is aware of all the bugs, and help you make the decision if the risk is worth it.

Also see Michael Lopp’s The QA Mindset for some really good perspective.

David Cancel has some interesting thoughts on how they split up product management and tech team responsibilities in How we transformed HubSpot into a Product Driven Company. I really liked this part about embedded designers:

While we kept the core technical team tight, they were bolstered by the presence of embedded product marketers and UX designers all fixed on the same problem and solution. Designers and UX researchers informed the product teams from the point of mockups, through testing phases, to the ultimate release and support the product. […] The upshot here is that product teams become wholly self-sufficient organisms. They are small enough to retain customer focus but still have the skilled resources they needed to design, test and market the solutions they developed.

That post led me to Jeremy Crane’s What does a Product Manager do at HubSpot, which goes into more detail on the PM/Tech team split:

Every product team’s job is, essentially, to solve problems for their customers. Solving problems involves two key components: (1) Understanding the problem, and (2) creating the solution. At HubSpot the product manager owns the “problem” and the technical team owns the “solution.”  The “problem” is defined by whatever is likely to produce the greatest value to the customer and the business at large within the area of influence. The “problem” is both long-term and short-term in scope. It addresses the immediate challenges that the customer is experiencing, while still keeping an eye the longer-term vision of the product as a whole.

Scott Sehlhorst makes some very good points about different levels of roadmap detail in Opposite Views of a Product Roadmap:

Depending on your role in your organization you will be biased towards viewing your roadmap either as a view of what the team will be building into your product, or a view of why the team will be building things into your product.  As a product manager, it is imperative that you can view it both ways.

When it comes to what you’re building, the roadmap gets less precise as you move further out:

I describe rolling-wave planning as being precise about the immediate-term future, having less specificity about the near future, and being nonspecific (but still helpful) about the more distant future. This is because – from the perspective of someone focusing on what they will be doing – there is too much uncertainty about what will happen between now and the future. (BTW, this is where waterfall is wasteful – it assumes incorrectly an ability to predict the future in detail.)

In contrast, when it comes to why you are building what you’re building, it starts off fairly broad and becomes more precise as you go on:

In the “right now” the team is testing hypotheses. Given a customer, and a problem the customer is trying to solve, there is a hypothesis about how best to help. That hypothesis is a design. The design may or may not be a good one. The implementation of the design may be great, adequate, failing, or incomplete. In this time horizon, the activities of the team building the product are concrete – build, test, learn.

The way I would summarize Scott’s post is as follows. When it comes to product planning, be rock solid on what problems you’re solving for which customers, but be open to data-informed change when it comes to short-term implementation details.