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 martin.Fowler.com).

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.

Principle #1 of the KJR Manifesto: There are no best practices, only practices that fit best.

Principle #2 of the KJR Manifesto: To optimize the whole you must suboptimize the parts.

Which gets us back to outsourcing – when it makes sense and when it doesn’t once you peel the onion beyond the usual, shallow rationales.

Last week we explored the practical matter of whether a company’s executives might be better or worse at hiring and managing a given business function’s leadership … and leaving it to that leadership to make that function effective … than they would be at selecting, negotiating a contract with, and managing an outsourcer to make that function effective.

Because really, when deciding whether to outsource or insource, isn’t that the only question that matters?

What’s left to be said on the subject? The first two principles of the KJR Manifesto, that’s what.

Why? Because the usual arguments in favor of outsourcing talk about how it lets executive leadership focus on what’s “core” to the business. Because of Principle #2, core-ness, is, as it turns out, a double-edged sword.

That’s because the concept of “core” is pretty much synonymous with the concept of strategic focus, just as strategic focus is, or at least should be, pretty much synonymous with a company’s unique selling proposition – its competitive differentiation.

Which means it’s the moment you’ve been waiting for: another look at KJR’s favorite stalking horse – the pre-2008 General Motors, and how it was a train wreck that happened at three miles per hour over a span of twenty years.

What GM should have been focused on, and what would have prevented its derailment, was selling cars people want to buy, not on bribing customers with rebates in order to sell more financing contracts.

But even with a relentless focus on selling cars people want to buy, that leaves open the question of what leads potential customers to decide to buy a car at all, and what it is that leads them to choose one make and model over another.

You know what’s coming: Different car buyers care about different car attributes. Some care more about flashy styling, others about reliability, or fuel economy, or driveability, or pick your characteristics.

Which gets us to Principle #1, which in the end means whatever you want to optimize for will lead to trade-offs in everything else you might want to optimize for.

If, for example, you want to design a car for engine power and lots of it, the space you’ll need under the hood to mount a bigger engine constrains your ability to design a car that looks sleek and streamlined.

And vice versa. Additional trade-off examples are left as an exercise for the reader.

What does this have to do with the subject? If you’re on the board of a car company that’s supposed to sell cars people want to buy, and you understand what leads car buyers to choose one car over another, you’ll put a CEO in place who understands which of a car’s many characteristics the company has to be phenomenal at: Styling, engines, quality of construction, and so on. Whatever the competitive differentiators, they are the core –the buttons and levers the business can push and pull to sell more cars and sell them profitably.

They must be insourced.

Does this mean everything else can be outsourced? Yes it does, emphasis on “can.” “Should” is a different question entirely.

Bob’s last word: When looking at outsourcers, remember they have their own competitive differentiators – characteristics they optimize for. They’ll call them “best practices.” As you decide whether to outsource, and if so with whom, pay close attention to Principle #1. Because what you want aren’t best practices. You want practices that are best for you, which can be a different proposition entirely.

Bob’s sales pitch: No, I didn’t write this week’s column to sell more copies of the KJR Manifesto (full title: Keep the Joint Running: A Manifesto for 21st Century Information Technology). But if you haven’t read it, you should. As one reviewer put it:

This should be required reading for all Boards of Directors and all Government leaders (MPs, Congressmen, Senators etc.) plus all of us in middle (and junior) management.Oh, and it is still a slim book which is almost impossible to put down! Amazing for a really great “management text”!