Overview

Abstract

Everest, a global integrator of utility-scale battery energy storage systems (BESS), set out in early 2024 to define its next-generation product. Internal conviction was strong: the platform needed higher energy density, more duration flexibility, and a lower price. Before committing its next-generation development capital, Everest ran a structured Voice of the Customer (VOC) program built on the lateralworks right-Product methodology. The study changed the product. A VOC council of representative customers — storage developers, independent power producers, a utility, asset owner-operators, and large electrical contractors — worked through discovery interviews, structured surveys, and pairwise-comparison workshops. The resulting Analytic Hierarchy Process (AHP) models showed that the drivers Everest assumed would define the product were not the drivers customers weighted most. Energy density, the presumed centerpiece, turned out to be a binary, project-specific consideration. What customers weighted most was power and energy availability over the life of the asset, and behind it, the software and services that keep availability high and optimize the storage asset’s revenue. The software platform, not the battery hardware, emerged as the differentiator customers would pay for. The next-generation program was redirected accordingly: hardware cost-down without damaging total-cost-of-ownership drivers, an availability-first engineering agenda, and a software roadmap elevated from supporting feature to product core. This paper documents the full study — the market context, the council design, the discovery instruments, the AHP model chain, the findings, and the product decisions — as a template for any technology company that suspects its next product is being defined by internal conviction rather than customer evidence. Figure 1. What VOC discovers: what customers want, when they want it, and what they value. From the lateralworks VOC toolkit.

The market — A market growing too fast to guess

Utility-scale energy storage is one of the fastest-scaling capital equipment markets in the world. Global installations reached roughly 106 GW in 2025, up 43% year over year, bringing cumulative capacity to approximately 270 GW / 630 GWh. Forecasts project more than 1,500 GW by 2034, a near-sixfold increase, and BloombergNEF projects cumulative capacity reaching 2 TW (7.3 TWh) by 2035. Utility-scale projects account for over 80% of installations. Analysts estimate $1.2 trillion of investment will flow into battery storage to support the global renewable buildout. Growth of that magnitude sounds like a seller’s market. It is the opposite. Three forces make BESS one of the most competitively complex equipment markets anywhere. Hardware is deflating LFP cell prices fell roughly 30% from 2022 to 2023, with a further 20% decline predicted for 2024. Chinese DC blocks were expected to reach $120–145/kWh by the end of 2024. Integrators must pass cost declines through to customers; at constant margin percentage, that means shrinking margin dollars on every megawatt-hour shipped. As hardware deflates, soft costs — installation, civil works, integration — grow as a share of CAPEX and become the new battleground.

The integrator’s role is under attack from both ends Developers can now self-integrate: buy a Chinese DC block, procure inverters directly, and add off-the-shelf EMS and SCADA. It is the cheapest path, by as much as $100/kWh versus the most expensive integrated options. Meanwhile, third-party O&M providers are entering storage services, unbundling the long-term service agreements integrators counted on. An integrator that cannot articulate why its wrapped solution reduces risk enough to justify its premium is structurally squeezed. Figure 2. The two storage integration models the study weighed: components procured separately versus an integrated AC block from the integrator — with opposite risk and financing profiles. From the study’s synthesis. Requirements are fragmenting by market Development is getting harder: permitting, fire-safety reviews with local authorities, land availability, interconnection queues. ERCOT looked saturated while newer markets emerged with unique demands, from noise limits in New York and Europe to grid-forming capability in Australia and utility cybersecurity requirements. Revenue models are shifting from simple capacity contracts toward merchant exposure and revenue stacking, which makes performance — availability, round-trip efficiency, auxiliary load — a direct revenue variable rather than a spec-sheet line. In a market like this, defining a next-generation product from internal assumptions is a bet with a widening downside. Everest chose not to make that bet. The question Everest could not answer from the inside Everest had built a successful modular AC-block platform and an installed base across multiple continents. The next-generation product would carry the company for a decade. Internal views of what it should be were confident and specific: denser, more flexible in duration, cheaper per kilowatt-hour. But confidence is not evidence. The leadership team recognized a failure mode that lateralworks’ FTTM (Fast Time To Market) research has documented across hundreds of technology programs: teams define products from what they can build rather than from what customers will pay for, discover the mismatch at launch, and pay for it in redesign spins and missed market windows. In a market compounding at double-digit rates, a product cycle spent building the wrong thing is a forfeited position, not a delay. Two questions framed the study. Which storage integration model was Everest best positioned to serve — full AC-block integration, or the disaggregated DC-block-plus-components model — and what should the product’s scope be? And within that scope, which requirements actually drive purchase decisions?

The process — The lateralworks VOC method

Everest adopted the lateralworks VOC process, the right-Product engine inside the FTTM system. Its logic is compact. VOC discovers three things: what customers want (and don’t want), when they want it, and what they value — what problem the product solves, why they want it, and how much they’ll pay. Figure 3. The FTTM system: right-Product, right-Time, right-Team, inside the environment. VOC is the engine that continuously defines the right product.

The process runs in four steps. – Wants. Capture what customers say they want, decode what they mean, and convert it into customer requirements. Start here, not with the solution. – Translation. Convert customer requirements into product requirements: what the wants mean to the engineering organization and how the product will meet them. – Solution. Define what will be produced, then put it back in front of customers. What do they say when the solution is presented? – Refresh. Keep confirming with customers throughout development, so the product is still right at the moment of introduction, not just at the moment of definition. Figure 4. The four VOC steps. Start at Wants — not at Solution — and never skip Refresh. From the lateralworks VOC toolkit. Discipline about sequence matters more than it sounds. Most organizations start at Solution: they show customers a nearly finished concept and ask for validation. The lateralworks process forbids that. Wants come first, unprompted, before the customer ever sees what the supplier has in mind. The fourth step is the one organizations forget. Requirements gathered once decay as markets move. Underneath the four steps sits a chain of quantitative models — market model, customer model, wants model, hows model — each feeding values to the next, each built by pairwise comparison. That chain is where AHP does its work, and section 03 walks through it. Building the VOC council The first design decision was who to listen to. VOC results are only as good as the voices in the room; a council that over-represents one customer archetype quietly biases every model downstream. Everest assembled a VOC council of representative users and buyers across the storage value chain: – A chief engineer at an Asia-Pacific storage developer building some of the region’s largest battery projects – A senior vice president of project execution and asset management at a US clean-energy IPP – A senior BESS technology engineer at a global renewables developer headquartered in Europe

– A director of energy storage engineering and a director of strategic procurement at a global energy major’s North American renewables arm – A senior manager of transmission and distribution projects at a US investor-owned utility, Everest’s utility customer – Large electrical contractors responsible for installing and commissioning utility-scale storage plants The mix was deliberate. Developers and owner-operators see the asset over its whole revenue life. The utility sees regulatory and reliability obligations. Contractors see the installation and commissioning realities that never appear on a datasheet. Titles mattered as much as logos: engineering voices weight operating costs and performance, procurement voices weight capital cost and bankability. Getting both meant the study could later separate those mindsets instead of averaging them into mush. In parallel, Everest surveyed its own sales and product organizations with the same instruments. This internal mirror proved to be one of the study’s most valuable design choices. It let the team measure precisely where the company’s assumptions diverged from its customers’ stated priorities.

Fieldwork Discovery: interviews, surveys, and structured data gathering Fieldwork ran from February into April 2024 in a fixed cadence for each council member: an introductory call framing the aspiration (“designing the most compelling energy storage product to serve global markets in 2025 and beyond”), discovery interviews of up to two hours, a structured survey requiring about four hours of the customer team’s effort, a 90-minute AHP prioritization workshop, and a concluding product data sheet workshop to test the resulting concept. Every instrument was built before the first conversation. The discovery question set was compiled in a matrix with a column the lateralworks method insists on: “Our Current Thinking” — what Everest believed the answer would be, written down in advance. Every question was tagged as a market, customer, or product requirement and prioritized. The point is falsifiability. When the customer’s answer contradicts the recorded assumption, the gap is undeniable and becomes a requirement change. Without the written prior, teams unconsciously reinterpret answers to fit what they already believe. Figure 5. A discovery-question matrix from the lateralworks VOC toolkit: every question is paired with “our current thinking” — the recorded assumption the customer’s answer will confirm or destroy.

The interviews worked through three structured frames, each backed by a worksheet the facilitator filled in live with the customer. – Macro environment. How will tomorrow’s environment differ from today’s for a BESS developer or owner? What characteristics will winning integrators have? How much do you value application flexibility — the ability to evolve a site’s cycling profile over its life? – Total cost of ownership. Six cost drivers: beginning-of-life (BOL) AC CAPEX, the installed capital cost of the system; installation; augmentation, the later addition of capacity to offset battery degradation; auxiliary load and round-trip efficiency (RTE), the parasitic power the system consumes and the share of stored energy it returns; maintenance; and financing cost. Each was rated for priority and for best-versus-worst performance observed in the market on a ±15% relative scale, with a probing question attached: what does best look like? Customers were also asked which categories they actually model differently between integrators — a question that separates stated preferences from the spreadsheet reality of procurement. – Product requirements. Seven requirements, through the same priority and relative-performance discipline: serviceability; power and energy availability; energy density and footprint; flexibility and compatibility with power conversion systems (PCS — the inverters that connect batteries to the grid, often selected before the battery vendor is); duration flexibility, the ability to configure the same product as a two-, four-, or eight-hour system; user interface; and controls, the battery and energy management software (BMS/EMS). Figure 6. Fieldwork instrument: the total-cost-of-ownership interview worksheet. Each cost driver is rated for priority and for best-versus-worst relative performance (±15% scale), with notes and “what does best look like?” captured live. The survey put the same frames in spreadsheet form so each customer organization could respond with internal alignment rather than one individual’s opinion, and so responses could feed the AHP models directly. Roughly seventy questions ran across fourteen categories — general experience, procurement, O&M, risk management, thermals, duration, electrical architecture, auxiliary load, form factor, noise, balancing, software and controls, safety, and financial modeling. A sample:

Category Question General In a few sentences, please describe your ideal stationary energy storage product. General What is the best reason to buy an ESS from a single integrator instead of self-integrating? Procurement Do you have a single- or multi-source ESS supply procurement strategy? O&M How important is it for an integrator to provide 24/7 operations support? (1–10) Risk management What types of evidence can an integrator provide to reduce your primary risk drivers? Electrical architecture Do you see an AC or a DC block as the more compelling product? Why? Auxiliary load Do your future projects require separate metering of auxiliary power? Is it an important decision factor? Form factor How does energy density affect your procurement decisions? (1–10) Software / controls When evaluating a procurement decision, how important are software and controls? What do you expect from an integrator’s platform (BMS/EMS)? Financials When you model differences in revenue or cost elements between products, which elements actually move the decision? Figure 7. Sample discovery-survey questions (of roughly seventy), edited to anonymize the client. Scalar questions used 1–10 scales; the rest were open-ended. Interview responses were captured verbatim in a wants matrix: the question asked, Everest’s prior thinking, the customer’s response, and the decisive column — the want behind the response, what the customer meant and intended. The distinction is not pedantic. In lateralworks’ canonical example from an earlier VOC program, a customer rejecting a proposed operating mode wasn’t asking for a spec tweak; the want behind the answer was “transit ticketing must work when the device is off,” a requirement that redefined the architecture. Everest’s interviews produced the same pattern. A statement like “we’ve had lower performance and higher OPEX than planned” translated into a want: provable availability guarantees that match how our financial models actually calculate revenue. Discovery closed with a synthesis of themes across the whole storage value chain — developers and owners, integrators, cell vendors — pairing each trend with the question it forces and the behaviors that will separate winning integrators. This one-page synthesis framed everything the AHP models would later quantify.

The models — The AHP engine

Interviews produce words. Product decisions need numbers. The bridge in the lateralworks VOC process is the Analytic Hierarchy Process, a decision method that converts structured pairwise comparisons into weighted priorities that can be added, compared, and stress-tested like any other numbers. Everest’s models were built and facilitated in fastDecisionAI, the decision-modeling tool in the lateralworks software suite. Every model in the study — customer selection, requirement weighting, sensitivity runs — lives as a fastDecisionAI workbook that can be rerun, audited, and refreshed as the market moves. The mechanics are simple to experience and hard to game. A participant is shown two items at a time (“low system cost” versus “high availability”) and asked which matters more, and how strongly, on a nine-point scale. The full set of judgments produces a weighted ranking of every item, summing to 100%. Because every item is compared against every other, participants cannot do what they do in ordinary surveys: rate everything “critical.” The method also computes a consistency score that flags contradictory judgment sets (if A beats B and B beats C, A had better beat C), giving the facilitator a quality gate on every model.

The lateralworks process chains four AHP models, each feeding the next. – Market model. Business objectives — time-to-market sensitivity, revenue contribution, margin, leverage across products, team focus — are pairwise-weighted, then candidate market segments are scored against them. Output: the driving market. – Customer model. Criteria such as chance of design win, quality of relationship, anticipated volume, market leadership, and roadmap alignment select the driving customers within that market, the customers whose requirements should steer the product. – Wants model. The driving customers’ weights are applied to the full customer-requirements list, producing a single prioritized wants ranking: what the market, weighted by who matters most, actually values. – Hows model. Customer wants become the criteria; candidate product implementations become the alternatives. The output is a force-ranked list of product requirements — the features that deliver maximum customer value, which is precisely the definition of an MVP worth shipping. Figure 9. The AHP model hierarchy: market model → customer model → wants model → hows model, each feeding weighted values to the next. Toolkit example from an earlier lateralworks VOC program (names blurred). The customer model is where Everest’s council came from. Five pairwise-weighted objectives — a vested interest in Everest’s future, a lifetime-value procurement mindset, technical sophistication, diverse integrator experience, and coverage of target markets — scored twenty-four candidate organizations across geographies and customer types. The top-scoring organizations became the council.

Model outputs From weighted wants to ranked product requirements The wants model concentrates the study’s judgment into two artifacts: the driving customers and their weighted requirements. The hows model then force-ranks the candidate implementations against those wants — the direct input to development focus and MVP scoping. Figure 12. Wants-model output: driving customers and the critical requirements that will steer development. Toolkit example (names blurred). Figure 13. Hows-model output: prioritized customer wants (top) drive a force-ranked list of product requirements (bottom) — the MVP feature set. Toolkit example.

Second, the same models support competitive benchmarking (scoring your product and competitors’ against the same weighted wants) and monthly refresh, so a requirement change arriving mid-development can be evaluated in minutes: rerun the model, compare the rankings, accept or reject the change with the cost-of-delay model. Figure 14. What-if scenarios: change the dominant customer requirement and watch the product-requirement ranking reorder. Toolkit example. Pairwise comparison carries the top of the hierarchy. Further down, where dozens of alternatives must be scored quickly, fastDecisionAI uses ratings scales: each criterion gets defined anchors — typically 1, 3, and 9 — so different raters score alternatives consistently and the arithmetic stays honest. The anchors below come from one of the program’s selection models.

Key finding The software discovery They were not buying a battery in a box. They were buying availability — and the software that delivers it. Next-generation VOC study Council prioritization workshops, 2024

The findings — What the models revealed

On total cost of ownership, one result was unanimous and unsurprising: beginning-of-life AC CAPEX ranked first. The instructive finding sat in the spread. Every one of the six cost drivers was ranked #1 or #2 by at least one customer — evidence that “the customer” does not exist in utility-scale storage; archetypes do. Installation ranged from 2nd to 7th in priority across respondents. Augmentation, which Everest’s engineers had treated as a serious design consideration, was ranked near the bottom by everyone except the utility, which weighted it as heavily as CAPEX. That is exactly the kind of split a single averaged ranking would have erased.

The assumption that fell: energy density Going in, energy density and footprint were treated internally as decisive. The sales organization saw density as an early, defining question from global customers, and the engineering roadmap reflected that belief. The council said otherwise. Density mattered on space-constrained projects and barely at all elsewhere: “binary,” in the study’s summary. A threshold to clear on some sites, not a driver to maximize across the portfolio. One sophisticated developer went further: efficient and safe layouts matter more than raw density even when density is sacrificed. Duration flexibility — the modular sizing capability Everest had engineered into its platform as a differentiator — was valued by almost no one. Customers do that diligence once, early, and simpler scaling beats cleverer granularity. Two internal assumptions, both load-bearing for the old product concept, both contradicted by weighted customer data.

The finding that redefined the product The software discovery The study’s most consequential finding was not a line item on the questionnaire, and at first glance the data seemed to argue against it. User interface ranked dead last among the seven product requirements; customers said plainly that UI plays no role in procurement. Yet the same customers, in the same interviews, kept relocating the product’s value from the hardware to the software and services around it. The paradox resolves cleanly. Customers don’t buy screens, and most integrate the system into their own third-party SCADA anyway. But nearly everything they do weight heavily turned out to be delivered by software: – Availability is delivered by software. The initiatives customers implicitly demanded — cell balancing, contactor management, power distribution, state-of-charge and state-of-health accuracy, predictive maintenance, automated controls improvements, a stronger remote operations center — are software and analytics programs, not mechanical ones. – Serviceability is a safety and uptime property, designed in through racking and de-racking maintainability and component weight, and increasingly scheduled by analytics rather than calendars. – Controls integration is a purchase criterion. Customers wanted proactive integration of their chosen SCADA and power plant controllers (best-in-class providers factory-commission the customer’s control stack for a fee), and they wanted the integrator’s energy management system to stop being a black box and become simple, intuitive, and transparent in real time. – The integrator’s premium is justified by de-risking, and the de-risking customers described is largely informational: flexible, easily modeled performance guarantees that let owners evolve a site’s use case over its life; field-proven data on auxiliary load and round-trip efficiency they can put into project models; a track record of operating sites at high availability through remote, analytics-driven operations. Customers, in short, were not buying a battery in a box. They were buying guaranteed, optimizable energy availability over a twenty-year asset life, and the software layer that monitors, controls, and continuously optimizes the storage asset is what makes that promise credible. The economics underneath are unforgiving: when hardware deflates toward commodity pricing, the scarce asset is no longer steel and cells. It is provable performance, which is information. The recurring software-and-services relationship was where differentiated value, and pricing power, lived. For a company that had always understood itself as a hardware integrator with supporting software, this was an identity-level correction. It came from the customers’ own weighted judgments, not from a strategy consultant’s thesis.

The product — From findings to the next generation

The Translation and Solution steps converted the weighted wants into a product direction with three planks. – Cost down, but never at the expense of TCO drivers. Meet the procurement archetype’s bar on BOL CAPEX while protecting installation cost, auxiliary load, and serviceability, the drivers the technology archetype weights. Cost reductions that damage TCO drivers are self-defeating in a market where soft costs are the growing share of CAPEX. – Availability as the engineering agenda. Component quality and reliability programs, thermal performance, and maintainable design, engineered so that guarantees can be structured the way customers’ financial models actually compute revenue, and backed by robust, defensible field studies that prove auxiliary load, round-trip efficiency, and availability claims. Unproven claims, the council made clear, are priced at zero. – Software elevated to product core. The next-generation program prioritized the availability-and-optimization software stack — balancing, contactor management, power distribution, SOC/SOH, predictive maintenance, automated controls, remote operations — as primary product requirements, with transparency and integration openness as explicit design goals. Energy density was demoted to a threshold requirement on constrained sites. Duration-granularity engineering was deprioritized.

The direction was then condensed into a product vision the whole company could carry: every VOC requirement maps to a pillar the next-generation product must deliver — safety, insight, availability, flexibility, and customer service. Two of the five pillars, insight and availability, are delivered primarily by software. Figure 21. Mapping VOC to the product vision, redrawn from the study: each customer requirement translates into a product pillar. Insight and availability — the software pillars — carry the weight of the study’s central finding. A hypothetical product data sheet embodying the direction went back to the council for the Solution step’s acid test: if we built this, would you buy it? And the Refresh step was built into the program’s operating rhythm. The VOC council was designed as a continuing relationship rather than a one-time panel, with the AHP models retained as living artifacts, refreshed as markets and requirements move, and used to adjudicate mid-development change requests against cost of delay. Why it worked: the playbook Six practices from this study transfer to any technology company defining a next-generation product. – Write down what you think before you ask. The “our current thinking” column converted every interview into a controlled experiment on Everest’s assumptions. Without it, disconfirming evidence gets absorbed instead of counted. – Constitute a council, not a sample. Five or six organizations sounds small. Chosen to span archetypes — developer, IPP, utility, owner-operator, contractor; engineering and procurement — it produces more decision-grade signal than a hundred-response survey, because each voice’s weighting can be modeled individually.

– Force trade-offs with pairwise comparison. Everything-is-critical is the default output of conventional research. AHP makes it mathematically impossible and attaches a consistency check to every respondent’s judgment. – Mirror the study internally. Running sales and product through the identical instruments turned “the customer disagrees with us” from an argument into a measured gap on a chart — the single most persuasive artifact in the executive readout. – Read the variance, not just the ranking. The consensus ranking answered what to build. The archetype structure answered how to sell it, to whom, and with which proof points. – Keep the models alive. A VOC study that ends at the readout starts decaying the day it is published. The standing council and monthly model refresh are what make the product right at introduction, not merely right at definition. The broader lesson is the uncomfortable one. Everest’s internal product concept was coherent, technically sophisticated, and wrong in two of its central assumptions. What saved the program was not better intuition but a process that let customers re-rank the company’s priorities before the capital was committed — and a willingness, when the models contradicted the roadmap, to believe the models. About lateralworks. lateralworks helps technology companies deliver the right product at the right time. The VOC process described here is part of the FTTM (Fast Time To Market) system: thirty-six years of original research into how the fastest technology teams in the world actually work. lateralworks.com

References

  1. Wood Mackenzie. “Global energy storage market surpasses 100 GW annual installation milestone in 2025.” Wood Mackenzie, 2025. https://www.woodmac.com/news/opinion/global-energy-storage-market-surpasses-100-gw-annual-in stallation-milestone-in-2025/
  2. BloombergNEF. “Global Energy Storage Boom: Three Things to Know.” BloombergNEF, 2025. https://about.bnef.com/insights/clean-energy/global-energy-storage-boom-three-things-to-know/
  3. Wood Mackenzie. “US$1.2 trillion in battery storage investments needed to support global renewable buildout.” Wood Mackenzie, 2025. https://www.woodmac.com/press-releases/bess-opportunity/
  4. S&P Global. Li-ion Battery Cost Report, January 2024. As cited in the client’s VOC discovery synthesis.
  5. Client VOC study. Discovery interview and survey synthesis, February–April 2024. Customer estimates and market observations gathered under confidentiality; organizations anonymized.
  6. lateralworks. “The FTTM Framework.” lateralworks methodology and engagement research, 1988–2026. https://www.lateralworks.com
  7. Client VOC study. AHP prioritization workshops and report-out, April 2024. Anonymized.
  8. Saaty, T. L. The Analytic Hierarchy Process: Planning, Priority Setting, Resource Allocation. McGraw-Hill, 1980.