Archive for the 'product management' Category

Urgent vs. Important & Time Management

Ben on Sep 7th 2008

There are whole books devoted to time management.  There’s even a methodology for time management which almost approaches a religion.Software programs are built just for this one task; Outlook, for example, may be a communication (email) tool but arguably it is really designed for time management.  It’s no accident that all the new items come into your “inbox”.  From there, you complete the task, file them in folders, create tasks for later, set priorities … and so on and so forth.Some people are better at time management than others.  There are the habits of highly effective people … and then there are the disaster stories.  Whatever the case, it’s something that hopefully we learn by the time we get to college, but more likely it is something that we pick up from the school of hard knocks.

Yet there is one very simple core concept in time management that I don’t think is focused on enough — urgent vs. important.  Learning this one concept can mean the difference between success and failure, because no matter what “rules” for time management you learn or what tools you use, you must always be aware of which tasks fall into which bucket, otherwise you are almost certain to be spending your days working on the wrong things.

Urgent vs. Important

So what is the difference between urgent and important, anyway?  Sometimes it’s hard to tell.  Experience provides a good measuring stick, but sometimes there is no clear cut answer.  In some cases, urgent issues are fire-fighting type problems or system-down issues.   In other cases, the urgency is determined by the person originating the request, either by their status (an email from the CEO may require urgent response regardless of the subject), or their perception of the problem (someone may be dealing with an upset customer, so to them, the resolution is urgent — even if the problem itself is not significant).

Important issues typically revolve around strategy and planning, long-term projects and initiatives, or anything that requires a gestation period.  Important issues can also be those tasks that don’t have specific deadlines or any sense of urgency to them, but which help to build to your goal.  Urgent tasks have a way of wiping these important tasks off the map, and in some cases may ultimately cause extremely urgent issues to bubble up that could have been resolved in a less painful and time consuming way.

Managing the Urgent

In many cases, urgent issues can be resolved by delegating them.  When they are time sensitive, but don’t require a particular person’s involvement, this is often the most effective way to resolve an urgent issue, especially if you have many other priorities.  It’s easy to get caught in the trap of thinking that you personally need to handle the problem.  Maybe you can solve personally without too much effort, but that’s not the point — if you have people who can solve the problem quickly, it saves you from having a stack of urgent issues, all waiting for your involvement.

It’s also easy to fall into the analysis (or procrastination) trap — an urgent issue comes up, and instead of solving it immediately, the tendency may be to analyze it or dwell on it.  Attend to it immediately, and save the brain cycles for the important issues.   This can also help keep urgent issues from turning into a true crisis.

Getting things down on paper and out of your head can help to clarify what needs to be done, and also helps to keep you from getting overwhelmed.  This applies to both urgent and important tasks, but is especially helpful for urgent tasks, which may appear urgent just because you haven’t thought of them before.Finally — and perhaps most importantly –  recognize that just because an issue is urgent, doesn’t mean that it needs to be solved right away.  It may warrant some consideration or discussion, and it certainly shouldn’t be ignored, but there’s a good chance that it is not urgent at all.  Restate the issue in different terms and you may find that a solution already exists or that what is perceived as a problem really isn’t one at all.

Managing the Important

Prioritization is typically vital here — without knowing what needs to be done, in what order, it’s hard to know what’s important.  I tend to write everything down that I need to do or might some day want to do, and sometimes just the act of taking notes on tasks and projects allows me to see the task more clearly and recognize where it fits within the overall priorities.  If I don’t know what the priority is, then that’s a good indication that it’s probably not very important.  Priorities often shift over time, though, so writing down any task that comes to mind can help clarify the overall issue when it does become important, and can help you see how multiple problems can be solved at once, and whether a project should take precedence over another, or in some cases,  whether it makes another project obsolete.Working on important tasks at off-hours, when the urgent issues are not rolling in, can be a useful approach.  The downside is that if you spend your days on urgent items, and your nights or mornings on what’s really important, you end up spending far more hours on tasks that do not feel productive.  This is a quick path to 70 hour work weeks, and eventually, burn-out.

Establishing a sense of urgency for important issues, both for oneself and certainly when working on projects within a team, is also a good approach.  This helps to re-align priorities and keep focus on the tasks at hand.  This is a reflection of basic human behavior — our instinct is to be reactive to threats or problems, and so we always respond best to urgency.

More specific methodologies can be useful as well, especially when dealing with complex projects.  In software development, we have Scrum (an agile programming methodology, but at it’s core it is a time management tool), in life there is GTD (Getting Things Done, the aforementioned productivity religious movement) and Inbox Zero, and there are also programs and certifications devoted to project management.  A few of the top books on project management at Amazon are a good start.

No methodology guarantees that you will get work done, though, and you can’t get work done if you don’t know what to spend your time on.   Drink the kool-aid if you want and follow the exact rules of whatever methodology you pick, but I vote for applying the fundamentals of time management within the context of your own life and work habits, taking the bits and pieces that work for you from each methodology. Maybe I should write book on this, but chances are it will only have one sentence:

Figure out what’s important, and focus on that.

Filed in product management, time management | No responses yet

The product manager challenge

Ben on Feb 18th 2008

I read the On Product Management blog and recently Saeed posted an article titled Product Managers need time to breathe… He states:

I’m going to make an assertion here, and please correct me if I’m wrong.

I believe that the vast majority of software product managers are running full tilt in their jobs, caught between the short term tactical cross-functional activities (working with Dev, Sales, Marketing etc) that are thrust upon us, and the important long term market research, business and product planning activities that are fundamental to managing successful products.

Which got me thinking about the role I play in my company, as the only product manager for the Windows-based software we sell. My response:

I would tend to agree with this — in general I think the more time that someone has to focus on the core elements of their work, the better the result will be.

First, some background: I work in a small software / technology company where I am the only official PM, although many others, especially the exec team, contribute heavily to the product goals and design. All told we have 6 developers and 2 main products (with many smaller, related products underneath), 1 of which I manage almost exclusively. I am also the project manager for 2-3 devs working on my product. To say I am the main product expert is probably an understatement. Because I understand all the different elements of the company and work with everyone on every level — from execs, to development, to design, to marketing, to sales and support — I am usually the resource that is most heavily used.

For me, the challenge is this: the short-term needs of my company do have a big impact on our long-term success (we don’t have deep pockets), so I feel it is important to stay close to the day-to-day needs of the company to make sure that as a unit we are all working effectively. My position, knowledge, and experience allows me to do that pretty well. On the other hand, it does mean that some of the long-term strategies are getting less attention than they otherwise might, and it does also mean that I am stretched pretty thin on a regular basis, and I’m certain that my creativity suffers as a result.

The only way I’ve been able to handle all of this is by being really good at managing my time (and I still have room for improvement there). Quite a bit of work, especially the creative kind, does get done outside of normal business hours when things are quiet, but I am also able to create certain hours in the day when I can work uninterrupted. The challenge here is being able to switch gears away from and back to a certain project, especially one that requires a lot of research or design or has a long process. Fortunately I am pretty good at that, although at times it does get frustrating.

Our track record so far has proven that this is working, as we are seeing products and profits improve. Our competitors are not able to keep up with the speed of our development either, and I’m pretty sure that we stay closer to the industry trends than anyone else in our market.

So for me the bottom line is that while I would love more time to focus on just the product management side, I don’t think it’s realistic or even recommended considering the size of my company and the speed in which we typically move. I accept this as the reality of the small business we are operating and I just do my best to juggle it all. Do I learn a lot and sharpen my skills regularly as a result? Absolutely.

So my point is that for our organization, as it stands now, I think I’m doing what I need to do. But the question remains — is the long-term strategy suffering because ultimately my company is focused on short-term results? And does it make sense to burden certain people so heavily that they really have no choice but to move on to something else eventually or simply burn out? How important really is deep research and strategy when you are running a small company that values quick decisions and single-person innovators? Does it make more sense to get a product out the door faster based on more narrow research, feedback and good assumptions, and make changes based on user feedback after the fact, i.e. focus on iterative development? (if you want a cool catchphrase this is “Googley”) Or does that just set you up for failure? (and you will fail at some point!) Failure on a large scale is certainly not an option, so perhaps the better question is — which approach offers less risk?

Filed in product management | No responses yet