The formula for persuasion consists of three straightforward steps: (1) sell the opportunity or problem; (2) collaborate in designing a solution; (3) formulate a plausible plan for implementing the solution that resolves, or at least ameliorates the problem or, in the case of an opportunity, successfully exploits it.

Political case in point (oh, don’t be that way – what follows won’t be tribal and will be relevant to leading in business situations): Here in Minneapolis we’re soon going to vote on amendments to the city charter. The most controversial is an attempt to address the clear and apparent deficiencies in how policing happens in our city.

What makes it controversial (and interesting from a KJR perspective) is how its proponents have failed to follow the principles of persuasion.

Sell the problem? As its proponents point out and its opponents don’t contest is that policing in Minneapolis needs to change. There’s broad consensus on the problem. Consider it sold.

Solution? It’s pretty vague – so vague that the courts have ruled that it can’t be on the ballot in its current form, on the grounds that voters can’t tell, based on the text of the amendment, what they’d be voting for or against.

Plan? Even the proposal’s proponents agree that there is no plan. Their plan is to figure out the plan once the proposal passes. Regrettably, if the proposal passes it would, by law, take effect 30 days later, which, given the vagueness of the solution, is an unlikely outcome.

Imagine you see the need for a change in how your company does business. For our hypothetical we’ll imagine you see severe inefficiencies in how it handles “non-strategic sourcing” (general purchasing, in case you aren’t FBC (Fully Buzzword Compliant)), along with many purchasers paying more than they should for the merchandise they need.

And so, frustrated with the status quo, you form a committee which does what committees do, and produce a proposal. Its explanation of what’s wrong right now is specific and compelling. Its solution, though … centralize non-strategic sourcing … is lacking in specifics.

But it’s the plan, which is to start work on a plan once the Executive Leadership Team (ELT in case you aren’t FBC) gives you the go-ahead, is what results in admiring guffaws at the excellent satire you presented to lighten the load created by so many of the other dreary proposals the ELT has to wade through, replete as they are with detailed financial and process optimization analyses, and fine-grained Gantt charts that illustrate their implementation roadmaps.

Which is to say the ELT laughs you out of the room before you even managed to explain you’re following Agile principles.

To be fair to all parties, your approach isn’t quite as absurd as it seems. While miniscule in scope compared to disbanding the Minneapolis Police Department, replacing it with a Department of Public Safety that might include policing functions should that turn out to be desirable … while miniscule in comparison, centralizing non-strategic sourcing in a large enterprise is no small task. Designing all of it in detail before implementing any of it would exemplify Waterfall at its worst, with lots of opportunity for blind alleys and into-a-corner painting.

And so, chastened, bloodied but unbowed, you read up on Agile and discover Agile isn’t what you’ve done. So you fire up the old word processor and write up a truly Agile approach, which is to say you explain the opportunity much as you’ve already done, but then ask for only enough funding and staff time to: draw up an Epic-level account of what the solution would entail; and describe a set of Agile business change methods that:

  • Rank lines of business from simplest to most complex …
  • Charter and create a “minimum viable product” centralized purchasing department …
  • Transition the simplest line of business to centralized purchasing …
  • Rinse and repeat until all lines of business have been transitioned to centralized purchasing, or, in a few cases, left alone on the grounds that the costs and disruption of transitioning them exceed the benefits.

Bob’s last word: If you’re really clever, you’ll figure out how to set this up so you can quantify the benefits of each line-of-business transition so they pay for the next transition.

Bob’s sales pitch: Want more about how to organize business change? Read (and share) a copy of Bare Bones Change Management).

When you buy your next smartphone, what features will you compare to make your decision?

So far as I can tell, the dominant contrasts appear to lie in their cameras – cutting edge smartphones have, in addition to their main camera, ones for wide-angle, telephoto, and front-facing (selfie-mode).

Add to that a bunch of different image manipulation features and you have a complex comparison.

Next question: When you buy your next point-and-shoot camera, what features will you compare to make your decision?

Answer: Most likely you won’t buy your next point-and-shoot camera. You’ll upgrade your smartphone instead, and for higher-end photography you’ll buy a DSLR.

As a category, point-and-shoot cameras are, along with Monty Python’s famous Norwegian blue parrot, on the way to joining the choir invisible. Steadily-improving smartphone cameras are rapidly extinguishing them, just as steadily-improving digital cameras extinguished those that use film.

Which will get us to this week’s topic in a moment, right after we ask ourselves whether better product management on Nikon, Canon, or Olympus’s part might have staved off this category calamity.

The answer: Probably not. Product management is an in-category discipline, which is why Canon’s product line dominates the DSLR marketplace but doesn’t provide OEM componentry for any smartphone. More broadly, it’s why the major camera companies didn’t add telephone-oriented features to their point-and-shoot cameras.

Which (finally!) brings us to this week’s topic: Whether IT should organize according to software product management principles rather than software project principles (see, for example, this lucid explanation on

The answer? No, but IT shouldn’t continue to organize around software projects, either. As all enlightened members of the KJR community (if you’ll forgive the redundancy) know, there’s no such thing as an IT project. It’s always around business change or what’s the point?

Organizing IT around IT products is certainly better than organizing it around IT projects … product-mode thinking does expressly incorporate business improvement into its planning and governance practices, more easily incorporates agile thinking into the mix, and solves the problem of maintaining a stockpile of expertise instead of disbanding it once the initial implementation project has completed.

On the other hand, most agile variants keep teams in place until the backlog has shrunk beyond the point of diminishing returns, so this last “benefit” is something of a strawman.

Meanwhile, the product perspective brings with it a potentially crippling disadvantage – the inevitability of internal competition. Here’s how it works:

Imagine you’re the product manager for your company’s in-house-developed, highly optimized, strongly supported SCM (supply chain management) system. You and your team have deep expertise in its workings, which lets you respond quickly and efficiently when business needs change or new needs arise.

Meanwhile, as a result of several mergers and acquisitions, three other business units also have SCM systems and supporting teams, each with capabilities roughly comparable to what your team brings to the table.

And so, the CIO and IT planning committee decide it’s time to rationalize the applications portfolio, building out the architecture to a hub-and-spoke model anchored by Oracle ERP Cloud (this is, understand, just a ferinstance, not an endorsement).

Suddenly, your team’s expertise is irrelevant. And so, being savvy at the game of corporate politics, you invite the head of your business unit’s supply chain function to join you for conversational lubricants, in which conversation you explain the disadvantages of forcing his team to use a software vendor’s plain-vanilla SCM module instead of the finely-tuned application they’re used to.

Describing how this scenario plays out is left as an exercise for the reader. Suffice it to say, it wouldn’t be pretty.

Bob’s last word: More problematic than everything else, the product perspective leaves in place defining IT’s relationship with the rest of the business as a vendor dealing with internal customers. This is a bad idea, something I’ve been explaining since1996.

IT should be organized to support business optimization, where each business function defines optimization according to what it will take for it to run differently and better, and the company defines IT’s relationship with the rest of the business as partner and collaborator in delivering profitable value to Real Paying Customers.

Bob’s sales pitch: Not the first time I’ve mentioned this, and it won’t be the last – you’ll find an in-depth explanation of how to make this work in There’s no such thing as an IT Project: A handbook for intentional business change. And it isn’t just in-depth coverage of content that matters. Dave and I took pains to make sure it’s readable, too.