The need for speed is rapidly transforming IT. Tasked with moving as fast as \u2014 or even faster than \u2014 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.\nOrganizations 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.\n[ Find out how IT organizations are making the shift to product-based IT and how IT leaders are rethinking IT service delivery. | Find out what your peers are up to with our 2019 State of the CIO report. | Get the latest insights by signing up for our CIO daily newsletter. ]\nThis evolution also has CIOs and their teams rethinking how they bring new technologies to consumers and business users. They\u2019re 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 \u2014 a far cry from the big-bang deployments of the past.\nBut 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.\nDevelop the right plan, skill sets\nIn 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 \u201ccustomer center experience,\u201d 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.\nTo 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\u2019s understanding of the problem the technology aims to solve was the same as the business\u2019 view and making sure everyone agreed on the product\u2019s 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.\n\u201cWe focus on whether each product will meet customer expectations,\u201d he adds.\nAdditionally, 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.\nSet a vision, keep working at it\nIn 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.\n\u201cOur 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\u2019t blow budgets,\u201d says Demetrius Comes, vice president of engineering at GoDaddy.\nBut as Comes\u2019 teams brought developers into the new environment, they had to manually create the infrastructure they needed \u2014 a process that was inefficient. So Comes\u2019 teams devised a portal that automates that process. His teams started work on this product in January 2019, launching the product\u2019s first iteration just a few months later in April 2019.\nTo ensure a successful product launch, Comes\u2019 teams started by setting a vision for the product.\n\u201cOur 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,\u201d he says, noting that they leveraged what they had learned from the developers\u2019 experience with the manual onboarding process to shape the vision they had for the portal.\nThen 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\u2019s first version to a limited number of users and planned for rolling out advanced iterations to more people.\nComes says the team\u2019s goal for the first week after the product launch was to work with developers as they moved through the portal\u2019s processes to get the environment they needed within 24 hours. The team\u2019s 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.\n\u201cDelivering a product is not just about pushing the release button and saying, \u2018The software is out there so I\u2019m done.\u2019 It\u2019s about the experience your customer is having and whether they are achieving what your initial vision was,\u201d Comes says. \u201cYou have this interactive process to ask that questions so you can improve the product.\u201d\nHold true to traditional project management principles\nRani 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.\n\u201cThe fundamental elements about getting business alignment, getting executive sponsorship, testing and demoing and handling change management remain important,\u201d she says. \u201cSo even though they\u2019re traditional project management activities, they blend into agile and [agile\u2019s concept of] product launches.\u201d\nJohnson says her IT teams follow those principles when developing products and readying them for their launches.\n\u201cWhen 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\u2019s a clear justification for why we\u2019re 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,\u201d she says.\nTo 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\u2019s initial launch.\n\u201cWe really hold ourselves accountable to what we put in that initial objective and that the product accomplishes the things we stipulated in our justification,\u201d she adds.\nJohnson says she declares success when the product is fully integrated into the user\u2019s work. \u201cOur work isn\u2019t done when we finished our work; it\u2019s when our customers, the consumers of our services, are happy with the work and they\u2019ve adopted it, when they feel it meets the business needs we set out to accomplish,\u201d she says.\nConfirm whether product fits market needs\nKyle Lomeli, CTO of CarGurus, an automotive research and shopping website, considers a product \u201ca collection of features that contribute to our overall business proposition.\u201d\nHe explains: \u201cOur overall business proposition serves the double role of bringing in revenue, but also solving a real market need. A \u2018product\u2019 could also be characterized as a tangible \u2014 though we are talking about the digital realm \u2014 feature or service that benefits a customer and our company, but doesn\u2019t have to be directly monetizable. It can be something that supports the business in other ways,\u201d he says.\nThat is in contrast with an IT project, which Lomeli sees as having a broader scope. \u201cAn 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.\u201d\nAnother difference? Lomeli says a product goes through many different phases that could be considered \u201claunches,\u201d starting with quick prototypes used by select users who shape improvements before moving to more widespread use.\n\u201cUltimately when it\u2019s 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.,\u201d he adds.\nThat view impacts how Lomeli views a product launch and how to judge its success.\n\u201cConsidering 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,\u201d he says. \u201cA successful product launch is the process of confirming whether or not a product idea fits the market need.\u201d\nStill, Lomeli says he and his team use several key concepts to ensure products roll out successfully. \u201cRapid 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,\u201d he says.\n\u2018Think of a product as a living, breathing thing\u2019\nCapital 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\u2019s managing vice president and CTO of small business and international.\nHe 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.\n\u201cThis helps us think of a product as a living, breathing thing that doesn\u2019t have an end or start date but instead advances,\u201d Mathewson says.\nUnder such a mindset, Mathewson says the traditional measures of success \u2014 on time and on budget \u2014 aren\u2019t sufficient. Instead, products are deemed successful if they\u2019re delivered fast (even if they\u2019re not complete) and if they work effectively (although they likely don\u2019t have rich set of features yet).\nTo 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.\nMathewson says Capital One supports that effort by investing in tools that take some risk out of product launches.\nThese 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 \u201cno fear releases.\u201d\nCapital 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\u2019s not working without taking down entire systems.\n\u201cIn the old days to roll something back you\u2019d 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\u2019t working,\u201d Mathewson explains.\nHis 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.\nMathewson\u2019s teams also have tools to track adoption and utilization of products and individual features.\n\u201cWe 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\u2019re adopting something quickly or not,\u201d Mathewson says. \u201cAnd we obsess over how effective and resilient a product is \u2014 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\u2019s better for customers.\u201d\nHe says at that point the teams can celebrate and claim a successful product launch.\n\nMore on IT as a product:\n\n Making the shift to product-based IT \n IT as a product: Rethinking IT service delivery \nInnovative CIOs make shift to managing IT as a product\nWho's succeeding with product-focused IT?