In this interview, Rick Vega, Wizeline Director of Software Engineering, and B. Neha, Wizeline Product Evolution Practice Lead, talk about the Product Evolution discipline at Wizeline, the value it delivers to Wizeline’s customers, and what makes the service a key differentiator in the marketplace.
Can you first tell us a bit about Wizeline’s Product Evolution discipline and how it started?
Rick: Several years ago, a new client came to us to request support and maintenance work for one of their products that was already in production. At the time, we were very hesitant to take on that type of work because it is often perceived as very low-skill, boring, and not innovative. But we saw it as an opportunity to approach the customer’s needs differently. We wanted to rethink the role of support and maintenance to change the industry by introducing a DevOps and agile mentality to incident management within the production environment. That’s how we came up with the idea to take a product that is already in production and evolve it using more mature processes, technologies, and frameworks — which we call Product Evolution.
It was also important that we made the offering innovative and fun for our engineers. So, we began by completely deconstructing the roles, removing skills we didn’t think were necessary, and adding skills that could take the service to the next level. We ended up with two roles: Application Owner and Software Evolution Engineer.
Neha: Adding to Rick’s description of the service, I will say that Product Evolution is really about ensuring the client’s product remains live and thriving while proactively enhancing the application over time — stabilizing, maintaining, upgrading, and maturing it. It is a fusion between the best of DevOps and Information Technology Infrastructure Library (ITIL) practices that create value for our clients.
Some people see Product Evolution as merely a support function because at the start of the engagement we begin in a very reactive place as we develop expertise on the product and address the backlog of issues and technical debt. Once the backlog is resolved, and we optimize and mature the entire product, and create streamlined monitoring and reporting with the right tools and automation, there comes a time when our team becomes an asset for the client by focusing our expertise on product enhancements.
What problems does Product Evolution address for Wizeline clients? What differentiates this offering from other Wizeline offerings or those offered by other vendors?
Rick: The support and maintenance of a product is a very tedious and costly process. Teams providing this service are comprised of several people who fill various roles — from incident management and product management to people working on the service calls — and can require long periods of time to identify bugs and implement the fixes into production. The typical role of a support engineer on one of these teams is very strict and inflexible, which doesn’t allow for a more proactive and innovative approach that can save businesses time and money. So, the traditional process for incident management requires the client to place a call to a team that then identifies the issue and implements a fix. Ultimately, the most common approach to product support and maintenance is typically very slow and expensive.
We approach the service differently. First, our teams require fewer roles and utilize agile frameworks and processes that allow us to validate the quality of the solutions we implement to ensure that there is no impact on the product or business. Second, we automate a lot of the tasks to free up engineers to focus on more complex tasks. When an incident occurs, it automatically triggers the support process to address the issue right away or initiates an auto-remediation process to fix the issue itself.
Product Evolution entails complete ownership of the product, whereas Product Management focuses more on the product features and roadmap. Product Evolution is concerned with how the product is functioning in the present moment while identifying potential features that improve maturity.
Neha: I would like to approach this question by considering how support services function in the current market absent our product evolution approach. So, if you’re a company that has an application that is already in production, you typically have a customer service team who interacts with the end-users; on the backend, you have several levels of support and a lot of teams working in silos and focused on one piece of the lifecycle, unaware of what other teams are working on; and then you have a product development team that is working on the new features and versions. When an incident occurs, customer service is first notified, and they raise a ticket to the support team. The support team has limited visibility into what’s going on because they only see the reported issues, but they don’t have the necessary skills to make changes to the code or design. If the incident is escalated, then it goes to the development team to resolve, in addition to all the new, innovative features they are trying to focus on building. In this scenario, the teams are working reactively to resolve issues as they occur.
In contrast, Product Evolution leverages the best combination of development engineers working close to operations and with a full understanding of the issues being generated, the underlying code, the architecture of the product, and how everything fits together, which allows us to solve the issue permanently and prevent it from happening again. Our team also syncs with the customer’s development team when necessary to identify how and when to remediate the issue for future iterations of the application. But resolving issues is just the beginning. We also work proactively to mature the product. Our main objective is to eliminate risks and proactively work on tech debts.
How does Product Evolution accommodate expectations from consumers of service providers like Wizeline to help them adopt best practices and enable them to operate independently once the engagement comes to an end?
Rick: We understand that our clients want to be self-reliant, which is why we strive to create a framework and process that is owned by the client and tool agnostic. What this means is that we work with our customers to enable the adoption of best practices, to get the best use out of the tools, and to implement the most efficient processes with our customers at the center. We work closely with the client from the very beginning to engage in comprehensive knowledge sharing through detailed documentation. We don’t embed ourselves into those processes, but rather we design it around the customer in a way that allows us to remove ourselves from the process easily.
Neha: We describe the work we do in Product Evolution as projects because we see the support lifecycle we provide eventually coming to an end in accordance with the DevOps Maturity Model. Once the DevOps practice optimizes the product, our role starts to come to an end for that specific product, though we may continue to provide our services to support other applications as they enter the production environment. Our goal is to mature the product and practice in such a way as to streamline the entire process, from monitoring and reporting to proactively addressing issues as they arise through automation via autocorrection. Once all of the proper structures, processes and tools are in place, our team can then become an asset for the client by focusing more on product enhancements, bringing our knowledge of the customer’s product, ecosystem and business. So, there’s always the opportunity for the customer to leverage us as a sort of natural extension of their development team, though it’s not necessary.
What are some examples of exciting Wizeline client projects that the Product Evolution team has supported?
Rick: One of the greatest examples of the work we do is a partnership we began with a food delivery startup in San Francisco. The company was growing really fast, which was resulting in a lot of technical debt for their development team. So, instead of focusing on creating new features for the app, they were spending the majority of their time fixing bugs. As a startup, they didn’t have a process around maintenance and support. When we started working with them, our first task was to help them adjust their services, processes, and frameworks to make sure that the technical engineers and leaders can focus on the product roadmap. Our second task involved resolving bugs and adding more value for the company by focusing on new features, proposals, and processes around automation, logging, and monitoring which allowed them to become more self-reliant. In the third phase of our support, we began to propose new ways to improve the end-user experience of the application, influencing how the client saw their own product and how their customers used it.
Neha: I would just like to add that at the time we joined this project, no one on the customer’s side had a complete understanding of the entire application architecture — its functions, how the various modules connected, etc. Their development teams were working in silos. So, we even helped the customer learn its own product by gathering and documenting all the information for the product, which gave the client clarity into how the product is connected end to end.
Another example that I would like to mention is a media client. We currently handle 10 products for them. They are a great example because most of the services that we mentioned above, we’ve applied for this particular client. In addition to all the benefits that come with those services for each product, the client also benefits from having a team of Wizeliners who know all 10 products, ensuring that there is always someone there who can help the client see the complete picture. We are beginning to see some great outcomes from our efforts. We’ve reduced the backlog in each product by an average of 30%. For this particular client, we are now in the mature phase of the engagement when our engineers become valuable assets to the development teams, we function as consultants for the product roadmap, and we are now training and onboarding the client’s teams.
What do you say to Wizeline clients who are skeptical of the value Product Evolution brings?
Rick: I would say that it’s important for businesses to ensure that their products and services, which they’ve invested a lot of resources into building the application, are continuing to deliver value for their customers. Customer expectations change over time as new technologies appear, the market demand changes and more innovative offerings become available to consumers. They expect the user experience of products and services to keep up with that pace of change. Now more than ever before, it’s easy for consumers to find newer products that meet their expectations. It’s important to ensure that your products remain up to date to retain customers and attract new ones — Product Evolution can help our customers do that.
Neha: I think it’s a great question. So, let’s focus on a scenario where Wizeline developed the product. During the product development lifecycle, there’s a point at which we need to begin handing it over to the client’s team. The product has been developed with engineering and design expertise from Wizeline engineers, delivered to the client, and is now going into production. Well, once it goes into production and real data flows through it and real users begin to use it, you realize that there are so many enhancements to make as well as bugs and tech debt that will need to be resolved. Once the product is in production, the client will need to maintain it. So, the question is: does the client have a team in place that has enough capacity or visibility into the product and business requirements to do this? We have clients who come to us for support because their teams do not have the understanding of the product code or architecture that is necessary to fix issues as they arise. And if they do have the resources in place to support these requirements, there is always an opportunity to enhance the processes with the right tools and automation.
Can you describe the typical roles involved within the Product Evolution team?
Rick: I’ll start with a little history behind the discipline. We wanted to make sure it remained flexible and agile, so we began evaluating the different services that were out on the market to understand how many roles they typically require as well as the various skills and behaviors. We came up with the idea for two roles: Application Owner (AO) and Software Evolution Engineer (SEE). If you look at the market, the application owner is a role that doesn’t exist; it’s something we created to cover product management, incident management, escalations, service level agreements, etc. This is a person who is very knowledgeable about software development practices, agile methodologies, product lifecycle, and incident management. They are the go-to person when it comes to the visibility of the product and how we are engaged with the customer.
Neha: In a nutshell, Application Owner is an SME for processes, methodologies, stakeholder management, and understanding customer needs. The SEE, on the other hand, is a hardcore technical role with strong engineering skills. This person is focused on the application code, infrastructure, and taking care of the day-to-day needs of the service.
What are the requirements for someone interested in joining Product Evolution in a “SEE” role or “AO” role at Wizeline?
Rick: When we’re talking about SEEs, we’re looking for people with T-shaped skills with very deep knowledge in a specific technology but also have a breadth of knowledge in disciplines such as infrastructure and quality assurance. The SEE will have broad visibility and understanding of the product and is able to collaborate with others to facilitate knowledge transfer. Ideally, this person will also have strong power skills as well, for example, good leadership and communication.
Neha: From my perspective, it’s important to understand that these are not interdependent roles. It’s not as though one cannot work without the other. They both have their own separate responsibilities and purposes, but when combined, that is when they form our Product Evolution offering that delivers exceptional service — good, clean code, DevOps maturity, and all-around best practices. That’s when they are most effective. And that’s when the client will see the true value of Product Evolution.
What does the future of Product Evolution look like at Wizeline?
Neha: For the future of Product Evolution, we’re working on promoting the service to our clients early on in our partnership so that we can engage projects using a proactive approach rather than being reactive. I think this will require us to grow awareness about the value of Product Evolution by continually educating our clients on the real benefit that the service can have on the business when clients partner with us early on.
Rick: I think there are three specific areas that we are focused on developing. First, we see an opportunity to help our clients rethink the product lifecycle by looking beyond development to consider what happens next in the weeks and months after the product goes into production. It’s our responsibility to have those conversations with our clients so that they are already thinking about what it means for the product to be live, what is the next step, and how to ensure that it’s successful and thrives. Second, when I’m thinking about the future, I’m interested in thinking of new ways to think about PE, for example, how we can leverage the methodologies of UX design and user research to help our clients improve their products. Third, we are considering how to incorporate PE processes with emerging technologies, such as AI and machine learning, so that we can be prepared for future projects that leverage these technologies.
Join the Wizeline Product Evolution Team
Interested in becoming a Wizeliner and joining our Product Evolution team? Our team is always on the lookout for new talent. In addition to those mentioned above, check out a couple of case studies on USC and Fitz Frames, highlighting the work of our Product Evolution team, to get a feel for the types of projects our team is working on. To learn more about the Wizeline Product Evolution discipline, visit our website or contact our team at consulting@wizeline.com to start the conversation.
