Virginia Heffernan’s A Sucker Is Optimized Every Minute is a deeply cynical, extremely funny rant on our obsession with data:

These days, optimizers of squeeze pages, drawing lessons as much from the labcoats at Optimizely as from the big daddies at Google, recommend creating a three-to-10 minute video that’s introduced by a “magnetic headline” (“Find the Perfect Lampshade for Any Lamp”) and quickly chase it with an “information gap” like “You’re Not Going to Believe the Trick I Use While Lampshade Shopping.” (Article of faith among optimizers: humans find information gaps intolerable and will move heaven and earth to close them.) Next you get specific: “Click the play button to see me do my lampshade trick!” — after which the video unspools, only to stall at the midpoint with a virtual tollbooth. You can’t go on unless you hand over an email address. Presto.

A sucker is optimized every minute.

My day didn’t start great. The first thing I read was Michael Dubakov’s statement about enterprise software people (i.e., people like me) in Enterprise software vendors have no taste:

My current theory is that enterprise software vendors have no taste. CEO, VP of development, Product managers that focus on enterprise market — all of them have no fucking taste. There is no taste in companies [sic] DNA, nobody cares about design and aesthetic. Profits, revenue, sales and new features — yes! Beautiful design — no.

Nobody, you guys. Literally nobody. I guess I don’t blame Michael for this false cause fallacy. It sure seems like a logical conclusion: product bad, therefore product person bad. As with most things, though, it’s more complicated than that.

Let’s start with the most difficult thing about designing in the enterprise space: in most cases, the people who buy the software and the people who use the software are completely different, and therefore have completely different needs. This is not a problem in the consumer market, where the person who gives you money is usually also the person who uses your product.

The people who buy enterprise software — IT managers, HR managers, etc. — care about things like configurability, control, more features than a competitor, and most of all: the ability to customize the thing just so, so that it fits in with whatever systems already exist. End users care about none of those things. They care about getting a job done as quickly and with as much enjoyment as possible.

So, what happens is what happens in most organizations that rely on outside sales. Many Sales teams go out and sell things that don’t exist in the product. And they often sign contracts that have two things in it that make designers wake up in a cold sweat: (1) a list of features (or — ugh, I hate this term so much — “product requirements”), and (2) delivery dates.

Product people then have to fulfill the needs of the contract/promise (as opposed to the needs of end users) in never enough time. Instead of having the time to understand a problem and user needs, building hypotheses and testing them, and taking time to iterate, they make a thing to hit a deadline and then move on to the next thing that has a deadline.

And that’s why enterprise software looks the way it looks. It’s not that product people don’t have taste. It’s that they don’t have agency.

But, I do want to say, there are welcome signs that this is changing. There is a new realization that the needs of buyers and end users can co-exist peacefully, and the result is better products. As an example, our new CEO is a huge advocate for design, and is pushing the organization to create “simple, smart, beautiful products.” This will take time, of course, but if you look at the new suite of apps that we’re working on, you’ll see that these are starting to look more like consumer products.

There are other things I think we can do to help along this shift:

• Train sales teams on the ins and outs of product development. How prioritization works, how long things generally take, what the major user needs are that the product is trying to solve, etc. If they have more knowledge about how their promises affect the teams, it will go a long way to change behavior.
• Spend as much time with end users as possible, record the sessions, and share it widely. Nothing gets an organization riled up about good design like seeing end users struggle with a product.
• Start on a small product that no one cares about (like the mobile site maybe?). Follow a Lean UX process (or whatever methodology you subscribe to). Build it well, and show people the results. Then start moving the process into other areas.

So, anyway. Yeah, enterprise software is still, for the most part, pretty bad. It’s time for us to break out of the constraints of the past that caused that, and do something better. It’s actually a good time to be in enterprise software. There’s so much opportunity, and a newfound agency for designers. I’m optimistic. The day can only get better from here.

Steve Barnett makes some great points on long-term planning in Plans, Details, Dates, and The Future1. I especially like the point about how user research fits into planning:

Before development starts on a new bit of work, you should be building prototypes and doing user testing with them. This always results in some changes to the plan, and often results in rather large charges. You can’t plan what these changes will be: you don’t know until you’ve done your user testing.

---

1. And bless his heart for using an Oxford comma. ↩

Rune Madsen wrote a really interesting post on how our design methods need to change when we work in software (as opposed to print). He explains in the post On meta-design and algorithmic design systems:

So what is meta-design? In a traditional design practice, the designer works directly on a design product. Be it a logo, website, or a set of posters, the designer is the instrument to produce the final artifact. A meta-designer works to distill this instrumentation into a design system, often written in software, that can create the final artifact. Instead of drawing it manually, she is programming the system to draw it. These systems can then be used within different contexts to generate a range of design products without much effort.

I’ll add my vote for the need to spend much more effort on design systems (like Atomic Design) upfront, to standardize (and eventually speed up) later development.

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…

Putting the linkbait title aside, Steve Denning’s The Dumbest Idea In The World: Maximizing Shareholder Value1 is a really interesting article about the difference between “real markets” and “expectations markets”:

In today’s paradoxical world of maximizing shareholder value, which Jack Welch himself has called “the dumbest idea in the world”, CEOs and their top managers have massive incentives to focus most of their attentions on the expectations market, rather than the real job of running the company producing real products and services.

And that comes at the expense of customers. This sentence also stood out for me:

Unfortunately, as often happens with bad ideas that make some people a lot of money, the idea caught on and has even become the conventional wisdom.

---

1. Link is to the print version because the Forbes site is so unreadable ↩

In Netflix’s Secret Special Algorithm Is a Human Tim Wu writes about the importance of human intervention in data-driven decision making:

Of course, there is a big difference between using data in combination with intuition and relying entirely on an algorithm—the decision-making equivalent of Siri finding gas stations near you. I don’t think anyone—Netflix, Mitt Romney—makes big decisions that way. As Chris Kelly, the C.E.O. of Fandor, an indie-film Internet channel told me, “It just isn’t true that you can rely on data completely.” Even Google, the champion of algorithms, employs substantial human adjustments to make its search engines perform just right. (It cares so much about this that Google claims First Amendment protection for its tweaks.) I do not doubt that companies rely more on data every day, but the best human curators still maintain their supremacy.

It’s a good reminder that following data blindly is a pretty bad idea. Joshua Porter’s Metrics Driven Design is stil the best presentation I’ve seen on this topic and how it relates to design.

Richard Seroter’s 10 Architecture Tips From “The Timeless Way of Building” is highly relevant to software development as well:

“Each building when it is first built, is an attempt to make a self-maintaining whole configuration … But our predictions are invariably wrong … It is therefore necessary to keep changing the buildings, according to the real events which actually happen there.” (p. 479-480) The last portion of the book drives home that fact that no building  (software application) is ever perfect.  We shouldn’t look down on “repair” but instead see it as a way to continually mature what we’ve built and apply what we’ve learned along they way.

Just as buildings need “repair”, software takes iteration to get right.

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.