IT will never be accused of being short on buzzwords. Just when you thought you’d mastered “digital transformation,” many IT leaders are now talking about shifting from projects to products. At first, it may seem like this is a semantic game, applying a fancy new term to a hackneyed idea, but done right, thinking in terms of products can be a game changer for your organization.
SEE: Return to work: What the new normal will look like post-pandemic (free PDF) (TechRepublic)
If a project delivers without anyone to hear it, does it really make a sound?
For years, IT leaders were admonished that the key to winning the hearts and minds of colleagues was successfully executing strategic projects. There’s nothing fundamentally wrong with the idea that being able to consistently deliver projects that advance the organization’s strategy is a very good thing indeed. The challenge at many IT shops and organizations is that most have become quite good at the “consistent delivery” part of the equation, but still struggle with the “advancing the organization’s strategy” piece.
Like the unobserved falling tree in the woods, at many organizations good people assemble to implement great technology, on-time and on-budget, but end up having little or no organizational impact. Like the tree falling unheard, the project that fails to create any meaningful change and becomes a non-event, causing outsiders to wonder if it ever occurred at all. IT leaders are then left having invested time and resources in something that essentially went unnoticed.
The keys to a successful product
While the challenges of the “successful failure” may be relatively new to IT organizations that have spent years perfecting their delivery chops, they’re old hat in the product delivery space. You can likely name a dozen products that were successfully delivered to the market but ultimately panned by consumers. Countless vehicles, consumer electronics, and digital offerings were delivered on-time and on-budget, but failed to understand their intended customers, communicate with those customers, or deliver the set of features and functions that the market wanted. In some cases, well-executed product launches missed changing customer tastes and launched a product built for yesterday that failed today.
SEE: The new SMB stack (free PDF) (TechRepublic)
These are hard and costly lessons, and most product organizations now spend weeks or months trying to understand whether their product makes sense in the market, and performing countless tests to validate demand before the first line of code is committed, or the first weld performed. With demand validated, they’ll spend additional time trying to understand the right combination of features and functions, and how they can best be packaged so that they’re compelling enough to customers to get them to click the Buy button, even when the initial price is free.
Contrast that to a typical project delivery, where the initial focus is around delivery methodology, project management tools, and organizational and governance models. All important considerations, but the best tools, leaders, and approaches will not turn the wrong product into the right one. Just because someone has allocated funding to a program doesn’t mean that they’ve thought through whether the program is actually relevant.
How to apply a product mindset
The simple shift from “how” you’ll deliver, to what you’ll deliver and how to make it relevant to the intended audience can change the game for how you deliver your programs. Starting with getting a deeper understanding of who your program impacts, what’s important to them, and how you’ll inform them of your brilliant new offering will position you for success, assuming you’ve got your delivery chops down.
If you believe this is all fluff or you’ve got this down, at your next status meeting, amid the discussions of WBS elements and completion percentages, ask someone why a user will engage with that particular function. After some stammering and blank stares, you’ll likely get a half-coherent answer about “change management,” which is shorthand for “I’m assuming that’s someone else’s problem.”
Too many IT teams follow what I’ve termed the Field of Dreams approach, following a disembodied voice that keeps repeating, “If you build it, they will come.” While it might work for baseball fields and ghostly apparitions, there are too many alternatives, including shadow IT, to bet your success on this “strategy.”
Push your teams to answer hard questions about who will use your product, and how they’ll benefit, just as you would if you were tasked with launching a new car, smartphone, or snack food. The discussions will be awkward at first, but they’ll make for a much better end result.