Some truth from Joshua Porter in There is no later for your customers (my emphasis added):

There is no later for your customers. The only thing that matters is what they’re using right now. They don’t give a shit about your roadmap, your brilliant feature pipeline, or your vision of a better future. They’re trying to get work done right now and they only know what you’ve already delivered. So build a discipline around your launches, knowing that your ‘temporary, let’s get this out quickly and iterate later’ release is the current reality for your customers. Build up your attention to detail and force yourself to treat every launch like it is your final launch. Imagine that you’ll never be able to deploy something after this…have you done your best work?

Release early, release often is not an excuse to release crap…

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 corporations1. 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 fixed2 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.

---

1. I.e., most practical and pragmatic. I’m talking specifically about corporations with >100 employees, not startups. ↩

2. And don’t get me wrong, there can be legitimate reasons for fixed release dates. ↩

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!

Steven Sinofsky wrote some excellent advice for product managers in his post Shipping is a Feature: Some Guiding Principles for People Who Build Things. I especially like this part:

A decision means to not do something, and to achieve clarity in your design. The classic way this used to come up (and still does) is the inevitable “make it an option”. You can’t decide should a new mouse wheel scroll or zoom? Should there be conversation view or inbox view? Should you AutoCorrect or not? Go ahead and add it to Preferences or Options.

But really the only correct path is to decide to have the feature or not. Putting in an option to enable it means it doesn’t exist. Putting in an option to disable means you are forever supporting two (then four, then eight) ways of doing something. Over time (or right away) your product has a muddled point of view, and then worse, people come to expect that everything new can also be turned off, changed, or otherwise ignored. While you can always make mistakes and/or change something later, you have to live with combinatorics or a combinatoric mindset forever.

The flip side of this is, of course, that the organization needs to agree that product managers have the autonomy to make these kinds of decisions.

In WordPress: How It Came To Be And Where It’s Heading Alex Moss interviews Matt Mullenweg and Mike Little, the two cofounders of WordPress. The whole interview is interesting, but their approach to technical debt caught my eye in particular:

We rewrite or refactor about 10 to 15% of WordPress in most releases, so that we can keep users getting updates and new features quickly, while doing the “ground up rebuild” incrementally in the background, fixing bugs and getting feedback as we go.

This is, in my experience, the best way to handle technical debt: pay down a little bit of it in every release. To steal a slide from my Product Management course, here’s my general rule of thumb (and of course there will be exceptions) for balancing a product roadmap:

Giff Constable makes the case for validation and learning in the product development process before you launch something. From You Are Spending 3x-5x More Than You Should:

Agile/lean has helped people debunk the “big upfront design” phase, but far too many replace it with nothing. I agree that waterfall-style, big-upfront-design is a waste of time and money. I do believe that getting into the market with a designer and an engineer and learning is a critical use of time.

James Stout explains how Responsive Design won’t fix your usability issues for you. If your site is bad before the redesign, those problems won’t just magically go away once you’ve gone responsive. It’s a good article, and I especially like this bit:

But in the face of all this great technology, it’s more important than ever to avoid the “features for features’ sake” pitfall. Maintain that ever-present purpose and goal and be deterministic concerning whether these technologies help drive that goal, or whether they’re being included simply because they’re new. Use only those features you need and make them truly spectacular when you do.

The mobile revolution is nothing new, yet the battle to bring it about rages on. Understand that success on the web is not defined by the tools in your arsenal, which any web-MacGyver can use, but by the strategy you employ, including the very manner in which you approach the field.

It reminds me of one of my favorite Product Management quotes, from Barbara Nelson’s Who Needs Product Management?:

It is vastly easier to identify market problems and solve them with technology than it is to find buyers for your existing technology.

Des Traynor’s Product Strategy Means Saying No is also a great article on the topic of product focus and market needs:

Identifying and eliminating the bad ideas is the easy bit. Real product decisions aren’t easy. They require you to look at a proposal and say “This is a really great idea, I can see why our customers would like it. Well done. But we’re not going to build it. Instead, here’s what we’re doing.”

And since I haven’t linked to Michael Wolfe’s answer to Why is Dropbox more popular than other programs with similar functionality? yet this year, I might as well do it now and get it over with:

“But,” you may ask, “so much more you could do! What about task management, calendaring, customized dashboards, virtual white boarding. More than just folders and files!”

No, shut up. People don’t use that crap. They just want a folder. A folder that syncs.

Ken Norton wrote a really nice post about the problem with prioritized feature lists in product development, using his team’s early work on Google Docs as an example. Specifically, here is the problem he highlights in Babe Ruth and Feature Lists (Why Prioritized Feature Lists Can Be Poisonous):

Our wish list approach also created false equivalence. There was a huge chasm between what #1 meant to us and what it meant to our users. For us, it was first amongst equals. To them it was a painful tumor overdue for removal.

Orders of magnitude separated #1 from the rest of the list. That urgency didn’t come through until we got a bunch of them in the room and let them vent.

It’s worth reading the whole post before continuing, because the context is important. Ken highlights a really important point about prioritised feature lists — they are too one-dimensional to give you enough confidence about the product development decisions you’re making. That’s why it’s so important to plot priorities on multiple dimensions to aid in decision-making.

The method that springs to mind immediately in the case of the Google Docs example is something I’ve written about before, the Kano model. Ken explains that even though they saw text formatting within Google Docs as an important feature to work on, users saw it as a major frustration, and a fundamental bug that needed to be fixed.

Plotting their list of features using the Kano model could have highlighted this disconnect earlier in the process. To recap, the Kano model, developed in the 1980s by Professor Noriaki Kano for the Japanese automotive industry, is a helpful method to prioritise product features by plotting them on the following 2-dimensional scale:

• How well a particular user need is being fulfilled by a feature
• What level of satisfaction the feature will give users

The model is generally used to classify features into three groups:

• Excitement generators. Delightful, unexpected features that make a product both useful and usable.
• Performance payoffs. Features that continue to increase satisfaction as improvements are made.
• Basic expectations. Features that users expect as a given — if these aren’t available in a product, you’re in trouble.

Here is a visual representation of the Kano model:

Now, let’s take Ken’s original list of prioritised features and plot them on the Kano model. Obviously I don’t have the background that the team would have had, so this is just a guess to illustrate the point:

With these added dimensions (and let’s assume there are 10 or more features on this graph), Product Managers can begin to make plans for what they need to work on by always keeping a balance between Basic expectations, Excitement generators, and Performance payoff features.

Now, I’m sure we could quibble about where exactly each feature should be plotted, but it’s immediately clear from this example that Formatting is a Basic expectation that needs to be very well met for Google Docs to get even close to parity with other word processors. That’s where they needed to start, and only once the basic expectations were met, should they have moved on to adding additional features to Formatting. At the same time, working on features like improved Sharing and Commenting would also have shown users that the product continues to get better over time (while generating some much-needed excitement).

So, with that said, I’d like to add a bit of a “yes, and” to Ken’s post. Yes, prioritized feature lists can poisonous, and one way to make sure that doesn’t happen is to add additional dimensions to the list to improve the accuracy of the decision-making. The Kano model is one approach, and I also discuss a couple more in The ultimate product question: How do you know what’s important?

Jessi Hempel’s The second coming of Facebook is a very interesting profile of the company and where it’s headed. There’s one paragraph in particular that has stuck with me for the past few days:

At Facebook developers choose the projects they want to work on, and product groups compete to woo them. Managers sent out reports highlighting the product teams that were doing a good job. Pretty quickly teams realized that if they wanted to get praised in the weekly memo, they needed to start recruiting mobile developers.

My first thought was that this is a great idea. If you want to get something done at Facebook, your idea has to be interesting and challenging enough to convince developers to work on it, otherwise it just won’t happen. I’m sure this weeds out a lot of ill-conceived project ideas.

But there’s a problem with this approach. If Product Managers have to convince developers to work on their projects, they are going to pitch ideas that have a big chance of being interesting to… developers. Not to Facebook users. So there’s a danger that the product features being pushed out are wild and challenging and extremely interesting, but don’t meet user needs particularly well.

In the example cited in the article, an internal weekly memo effectively changed the company’s entire roadmap by shifting attention to mobile. Not that shifting to mobile is a bad thing, but too much focus on things like who gets praised in an email has the potential to seriously derail a company.

Still, the idea is really appealing: making Product Managers effectively vie for developer attention ensures that the PMs do their homework so that they can sell and defend their ideas to the company and to customers. That’s a worthy cause. It would be great to make some form of user validation part of what happens before projects are pitched, though. I guess I just remain weary of the prevailing myth that we are like our users.

Kenton Kivestu defines the difference between accuracy and precision, and then discusses what it means in the context of product decisions:

There is a significant opportunity cost in consistently prioritizing precision over accuracy. Accuracy is about launching what the market needs, precision is about optimizing and delivering relentlessly on it. Unless you’ve nailed the former, material effort on the latter is going to be wasted because you’re optimizing something too far from the true north (the accurate goal) you should be pursuing.

This is an important point. Any call for data-driven design (in the quantitative, 41 shades of blue sense of the word) needs to come with a disclaimer that it’s an extremely useful approach to get closer to the middle of a target (precision), but it’s useless if you’re shooting at the wrong thing (accuracy).

(link via @ixhd)