While IT projects and business-led product rollouts may seem to have a lot in common, there's a different mindset with product management that's worth IT leaders observing and co-opting.
When IT leaders consider their core competencies, project management often comes to mind. After all, IT organizations are no strangers to complex, expensive, and time-consuming projects that often aim to spark major organizational change.
While the distinctions between IT projects and business-led product releases may seem so minute as to be irrelevant, having worked in both environments, there are definitely things IT leaders can learn from their product-focused counterparts. Here are some of the most relevant.
Find a singular focus
Successful products often have a singular focus that keeps the product release pushing inexorably forward. The product might be locked in a race with a major competitor in an effort to be the first entrant into a new market; or, a product might be an internally driven effort to replace an aging predecessor that customers deem no longer relevant. Rather than platitudes about cost savings or process improvements, these singular focuses are easy to explain, and inspire others to action. "Cost savings through additional automation" won't allow you to blast through organizational roadblocks or accelerate key decisions like "beating our competitor to the app store."
IT projects can often get lost in the weeds of their business cases, and after several weeks, everyone knows an IT project is a worthwhile endeavor but can no longer articulate why. A singular focus does not need to be backed by lots of metrics — it could be as simple as "allowing our customer reps to do their jobs more effectively," or "cutting the time the sales force spends on BS paperwork by half." Be bold, concise, and easily understandable, and you'll rally people to your cause rather than lulling them into blissfully ignoring your project.
Target the date
Anyone involved with a major IT project has likely seen dates that slip, in some cases double the original proposal. Often, the reasons cited for slips like this are poor scope control or unforeseen difficulties, which are par for the course with product releases.
The best product-driven organizations know that scope can be highly variable, and that it's usually the primary driver of missed dates and cost overruns. These organizations regard scope as a fungible entity, regularly reviewing and adjusting what's slotted for a given date and what will be deferred. Slipping dates in only the most dire circumstances forces scope to be tightly managed, and creates products that release frequent, intermittent updates rather than massive, monolithic releases.
Manage cost in the context of objectives
I'm always amazed at how IT organizations forego value in pursuit of minor cost savings. Product releases place costs clearly in the context of ensuring a successful release. If a six-figure expenditure on travel, tools, or resources will help meet a critical milestone, it's considered money well spent. IT organizations faced with a similar decision often balk and save the seemingly massive expense, and then may have to extend the project by weeks or months, which is usually much more costly in the long run.
No one is suggesting abandoning financial discipline, but in many cases, an expense with a high-dollar figure may produce a return that makes the expense look like peanuts.
Consider the total package
One area almost universally absent from IT projects that's a core of product design is considering the user experience. How will the end consumer interact with the product, and how can that interaction be refined to make it easier, faster, more intuitive, or more enjoyable?
Corporate IT has long been able to deploy applications and platforms that give user experience cursory consideration, if at all. While it may seem like an unnecessary expense or touchy-feely "soft stuff," the fact is IT services now compete directly with third-party cloud applications that users can provision with a credit card and a few clicks of the mouse.
Applications that are difficult to use, or that just look bad may suffer the worst fate of IT projects: a "successful" rollout that no one actually uses. Take some time to understand basic design principles, and get help with incorporating design and usability into your IT projects, just like an effective product designer would.
While IT projects and product rollouts target different purposes and entities and have different budgetary and organizational constraints, IT leaders can learn from product managers and effective product releases. Even if your IT projects can only benefit minimally from these concepts, technology is increasingly being embedded into the products companies produce.
Like it or not, even your internal IT services may one day be embedded into a product being targeted towards your end customer. Introducing elements of the product release process can only help make your IT organization more effective.