IT as a product: Secrets of successful launches

The need for speed is rapidly transforming IT. Tasked with moving as fast as — or even faster than — the business, IT has adopted a host of new strategies for delivering tech capabilities quickly. Central to this shift has been a movement toward agile development, which has heralded a multitude of changes to the development and delivery process.

Organizations at the forefront of this trend are shifting from big, monolithic projects with corresponding large-scale, high-risk deployments to a product mindset, where teams own a function, capability or service from its start to finish.

This evolution also has CIOs and their teams rethinking how they bring new technologies to consumers and business users. They’re leaving behind go-live dates and instead opting for product launches, with products typically far from finished. In fact, these product launches sometimes happen quietly with small-scale rollouts designed to test out how well they work — a far cry from the big-bang deployments of the past.

But IT leaders say that IT product launches, like those big project deployments, still require attention to guarantee success. Here, five IT executives share their strategies for successful product launches.

Develop the right plan, skill sets

In early 2018 executives at software maker Ellucian decided to improve how customers reached the company. The company had multiple avenues for customer communications, but each offered a different experience and even different terminology. So Ellucian leaders decided to implement a new “customer center experience,” a front-end with a single landing page that used uniform easy-to-understand language. The main goal was to improve the customer experience. IT launched the first iteration of the product in February 2019.

To ensure it went well, Senior Vice President and CIO Lee Congdon had his IT team run through a series of steps. The first step was getting alignment, he says, making sure his staff’s understanding of the problem the technology aims to solve was the same as the business’ view and making sure everyone agreed on the product’s objectives. Then they analyzed plans and tested out ideas through proofs of concept, asking as part of that work whether the planned product would actually address the problem and offer a fix. Then they designed the appropriate technology platform along with an appropriate budget and timeline to deliver.

“We focus on whether each product will meet customer expectations,” he adds.

Additionally, Congdon says a new type of IT worker is needed to guarantee a successful product launch. He explains that IT workers must be able to engage with colleagues and influence others to get through those steps he outlined. They should also have financial acumen, an understanding of business processes, and process re-engineering capabilities as well as more traditional change management skills. To get the staff he needed, he says he has focused on developing those skills in staff and hiring new workers who already demonstrated those skills.

Set a vision, keep working at it

In 2018 GoDaddy, the Internet domain registrar and web-hosting company, decided to move from on-premises systems to the public cloud (more specifically AWS), in part to gain agility.

“Our No.1 goal in moving teams to AWS was to increase the speed of delivering new features and functions to our customers, so we wanted a safe place to develop with security [built in] that didn’t blow budgets,” says Demetrius Comes, vice president of engineering at GoDaddy.

But as Comes’ teams brought developers into the new environment, they had to manually create the infrastructure they needed — a process that was inefficient. So Comes’ teams devised a portal that automates that process. His teams started work on this product in January 2019, launching the product’s first iteration just a few months later in April 2019.

To ensure a successful product launch, Comes’ teams started by setting a vision for the product.

“Our vision was that within six hours of the employee having the budget approved, they could have the environment to work in sitting on the public cloud. That was the driving force,” he says, noting that they leveraged what they had learned from the developers’ experience with the manual onboarding process to shape the vision they had for the portal.

Then they developed ways to support users as they learned to use the product, setting clear goals for each phase as they rolled out the portal’s first version to a limited number of users and planned for rolling out advanced iterations to more people.

Comes says the team’s goal for the first week after the product launch was to work with developers as they moved through the portal’s processes to get the environment they needed within 24 hours. The team’s second- and third-week goal was to take feedback from the first week, fix any problems and be ready to support the developers who used the tool. They then aimed to learn what they did in those second and third weeks to make the product even better, with iterative improvements continuing to follow as they mature the product beyond those first few weeks.

“Delivering a product is not just about pushing the release button and saying, ‘The software is out there so I’m done.’ It’s about the experience your customer is having and whether they are achieving what your initial vision was,” Comes says. “You have this interactive process to ask that questions so you can improve the product.”

Hold true to traditional project management principles

Rani Johnson, CIO of software maker SolarWinds, says the project management principles that contributed to successful IT deployments in the past remain essential even to product launches.

“The fundamental elements about getting business alignment, getting executive sponsorship, testing and demoing and handling change management remain important,” she says. “So even though they’re traditional project management activities, they blend into agile and [agile’s concept of] product launches.”

Johnson says her IT teams follow those principles when developing products and readying them for their launches.

“When we bring a product to the enterprise, we get stakeholder alignment and active executive sponsorship. We make sure it has value to our business users, that there’s a clear justification for why we’re doing it, that we have a clear objective with an expected outcome, and that we know what the ROI or return on value will be. We also have a specific agreement around success criteria,” she says.

To meet those marks, Johnson says she expects her teams to have completed all the change management steps needed and communicated the product and its capabilities before actually launching it. She also expects them to gather user feedback and assess user adoption, using those to make improvements after the product’s initial launch.

“We really hold ourselves accountable to what we put in that initial objective and that the product accomplishes the things we stipulated in our justification,” she adds.

Johnson says she declares success when the product is fully integrated into the user’s work. “Our work isn’t done when we finished our work; it’s when our customers, the consumers of our services, are happy with the work and they’ve adopted it, when they feel it meets the business needs we set out to accomplish,” she says.

Confirm whether product fits market needs

Kyle Lomeli, CTO of CarGurus, an automotive research and shopping website, considers a product “a collection of features that contribute to our overall business proposition.”

He explains: “Our overall business proposition serves the double role of bringing in revenue, but also solving a real market need. A ‘product’ could also be characterized as a tangible — though we are talking about the digital realm — feature or service that benefits a customer and our company, but doesn’t have to be directly monetizable. It can be something that supports the business in other ways,” he says.

That is in contrast with an IT project, which Lomeli sees as having a broader scope. “An IT project supports the internal company efficiency without necessarily being something that a customer would experience, such as sales process improvements and engineering support projects.”

Another difference? Lomeli says a product goes through many different phases that could be considered “launches,” starting with quick prototypes used by select users who shape improvements before moving to more widespread use.

“Ultimately when it’s time to aggressively roll it out to the entire market, large-scale marketing campaigns and PR efforts will be put into place to help with the large roll-out. During this phase, the company can internally line up resources to progressively improve on sales process, maintenance process, etc.,” he adds.

That view impacts how Lomeli views a product launch and how to judge its success.

“Considering the gradual and continuous evolution of a product as it matures, there is no specific point where a product is launched in the traditional sense,” he says. “A successful product launch is the process of confirming whether or not a product idea fits the market need.”

Still, Lomeli says he and his team use several key concepts to ensure products roll out successfully. “Rapid prototyping and market testing, constant result measuring, and collaboration across teams are all components to make sure that a product launch is successful and meets market needs,” he says.

‘Think of a product as a living, breathing thing’

Capital One started to adopt agile principles in 2011. As part of that, the technology teams moved away from monolithic IT assets and large-scale projects to focusing on smaller elements, or products, says Mark Mathewson, the financial services firm’s managing vice president and CTO of small business and international.

He says these products feed up into larger programs that deliver the features, functions and services that both company employees and its customers need to accomplish their tasks.

“This helps us think of a product as a living, breathing thing that doesn’t have an end or start date but instead advances,” Mathewson says.

Under such a mindset, Mathewson says the traditional measures of success — on time and on budget — aren’t sufficient. Instead, products are deemed successful if they’re delivered fast (even if they’re not complete) and if they work effectively (although they likely don’t have rich set of features yet).

To do that, Mathewson starts out with four key items: a strong vision and purpose for the product; clear ownership with an established roadmap; service and support infrastructure already in place for the product; and a process to evolve the product through continuous innovation.

Mathewson says Capital One supports that effort by investing in tools that take some risk out of product launches.

These tools include ones that automate numerous development-related processes, such as testing, so the product gave be created more quickly and that its development follows established standards and best practices. Mathewson says automation creates “no fear releases.”

Capital One also implemented tools that allow IT to put features into production and then can turn them on and off, so that IT can easily and quickly react to a very specific feature if it’s not working without taking down entire systems.

“In the old days to roll something back you’d have to take the whole thing offline to fix it, to fix say a defect; now we develop in a more microservice way and build into it this ability to turn on and off features if something isn’t working,” Mathewson explains.

His teams also use traffic throttling, where they can limit requests to use new features and control what percentage of users use a new and which use an old feature. For example, Mathewson says a team might decide that only 5 percent of traffic will go to a new feature and then increase that percentage when it finds that the feature is working well.

Mathewson’s teams also have tools to track adoption and utilization of products and individual features.

“We make sure we get real-time feedback on how and when users are using products and what features they spend the most time hovering over, so we can see if they’re adopting something quickly or not,” Mathewson says. “And we obsess over how effective and resilient a product is — so how long does it take us to detect and fix an issue, for example. And when those collapse in time, we know our product is maturing to a state that’s better for customers.”

He says at that point the teams can celebrate and claim a successful product launch.