Meeting Hell


Do you ever feel like you come in early, work frantically until late in the evening, day after day, week after week, yet at the end of the month you didn’t get anything important done? Is your day packed with back-to-back meetings, with bursts of e-mail in between? If so, you’re not alone. Especially in larger companies, the life of a product manager or designer can be meeting hell.

Partly this is a function of company size; smaller companies need fewer meetings because there are less people to keep in the loop. Partly this is a function of growth – when the company is small everyone gets used to being included in every meeting, and as the company grows this expectation continues even though it obviously doesn’t scale. And partly this is a function of the company culture.

But for whatever reason, many product managers and designers find themselves in meeting hell, and it puts a serious strain on their ability to get their job done. As a manager of these people, all too often I need to sit down with these people and explain to them that even though they’re working like crazy, they’re not doing what they need to in order to make a difference. They may get an A for effort but they still fail.

What are these things that truly make a difference? The types of questions I ask include:

- how many users or customers did you talk to this week?

- have you had a chance to come up with your long-term product strategy?

- what’s changed in the competitive landscape?

- what big insights about your product have you had this week?

- what new technologies do you see emerging that may enable new approaches to our products?

- what new skills are you trying to learn right now?

Most people respond by saying that’s what they wish they were working on, but then they show me their Outlook Calendar for the week. It is typically jam packed with status meetings of various flavors, interviews, planning sessions, one on one’s with engineers, marketing, project management, operations, peers, HR meetings of some sort whether it’s 401K or company culture surveys or planning some event, and the list goes on.

Unfortunately, most of these meetings will do little to help you make progress on the items that will actually make a difference to your product.

The good news is that you really can turn this situation around. And not only will you do a much better job for your product and your company, but you’ll also enjoy your day and life more at the same time. But it’s not easy – it requires some difficult changes in what are by now likely habits.

In order to fix this, there are three major behavioral changes.

First, you need to let go and start trusting your colleagues more to do their job while you do yours. So many product managers think they need to be present at every single meeting in any way related to their product. But in many cases, you really don’t need to be there. You can tell these people what you’re trying to do, and say that if something big comes up that requires your personal attention, that they should feel free to contact you directly, but that unless you hear otherwise you’ll assume things are under control. The truth is that many if not most meetings simply aren’t truly necessary.

A corollary to this is that you need to be smart and efficient about communicating status to those that need it. A concise, well-structured status note takes you only a few minutes to write and even less time for the members of the product team to read. A good status is a topic in itself, but one key tip is to highlight at the top any exceptions or actions you need taken by others. Write it so that the reader can assume the project is on track unless something is clearly highlighted at the top.

Second, you need to realize that every hour of your day represents a choice of both what you’ll do during that time and just as important, what you won’t be doing. We’ve all fallen into the trap of getting so caught up in the urgent items that we can’t actually get to the important items. Correcting this starts with a very clear awareness of whether an item is important or urgent. The questions above are examples of important. You need to have a list of what your important items are and when you need them by, and you need to change your mindset so that becomes your true priority.

One technique that I’m a big fan of is to literally block off 2-4 hours every day for these important items. I just don’t know how someone can do the product manager or designer job without this quality time to concentrate and think about these bigger issues. Then it’s a matter of using the time that remains for your “urgent” items. This will typically involve triaging, as there won’t be enough time for everything. So you’ll need to decline or defer some things, delegate others, and in some cases enlist your manager’s help to find a way out.

A corollary to this is that it will be tempting to spend the blocked off time responding to all the e-mail that has come in during all of your meetings. You’ll need the discipline to ensure that you are really spending this time on the truly important items. Managing your e-mail is also another topic, but make sure you use this blocked time wisely. If you have to quit Outlook and turn off your cell, do it. Or you may find it useful to find a quiet conference room to hide out in.

Third, for the meetings you do attend, and especially the ones you lead, you need to make sure that they’re effective meetings and a good use of everyone’s time. You need to have a clear and well-understood and communicated purpose, and make sure that you and everyone else is prepared, and you need to move the meeting quickly to resolution.

There are many systems for personal time management and improving the effectiveness of meetings, but you’ll find these core principles behind most of them. It is a shame that so few managers help their employees with these time management issues. It’s one of the most useful things a manager can do for an employee. Try them out and see if you can’t make some progress digging yourself out of Meeting Hell.

Email to a friend

Sign up for the free newsletter here.

Product Management vs. Product Design


The last note discussed the different types of user interface design – interaction design and visual design – and tried to make the point that both are required for a good user experience. But the response surprised me. So many people wrote to me to complain that their company essentially doesn’t do either type of design, and they know their product suffers for it. Most said that the UI engineers just did whatever they could and that was the design. Sometimes the product managers waded into the design waters and did what they could. Some companies try to outsource some visual design at the end of the process, just before the product goes into QA. Some people that wrote to me said they had no idea what any of these roles were.

It seems to me that the design community hasn’t really been doing enough to address this problem. They do a good job communicating among themselves, and there are some outstanding talents in the design community (Mark Hurst, Hugh Dubberly, Alan Cooper, to name a few) but in general I think these guys spend a lot of time preaching to the choir, and that the message about the value they deliver needs to get to those teams that need them the most, and these are the teams without designers. I realized one way to do this is to work on educating the product managers.

The reason I care so much about this problem is simple. A good product requires a good user experience. And a good user experience requires the close collaboration of product management and design. This is a big topic, but first I think we need to try to get us all on the same page in terms of what “design” includes. So in this post I’d like to spell out what I consider the design related roles that are essential to creating a good user experience. Note that I’m emphasizing roles rather than people, as it’s possible to find people that can competently handle more than one role, but one way or the other you need these roles if you want a good experience:

Interaction Designer (aka information architect, user interface designer, user experience architect) – these people are responsible for developing a deep understanding of the target users (each user profile that you’re trying to satisfy in your product), and coming up with the tasks, navigation and flow that is both usable and satisfying. Generally, the interaction designer maps product requirements to a design represented by wireframes, and passes them to the visual designer.

Visual Designer (aka graphic designer) – these people put the flesh on the wireframe and create the actual pages and user interface look and feel, which includes everything from the precise layout, colors, and fonts, but more importantly, the visual design communicates and evokes emotion in the product (which is far more important than you may think).

Rapid Prototyper – this a special breed of developer that loves to explore product concepts. Rather than focusing on the issues of creating commercial software that is robust, scalable, and high-performance, these people create “disposable” software – the lifespan of the prototype may be less than a day – the purpose is to quickly try out an idea by creating something that simulates the intended user experience.

Usability Tester (aka human factors engineer, usability engineer, usability researcher) – this person specializes in evaluating whether the prototype allows a given user to easily achieve his objectives. It includes recruiting appropriate test subjects, administering the tests, evaluating the results, and recommending alternatives.

The four design roles above work closely with the product manager to discover the blend of requirements and design that meet the needs of the user - the idea is to get to the point where the software is both usable (users can figure out how to use it) and desirable (users actually want to use it). You also need to ensure the software you’re designing is feasible, so you need to have a software architect reviewing the progress and prototypes.

For large companies, especially consumer internet service companies, you really do need all four roles represented on your team. If you’re an enterprise company, and you’d like to differentiate your product from your competition, one of the easiest ways to do this is to create a good user experience; as a general rule, most enterprise products are very weak in this respect.

For smaller companies, you may be able to double-up some of the roles. For example, I recently was working with a consumer internet service startup in the Web 2.0 space, and they assembled a terrific team of three: a product manager, an interaction designer that also covered usability testing, and a visual designer that also covered prototyping. The three of them worked together extremely well to quickly come up with numerous prototypes that they then tested with target users (in their case, since the site is a sports-oriented site, they found lots of friendly target users hanging out in sports bars, all too happy to try out some software in exchange for a beer).

One other important note. Many companies realize they need to do something here, but think they can outsource this type of work to a design firm. And to a degree you can, but beware that certain functions are more appropriate than others.

For example, I really don’t like to outsource the interaction designer role for three reasons:

1) it takes months to truly develop the necessary understanding of the users and customers, and most contracts don’t have the time to do that, and even if they do, that knowledge is lost when the next release comes up;

2) the interaction designer needs to be on-hand and deeply involved all the way through the project, from the beginning to launch, as there will be literally hundreds of detail questions that come up during development and test where an interaction designer making the right decisions is critical;

3) the user experience of the product is simply too core to the company to not have in-house. It’s a better choice to outsource QA.

You can get away with outsourcing visual design, as there are a number of studios that can do what you need, especially if you have a strong interaction designer on staff. You can also outsource usability testing, although it’s often expensive and I’m a big fan of informal testing (see the book “Don’t Make Me Think” by Steve Krug) and the product manager and interaction designer can often team up to cover this (there are pros and cons to this).

For the rapid prototyper, the easiest thing to do is to borrow a developer from your engineering team. This can work great as long as you make very clear to that person that this is a totally different type of activity, and that he should not try to build a prototype where any of it can be reused later in the real product.

There’s a great deal more to say on this critical topic, but hopefully this discussion lays the foundation. Which of these roles are already covered on your product team and which ones are missing?

Email to a friend

Sign up for the free newsletter here.