Monthly Archives: October 2008

Is Product Management Agile?

There’s a lot of talk about Agile Product Management these days, and for obvious reasons. The thinking is that because of Agile development, Product Managers need to change how they function and adapt themselves to a new way of developing software and become “agile”.

But the reality is, Product Managers have always been agile, and finally the software developers are coming around to OUR way of thinking!

Yes, you read that right. Agile is the result of engineers finally understanding what’s really important and making a bold declaration that they now understand. But of course, being engineers, they won’t give credit to Product Management. They’re taking all the credit themselves for this tremendous insight and seachange in their profession. :-)

Don’t believe me? I’ll prove that Product Management has always been “agile” using the Agile Manifesto itself.

The Manifesto has 4 elements. They are:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

OK. Let’s take one at a time and apply them to Product Management.

Individuals and interactions over processes and tools

Most product management teams are understaffed. In fact, in many companies you’ll only find individual product managers working alone with teams of developers. They have no choice but to interact face-to-face. And not just with Development, but with every other group in the company and many parties outside of the company.

“Hub of the wheel”? You know what that translates to in the real world? Meetings, and lots of them, with the primary objective to keep all teams aligned and aware of progress, status and plans. Those cross-team meetings aren’t for the benefit of Product Management!

As for processes and tools…well, most PMs will tell you they do what it takes to get the job done, and the only tools they have are usually email, Excel, PowerPoint and Word, possibly some crappy (free) wiki software and Post-it notes. No fancy (or even basic) requirements management tools for most Product Managers. Individuals and interactions: Yes. Processes and tools: Not much. Score: 1 for 1.

Working software over comprehensive documentation

What PM doesn’t want working software? If only the final product that came out of Dev and QA was guaranteed to always work as expected. PMs want working software so much they perform QA, file bugs, run beta programs and hound the testing teams to ensure all the important use cases actually work.

How many times have we taken a pre-release build and found that it doesn’t install properly, or fails when upgrading from a previous version, or has licensing problems or runs really slowly using real world data sets. Ensuring working software gets out the door is top of mind for every PM, and even though helping QA the product is not technically part of our job, many of us do it anyway to raise the probability of actually delivering working software.

Regarding comprehensive documentation, we don’t tell Dev teams to create 50 page spec documents. They choose to write them and then PMs are forced to sit through endless “spec review” meetings to ensure Dev has taken the requirements and translated them properly into something THEY understand.

As for creating comprehensive documentation, PMs can never be accused of that. What’s the most common complaint from Engineering about Product Management? Answer: “The requirements aren’t detailed enough.” ‘Nuff said. Score: 2 for 2.

Customer collaboration over contract negotiation

Too easy. Really, do I have to explain this one? OK, I will. “Product Management: Voice of the Customer”. How often have you heard that phrase? Meaningful phrase or not, Product Management focuses extensively on customer insight and collaboration. It’s another core aspect of the job.

But, there are countless true stories of Engineering VPs who exhibited disdain for what customers actually want or need. These people are so smart they know what customers need, with little if any input from the customers themselves. Case in point.

A survey of 500 customers showed clear priorities for a number of big ticket items that needed to be added to a product. Capability <A> was ranked #15 by customers but was a pet project of the VP Eng. Capability <B> was ranked #2 by customers. We only had the resources to do one of those 2 items, along with everything else that was planned.

PM: We’ve laid out the requirements in priority order. < B> is critical for the next release and given the target release date, resources and survey results, we’ve deprioritized <A>.
VP: Hold it a minute. Are you saying that <A>  is not important?
PM: Well, it’s not as important as <B> and the other things we’ve prioritized for this release.
VP: I was talking to MegaBankCorp last week, and they really emphasized the need for <A>.
PM: Yes, I spoke to them too. But they’re one of only 3 companies who have indicated they have an urgent need for <A>. I’ve got 50 companies that need <B>. <B> is more important than <A>.
VP: I don’t think you’re talking to the right people. I hear people asking for <A> all the time. Our major competitor has <A>, and we’ve lost deals to them.
PM: We’ve lost 1 deal to them on <A>, The sales team agrees that <B> is much higher priority than <A>, and the 500 hundred customers I surveyed agree as well.
VP: Don’t you realize <A> is strategic? Don’t you even read the industry news? You know what the problem with Product Management is?
PM: I’m sure you’re going to tell me.
VP: You talk to too many customers! You don’t talk to enough people who don’t use our product.
PM: People who don’t use our product also don’t tell us what they want added to the product. But, if you have the resources to do both <A> and <B> in this release, then be my guest. But <B> is top priority if you can’t do both.

Result: VP storms out of the meeting. Sends and email the next day indicating that after analyzing the effort and resources, both are not possible in the coming release so only <B> can be done.

Of course, not all Dev leads and VPs are as stubborn. But when it comes to wanting to work with customers, as opposed to sitting in meetings trying to get Engineering to buy-in on what is needed, Product Managers have always advocated for that. Score: 3 for 3.

Responding to change over following a plan

Next to “The requirements aren’t detailed enough“, the most common complaint that Engineers have of Product Management is that PMs regularly “change their mind“. Most PMs don’t simply change their mind about things, but reprioritize what is important based on new data, new market conditions or other external changes that take place. That’s core to the role of Product Management. The world is a dynamic place, and when your competitor is bought out by and industry giant, or you find that you’re losing deals because of product gaps, action must be taken.

Yes, there are some flaky PMs who don’t have a clue about things, but that can’t be helped. Most capable PMs are reasonable people who need to focus on the business and leverage the engineering resources to help drive business benefit. It’s hard enough to predict what will happen 3 months from now, let alone 12 months from now.

But if a development cycle will take 12 months to complete, Product Management must be collecting the data to define that release many months in advance. Hey, we’re smart, but we’re not the Oracle of Delphi. We make decisions. Decisions are based on the information we have today. If something material happens after a decision is made that requires a change in product plans, the change must be made. Product Management always understood that. Engineering seems to be finally realizing that. Score: 4 for 4.


So there you have it. QED — quod erat demonstrandum.

Product Managers have been living, breathing and advocating the elements of the Agile Manifesto for years before the Manifesto was even a firing synapse in the brains of any of it’s authors. Developers though were set in their ways, pushing back on Product Management for changing priorities, not providing enough detail in requirements etc.

I’m glad, even if they don’t want to admit it publicly, that Engineers are finally seeing the light. Now, if we could only get Management to allocate more headcount to Product Management, life would almost be perfect.


Agile/Scrum and Product Roadmaps

By Saeed Khan

A common question that come up when discussing Agile/Scrum is how to develop and maintain a product roadmap in an Agile environment.

The confusion seems to come from the focus of Scrum on short development cycles and the ongoing prioritization and reprioritization of needed functionality in the Product Backlog.

So, is there a conflict here that would prevent or hamper the creation and maintenance of product roadmaps in an Agile environment?

The answer is absolutely not. In short, Scrum is a development methodology, and roadmaps are business planning and communication tools. The two are independent of one another and there should be little impact on maintaining a product roadmap in any company where Engineering adopts Scrum.

Not satisfied? OK, here’s a slightly more detailed answer.

First, let’s agree on what a product roadmap is NOT.

It is NOT a 100% guaranteed, take it to the bank (ok, not all banks these days) definitive and unswerving description of what will absolutely be built in the next several releases of a given product.

No, that is not what a product roadmap is. Even though, that is what a lot of salespeople will want and demand it to be.

BTW, as an aside, here’s a little trick on how to handle salespeople who demand an absolutely fixed, definitive roadmap for the future. Tell them, Product Management will commit to such a roadmap, when the sales team commits to an absolutely fixed, definitive sales number for the next 4 quarters. Watch their reaction. I doubt you’ll have any takers.

So, what is a Product Roadmap?

A roadmap is a planned future, laid out in broad strokes — i.e. planned or proposed product releases, listing high level functionality or release themes, laid out in rough timeframes — usually the target calendar or fiscal quarter — for a period usually extending for 2 or 3 significant feature releases into the future.

For startups or companies in fast moving and growing markets, those 2-3 releases might only cover the next 12 months of time. For other more mature companies in less dynamic markets, those releases might cover several years.

I emphasized the word “planned” above. Plans are simply plans. They are our intentions for the future given what we know and believe today. They are not commitments. Most roadmap presentations I’ve seen, and virtually every single one I’ve seen from a public company starts with a big disclaimer that absolves the company from committing to anything that is presented in the roadmap.

And, people listening to the roadmap take it in stride. They understand that the future is not certain. What they want to hear is a statement of intent, that is credible and potentially achievable, and that can help them make plans for their own futures.

Note that none of this has anything to do with what kind of development methodology is used to potentially implement the planned functionality. And if anyone does ask, a great answer might sound something like this:

Our development teams use a hybrid approach that leverages the best of current Agile methodologies, mixed with the more predictable and steadfast aspects of waterfall. This gives us the flexibility we need to adapt to changing market conditions and customers needs, but still maintain a rock-solid foundation in our development cycles that enables us to continue to deliver high quality releases year after year.

If nothing else, people will nod their heads in agreement and never again ask about your development methodology.

Finally,  most product roadmaps are so devoid of useful information that they are simply a set of talking points or a listing of product release codenames on a single slide. This provides a lot of wiggle room for the presenter (Sr. Executive, Product Manager, Product Marketer or someone else) to paint a rosy picture of the future but never actually commit to anything.

Here are a few REAL roadmap images I pulled down from the web. Which of these companies uses Agile in the development shop? Can you tell? Does it matter?

Click on any image to enlarge to full size.


Motto for ProductCamp Toronto

Hey, here’s a little contest.

Suggest a motto for ProductCamp Toronto and if we use it, we’ll send you a ProductCamp Toronto t-shirt with the motto. You don’t even have to attend the ProductCamp to win!

But if you do attend, then we’ll give it to you onsite, and make a big fuss or something about as well, just to recognize your contribution.

That’s it, it’s really simple. Just leave a comment with your suggestion or email us: productcamptoronto at gmail dot com.

Here’s a little inspiration to get the creative juices flowing:

  • ProductCamp Toronto: An Unconference in the Great White North
  • ProductCamp Toronto: Participate,  Captivate, Agitate, Permeate
  • ProductCamp Toronto: Took longer to plan than the Federal election
  • ProductCamp Toronto: A much better name than P-Camp!

Oh yeah, deadline is Wednesday October 26. 2008! We need time to get the shirts made for the November 2nd event.

Hope to hear from you.


ProductCamp Toronto Update

ProductCamp Toronto

ProductCamp Toronto is fast approaching.
It is on November 2, 2008 at the Ted Rogers School of Management at Ryerson University in downtown Toronto.

It’s an unconference. Participants get to decide the topics. Here’s a list of topics suggest by people like you. Make sure to scroll down to see the full list. It’s a Wiki, so edit the page to add your own topic.

Click here to cast your vote on the topics you want to are interested in.

Or check out the results of the survey so far.

And if you plan on attending, register here.

Hope to see you at the event!


Product naming

April Dunford had a good post last week about Product Naming. She summed it up quite well with the three kinds of product names. Back in the day (circa 2000), on of my products was the focus of a corporate rebranding, and we spent a whack of money on a new company name, a product name, and a brand architecture. It was a real education for me personally, as I got to work with Interbrand, which is one of those companies who, like April described, just gets the naming and brand-image thing.

We ended up with two new names: Sitraka (company), and PerformaSure (my product), along with some nice graphics, logos, corporate colors, and a “voice” for the company. It was really slick, but also very expensive. There are some very creative people and small firms out there who can do this kind of work for a lot less, but with Interbrand, we knew we were going to get a great result.

Eventually it paid off, when the company was acquired. I know that the branding and the vision we were painting made us look much bigger than we really were, and attracted a great stable of acquirers. Or maybe it was just the great product we built!

I’d be interested in hearing from you (in the comments below) about some:

  • great, but inexpensive, branding you’ve done. Shout out to the companies you admire for the great job they do on a budget.
  • mistakes, flops, or bad names that you’ve seen or developed.

I’ll start the ball rolling: When I was at Fortiva, Evoke re-made our web presence. They did a fantastic job in a short time period, and again, really helped the company project an updated and large image. Here we are in their gallery.

And in the mistakes category, everyone has heard of how the Chevy Nova played in Latin America, or perhaps how “Roots” came across in the Sydney Olympics. But here’s one in Chinatown that made me laugh:

Unison Academy of Music

Curiously, the store appears to be out of business. Perhaps with such a concrete name, they couldn’t adapt to the market, which is focused on polyphonic harmony, going forward.


The value of Scrum

Richard from left an interesting comment to one of my Agile/Scrum/PM posts that I think is worth discussing. I agree with some of what he said, but of course, the interesting parts (IMHO) are where we don’t agree!

You can see the whole comment in the link above, but I’ll pick out the salient parts here. Richard starts:

Scrum’s key value is most definitely NOT in its definition of roles to support a development methodology.

Agreed on this point, the value is not specifically the roles, but for software companies trying to implement Scrum, implementing the roles, such as Scrum Master, Product Owner etc. and processes that make up Scrum are key.

And what I’ve focused on is the Scrum team’s interface role — Product Owner — and it’s relationship to Product Management. There is a lot of confusion in both the Development and Product Management communities about how best to enact this role.

Its genius is giving all of us business veterans a lighter, more realistic project management framework that recognizes results improve when you break large, long projects into short iterations that inspect and adapt along the way.

While I agree with this, the notion of breaking larger projects into smaller tasks is hardly new, nor unique to Scrum. I think my grade 3 teacher taught us this principle, but it is enforced much more strongly in Scrum through the concepts of stories and iterations. The other, and in my opinion, more important differentiators from other methodologies are:

  • the daily tracking of both group and individual progress, issues and interactions so as to minimize lag time between when a problem is identified and when addressing it begins
  • the tight-coupling of teams such as development and testing during iterations to keep the process moving forward

In fact, given the code and functional interdependencies that are a natural consequence of any software development project, for tightly-coupled teams to work hyper-efficiently, they MUST resort to daily tracking and conflict resolution.

This adaptive approach works equally well for planning a trade show, writing a whitepaper or burning down your backlog of sales tools.

Well, yes and no. Virtually all projects are broken down into smaller more manageable and measurable tasks. When writing a whitepaper, one might break it down into smaller steps such as initial research, initial draft, first edit review, updates, second edit review etc. But in this case, unless there are several people writing and editing the whitepaper simultaneously, there is no “scrum” to speak of and the benefits of Scrum don’t come into play.

I would argue that trade show planning would be similar. While again there is benefit to identifying smaller, more measurable tasks, a lot of the tasks are completely independent from one another — e.g. booth design, giveaways, demo and script preparation etc. — and all have to be done by certain dates but are not directly interdependent. i.e. these are loosely-coupled tasks.  If there is no tight-coupling of teams, the value of Scrum is diminished though not eliminated.

Dean Leffingwell says it best in his “CIO Playbook:”

Know where you are every day with Scrum
- or -
Think you know where you are on your well-formed plan
and discover that you are very wrong, very much later

There is a bit of religiosity entering the discussion here. No project tracking mechanism is entirely accurate. And any process can be executed on well or poorly. I’ve seen many projects executed and tracked well via non-Agile/Scrum methods.

Scrum does — as I said in the first post on this topic –  “provide potential for greater visibility into current work status, work remaining, can identify development hurdles earlier and can communicate them outward more easily.” But there are no absolutes here.

Scrum is not a panacea. And while it can likely be applied to other domains than software development, the current focus of the Agile Alliance and certainly that of the Agile Manifesto is on Software Development. And for good reason.

Software projects are very complex.  The final result — “the software” — must be flexible, scalable, secure, robust etc. It must work. There are a lot of dependencies and unknowns that must be resolved as part of the software development process. Those dependencies can be in the software code itself, interaction with 3rd party software or hardware, and under conditions that may be difficult to plan for and test. These dependencies and complexity can only be minimized with constant vigilance and communication. This is why Scrum is suited for software development.

Other tasks that don’t have the complexity, level of dependency, or unknowns that software development has, will not benefit as much, and sometimes not at all, from Scrum-like methodologies. Ask yourself, could HR go Agile? :-)

Given adaptive management approaches are better than predictive methods whenever you have unknowns, the rest of the business absolutely needs to “bend and accommodate.” If development is finally able to deliver customer value faster, what is preventing your company from experiencing the revenue gains? Is it because Marketing can’t adapt to the new pace? Support? Sales? A lame install & update process?

Put it another way, if your #1 competitor is consistently delivering new features in half the time you are, how long do you think that is tenable?

So here’s where the crux of the problem lies. It’s an engineering centric view of the business. As I read the paragraph above, I can’t help but think a few things:

  1. Richard is an engineer given the snarky comment about Marketing and the comment about “lame install process” (no offense intended Richard if you are not an Engineer)
  2. The air of superiority I hear from many Agile advocates over other project tracking methods reminds me of certain political or religious campaigns. Lower the intensity level folks!
  3. Customer value is about more than just software features sooner. If Development can work faster than before, that doesn’t mean the market or customers are ready to accept product every 4 months vs. every 6 months. Engineers seem to often forget this unfortunately.
  4. As for competitors building software faster…that has little to do with methodology. My #1 competitor may be twice as big as me (or twice as small!), or their quality may be half of mine, or their feature set is built on a house of cards, while mine is built on a solid architecture. Velocity, to use a Scrum term, is important, but it is only one aspect of what the business needs from the development organization.
  5. I’ve never seen a Development team that can deliver product faster than a Marketing team can put together and execute a launch plan. Seriously, is this a problem that Scrum needs to address?

Agile may have started out as being about development, but it’s quickly becoming about the whole enterprise.

As I read this last line, I’d like to agree, but the following line comes to mind:

To a hammer, everything looks like a nail.

There are aspects of Agile that can be used or adapted to areas other than software development. And if other teams benefit, then more power to them. But there is little evidence that the “Agile Enterprise” will emerge in the coming decade any more than the “Real-time Enterprise” emerged in the previous one. I may be wrong, but those kinds of changes, if they happen, take a long time and a lot of effort to enact. To paraphrase myself:

Change is a process, not an iteration. :-)


Agile/Scrum and Product Management (part 4)

So, here it is, finally, part 4 of this series. Sorry for the gap since part 3 (and 3a), but work and life have a habit of keeping me busy.

In this post, I’ll discuss where I think the Product Owner should reside in the organization, and some of the issues to consider when making that decision.

As discussed in part 3, and so well illustrated by Dean Leffingwell, the table below lays out the differences between a Product Manager and a Product Owner.

Product Manager vs. Product Owner

So where does the Product Owner role belong. Well, the answer is…. “it depends”.

The Product Owner is part of the Scrum team, and as I’ve said many times, Scrum is a DEVELOPMENT methodology, and thus, in general, the role should be part of the Development organization.

This does NOT mean that Product Management does not communicate with the Scrum team at all. What it does mean is that the Product Owner must be customer-centric enough and have enough understanding of the requirements to help the development team efficiently work through day to day issues when implementing well defined stories.

The Product Owner lives with the Development team. The Product Manager works with the Development team, but also with other teams such as sales, marketing, support, finance etc. Thus it is really not practical to make the PM also the PO, given the nature of the role.

Earlier I said, “in general” the role should be part of the Development organization. In a healthy and mature development culture, it should reside there. But as we know :-) , many development organizations are neither healthy nor mature.  If that is the case, you or the management team in your company need to decide how best to accomodate that role. Perhaps Product Management needs to take charge of the Product Owner role. Maybe some Development teams need someone from outside the org and others don’t. Does Product Management have the bandwidth or the skillset to take on that role?

There are a number of questions that need to be thought through. The end goal needs to be how best to keep the development teams effectively aligned with requirements and customer/market needs. Find the right people for the role(s) of Product Owner and ensure they clearly understand the objectives, and put them in the right place in the organization to maximize their potential for success.

Rich Mirinov stated in a comment on a previous post:

The crunch is when there’s not enough money (or staff or attention) to have both a Product Manager and a Product Owner.

If the company decides to adopt Scrum, then the company must acknowledge the requirements it puts on the development team and staff accordingly. If the company is not willing to do that, then they should wait until they can staff it properly, or understand the trade-off that they will need to make.

If the PM takes on the role of PO as well, the company MUST acknowledge the dual role, and not be surprised when the next set of product requirements doesn’t come out in time, or is deficient.

Steve wrote:

My concern with the Product Owner being part of the Development group is that there may be too much pressure on them to make decisions that are best for the schedule/easier for the developer or more fun for the developer – and not what is best for the customer or the market. Their allegiances could lie more towards Development and the person that manages them – not necessarily the product.

The ROLE of the Product Owner in Scrum, is to be the “voice of the customer”. That is fundamental to the methodology. If the PO does what is in the developers’ best interests and NOT the customers’ interests, then the PO is not doing their job, plain and simple. It then becomes a management issue to resolve. The VP of Engineering or whomever is in charge, needs to be mature enough to ensure that people in the Engineering org do their job. If that’s not the case, the problems have nothing to do with Scrum or the Product Owner. As mentioned in a previous post:

Scrum is not a panacea for organizational issues

Finally, here’s what I find strange. Before Scrum, Development Managers, UI and Interaction Designers, Developers, Architects etc. were empowered to make tactical implementation decisions.  They were also tasked with the responsibility to escalate issues that could result in not meeting requirements. There was regular dialogue (at least in the companies I worked in) between Development and Product Management via status meetings, functional and design spec reviews, UI reviews, feature complete reviews etc.

Now with Scrum, people seem to have suddenly forgotten all that, and feel that the Product Manager needs to be involved in all decisions and that the various touch points that existed previously are no longer needed.

Spec review? Who writes specs in Agile? Remember that line from the manifesto? Working software over comprehensive documentation.

Reality check folks. Hate to tell you this, but Engineering is NOT the center of the universe, and just because they’ve adopted Agile/Scrum, it doesn’t mean the rest of the company should suddenly bend itself to accommodate. Engineering needs to work within the context of the business, and not the other way around.

And Product Management needs to have a backbone and stand up for what is right and best for the products and the business.  Wanna really be the CEO of the product? Then ask yourself, what CEO would define his or her business based on the current methodology used by any functional team?


Obama / McCain debate: long on features, short on positioning

Like many of you I watched the US Presidential Debate on Tuesday night. The night before that I watched a re-run on YouTube of the first debate last month. What struck me more than anything was that neither candidate seemed to take the lead. It reminded me in many ways of salesmen arguing about product features rather than telling a compelling story.

What was missing was the underlying narrative about what’s going on in the US and around the world. With all the money that the candidates spend on polling, research, and spin, I wish they could get their positioning right.

Here’s the outline of what I’d like to hear from both sides. I’m not trying to be comprehensive, mostly just to sketch the format of the argument with a few examples.

Dear Americans:

America is at a cross-road, and the outlook right now appears dark. If I told you that things just needed tweaking, that would be misleading and dishonest, because what we need is an overhaul of the systems that govern this country. At its core, capitalism and democracy are sound, but we have some problems to fix:

  1. The capital and financial markets need to be restored to health. Like it or not, the financial system in this country – and around the world – is like the circulatory system of the body; no one notices when the blood is flowing, but when it stops flowing, the body shuts down. In the past two weeks we came terribly close to a collapse of those systems, and getting out will not be easy, but it has to be JOB 1 of the next president.
  2. The war in Iraq has taken a toll on this country that goes beyond money and into our national psyche. Regardless of what you think about how the war was started, we’ve now inherited a situation that needs to be solved.
  3. We need to restore the innovative, aggressive, competitive nature of our nation’s industry, across the board. This will not be easy. Some kinds of jobs will never come back to our shores, but we can restore the competitiveness of American manufacturing and we can create jobs that can never be off-shored.
  4. The social infrastructure that we rely on is breaking our backs. The costs of health care and education are sucking the life out of individual families, and in aggregate, the economy.

Those are the problems, my friends, and we have not faced a situation like this in our lifetimes. We are at a cross roads. BUT!

  1. We can do it because we’ve done it before! Talk about the nation’s forebearers, the founding fathers, JFK, Abe Lincoln, and current leaders in all areas of society, economic and social. We can climb this hill.
  2. I believe in us. I believe in you. The America I believe in can tackle these problems. We have the technological infrastructure. We still have the strongest economic engine in the world.
  3. What we need is leadership that knows the problems, and can pull the nation together to work on them. We DON’T need a leader who will control everything, but one who can see a bright future and bring Americans together to re-tool this country to be the leader of this next century.

The trouble is:

  1. these problems are not simple, and thus the answers are not simple. Fixing them will require sacrifices. It’s not popular for me to talk about sacrifices; my pollsters tell me that you want bonuses, not sacrifices.
  2. The reason the financial system is broken: <explain … show you’ve diagnosed and understand the problem, help people understand what’s really going on. If you do this well, you can later explain how you’ll fix it with their help.>
  3. The reason the healthcare system is broken: <diagnose, explain>
  4. Diagnose, explain each core problem.
  5. For Obama:
    1. Before we can fix a problem, we need to admit it, admit the depth of the problem, and recognize our own parts – as a country, and as members of government – in creating the problem.
    2. The current administration is defending its record.
    3. While Senator McCain calls himself a renegade, he is part of the republican system, and his team would be more of the same.
    4. My opponent really will not admit the problem exists; he’ll talk about the problems in vague ways, but he’s stuck defending his own voting record and his long-standing alliance with President Bush.
  6. For McCain:
    1. Talking about hope is different than creating hope; Senator Obama has a lot of spark and some good ideas, but this situation requires more.
    2. A complex situation like this requires a steady hand and experience.
    3. Senator Obama has almost no international experiences, and whether you like it or not, we are in a globally connected world. The success of the next 50 years will depend on the ability of your next president to understand world issues and work with world leaders. One or two trips to Europe is not enough preparation for the job, sir.

And I am asking for you to elect me to be your president:

  1. We will start on day one with initiatives to restore confidence in the financial markets in American and around the world:
    1. Surely the candidates have ideas here?
  2. With those initiatives under way, my next priority would be to stimulate the economy: <plan>
  3. Include a LOT about how average citezens can help. This isn’t about government welfare; it’s about a country getting back in shape, and that requires all of us.
  4. I believe in XYZ for healthcare, and I would do ABC…

    … continue to lay out the platform.

Do you you get the picture?

What I present above puts the argument into a framework that explains:

  1. The problem(s) we face, and the magnitude of the problem…
    … candidates talked about individuals with problems (which is ok), but not as much about the deep structural problems with the country itself and its place in the world.
    1. But we can do it… show belief; talk about the kind of country this is.
      … John McCain did some of this, but not nearly enough… and without an overall strategy to help Americans understand how they can help.
    2. The trouble with the existing situation (Diagnose the problem), and why my opponent can’t solve it.
      … diagnosis was sadly lacking in this debate.
    3. Why my plan addresses the problem and avoids pitfalls
      … again, this depends on a clear articulation of the problems and the reasons the problems exist. At this point, lay out the policies!

    I think both candidates missed the boat. Their problems all come back to positioning:

    1. They didn’t admit the problem, or the scale of the problems. There was not a full reckoning of the magnitude of the problem in the capital markets, but perhaps they don’t want to spook the public? I’m not sure how many Americans have internalized the impact of the collapse of the Wall Street giants over the past several weeks, and the tumbling stock market, but it seems to me that the nation must be stunned. What happened? What next? Americans know the problems are big, but if a leader doesn’t talk about it, he doesn’t connect with us.
    2. I didn’t hear a lot of confidence. People are scared, and they need to believe. Show belief in the country to overcome this challenge.

      This isn’t just about government doing more. It’s about giving citezens their own marching orders; what can they do for the economy? Empower the nation, and you’ll reduce the reliance on government by definition.

    3. Diagnosis: I didn’t get the sense that either leader really understands why we have the problems we do! If he doesn’t undersand the problems folks, I guarantee he can’t solve them. And if he doesn’t share his diagnosis with Americans, Americans can’t get on board!
    4. Lay out the plan. In the product world, these are the features. In this debate, they talked about the features without describing the problems. We were left with a debate about features with no way to evaluate them.

    Maybe what these guys really need is a product manager.

    - Alan