If you want to be a bad product manager, plan for far advance into the future. Your product will of course be a success, so you need to have every possible detail figured out now to ensure it will continue to be a success for years to come. It’s just as important to plan for an issue that will likely come up tomorrow as it is to plan for an issue that could possibly come up a few years from now. If things go really well — or really poorly — you want to be prepared “just in case,” no matter how unlikely that may be.
If you want to be a good product manager, plan for now and the likely future. Understanding the long-term implications of decisions is important, though possibilities well into the future should not overshadow more pressing short-term decisions.
Too often, good ideas are rejected because they will not hold true “if” lots of things happen. For example, a good design for a database holding 10,000 records may be overruled because it will not scale to 1 million records — despite the fact that only one in a million potential customers would ever have that many entries. Or, some will insist on expending substantial effort to automate a simple manual process which takes 2 minutes to complete and is performed only on occasion, using the argument that if the process ever occurs more frequently (which would be several years into the future, at best), the automated version will be more efficient.
Planning for too far into the future often happens because people are in search of the “perfect” solution. (Surprise — there is never one!) A “good enough” solution might perform well for several months or years; unfortunately, those looking for the “perfect” answer will reject what is “good enough” and insist on a solution that is usually more complicated, more complex, and more expensive.
Another danger in planning ahead too much is that the farther into the future you try to look, the more likely you are that your predictions will be wrong. Anything beyond what is known at this moment is speculation. Sure, some areas are easier to predict than others, though in many aspects of product development, predictions may be little more than educated guesses combined with wild optimism.
Speaking of optimism, the reason for long-term thinking is often that product development teams assume wild success and plan accordingly. Yes, it would be great if you get a million sign ups for your social network in the first week. Sure, you hope that your brilliant marketing campaign drives demand for your entire 12-month inventory in 3 months. What if things do not turn out as well? Unfortunately, most of the too-future thinking is intertwined with extreme optimism (or, in some cases, pessimism). Product managers need to be reasonable and rational in their assumptions and expectations. There is a need to balance hope and positive thinking with reality, and too often product managers and product development teams end up on one end of the spectrum or the other.
As 37signals describes in Optimize for now!:
One of the easiest ways to shoot down good ideas, interesting policies, or worthwhile experiments is by injecting the assumption that whatever you’re doing needs to last forever and ever. … The best way to get to the point of needing more is by optimizing for today. Use the strengths of your current situation instead of being so eager to adopt the hassles of tomorrow.
Rather than planning for the far future, product managers need to plan for what is known and what is reasonable to expect for the future. When ideas are rejected because they will not “scale” to unreasonable levels or due to the fact that they will “only” last for a certain reasonable period of time, the product manager needs to remind the product development team to keep the issues in perspective. Clarify requirements and objectives, understand trade-offs, prioritize appropriately, and make smart decisions based on what is logical today and what is most likely in the future.
Translations available:
This is a widely debated subject among me and my PM friends. I work for a company that work with B2B solutions and other of my friends work with retail Products. The difference is huge, while my friend at a large french make-up company has to plan for next week or possibly for the Oscars by spotting trends, I have regulations to follow set by International forums a couple of years ahead of time. Big difference, same decisions =)
Jeff,
Great post! Your point about not planning too far into the future rings true, especially that “your predictions will be wrong.” This was driven home to me recently in two ways:
1. I was PM for nine months on a massive platform-rev project that had been underway for about six months when I took over. There was no real focus on what the product needed to do before I took over. As I started digging into the details of the PRD and func specs I was quite alarmed at where we were headed. I realized we were missing a great opportunity to shift to a hosted model (or at least enable MSP customers to go to a hosted model). As I tried to drive changes I got push-back from dev and other groups. I was unable to convince the “powers” to shift focus, and now the updated platform is projected to release in Q3 — more than a year behind schedule — and will not have the features it needs for market it will be sold into.
2. Three months ago I took a director position at a smaller company in a different market sector. At the new company the dev team uses Agile software development practices. It’s been a fun and challenging change for me. One of the great things I’ve realized is Agile dev allows you to keep up with important changes in the market. It helps you to get things done today that you need today. It’s not perfect but it allows teams to focus on important things needed now and move ahead in the direction you need to go to hit the market. Most important: we do not get bogged down in projects as the market changes around us.
Ultimately we, as product managers, need to drive the things that are important now, and proactively work, research, dig, etc. to find what’s coming in the foreseeable (and predictable) future.
Thanks,
Michael
Michael, an excellent point you make on the strong association between short/long term product focus and the development style used. Based on Jeff’s post, I would tend to agree that any of the Agile methodologies would help align a product manager focused on the present with the development team. Coming from a development background I also read Agile Commons (http://agilecommons.org) for great discussions on Agile practices.
@Henrik: There’s a difference between planning ahead due to regulations / standards and speculating too far off into the future. For example, maybe there is a “defacto” standard in place today that you are considering supporting, even though there’s the potential that an “official” standard may be released 5 years from now which will require you to do some re-work. Do you refuse to support the defacto standard because some other new rules may be imposed in the future, or do you make decisions based on what you know today and plan to adjust as necessary going forward?
@Michael — Great point, though your first anecdote sounds like a project with a whole bunch of problems, not just one about planning too far into the future!
@Chad — Agile certainly helps and forces this type of thinking a bit, though I don’t think it’s necessary that a product development team use agile methods for this concept to be effectively implemented. Plenty of physical / consumer products have been developed in non-Agile ways and have been very successful with this approach. Apple’s technique of launching regular updates to their increasingly-successful iPod models — rather than waiting a long time to release the one “perfect” model — is probably the most obvious example.
Great article, Jeff. I’ve followed up your article with the techniques for quantifying future capabilities, so that they can be intentionally prioritized alongside immediate term market needs. I think you’ll like it [linked to my name above]
“Speaking of optimism, the reason for long-term thinking is often that product development teams assume wild success and plan accordingly. Yes, it would be great if you get a million sign ups for your social network in the first week. Sure, you hope that your brilliant marketing campaign drives demand for your entire 12-month inventory in 3 months. What if things do not turn out as well?”
By the way, one historian blamed the United States’ problems in the Vietnam War on exactly the same thinking. There were too many “ifs” that had to pan out (if the South Vietnamese government remained stable, if the American public didn’t get fed up with the war, if…) to achieve anything like a US victory.
Which is another way of saying, this isn’t a problem unique to product management, or even the technology industry. Those of us in this particular profession might encounter it a lot more than other people, however.
I like the idea of planning for the future, but executing for the present. When I write up the requirements for a release, I am thinking big picture, which is in line with the product roadmap. But when I get to the PRD, I know there will be trade offs that I will make to get the features I need and the foundation for the future, but not necessarily all at the same time. I need to get the release out on time and set the stage for what I want in my product in the future, but it usually makes sense to address short-term issues now, but I still have to lay the foundation for the future and leave some wiggle room for mid-course corrections.
The only thing I plan for is to ensure that the marketure for the technology adoption lifecycle is built into the product, and that the cash flow is going to be there.
The rest of the plan represents a collection of options. You can decide to go or not. This isn’t optimisim in my book.
Since the technology adoption lifecycle is said to not be a clock, not a sychronous clock, working through that process means having plans that can wait, and wait a long time.
I have come across an approach that starts out as a strategic sketch and incorporates more details as the timeframes are nearer. The next quarter is very detailed. The next is loose. A year out is even looser.
Its also been said that if the idea is five years out, you’re a genious. If it is ten years out, you’re a nut.
Go out for the pass, but don’t cross into the parking lot.