Good thoughts from Martin Eriksson on how the PM is not The Boss. From Product Management is a Team Sport:

The bottom line is that everyone in the company owns the product, and its success or failure lie in the hands of everyone who touches it. A product manager’s job is to lead the team to tackle the product challenges together, to get the best out of everyone on the team when building the product, and to provide a gentle hand to keep it all consistent and going in the right direction.

Ben Melbourne’s UX Designers: Why are we Wasting Time? is a great post on lean methodologies and Lean UX in particular. Of course, I especially like this point:

No amount of text or slides will ever replace the richness of observing your target audience first-hand. Take your client/team out in the field with you, or you’re greatly reducing the value of your research. Seeing a user point out the flaws in your product is the quickest way to convince a CEO to drop his pet feature.

I’ve been thinking about the topic of my latest A List Apart column for a while, but I was just too scared to write it. I mean, what right do I have to talk about work and privilege? But I ran the idea by my amazing editor, and since she was really supportive and enthusiastic about it, I went for it.

So I wrote Why?:

Why we work—and what kind of work we do—is a function of our privilege and our history as much as it is a function of our choices and our dedication.

I hope you enjoy reading it, and take something from it. This one took a while to get right.

Aaron Shapiro makes some interesting observations in The Next Big Thing In Design? Less Choice:

Technology has revolutionized the way we live our lives and do business, but it has done a terrible job reducing the stress of so many decisions. Industry by industry, great digital design has eliminated middlemen from the economy and put users in control, making it fast and easy for us to determine what we want and purchase it directly, whether on a computer or over a phone. Now, with unlimited opportunities for decision-making, we have essentially made ourselves the middlemen in our own lives.

The enjoyment, and even fetishization, of the beautifully designed experiences we rely on to make these decisions has distracted us from our original goal of simplifying our lives. We’ve forgotten that the ultimate purpose of an interface is to make things simpler.

That last sentence is interesting. “We’ve forgotten that the ultimate purpose of an interface is to make things simpler.” I understand and agree with the sentiment, but the statement got me thinking about how I would define the purpose of a user interface.

In the context of modern UI design I would probably want to adjust that statement a little bit to say that, “The ultimate purpose of an interface is to enable users to accomplish their goals within a system easily, in a way that also fulfills pre-defined business goals.” I’m sure there’s lots to argue about and disagree with in that statement as well, but it’s an interesting thought process to go through.

The rest of the article goes a little too deep into #NoUI territory for me. I’m more with Cennydd on that one:

This is the world desired by some #NoUI adherents. It’s not a world I recommend.

— Cennydd Bowles (@Cennydd) April 21, 2015

But there are still some interesting examples. Well worth going through.

Chris Baraniuk looks at the futility of things like traffic signal buttons in Press me! The buttons that lie to you:

Some would call this a “placebo button”—a button which, objectively speaking, provides no control over a system, but which to the user at least is psychologically fulfilling to push. It turns out that there are plentiful examples of buttons which do nothing and indeed other technologies which are purposefully designed to deceive us. But here’s the really surprising thing. Many increasingly argue that we actually benefit from the illusion that we are in control of something—even when, from the observer’s point of view, we’re not.

I’m not usually one to freak out about kids and technology use, but Bruce Feiler makes some interesting points in Hey, Kids, Look at Me When We’re Talking:

Dr. [Clifford Nass, a communication professor at Stanford University] told me about research he was doing that suggested young people were spending so much time looking into screens that they were losing the ability to read nonverbal communications and learn other skills necessary for one-on-one interactions. As a dorm supervisor, he connected this development with a host of popular trends among young people, from increased social anxiety to group dating.

That’s pretty alarming.

In The Machines Are Coming, Zeynep Tufekci talks about the kind of tasks that are being automated by machines:

Today, machines can process regular spoken language and not only recognize human faces, but also read their expressions. They can classify personality types, and have started being able to carry out conversations with appropriate emotional tenor.

Machines are getting better than humans at figuring out who to hire, who’s in a mood to pay a little more for that sweater, and who needs a coupon to nudge them toward a sale. In applications around the world, software is being used to predict whether people are lying, how they feel and whom they’ll vote for.

This is not a new topic. Back in 2012, Kevin Kelly proclaimed in Better Than Human: Why Robots Will — And Must — Take Our Jobs:

It may be hard to believe, but before the end of this century, 70 percent of today’s occupations will likewise be replaced by automation.

At the end of last year Claire Cain Miller wrote for the New York Times that As Robots Grow Smarter, American Workers Struggle to Keep Up:

Although fears that technology will displace jobs are at least as old as the Luddites, there are signs that this time may really be different. The technological breakthroughs of recent years — allowing machines to mimic the human mind — are enabling machines to do knowledge jobs and service jobs, in addition to factory and clerical work.

Who knows if this fear is going to turn into reality or not — there are lots of counter-arguments as well (For example, Nicholas Carr has a really interesting historical perspective in Should the Laborer Fear Machines?).

Still, I find the discussion fascinating — especially as it relates to the balance of power in workplaces. Tufekci continues:

Machines aren’t used because they perform some tasks that much better than humans, but because, in many cases, they do a “good enough” job while also being cheaper, more predictable and easier to control than quirky, pesky humans. Technology in the workplace is as much about power and control as it is about productivity and efficiency. […]

This is the way technology is being used in many workplaces: to reduce the power of humans, and employers’ dependency on them, whether by replacing, displacing or surveilling them.

Maybe that’s the real cause for concern here. Not that jobs might go away (although that’s certainly worrisome too), but that power will continue to shift to employers and away from employees.

Back in 2012 I wrote the following about a blind spot I’ve noticed in Agile development:

Problem solving involves not just iteration, but also lots of variation. This often requires time to get it wrong a few times, which doesn’t fit comfortably with the concept of release dates. See, the problem with integrating Agile and UX is not that designers want to hang on to “slow and heavy documents,” “big upfront design”, or whatever you want to call it. The problem is that each iteration further solidifies the chosen path, and there is no time to stop and ask if you’re going in the right direction.

All of that came flooding back when I read Jeff Patton’s Common Agile Practice Isn’t for Startups, in which he puts a slightly different spin on the issue that Agile is not very good at helping us figure out what to build. His solution is a product discovery process (something that’s obviously near and dear to my heart as well). He places the discovery process in the context of a different kind of velocity than is usually measured in Agile—trying to learn as much as possible about customers and the product:

There’s something very different about this process loop: the primary measure of progress during discovery isn’t delivery velocity, it’s learning velocity. And sadly, we can’t measure it in features or stories completed. And, even worse, we can’t plan two weeks of it in detail because what we learn today can and should change what we do tomorrow.

He goes on to describe a Nordstrom process:

Notice the Nordstrom Lab still uses time-boxes, 1 week in this case. But, they didn’t start the time-box by predicting how much they’d deliver, but with learning goals in mind. Then they iterated around the build-measure-learn loop as fast as they could.

The post is hard to quote from, so really, just go ahead and read it. It’s a very interesting approach to making discovery part of a regular Agile process.