<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Plan for the present and likely future</title>
	<atom:link href="http://www.goodproductmanager.com/2008/03/17/plan-for-the-present-and-likely-future/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.goodproductmanager.com/2008/03/17/plan-for-the-present-and-likely-future/</link>
	<description>A blog with tips on product management and related topics. Written by Jeff Lash, a product manager in St. Louis, MO</description>
	<lastBuildDate>Sun, 07 Mar 2010 10:14:56 -0800</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: David Locke</title>
		<link>http://www.goodproductmanager.com/2008/03/17/plan-for-the-present-and-likely-future/comment-page-1/#comment-8280</link>
		<dc:creator>David Locke</dc:creator>
		<pubDate>Mon, 28 Apr 2008 23:48:42 +0000</pubDate>
		<guid isPermaLink="false">http://www.goodproductmanager.com/2008/03/17/plan-for-the-present-and-likely-future/#comment-8280</guid>
		<description>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&#039;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&#039;re a genious. If it is ten years out, you&#039;re a nut. 

Go out for the pass, but don&#039;t cross into the parking lot.</description>
		<content:encoded><![CDATA[<p>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. </p>
<p>The rest of the plan represents a collection of options. You can decide to go or not. This isn&#8217;t optimisim in my book. </p>
<p>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. </p>
<p>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. </p>
<p>Its also been said that if the idea is five years out, you&#8217;re a genious. If it is ten years out, you&#8217;re a nut. </p>
<p>Go out for the pass, but don&#8217;t cross into the parking lot.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ivan Chalif</title>
		<link>http://www.goodproductmanager.com/2008/03/17/plan-for-the-present-and-likely-future/comment-page-1/#comment-8012</link>
		<dc:creator>Ivan Chalif</dc:creator>
		<pubDate>Sun, 13 Apr 2008 05:53:18 +0000</pubDate>
		<guid isPermaLink="false">http://www.goodproductmanager.com/2008/03/17/plan-for-the-present-and-likely-future/#comment-8012</guid>
		<description>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.</description>
		<content:encoded><![CDATA[<p>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.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tom Grant</title>
		<link>http://www.goodproductmanager.com/2008/03/17/plan-for-the-present-and-likely-future/comment-page-1/#comment-7696</link>
		<dc:creator>Tom Grant</dc:creator>
		<pubDate>Thu, 27 Mar 2008 21:58:06 +0000</pubDate>
		<guid isPermaLink="false">http://www.goodproductmanager.com/2008/03/17/plan-for-the-present-and-likely-future/#comment-7696</guid>
		<description>&quot;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?&quot;

By the way, one historian blamed the United States&#039; problems in the Vietnam War on exactly the same thinking. There were too many &quot;ifs&quot; that had to pan out (if the South Vietnamese government remained stable, if the American public didn&#039;t get fed up with the war, if...) to achieve anything like a US victory.

Which is another way of saying, this isn&#039;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.</description>
		<content:encoded><![CDATA[<p>&#8220;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?&#8221;</p>
<p>By the way, one historian blamed the United States&#8217; problems in the Vietnam War on exactly the same thinking. There were too many &#8220;ifs&#8221; that had to pan out (if the South Vietnamese government remained stable, if the American public didn&#8217;t get fed up with the war, if&#8230;) to achieve anything like a US victory.</p>
<p>Which is another way of saying, this isn&#8217;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.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott Sehlhorst</title>
		<link>http://www.goodproductmanager.com/2008/03/17/plan-for-the-present-and-likely-future/comment-page-1/#comment-7692</link>
		<dc:creator>Scott Sehlhorst</dc:creator>
		<pubDate>Thu, 27 Mar 2008 03:08:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.goodproductmanager.com/2008/03/17/plan-for-the-present-and-likely-future/#comment-7692</guid>
		<description>Great article, Jeff.  I&#039;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&#039;ll like it [linked to my name above]</description>
		<content:encoded><![CDATA[<p>Great article, Jeff.  I&#8217;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&#8217;ll like it [linked to my name above]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeff Lash</title>
		<link>http://www.goodproductmanager.com/2008/03/17/plan-for-the-present-and-likely-future/comment-page-1/#comment-7593</link>
		<dc:creator>Jeff Lash</dc:creator>
		<pubDate>Wed, 19 Mar 2008 02:15:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.goodproductmanager.com/2008/03/17/plan-for-the-present-and-likely-future/#comment-7593</guid>
		<description>@Henrik: There&#039;s a difference between planning ahead due to regulations / standards and speculating too far off into the future. For example, maybe there is a &quot;defacto&quot; standard in place today that you are considering supporting, even though there&#039;s the potential that an &quot;official&quot; 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&#039;t think it&#039;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&#039;s technique of launching regular updates to their increasingly-successful iPod models -- rather than waiting a long time to release the one &quot;perfect&quot; model -- is probably the most obvious example.</description>
		<content:encoded><![CDATA[<p>@Henrik: There&#8217;s a difference between planning ahead due to regulations / standards and speculating too far off into the future. For example, maybe there is a &#8220;defacto&#8221; standard in place today that you are considering supporting, even though there&#8217;s the potential that an &#8220;official&#8221; 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?</p>
<p>@Michael &#8212; 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!</p>
<p>@Chad &#8212; Agile certainly helps and forces this type of thinking a bit, though I don&#8217;t think it&#8217;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&#8217;s technique of launching regular updates to their increasingly-successful iPod models &#8212; rather than waiting a long time to release the one &#8220;perfect&#8221; model &#8212; is probably the most obvious example.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chad</title>
		<link>http://www.goodproductmanager.com/2008/03/17/plan-for-the-present-and-likely-future/comment-page-1/#comment-7591</link>
		<dc:creator>Chad</dc:creator>
		<pubDate>Tue, 18 Mar 2008 22:57:52 +0000</pubDate>
		<guid isPermaLink="false">http://www.goodproductmanager.com/2008/03/17/plan-for-the-present-and-likely-future/#comment-7591</guid>
		<description>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.</description>
		<content:encoded><![CDATA[<p>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 (<a href="http://agilecommons.org" rel="nofollow">http://agilecommons.org</a>) for great discussions on Agile practices.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Ray Hopkin</title>
		<link>http://www.goodproductmanager.com/2008/03/17/plan-for-the-present-and-likely-future/comment-page-1/#comment-7590</link>
		<dc:creator>Michael Ray Hopkin</dc:creator>
		<pubDate>Tue, 18 Mar 2008 17:43:09 +0000</pubDate>
		<guid isPermaLink="false">http://www.goodproductmanager.com/2008/03/17/plan-for-the-present-and-likely-future/#comment-7590</guid>
		<description>Jeff,
Great post! Your point about not planning too far into the future rings true, especially that &quot;your predictions will be wrong.&quot; 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 &quot;powers&quot; 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&#039;s been a fun and challenging change for me. One of the great things I&#039;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&#039;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&#039;s coming in the foreseeable (and predictable) future.
Thanks,
Michael</description>
		<content:encoded><![CDATA[<p>Jeff,<br />
Great post! Your point about not planning too far into the future rings true, especially that &#8220;your predictions will be wrong.&#8221; This was driven home to me recently in two ways:</p>
<p>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 &#8220;powers&#8221; to shift focus, and now the updated platform is projected to release in Q3 &#8212; more than a year behind schedule &#8212; and will not have the features it needs for market it will be sold into.</p>
<p>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&#8217;s been a fun and challenging change for me. One of the great things I&#8217;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&#8217;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.</p>
<p>Ultimately we, as product managers, need to drive the things that are important now, and proactively work, research, dig, etc. to find what&#8217;s coming in the foreseeable (and predictable) future.<br />
Thanks,<br />
Michael</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Henrik</title>
		<link>http://www.goodproductmanager.com/2008/03/17/plan-for-the-present-and-likely-future/comment-page-1/#comment-7589</link>
		<dc:creator>Henrik</dc:creator>
		<pubDate>Tue, 18 Mar 2008 12:35:15 +0000</pubDate>
		<guid isPermaLink="false">http://www.goodproductmanager.com/2008/03/17/plan-for-the-present-and-likely-future/#comment-7589</guid>
		<description>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 =)</description>
		<content:encoded><![CDATA[<p>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 =)</p>
]]></content:encoded>
	</item>
</channel>
</rss>
