In Avoiding product management whiplash Hemal Kuntawala describes the constant context-switching that PMs need to do as they move from strategy to execution and back:

Each phase of product development requires a different perspective, almost a different mindset. At one end of the scale you have a big-picture view of the world, like looking at the market you’re in and hypothesising new value propositions. At the other end you have nitty-gritty details like the pixels and font-sizes of your UI.

I like the gentle slopes of the sine wave he uses as illustration, although I think in reality the back-and-forth is a lot less gentle…

I like Jordan Koschei’s defense of enterprise software work in UX for the Enterprise. This is what I get to do every day at Jive:

As designers, we live to solve problems, and few problems are larger than those lurking in the inner depths of a global organizations. After all, Fortune 500s tend to have a “just get it done” attitude toward internal tools, resulting in user experiences that aren’t well designed or tested. By giving those tools the same attention to experience that you give consumer-facing products, you can improve the lives of your users and support the organization’s values and brand.

And this is so important — it’s why it’s essential to do research with end users:

A successful enterprise UX project considers the users’ needs, the clients’ goals, and the organization’s priorities. The best user experience sits at the intersection of these concerns.

I really liked this interview with Josh Porter where he talks mainly about good product design, and the importance of user feedback:

Good product design is the result of persistence as much as anything else. That’s why you hear companies like Airbnb and Evernote and others say that it can take years to figure out user onboarding or free trials or other sophisticated flows. It takes a lot of time to get your message right, get the user incentives right, get the interaction right, etc. It is easy to become impatient and throw out some great ideas prematurely.

And this:

The interplay between vision/intuition and data/feedback is that you need both. You need to be able to assess how you’re currently doing with data but also not let data stop you from taking risks with your product. Many teams become conservative over time as they rely more and more on data to make decisions. They ultimately become paralyzed and unable to build something really new.

Marty Cagan wrote one of his characteristically great posts in Product vs. IT Mindset. In one particularly harsh section he describes what happens when the people who make decisions about a product are far removed from those who make the product:

In IT mindset companies, accountability frankly is a farce. The people actually working on a project typically have no real say in what they are building, and sometimes even in how it’s built, and even when it’s due. In theory, the leadership team could try to hold the requesting stakeholders accountable for the results, but if they do they immediately hear complaints that they didn’t get what they actually wanted, and because of delays and costs, critical things had to get cut, and so it’s certainly not their fault. So management writes it off as yet another failed technology initiative. In contrast, in a product organization, we are measured by results.

I’ve always felt that this is the biggest challenge to companies as they grow. The further away those who make decisions are from those who build the product, the harder it is to remain customer-focused in the long term.

I try not to overwhelm you with posts about the product management book I wrote recently, but I do think this deserves a post. After a few hiccups, Making It Right is now available in paperback on Amazon, through CreateSpace Independent Publishing.

If you like papery things and margins, I’m sure you will like it.

Buy ‘Making It Right’ on Amazon.

Craig Mod discusses single-purpose products in his product design essay There is much to learn from the paper towel:

All of these single-purpose tools or philosophies strive towards the same goal: whittle away the cruft around an idea to reveal its most base components, and in doing so, strengthen what is left.

The single-purpose lecture attendee is, in theory, a better student. The single-purpose-sized paper towel makes us happier, is gentler on the earth. Individual tools in unix are more efficient and easier to debug because of their specificity. Facebook Messenger on its own is easier to use to communicate without the deluge of Facebook notifications flying in our faces. And so on and so forth.

I’ve started using Craig’s solution for single-purpose Twitter notifications and single-purpose Facebook messages and it works really well.

In the midst of the recent brouhaha about Markdown1, Craig Mod posted an interesting tweet about the nature of software. In response to John Gruber’s assertion that the original version of Markdown doesn’t need a significant amount of work, he said this:

@gruber @waxpancake I think your point about it being ok for software to be “done” is very strong. We need more “done” software.

— Craig Mod (@craigmod) September 5, 2014

This gave me pause, because it flies in the face of a very common mantra in the design world. Sure enough, it didn’t take long for another big name in Design to throw down the words many of us have said over and over:

@craigmod @gruber @waxpancake Software is never done.

— iA Inc. (@iA) September 5, 2014

This happened a while ago, but I can’t stop thinking about it. Craig is one of my favorite thinker-writers (hey, if singer-songwriter is a real word, this is totally a real word as well), so I didn’t want to treat it as just another easily-refuted throwaway comment.

The fact is that it isn’t that long ago that software was actually done when it came out. It’s only a couple of decades ago that software showed up on a CD-ROM and we made videos about how to use it:

When Windows 95 came out, it was done. Yes, there were some patches to it, but they were few and far between, and in general quite difficult to come by. But of course, then the Internet and App Stores happened in full force, and suddenly we decided that “Software is never done”. In some sense this is certainly true. There are always bugs to fix, things to improve, more features to add, unused features to remove — and of course, the SaaS model makes it all so easy. But I wonder if we’ve taken this a bit too far.

A fairly recent example that comes to mind is email software Sparrow’s acquisition by Google. Man, did we freak out about that one. The thing is though, the software didn’t suddenly stop working just because it was “done.” It was still there, it was still great, and it still works to this day. But that’s not good enough for us any more. Things have to keep getting better and better. And that’s fine — I’m not arguing against progress. In fact, I deliberately turn off automatic app updates on my phone because I love updates and release notes so much.

But I also wonder if our obsession with the never-doneness of software — the inherent throw-awayness of our MVP and test-and-learn culture — is having a negative effect on the quality and lasting meaning of the software we make. I’m reminded of Jennifer Fraser’s words in her article What I Bring to UX From … Architecture:

As an architect, the implicit permanence of designing a building carries with it a sense of responsibility… I can’t help but wonder if we would have better designed products if some of that responsibility and sense of permanence of architecture found its way into what we do as user experience designers.

And here’s Tony Fadell, talking about the creation of the Nest thermostat:

Fadell looks out at the Manhattan skyline and says that he always wanted to be an architect; that buildings stay beautiful forever but digital devices are quickly obsolete. “You look at hardware or software five years later? They’re crap. You would never use them again. People use architecture all the time.”

His voice rises. “What is our form of architecture? What is the thing that lasts of beauty?”

Or consider Dmitri Fadeyev’s words in a discussion about Russian architecture:

What’s interesting about this type of architecture is that its aim goes far beyond that of creating a functional underground system. Its aim is to promote a political ideal, and it does it through beauty by enriching lives of the people who get to experience it. The question here isn’t: how do we solve the problem of creating a metro station in an efficient manner – instead the question is: how do we create a station that elevates people’s mood and inspires their lives. This architecture isn’t there just to help you live – it makes life worth living.

I do wonder what would happen if we felt the weight of responsibility a little more when we’re designing software. What if we go into a project as if the design we come up with might not only be done at some point, but might be around for 100 years or more? Would we make it fit into the web environment better, give it a timeless aesthetic, and spend more time considering the consequences of our design decisions?

Coming back to Craig Mod’s tweet, I have to say that on reflection I agree with him. We need more software that’s done — not all of it, just more of it. Just like we’re always going to have prefab buildings to serve a particular function at a particular time, software that continues to change and improve pushes us forward and is absolutely necessary. But maybe it’s ok for Markdown to be done. Or Sparrow. Or that app you’re working on. And by going into it with a realization that this is going to be done some day, you might even make something that lasts for decades.

---

1. The details of the Markdown argument between John Gruber and Jeff Atwood isn’t the point of this article, so don’t worry if you missed it. ↩

As I’m sure you’re extremely tired of hearing by now, I recently wrote a book on Product Management. For those of you who are too cheap to buy it (I kid, I kid1), there is now an edited chapter excerpt up on Smashing Magazine. In Why Companies Need Full-Time Product Managers (And What They Do All Day) I give my definition of Product Management, and go into some of the characteristics of a good PM. Also:

The truth is that, to be effective, the role of a manager for a particular product or area must not be filled by multiple people. It is essential for the product manager to see the whole picture — the strategic vision as well as the details of implementation — in order to make good decisions about the product. If knowledge of different parts of the process resides in the heads of different people, then no one will have that holistic view, and all value will be drained of the role.

Enjoy the freebie!

---

1. But not really. PLEASE BUY IT. ↩

I’ve done quite a bit of writing here on architecture and design (see this, for example), so I really enjoyed Melissa Mandelbaum ‘s Applying Architecture to Product Design: Lesson 1 - Circulation:

As an architect, I learned circulation systems including stairs, hallways and elevators are very important in helping people navigate buildings. Similarly, as a product designer, I’ve learned circulation systems such as list menus and tabs are necessary for helping people navigate products.

She goes over some really great examples of helping people “circulate” through an app. I’m looking forward to the rest of the series!

My thanks to Greg Heade for sponsoring Elezea this week to promote his excellent wireframe stencils.

If you use Photoshop, Illustrator, Fireworks or Omnigraffle, you’ll love volume one and volume two of Greg Heade’s tiles for wireframes and flowcharts. These stencils are 100% vector-based and editable, and it allows you to put together page layout and flowcharts quickly so you can focus on adding the details — not drawing the skeleton.

These tiles include standard layouts like home pages, product pages, and error pages, but it goes beyond that to give you a framework for shipping and payment flows. These are an invaluable resource — so check his store out!

Sponsored via Syndicate Ads