“Work on what’s important, not just what’s interesting – there’s an infinite supply of both.” – Frank Guarnieri.
There is a lot in this chapter (chapter 3), but I find that the high-level concept is sufficient: there is a MAJOR difference between a problem that’s important versus a problem that’s interesting.
- Is this an important project or problem or is it just interesting?
- Can this make a demonstrable difference to my customers?
- Is this aligned with my company’s goals and strategy?
- Are we willing to commit to this?
Companies, business units, departments, teams and individuals need a SYSTEM for regularly assessing workload and focusing in on important projects. It’s a critical activity at every stage of product development.
I’ve found that a super-rigorous method for identifying “important” projects is not always necessary. By that I mean some system with metrics, weighted scoring, and standard operating procedures nobody follows. Systems like that can be prohibitively intimidating, especially if you’re starting them from scratch. Like they said about obscenity, to some extent you can know it when you see it, and I’d say the same can go for important projects.
A lot of times the challenge is not in telling the difference between important and interesting; the challenge is staying vigilant to your workload and maintaining the discipline to say “no” when necessary. They say that when everything is a priority, nothing is a priority. I don’t know who “they” are, but I think they’re right.
- Figure out how to identify if a project is important
- Use that system
- Work on important projects