In today’s digital landscape, where user engagement directly correlates with product longevity, the stakes for developing user-centric products have never been higher. Success demands not just initial user understanding, but a continuous cycle of testing, learning, and iterating to refine products based on real-world usage and feedback. When technology product teams rush to build solutions before establishing this foundational cycle, they overlook critical user needs, mistakenly believing they’re accelerating delivery. Organizations that bypass this iterative approach don’t just risk poor adoption rates—they jeopardize their entire product lifecycle and, ultimately, their market position. Yet despite these evident risks, many companies still find themselves in reactive modes, struggling to retain customers and maintain market relevance.
This challenge stems from a complex interplay of organizational dynamics that extends far beyond simple oversight. When technology product teams craft their strategic vision, they often rush to build solutions before fully understanding what users truly need, mistakenly believing this accelerates delivery. This approach, while seemingly efficient, leads to misaligned products that fail to resonate with their intended audience. The reality is that user requirements must be the foundation of product strategy—not an afterthought—and should be shaped by those closest to the user experience.
Our work with organizations across industries has revealed a consistent pattern: companies that do not invest adequate time in upfront user understanding and ongoing iteration inevitably pay the price in form of multiple product iterations and customer dissatisfaction. When combined with aggressive timelines and insufficient user data, this creates a perfect storm that not only undermines product success but also strains organizational resources and team morale.
Through careful analysis of successful product-centric transformations, we have identified five fundamental steps that enable organizations to pursue customer centric product design. These steps aren’t meant to be executed once and forgotten, but rather form a continuous cycle of learning and improvement:
By embracing this framework, organizations can transform their approach to product development. Instead of navigating uncertain returns and user indifference, teams can create products that consistently delight users and drive sustainable business growth. This systematic approach not only enhances product success rates but also establishes a foundation for continuous innovation and market leadership.
To illustrate how these steps transform product development in practice, let’s take a look at a product team tasked with reimagining the customer checkout experience for an eCommerce platform. Composed of Design, Engineering, and Product roles, the team recognizes that successful product development requires seamless collaboration across these critical functions—each bringing unique perspectives that collectively unlock user-centric innovation. Guided by executive leadership’s strategic mandate to reduce customer drop-off rates and improve conversion metrics, the team oversees both web and mobile interfaces and faces a critical challenge: high customer abandonment after cart additions, directly impacting revenue and customer satisfaction. With clear directives from senior management to develop a comprehensive strategy that balances user needs with business objectives, the team must rapidly identify pain points and craft innovative solutions. Under the guidance of an experienced Product Manager, they embark on a systematic journey to uncover user challenges and transform the checkout experience from a point of friction to a competitive advantage.
Image 1: Cross-Functional Team Integration: Ensuring seamless collaboration between Product, Design, UX, and Engineering to aid the product discovery process
To develop customer-centric products, it’s essential to first understand who the product team is designing the experience for. Defining the customer persona is not just a step in design thinking—it is the foundation of a successful product strategy. By clearly outlining user preferences, challenges, and motivations, teams can ensure their solutions are relevant and impactful. Keep in mind that customer persona can represent either a customer or an employee, depending on the product’s focus.
Once a comprehensive persona is created, teams should map out the user’s current experience. Journey maps visually represent the customer’s interactions with the product, enabling teams to identify friction points and tailor enhancements.
For example, the checkout team’s persona might be a 37-year-old working mother of two, often shopping in a rush. Her journey could include:
By understanding these stages, product teams can address user preferences holistically, ensuring that improvements align with both immediate and long-term goals.
After mapping the stages and understanding how customers engage with the app, the next step is to evaluate the pain points they encounter. The ‘jobs-to-be-done’ framework can help product teams understand that users choose products to accomplish specific tasks. By outlining these jobs, product teams can define desired outcomes, segment them and devise strategies to address them. This approach not only fosters empathy for user challenges but also provides actionable insights to define the desired future state.
For the checkout team, this might involve analyzing app usage, metrics, and customer feedback to pinpoint issues like:
Mapping these pain points to the identified journey stages, enables the product team to create a comprehensive overview of specific pain points across the customer journey.
With a clear understanding of user personas and pain points, teams can envision the ideal future-state experience. This critical step requires a nuanced approach that balances user preferences with technical feasibility and business constraints. While user feedback is invaluable, product teams must recognize that not every user suggestion represents a viable or optimal solution—some ideas may introduce unintended complexity or misalign with broader product strategy.
For the checkout team, crafting an ideal experience means carefully prioritizing enhancements that deliver maximum user value while remaining technically and strategically sound:
During a recent engagement with a leading technology company’s mobile application team, this strategic approach enabled the client to boost user engagement and streamline upselling opportunities. By defining an ideal experience that balanced user desires with technical constraints, the team could allocate resources effectively and build toward a cohesive vision.
Once the future state is defined, product teams must identify the capabilities required to bridge the gap. Developing these capabilities proactively—rather than merely reacting to user feedback—empowers teams to anticipate needs and deliver innovative solutions that surprise and delight users.
Leadership support is essential to ensure teams have the resources and authority to pursue these enhancements efficiently. For the checkout team, this might mean prioritizing:
By focusing on proactive development, teams can release iterative changes more rapidly and achieve a continuous cycle of improvement.
Finally, measuring success is as critical as defining the vision. Product teams must identify key performance indicators (KPIs) that align with the desired user experience and overarching business goals. Well-defined KPIs enable teams to validate assumptions, track progress, and refine strategies in real time, making them an integral part of a mature dual-track discovery and delivery process.
For the checkout team, KPIs such as site loading times and drop-off rates provide tangible benchmarks for success. These metrics not only indicate the immediate health of the product but also serve as early signals of deeper issues or opportunities.
Establishing a metrics-driven approach not only elevates the team’s problem-solving capabilities but also creates a culture of accountability and continuous learning. When both product teams and leadership actively engage with KPIs, they foster an environment where decisions are based on evidence rather than assumptions, paving the way for long-term success and innovation.
Through the application of these five steps, the eCommerce checkout team transformed their approach to product development. By deeply empathizing with their users, mapping the customer journey, and methodically addressing pain points, they gained invaluable insights that traditional feature-driven development would have missed. Their systematic approach to defining the future state and identifying necessary capabilities ensured that every enhancement addressed user needs, ultimately resulting in meaningfully lower drop-off rates and higher customer satisfaction.
This framework, though straightforward, opens doors to broader strategic considerations. Teams must handle capability prioritization, cross-functional responsibilities, and resource allocation—challenges that extend beyond any single product team’s domain. Yet these challenges are worth tackling, as they lead to more cohesive, user-centric solutions.
The path to user-centric product development requires more than just following steps—it demands a fundamental shift in how organizations approach product strategy. Success is dependent on leadership’s commitment to empowering teams with both the framework and the organizational support to execute it effectively. By establishing a dual-track discovery and delivery process, teams can maintain their user focus while delivering tangible results. This balance between user needs and business objectives, supported by clear vision and strong change management, creates the foundation for products that truly resonate with users and drive sustainable business growth.
Image 2: Illustrative E2E Product Discovery & Delivery Product for Product Teams
Underestimating the importance of this role could make or break your operating model transformation: here’s how to think about sourcing the role that will only increase in importance.
This article was originally published on CIO.com by Michael Bertha, Partner at Metis Strategy and Kira Kessel, Associate at Metis Strategy
You’ve seen the virtues of transforming from a project to a product operating model: value-driven work, delivered by dedicated teams rather than through projects led by disparate team members.
But as you embark on this transformation, you’ll have to remember one thing: you can’t do it without a product owner. The strategist, the technical expert, the business savvy leader—those with all three commonly called unicorns, or rock stars—is a person not easy to find.
Product owners are the linchpin of the product operating model; on product teams, a bad engineer is one bad apple, but a bad PO can sour the whole batch. No one else has the end-to-end accountability for a product like the product owner does. No one else so consistently represents customer interests, pushes engineers to adopt DevOps and Agile methodologies, and corrals individuals to execute against a roadmap. This is a leader who thinks of technical features in one conversation and business strategy in the next. The unicorn, if not sourced with proper due diligence, will be viewed only as a creature in fairy tales.
In a traditional project model, a leader is judged based on how well they react to requests and executes on them. In a product model, however, a good product owner anticipates the customer needs and responds to them by prioritizing items on a roadmap based on the capacity of a product team.
Product owners move you from reactive to proactive.
Adopting the product model is no meager mind-shift. Broadly speaking, you have two main options: hiring or upskilling.
You might hire for either of two reasons. The first is that you may not have the luxury of time and mistakes. This is largely a matter of two things: culture and industry.
Let’s start with culture. Ask the following of your company: Is learning tolerated? Is training available? Are there resources you can use to help establish the person in their role? Is there strong leadership and mentorship? Without these variables at play it will be difficult to develop someone internally. You might need someone who has the core PO competencies and fits your culture, someone who perhaps already has the leadership chops you’re lacking—a necessary hire.
Then there’s industry. Also unable to afford time or mistakes are those industries that are heavily regulated, scrutinized by agencies and governments, or uniquely depended upon by their customers. If, for example, you work in medical, military, aviation, and so on, you may not want to risk upskilling when you need someone who can navigate complexities beyond just those inherent to a product owner’s role. These product owners will have to consider certain variables—safety, cybersecurity, geopolitical factors, and many others—that require extra attention when representing the voice of the customer.
Say you’re a technology executive at a biopharma company. Your product owner will not only need to drive innovation—putting the most promising features at the top of the backlog—but will also need to do this while adhering to regulatory constraints. For Shobie Ramakrishnan, Chief Digital and Technology Officer at GlaxoSmithKline, this looks like balancing core values like “accountable for impact” with the pursuit of AI/ML technologies to “supercharge” R&D and clinical trials.
Luxury and time, of course, is only one of the reasons you might hire. The other is that you want a fresh perspective. In particular, someone who offers a point of view you can’t train. Usually that someone comes with a mixed bag of experience: a background in product, engineering, marketing, and finance are most common. What matters is that they offer something new to your company. A leader like this may disrupt the status quo, bring innovation, and offer new ways of thinking about the same problem. They may even serve as a catalyst for change beyond your recent move to the product model.
But could you not solve these issues—the constraints of luxury and time and the desire for a fresh perspective—by outsourcing? Your contractor may not cost as much, but you may face bigger drawbacks. A contractor who doesn’t stick around will take with them the skills and experience you want an employee to share with colleagues so that expertise, new ideas, and growth of the company reinforce one another from within.
In contrast, when you retain someone full time, especially a product owner, you retain institutional knowledge, which is especially valuable when it concerns strategic areas like GenAI, data, cyber and other innovation—areas of central concern to the product owner. A good example of this comes from Zurich North America’s COO Berry Perkins, who has made it part of IT strategy to keep this type of knowledge in-house. Of course, that’s not the only part of the strategy—it also involved the establishment of nearshore competency centers that will depend on Zurich’s employees acquiring new skills and embracing new processes and technologies. Which brings us to upskilling.
You may have a unicorn in your backyard without even knowing it.
What can distract you from that realization? Budget. If it prevents you from hiring, then you may next consider whether you have the funds, and the bandwidth, to pursue training your soon-to-be product owner.
Investing in your training muscle—developing a training capability, establishing career coaching, and encouraging growth from within in other forms and fashions—could do more than just produce the perfect product owner. It will signal to your employees that you want them to stay, that their contributions matter, and that there is space for them to grow internally. Retention could soar, innovation may spike, and revenue would, inevitably, grow.
If training isn’t on the agenda, you may decide to pursue upskilling simply because your employees hold something valuable already: their relationships and their institutional knowledge. The high-performing product owner will have already built relationships with their colleagues, will know the dynamics that exist between teams, will understand the technologies used, and will be better equipped to align IT and business stakeholders. Most importantly, they will have established trust.
Perhaps not even trust is the most important thing. What could be? Institutional knowledge, which, as we’ve seen, an existing employee will already have. They will know the tools, know the processes (which they’ve seen are convoluted at times), and know the customers of the company they are serving (and can speak to the company’s competitive differentiation, not just industry norms). Best of all, they know the product—its thorns, buds, and roses.
Believing in the value of the product operating model is one thing. It’s another to embrace the transformation from project to product with eyes wide open. You should acknowledge the challenges you will encounter, most notably that this one role could make or break the transformation. So before you’re too far into the journey, remind yourself: if you don’t know who your product owner is, at least understand what will dictate whether you hire, contract, or upskill. Better to figure it out now, not later.
With all the ways digital innovation has enabled companies to remain productive during the pandemic, one of the most positive outcomes is improved collaboration across traditional business silos. In my new book, Getting to Nimble: How to Transform Your Company into a Digital Leader, I discuss how enterprises have made these silos more permeable, creating greater partnerships along the way.
Consider the following five examples and how they could apply to your digital transformation efforts.
Talented technologists are in high demand at most organizations, tasked with helping teams in other divisions figure out the digital implications of their ideas and strategize accordingly. In many cases, these ideas come from the technologists themselves. Companies that provide such “T-shaped” career paths offer an enormous advantage, developing leaders with great breadth and depth of experience. When they ascend to “chief” roles, they do so with a much clearer understanding about how value is created within the enterprise.
Agile methodology has been a boon for collaboration across the enterprise.
The traditional “waterfall” method of development involves someone from the business side (outside of IT) placing an order with the IT department. The IT team then develops this order, with little input from the business side until the project is completed months later.
In contrast, agile development includes the intended audience or user of the project in development from ideation through completion. With each iteration, the user validates value, and features are amplified or turned off accordingly. In some cases, the entire project may even be scrapped as a result of what the team learns.
DevOps blends two traditionally siloed parts of the technology and digital domain: development and operations. In a traditional project development model, developers take a project from ideation through completion, and the operations team then moves it forward. There is often a moment in the lifecycle when the project is “thrown over the wall” from development to operations (even this phrase highlights the distance and disconnects between the activities of the two groups).
DevOps instead makes delivery teams responsible for production issues and fixes, whether legacy or new, drawing them into the lifecycle earlier. Greater levels of involvement and accountability make for better work products.
The migration from a project to a product orientation is another area that benefits from greater collaboration. Internal “products” are also good examples of this – think order-to-cash, onboarding new hires, or creating a mobile customer experience.
These products potentially involve great value, and the product teams are typically cross-divisional or cross-discipline: They might include tech and digital, marketing, sales, operations, and any other division to which the product is relevant. A product leader should lead the cross-functional team, and that team should be prepared to remain intact for a longer period of time than the typical project.
An early example of this type of project orientation comes from Atticus Tysen, Chief Information and Security Officer at Intuit. When Tysen became CIO, he brought with him a product orientation, defining products for IT to drive. By developing in long-term teams, each team member was able to develop a higher level of expertise in the product area than they would have in a more traditional project structure.
Data strategy has also driven more cross-functional thinking. Done well, all strategy should invite greater collaboration across traditional silos since value is truly driven at the intersection of the disciplines. Data strategy should apply everywhere data is gathered, secured, synthesized, and analyzed – across the entire company.
Many companies have found it useful to have a leader who drives data strategy on the company’s behalf. To do this effectively, that leader (whether the CIO, the chief data officer, or another IT role) should engage leaders in other parts of the company to ensure that the data strategy is as comprehensive and useful as possible.
These are just a few areas where stronger collaboration is happening across industries and geographies. Companies that fail to take advantage of these trends risk falling behind more nimble players in their industry.
Peter A. High is the author of GETTING TO NIMBLE: How to Transform Your Company into a Digital Leader (Kogan Page, Spring 2021) and President of Metis Strategy, a management and strategy consulting firm focused on the intersection of business and technology. He has advised and interviewed many of the world’s top CIOs and leaders at multi-billion-dollar corporations like Gap, Bank of America, Adobe, Time Warner Inc., Intuit, and more.
While CIOs continue to prioritize the shift to product-oriented operating models in 2021, companies still struggle to create empowered product teams throughout their organizations. One significant inhibitor is often the lack of progress and investment in DevOps.
Amazon Web Services defines DevOps as “the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity.” In this setup, “development and operations teams are no longer siloed… [and] engineers work across the entire application lifecycle, from development and test to deployment and operations”.
DevOps can significantly enable product operating model transformations. It brings agile processes to life through technical enablement, turning processes into automation. Put simply, this often means automating the software development process from start (continuous integration / CI) to finish (continuous deployment or delivery / CD) while also creating empowered developers with a pulse on customer needs.
A successful DevOps transformation enables teams to react quickly to shifting market demands and reduces risk by decreasing the time it takes to get working software out the door. For example, an empowered product team that releases new features daily or hourly can iterate and innovate securely much faster than in the past, allowing for constant validation of product strategy and the ability to scale when they find something that works.
DevOps, Agile, and product operating model shifts are closely linked in successful digital companies. Through our work with some of the largest organizations in the world (both digital natives and digital immigrants), we have found that leaders who closely couple DevOps transformation efforts with Agile and product management transformations are significantly more successful in realizing their goals. Below are four tips to help you do so successfully:
In future posts, we will go into more detail about how to kickstart your DevOps transformation, from examining the key dimensions of the transformation process to exploring creative ways to fund DevOps efforts. Drop us a note if you have any questions, thoughts, or suggestions for future topics to cover!
Chris Boyd co-wrote this article.
Leading digital transformations is the CEO’s top priority for CIOs, according to the 2020 IDG State of the CIO study. Doing so effectively requires an IT operating model that allows business and IT to work together to navigate a dynamic competitive landscape, a seemingly infinite set of digital tools and shifting stakeholder demands.
In our work with Fortune 500 companies, we have found IT organizations that use the traditional “plan, build, run” operating model struggle to conceptualize, launch and maintain momentum on digital transformations. To bolster their transformation capability, IT organizations across industries and geographies are shifting toward product-oriented operating models, or “product-based IT”. When done right, organizations experience increased agility, happier customers and more successful transformations.
A product is a capability brought to life through technology, business process and customer experience that creates a continuous value stream. Examples of products are eCommerce, supply chain, or HR. An operating model defines how an organization positions its people, process and technology to deliver value to both internal and external customers.
A product-oriented operating model, then, is one in which IT resources are organized around business capabilities or “products” instead of specific IT systems (e.g. SAP, CRM) or functions (QA, Engineering, Infrastructure). In this model, each product team works as if they are managing a market-facing product such as a consumer electronics device. They develop a product strategy and roadmap in lockstep with the business that clearly articulates how they will mature the product to better meet customer needs and optimize competitive positioning. Every feature on the roadmap is aligned with a measurable business outcome and goes through a rapid discovery phase to validate value, usability and feasibility before it is slotted in a sprint to achieve a minimum viable product.
Most organizations have honed their ability to deliver when the scope and desired outcome are static, but struggle when next steps aren’t defined or are painted with a broad brush. Several leading IT organizations have turned to product-based IT to cut through this ambiguity and elevate their role from service provider to business partner.
Art Hu, the global CIO of Lenovo, is one of the pioneers in the shift from project-to-product. He noted in a recent conversation that his organization grappled with the question of what to work on next after completing a series of legacy ERP integrations resulting from acquisitions. “The fundamental paradigm shift for us was that the level of uncertainty had changed when there was no longer one single imperative,” he said, referring to the ERP project. “When we took that away, it was a totally different world and traditional waterfall didn’t make sense anymore. Until we as an organization realized that, the business teams and my teams struggled.” Product-based organizations rely on continuous customer engagement to remove guesswork from the prioritization process, which often leads to better business outcomes and increased agility.
CIOs have targeted key behavioral changes to jumpstart the shift to a product-based operating model:
Project plans developed with fixed deliverables and timelines encourage predictability but rarely equate to business outcomes. This plan-driven work is increasingly yielding to continuous discovery and delivery, which seeks to answer two questions on a recurring basis: what should we build, and how should we build it? A discovery track intakes opportunities, ideas and problems to solve. Teams then engage with customers to validate that those ideas create value (desirability), will be used once released (usability) and are feasible in the current business model (feasibility/viability).
“Great companies that have built a product orientation start with desirability and leverage design thinking to have empathy-based conversations to get to the core of problems,” Srini Koushik, the CIO/CTO of Magellan Health, said during a recent product management panel. Ideas that make it through discovery are added to a product backlog and are slotted into sprints for delivery based on relative business priority. Discovery and delivery tracks operate concurrently to ensure that a steady stream of validated ideas and a working product that drives business outcomes is delivered at the end of each sprint.
In a recent strategic planning session, one CIO stated that “transformation is not a part time job,” noting that dedicated teams are critical for both digital transformation and building a product orientation in IT. Teams that are formed on a project-by-project basis spend valuable time ramping up subject matter expertise and building chemistry, but then are disbanded just when they start to hit their stride. Product-based IT organizations, on the other hand, favor dedicated teams that own a product from introduction until sunset, including the execution of discovery, delivery, testing and maintenance/support. In this model, the dedicated teams become true experts on the domain and avoid pitfalls resulting from intraorganizational handoffs and revolving resources.
The increased frequency and quality of customer interactions is a hallmark of product-based IT. Ideally, customers are engaged during the discovery phase to validate ideas and prototypes, and then provide feedback at regular intervals after the product is released. If your end customer is a business unit, you should strive to have even more interactions. Some organizations have business stakeholders participate in daily stand ups, and some may even have their product owners sourced directly from the business instead of IT.
Atticus Tysen, the Chief Information Security, Anti-Fraud and Information Officer at Intuit, is another pioneer in the shift from project to product. At the 2019 Metis Strategy Summit, he emphasized that true product organizations reflect on key questions that demonstrate their strong relationships with customers. For example, do you really know who your customers are, and are you organized around serving them? Do you have metrics to measure customer happiness and show you are working with them in the correct way? “You have to have customers if you’re going to have a product organization,” Tysen said. “Product managers in a lot of ways are relationship managers.”
To achieve the benefits of a product-centric operating model, the funding model must shift as well. Rather than funding a project for a specific amount of time based on estimated requirements, teams instead are funded on an annual basis. Also known as perpetual funding, this setup provides IT product teams with stable funding that can be reallocated as the needs of the business change. It also allows teams to spend time reducing technical debt or improving internal processes as they see fit, which can improve productivity and quality in the long run.
Here are a few key steps to begin the journey…
Organizations should first and foremost target business impact when shifting to product-based IT. For example, one Fortune 500 client chose to measure Net Promotor Score to assess business satisfaction, product team velocity to assess speed to market and the number of critical defects per product to assess quality. It is also prudent to create metrics that track the adoption of key aspects of the working model. For example, you may track the percentage of product teams that have developed strategic roadmaps, or survey product teams on a regular basis to see how many feel like they have the skills needed to succeed in the product-based operating model.
Start by identifying the highest-level customer-facing and internal capabilities in the organization, such as Product Development, Sales, Marketing, Supply Chain, HR and Finance. At the highest level, these are your Product Groups, or “Level 1.” If your organization is smaller and has a relatively simple technical estate, you may not need to break this down any further.
However, we have found most enterprises with multiple business units and geographies need to do so. Inside the Sales group at a SaaS company, business processes would likely include steps such as Discovery, Lead to Cash and Customer Success (which includes activation, adoption, expansion and renewals). These may become your product groups since each of these steps involves different business stakeholders, targeted KPIs and technology components. However, the way you design your product teams will ultimately depend on the intricacies of your organization.
Absent a one-size-fits-all approach, we suggest the following guiding principles:
A key to product-based IT is building cross-functional teams that have the business and technical skills needed to accomplish most tasks inside their teams. The most important role in your product team will be the Product Owner (or Product Manager). Referred to as unicorns by some, these individuals possess the unique blend of business (strategy, competitive analysis), technical (architectural vision, technical project management) and leadership (decision-making, stakeholder management) skills and are responsible for driving the product vision and strategy and leading execution.
To fill this role, many organizations will conduct a skill assessment with their organizations to determine the skills needed to be successful, gather an inventory of available skill sets and shape a training program to fill gaps. As you structure the rest of the product team, think about how the skills of other team members can complement the product owner skill set so you are creating a strong blend of business, technical and leadership skills in the team. Beyond the Product Owner, you may have a Business Analyst that serves as a Junior Product Owner and supports detailed data and process analysis. A Scrum Master would drive Agile ceremonies, a Technical Lead would create a solution architecture and orchestrate technical activities, and an Engineering/QA team would ensure delivery of a high-quality product.
Think about IT services that are BU agnostic, needed across all product teams and in demand only on a part-time basis by the product group. These are your Shared Services. Shared Services cut horizontally across the product groups and teams. Just like products, these specialized groups endeavor to mature and develop new capabilities and empower their customers (in this case the product teams themselves).
Typical Shared Service groups include Enterprise Architecture, Infrastructure & Cloud, Security, DevOps, Customer/User Experience, Data & Analytics, Integration, Program/Vendor Management and IT Operations/Support. The Office of the CIO is an increasingly prevalent Shared Service that is responsible for defining the enterprise IT strategy, setting metrics and measuring success. Each Shared Service should publish a service catalog detailing their offerings and processes for engagement with a bias towards self-service (where possible). Shared service resources can be “loaned” to product teams if there is demand for an extended period.
IT often starts with feasibility and viability, approaching desirability only if the former two boxes are checked. Product managers need to start with desirability and build the ability to adapt their storyline based on the audience. Avoiding technical speak and endless strings of three letter acronyms will also go far in building this rapport.
Shifting to product-based IT is a major cultural and operational change. When done well, it can result in better relationships with customers and business partners, increased agility and improved business outcomes.
This article originally appeared on CIO.com. Chris Boyd co-authored the piece.
As technology departments shift from traditional project management frameworks to treating IT as a product, it is triggering a broader re-think about how technology initiatives are funded.
Under the existing “plan, build, run” model, a business unit starts by sending project requirements to IT. The IT team then estimates the project costs, works with the business to agree on a budget, and gets to work.
This setup has several flaws that hamper agility and cause headaches for all involved. Cost estimates often occur before the scope of the project is truly evaluated and understood, and any variations in the plan are subject to an arduous change control process. What’s more, funding for these projects usually is locked in for the fiscal year, regardless of shifting enterprise priorities or changing market dynamics.
To achieve the benefits of a product-centric operating model, the funding model must shift as well. Rather than funding a project for a specific amount of time based on estimated requirements, teams instead are funded on an annual basis (also known as “perpetual funding”). This provides IT product teams with stable funding that can be reallocated as the needs of the business change. It also allows teams to spend time reducing technical debt or improving internal processes as they see fit, improving productivity and quality in the long run.
“We have to adapt with governance, with spending models, with prioritization,” Intuit CIO Atticus Tysen said during a 2019 panel discussion. “The days of fixing the budget at the beginning of the year and then diligently forging ahead and delivering it with business cases are over. That’s very out of date.”
Business unit leaders may be skeptical at first glance: why pay upfront for more services than we know we need right now? A closer look reveals that this model often delivers more value to the business per dollar spent. For example:
Shifting away from old ways and adapting a new funding model can seem like a daunting task, but you can get started by taking the following first steps:
First, establish the baseline to which you will measure the funding shift’s effectiveness. A technology leader must consider all the dimensions of service that will improve when making the shift. Two areas of improvement that have high business impact are service quality and price. To establish the baseline for service quality, it is important to measure things like cycle time, defects, net promotor score, and critical business metrics that are heavily influenced by IT solutions.
The price baseline is a little more difficult to establish. The most straightforward way we have found to do this is to look at the projects completed in the last fiscal year and tally the resources it took to complete them. Start with a breakdown of team members’ total compensation (salary plus benefits), add overhead (cost of hardware/software per employee, licenses, etc.) and then communicate that in terms of business value delivered. For example, “project A cost $1.2M using 6 FTE and improved sales associates productivity by 10%”. When phrased this way, your audience will have a clear picture of what was delivered and how much it cost. This clear baseline of cost per business outcome delivered will serve as a helpful comparison when you shift to perpetual funding and need to demonstrate the impact.
The shift to a new funding model will be highly visible to all business leaders. To create the greatest chance of success, focus on selecting the right teams to trial the shift. The best candidates for early adoption are high-performing teams that know their roles in the product operating model, have strong credibility with business unit stakeholders, and experience continuous demand.
In our work with large organizations piloting this shift, e-commerce teams often fit the mold because they have a clear business stakeholder and have developed the skills and relationships needed to succeed in a product-based model. Customer success teams with direct influence on the growth and longevity of recurring revenue streams are also strong candidates as their solutions (such as customer portals and knowledge bases) directly influence the degree to which a customer adopts, expands, and renews a subscription product.
Estimation in the product-based funding model is different than in the project model. Under the new model, teams are funded annually (or another agreed-upon funding cycle) by business units. As funding shifts to an annual basis, so should cost estimation. Rather than scoping the price of a project and then building a temporary team to execute it (and then disbanding after execution), leaders should determine the size and price of the team that will be needed to support anticipated demand for the year, and then direct that team to initiate an ongoing dialogue with the business to continuously prioritize targeted business outcomes.
When completing a team-based cost estimation, it is important to include the same cost elements ( salary, benefits, hardware, licenses, etc.) that were used to establish your baseline so that you are comparing apples to apples when demonstrating the ROI of product-based funding. Where you will see a difference in the team-based model is resource capacity needed to deliver demand. In a product model, a cross-functional team is perpetually dedicated to a business domain, and there is often zero ramp-up time to acquire needed business and technical knowledge.
Since the teams have been perpetually dedicated to the domain, they are encouraged to take a longitudinal view of the technology estate and are able to quickly identify and make use of reusable components such as APIs and microservices, significantly improving time to market. For these reasons, among others, teams in the product-based operating model with perpetual funding can achieve more business value for less cost.
Pilot teams should work closely with the BU leadership providing the funding. Stakeholders should work together to generate a list of quantitative and qualitative business outcomes for the year (or other funding cycle) that also satisfy any requirements for existing funding processes operating on “project by project” basis.
If you don’t already have a great relationship with finance, start working on it now. Your partnership with finance at the corporate and BU level will be critical to executing your pilot and paving the way to wider enterprise adoption of team-based funding models. Ideally. Leaders should engage with finance before, during, and after the team-based funding model so that everyone is in lockstep with you throughout the pilot. This alignment can help bolster adoption with other areas of the enterprise.
Each finance department has unique processes, cultures, and relationships with IT, so while you will need to tailor your approach, you should broach the following topics:
You will need to achieve success in the pilot to bolster adoption in other areas of the business. Your success needs to be communicated in terms that resonate with the business. As your pilot comes to an end, gather your baseline data and match it up with the results of your pilot. Put together a “roadshow deck” to show a side-by-side comparison of costs, resources, and business outcomes (Business KPIs, quality metrics, cycle times, NPS, etc.) before and after the shift to team-based funding.
Depending on your organization, it may be prudent to include other observations such as the number of change control meetings required under each funding model, indicators of team morale, and other qualitative benefits such as flexibility. Have conversations with other areas of the business that may benefit from team-based funding (start off with 1-on-1 meetings) and offer to bring in your partners from finance and the product teams as the discussion evolves. The most important part of your story is that the team-based funding model delivers more business impact at a lower cost than the old model.
Establish light and flexible governance mechanisms to monitor performance of the teams operating in the teams-based model. The purpose of these mechanisms is to validate that the increased level of autonomy is leading to high-priority business outcomes, not to review progress on design specs or other paper-based milestones. A $40B global manufacturing client adopting the team-based funding model established quarterly portfolio reviews with BU leadership and the CIO to review results. BU leadership reviews results of the teams and the planned roadmap for the subsequent quarter. BU leadership is then given the opportunity to reallocate investment based on changing business needs or can recommend the team proceed as planned.
It is important to communicate that this process requires constant buy-in from business units. While funds will be allocated annually, demand will need to be analyzed and projected on at least a quarterly basis, and funds should be reallocated accordingly. In cases where investments need to be altered in the middle of a fiscal year, it is important to note that the unit of growth in this model is a new cross-functional team focused on a targeted set of business outcomes. The idea is to create several high-performing, longstanding, cross-functional teams that have the resources needed to achieve targeted business outcomes, rather than throw additional contracted developers at teams as new scope is introduced.
Making the shift from project-based funding to product team-based funding is a major cultural and operational change that requires patience and a willingness to iterate over time. When executed successfully, CIOs often have closer relationships with their business partners, as well as less expensive, more efficient ways to deliver higher-quality products.
At the Forbes CIO Summit at the Ritz Carlton at Half Moon Bay, the theme of the conference this year is The Digital CIO Takes Charge, as the CIO is now positioned to drive product, revenue and customer experience. At our conference you will see these trends personified.
I have been enormously encouraged by the number of CIOs who have taken digital responsibilities in part or completely for the enterprises they are a part of. As they do, they tend to get more involved in product development, as well. In the process, these grade A CIOs are getting more involved in driving revenue growth for their companies in addition to the traditional purview of CIOs of cost cutting.
We will hear from a number of leading lights who are shaping the technology landscape. Former Cisco CEO, John Chambers will join me on stage to talk about his career in addition to his current work as a venture capitalist.
Life insurance does not seem like the sexiest of segments. Most of the major players in the industry were founded 150 years ago or more. They often develop such scale and recurring revenue streams that they can develop a bit of strategic laziness, as well. These were among the reasons why entrepreneur, Peter Colis, saw opportunity as he evaluated the life insurance industry.
Colis had a job in advertising prior to attending Stanford Business School. When he arrived in Palo Alto, he met Lingke Wang, a computer scientist who also had an entrepreneurial bent. As they scoured industries that presented opportunities, life insurance checked a lot of boxes suggesting major opportunities. Investors have agreed, as the company has a stable of A-grade venture capital firms have invested in their company, Ethos Life, including Sequoia, (see my interview with Sequoia’s lead investor in Ethos Life here), Accel, and GV, Google’s venture arm. Additionally, Jay-Z and Kevin Durant have also invested in the company.
Life insurance was attractive for two reasons. First, the product is difficult to obtain. It is time intensive, confusing, and it requires many tests to validate coverage. Second, Colis highlights that the incentives for brokers, who are paid on commission, often lead to consumers purchasing coverage that is beyond their needs and their means.
In this interview, Colis describes his entrepreneurial journey, the growth and team composition of Ethos Life, as well as his thoughts on what is next.
Peter High: You are the Co-founder and CEO of Ethos Life, a San Francisco-based company that you founded in September 2016. Your organization has caught quite a bit of momentum, especially in the investor community. Could you talk about the business and the problem that you were looking to solve when you created it?
Peter Colis: My partner Lingke Wang and I started Ethos when we were roommates at Stanford Business School. I came from a background in advertising, and Lingke came from a technical background. Originally, we got interested in a different aspect of life insurance, and we learned a great deal about it. In doing so, we came to understand that life insurance is incredibly important. More than five percent of children in the U.S. are going to lose a parent by the time they turn 18, and 70 percent of families are so unprepared that if they lose a breadwinner, they would be in total financial ruin within three months. This data implies that Americans are vastly unprepared for the loss of a breadwinner. While this is an important industry, we realized that it is executed poorly by the existing players, so we saw an opportunity to dramatically improve how it is executed with technology.
Ethos is a modern and ethical life insurance company. Unlike the traditional life insurance experiences, with Ethos, you go to our website, you fill out an application online in ten minutes, and then you are done. There are no medical exams, no blood tests, no paper applications, and no pushy agents. We launched in early 2018, we are now processing thousands of applications per month, and we look forward to continued growth.
by Peter High, published on Forbes
6-22-2015
As interim CEO of the Broadcasting Board of Governors (BBG), Andre Mendes sits atop a broadcasting enterprise with as broad a reach as any in the western world. Unlike some other organizations that you might think of among leaders in this space, the BBG operates in the corners of the world that tend to be most inhospitable to the dissemination of unfiltered media. What makes Mendes even more interesting is his path to his current perch. He was a chief information officer before his further rise. As Mendes notes, however, with so much of media being dominated by new media, much of it of a social variety, his background as a technology executive are quite suitable to the times. In this interview, Mendes describes the mandate of the BBG and its various brands such as Voice of America, the traditional and new media methods he and his colleagues use, and his own unique path to become interim CEO.
(To listen to an unabridged audio version of this interview, please visit this link. This is the 20th article in the Beyond CIO series. To read the prior 19 articles, featuring interviews with executives at HP, Schneider National, Marsh & McLennan, Symantec, and Allstate, among others, please visit this link. To read future articles in the series, please click the “Follow” link above.)
Peter High: Andre, for those who may not be familiar with your organization, you are the Interim Chief Executive Officer of the Broadcasting Board of Governors. I wonder if you could take just a moment to describe this organization and its mandate.
Andre Mendes: The Broadcasting Board of Governors is the agency of the federal government that is responsible for all of the United States’ civilian broadcasts throughout the entire world. We have a very clear mission: to address populations that live under regimes that have no freedom of the press and freedom of information, and to address those populations in any platform in which they choose to consume news and other information. We are about a $750 million agency that comprises five different networks of brands that disseminate information. The largest one is our flagship: the Voice of America, which is an organization with tremendous roots going back to the 1940’s with preponderant roles in World War II, and also during the Cold War in addressing the issues in Eastern Europe. Our other brands include Radio Free Asia, which addresses some of the freedom of the press issues in Southeast Asia; Radio Free Europe/Radio Liberty (RFE/RL), which also has a strong role associated with disseminating information in the former Soviet Union and satellite countries; the Middle Eastern Broadcasting Networks, which is comprised of Alhurra TV and Radio Sawa and targets the Middle East in Arabic; and, finally, the Office of Cuba Broadcasting, which has been broadcasting into the island for a couple of decades, which has had a tremendous impact in the dissemination of information in what is one of the most restrictive systems in the world.
High: And in terms of methods, since you’re broadcasting in areas where the government often does not welcome the broadcasts, what methods are used?
Mendes: It’s actually an interesting proposition about this agency. We have what is likely the widest distribution portfolio of any western media organization. We range from operating very large short-wave stations throughout the entire world– some owned and operated, some via leases—to medium-wave stations running some of the largest AM transmitters, along with a large FM distribution network. We utilize satellites for direct-to-home for both TV and radio and data. We also have substantial presence on the web, on social media and through mobile dissemination, including Twitter. So from short-wave to Twitter, it is a lot of different steps. But the truth is that we operate in areas where short-wave is still a very viable mechanism. For example, in rural Afghanistan or North Korea or in parts of Africa, like Nigeria, where there is still a huge population numbers consuming short-wave, to medium-wave because it allows us have a very powerful signal from outside the borders of a country—it’s what is called a cross-border transmission methodology. For example, in Iran, we have a very large transmitter in the United Arab Emirates that covers the entire country. We are constantly expanding our FM network, some of it being operated in some of the most dangerous, and to a certain degree, chaotic places in the world.
To read the full article, please visit Forbes
The $35 Tablet That Is Changing The Education Landscape In India
11-19-2014
As anyone in the US with children of school-age can attest, technology enhanced learning has become a standard. Increasingly, that computing is embedded in the methods that children learn. Moreover, “flipped classrooms” are taking hold. Under this model, lectures and homework in a class are reversed. Short video lectures are viewed by students at home before the class session, while in-class time is devoted to exercises, projects, or discussions. This model has proven to be quite effective. Naturally, the cost of computing has been prohibitively expensive in many developing countries, and as a result the digital divide between the developed and developing world has grown.
For all that we read about India’s rise as a technology powerhouse, the country has relatively poor infrastructure. Less than 20 percent of mobile towers deliver 3G service, and therefore, 3G data services are used by less than 5% of active subscribers. The country also has the slowest internet penetration growth in the Asia Pacific region at only 12.5 percent. Compare that to China’s rate which is over 42% or even Bangladesh’s, which is 21 percent.
It should also be noted that in India, the drop-out rates of school children remain appallingly high. 16 percent of students drop out during grades one through four, 43% drop out during grades five through eight, and 68% drop out between grades nine and 12. As a result, there are roughly 142 million children who should be in school but are not.
A few weeks ago, I spoke at a gathering of IT executives at former Mexican President Vicente Fox’s presidential library, Centro Fox. Another speaker at the conference was Suneet Tuli, an Indian who now lives in Toronto. Tuli is the founder and chief executive officer of DataWind, a Canadian wireless web access products and services developer. Having become familiar with the discouraging data regarding the digital divide, Tuli elected to do something about it. As Tuli explains it, “Although I was born in India, I grew up in Canada, and had access to Canada’s world-class public education system. But in various family trips over the years, I realized that in India the quality of education one received was in direct correlation to one’s economic class. I felt very strongly that access to the internet would level the playing field.” He developed a goal for his company to develop a tablet computer that would be affordable for the masses in India. PCs became ubiquitous in the US once the cost of the PC dropped to below 25 percent of a person’s monthly income. In order for this to work in India, Tuli realized that his tablet would need to cost $35.
