The post I wrote this weekend on software development belief systems in corporate environments has been in my head for quite a while, I just hadn’t been able to write it up until yesterday. As often happens with these things, I noticed three articles in that past 24 hours that tie in really nicely with that post.

The first is Jeff Weiner’s Avoiding the Unintended Consequences of Casual Feedback, which talks about the kind of feedback executives should give to their teams:

Years ago, a former direct report of mine helped bring this point home. While he and his team welcomed my input, he observed that oftentimes what I thought was a take-it-or-leave-it remark would create a massively disruptive fire drill. Up until that moment, I had no idea my opinion was being weighted so heavily.

To address the issue and to ensure that the team and I were on the same page with regard to situations like that, we developed three categories to describe any feedback I provided (either in conversation or via email): One person’s opinion, strong suggestion, or mandate.

Next is Michael Lopp’s Chaotic Beautiful Snowflakes, which talks about the unintended work that managers often create without even knowing it:

The fact is that you significantly underestimate the amount of work that you generated this morning. You could document and communicate the obvious work, but you can’t document all the unexpected side effects of your actions. In a large population of people, it’s close to impossible for an individual to perceive and predict the first order consequences of their well-intentioned actions let alone the bizarre second order effects once those consequences get in the wild.

Finally, there’s John Maeda and Becky Bermont’s Building a Design Culture in an ‘End-Up’ Technology World, which talks about the elements of a good design culture in larger corporations:

In the end, building a great design culture is not the goal in and of itself. What it does is allow a company to recruit great designers, and then supports their ability to build great products, along with their counterparts in product and technology. Start-ups and end-ups may each think that they other has an easier time building or sustaining a design culture, but it takes work at any stage of the game.

All three articles are great companion pieces to what I wrote yesterday. I realized this morning that even though the traffic on yesterday’s post wasn’t huge, it will always be a personal favorite of mine, because it documents a lesson learned from a lot of sweat and frustration. And those are often the best lessons you can teach yourself.

Executives in corporate environments have one of three belief systems about software development. To build successful products it is essential for product managers to understand what belief system their executive team subscribes to.

• Belief system #1: We have to build these features and they have to be live by this date.
• Belief system #2: We have to be live by this date — what features can you get done by then?
• Belief system #3: We have to release these features next — how long will it take to get that done?

Belief system #1 is the most common, and it is poison. It usually goes along with a distorted Steve Jobs “reality distortion field” complex, and the only thing it produces is crappy software and burnt-out teams who feel distrusted and undervalued. A product manager’s first job is to move the executive team away from belief system #1.

Belief system #3 is the ideal scenario for most large corporations¹. Software development and the product manager’s role are usually well understood in such environments. The product team gets to present their market-driven ideas to the executive team, who can focus on what they do best: providing perspective, vision, and assistance with prioritization. This allows product teams to set their own schedules based on what everyone agrees needs to be done as they balance what’s best for users, the business, and the technology.

Belief system #2 is not ideal, but it is certainly better than #1, and I’ve learned that it is impossible to move executive teams from belief system #1 to belief system #3 without the interim step of belief system #2. The logical jump from #1 to #2 is easier to influence since product managers only have to deal with one variable: the constraints of time.

If a release date is fixed² product managers shouldn’t spend time trying to move out the date to accomplish everything the executive team wants them to. Instead, spend time explaining that the release date is a horizontal line. All features above the line gets done by the date, and all features below the line don’t, and will have to wait for a future release. Explain that the development team can only do a limited number of things in a given time frame, and if some feature suddenly becomes a must-have, one of the other features have to move “below the line”.

This might seem like a trivial concept, but that’s because we’re software people. Most executive teams have a really difficult time with this because software development in agile environments is fairly new to them.

It bears repeating that one of the biggest mistakes a product manager can make is to try to change people’s belief systems from #1 to #3 without first taking them through the logic of #2. That said, once a project has been completed successfully using #2, the shift to #3 is usually fairly easy to make. That’s because the executive team had the opportunity to get a glimpse of how much better the software can be if “required” features aren’t shoved down a funnel that cannot withstand the pressure.

If you work in a large corporation, identify your executive team’s software development belief system, then guide them to #3. Your product, your business, and your team’s morale will be better for it.

Rob Horning’s Me Meme is not an easy read, but it’s worth the investment. He doesn’t waste time with a fluffy intro, he just jumps straight in:

With social media, the compelling opportunities for self-expression outstrip the supply of things we have to confidently say about ourselves. The demand for self-expression overwhelms what we might dredge up from “inside.” So the “self” being expressed has to be posited elsewhere: We start to borrow from the network, from imagined future selves, from the media in which we can now constitute ourselves.

There are too many great quotes in here to choose from, so I’ll go with one more and then just encourage you to read the whole thing:

We shift from consumerist pleasures of fantasizing about how owning certain branded goods would make us into a certain kind of person and secure us a certain sort of affirmation to fantasizing about triumphant moments of social quantification, about getting likes and retweets, having lots of Tumblr activity, etc. […] Without viral content, you are in danger of becoming a blank.

Jason Green writes about The Promise, Progress, And Pain Of Collaboration Software:

Given the explosion of communication, conversations can take place simultaneously over several competing channels, creating confusion and inefficiency by requiring multiple changes in context. In addition, the ability to access prior content easily and seamlessly across all these communication channels becomes more challenging.

Between email, Trello, Slack, and InVision, we’re definitely feeling this pain as well. App Fatigue, indeed.

Jason Kottke in The revenge of the nerds:

On the very public stage of the web, the nerds of the world finally had something to offer the world that was cool and useful and even lucrative. The web has since been overrun by marketers, money, and big business, but for a brief time, the nerds of the world had millions of people gathered around them, boggling at their skill with this seemingly infinite medium.

There’s been a lot of talk about the web we lost in recent months. It’s now gone mainstream with TechCrunch calling the phenomenon The Fourth Internet:

If the first Internet was “Getting information online,” the second was “Getting the information organized” and the third was “Getting everyone connected” the fourth is definitely “Get mine.” Which is a trap.

I certainly understand where everyone is coming from with this. I also go on about the importance of self-publishing on your own domain (or as Jeremy Keith calls it, “selfish publishing“). And I also miss the old Twitter, back when it was about discussions and sharing knowledge, and not about big brands taking over our feeds with promoted photos.

But we also have to remember that the web is always going to be an Eternal September. So many new people are coming online every day, and they don’t know our “rules”, so they make up their own. And as much as we might long for earlier days, that’s how progress happens — through the actions of people who don’t know what they’re supposed to do.

So, sure. Let’s continue to publish on our own sites, and shout loudly about the virtues of doing so. But let’s not make people feel like unwanted newbies when they dream up a different web. We need them as much as they need us.

You know that thing where you get home after a long day and catch yourself some time later staring off into space, pigging out on a bag of Doritos and…? Oh, uhh, no me either. But I heard that happens to some people.

Anyway. I’ve been thinking about that phrase you always see on consumer goods packaging when they go through a redesign. The almost-apologetic and slightly nervous proclamation that even though the thing now looks different, nothing else has changed:

Clearly marketers have learned that consumers don’t like redesigns, so they started using this message in a defensive attempt to soften the blow for people. Even then, it doesn’t always work. Remember when Tropicana reverted to their old packaging because some people called the redesign “ugly” and “stupid”? We should know this by now: people have opinions, and they are going to make a big noise about those opinions.

Yet whenever we go through a website redesign process we appear to develop some amnesia around this topic. We seem surprised when people spew vitriol all over Twitter, and we try to make ourselves feel better by saying that they’ll “get used to it.” Some part of me really wants us to create “Bold new look, same great functionality!” gifs for those kinds of projects, in the spirit of the “Under construction” gifs of yesteryear. But just like in the case of Tropicana, I don’t think that will work.

What’s the alternative? Well, first, we have to realize the biggest problem with big web/app redesigns. It might be the same functionality underneath (or not), but that functionality is often harder to find, and that frustrates users to no end. The good news is that we work on the web, not in packaging. We can do things incrementally! In the words of Cameron Moll, “Good designers redesign, great designers realign”. I’ve also written about this before in The Data-Pixel Approach To Improving User Experience:

The main problem with big redesigns, therefore, is that, even though objectively the UX might have been improved, users are often left confused about what has happened and are unable to find their way. In most cases, making “steady, relentless, incremental progress” on a website (to borrow a phrase of John Gruber) is much more desirable. With this approach, users are pulled gently into a better experience, as opposed to being thrown into the deep end and forced to sink or swim.

Look, I’m not saying this is a perfect analogy. But I spent a lot of time spacing out about this on Friday, so I thought I’d write it down for posterity. What I’m trying to say is, let’s worry less about bold new looks in web design, and instead work on making things taste better.

We’re in the process of hiring UX designers and Product Managers, so I’m currently looking through a lot of resumes. I’m finding the breadth and depth of UX resumes really impressive — there are a ton of great people looking to make a shift at the moment. But on the Product Management side, not so much. I don’t want to believe it’s because most Product Managers suck. I just think there is a big supply/demand issue in this area at the moment.

But not just that, I also think that Product Managers need to write better resumes. Designers have, for the most part, figured out that it’s more about showing than telling. It’s easy to go to someone’s sites and portfolio to get a sense of what they’re about. Product Managers still appear to be stuck in the “Let me tell you how awesome I am” rut, though. This is a generalization, of course, but what I’m mostly seeing right now is resumes that excel at vagueness. It’s not uncommon to see a sentence like “Applied world-class methodologies to create a successful customer-centric product”, or some variation of that. What does that mean?

It’s great to see proof of success, yes — stats about conversion improvements, etc. are extremely useful. But hiring managers need more than that to assess Product Managers. We need to know how you think. We need to know how you approach problems, how you work, what methods you like and don’t like, and why. And for some reason most PMs I speak to seem surprised by those questions and have trouble answering them.

I’ve now gone so far as to send a short list of questions to our HR department. I’ve asked them to forward these questions on to potential candidates, and send their answers to the hiring team along with their resumes. So I wanted to share those questions here in case it’s useful to PMs looking for a new opportunity. This isn’t an exhaustive list, but here are some of the questions Product Managers need to be able to answer at any time of day or night:

• How would you describe your ideal product development process? Please share details including, but not limited to, the following:
  • Roles and responsibilities within the team
  • How to develop a strategy and vision for the product
  • How to decide what to build, and when (include thoughts on different prioritization methods and, in your experience, what works best)
  • Development methodology
• In your experience, what are the most important characteristics of a good Product Manager?
• In your experience, what are the conditions for success that have to exist in an organization for a Product Manager to be successful?

This is one of those classic “there is no wrong answer” situations. The absolute answers matter, but what matters more is the thought process. I want to hire PMs who think about these things. PMs who have an opinion on UCD vs. ACD. On Kano vs. KJ prioritization. On user stories vs. job stories. I want to work with people who read and think and build, and have found a way to balance those different activities effectively.

So, if you’re looking for a Product Management role, communicate those things to the recruiter and/or hiring managers. I’m pretty sure it will get you an interview. Oh, and if you want to move to Portland to help us make better healthcare software, and you have good answers to those questions, let me know!

I found Ellis Hamburger’s view on what’s wrong with Facebook quite interesting. From Facebook’s friend problem:

In the real world, losing touch with people happens naturally and effortlessly, but on Facebook, unfriending is reserved only for breakups and acts of malice. So, the ghosts floating through my News Feed vastly outnumber the friends I’ve kept. My Friends list went from a roster of my current friends to a collection of everyone I’ve met in the last 10 years — a social group too massive to feel urgent, and too broad to share with on a daily basis.

Facebook is broken for its earliest users, and perhaps soon, for many of its new ones as well.