Abstract
This article tells a story about two methodologies, one used to examine the workings of the other. The examined methodology, the build-measure-learn loop used in Lean Startup, is a design methodology: It involves developing a series of design objects and using them to elicit feedback from huddles of stakeholders in a series of dialogical encounters. But unlike most design methodologies used in technical and professional communication, which assume that both stakeholders and propositions constitute stable categories, this one tests different propositions with different compositions of stakeholders during each cycle. Thus, it disrupts the incrementalist assumptions that underpin conventional design methodologies. To examine the build-measure-loop in action, we require an examining methodology that guides our conceptual decision about what to study. In this article, I use a compositional methodology to offer one such conceptual decision: the fractional object, which is made to cohere across diverse dialogic cycles, with different huddles, evaluating different claims. I apply this examining methodology to a 7-year study of a device developed by an early-stage technology startup. The study has implications for both design methodology and case study methodology.
Keywords
Introduction
This article tells a story about two methodologies, one used to examine the workings of the other.
The examined methodology, the build-measure-learn loop (Ries, 2011), was used by an early-stage technology startup I’ll call “Sapient Engineering” (SE) as it developed its offering, “SapienTap.” (These and other names in this paper are pseudonyms.) SapienTap is a motion-controlled shower adapter that lets water warm up to the perfect temperature, then pauses the water stream until a bather enters the shower. SapienTap conserves water and energy, making it attractive for hotels. To develop SapienTap, SE formulated a series of design objects: unfinished, prototypical versions of the final product that can elicit stakeholder feedback through a build-measure-learn loop (Ries, 2011). In this loop, the startup builds the design object, offers it to stakeholders and measures the results, then learns from the results by formulating another proposition to test and another design object to test it in the next loop. Design objects could be as unfinished as a sketch or computer render, or as finished as a fully working device. The results of each encounter informed how SE developed subsequent design objects. That is, this methodology was a design methodology, like ones used in technical and professional communication (TPC) (e.g., participatory design, Design Thinking). But the build-measure-learn loop had one key difference: rather than being oriented to a relatively stable category of users, these design objects were also offered to varying compositions of investors, funding agencies, contractors, suppliers, partners, and non-user stakeholders occupying various roles in the customers’ organizations. By drawing different compositions of stakeholders into each encounter with a design object, SE explored different sets of potential relations and requirements so that an eventual device could emerge.
As Table 1 shows, this difference in design methodology is significant. Other design methodologies assume stability in the proposition being tested (why) and the stakeholders (for whom) so that they can iterate the design object (what). Through this stability, they can iterate the design object dialectically, working toward a single, united design that satisfies most of the involved stakeholders. But in the build-measure-learn loop process, all three categories vary. Each encounter is dialogic in the sense that meaning emerges from difference, rather than unity, as a dialectical approach entails (Matusov, 2013; Wegerif, 2008; cf. Spinuzzi, 2023a): entrepreneurs seek to understand differences in stakeholders’ feedback, both within and across encounters. What is iterated is not just the design object but the combination of design object, proposition, and stakeholders.
Differences Between Dialectical Design Methodologies and the Dialogic Build-Measure-Learn Loop, Illustrated by Contrasting an Exemplary Usability Study (Rose et al., 2017) With the Case Examined in This Article.
To effectively examine this design methodology, our examining methodology must account for fluxing compositions of design objects, stakeholders (cf. Walton, 2013), and propositions. One candidate is case study methodology, but as I investigated the research question “How does the startup use encounters with design objects to develop its offering?”, I realized that a case study would be inadequate. A case study defines boundaries, characterized with questions such as who, what, when, where, why, and how (Spinuzzi, 2023b; Yates & Orlikowski, 2002). But in the examined methodology, boundaries vary: Each dialogic encounter uses a different what, why, and for whom. Thus data collection had to vary in each encounter. I turned to what Lury (2020) calls a compositional methodology, characterized by shifting boundaries. To develop this compositional methodology, I use three conceptual terms: fractional object, claim, and stakeholder huddles, which are further discussed in the literature review (See Table 2).
Understanding the Build-Measure-Learn Loop Through a Compositional Methodology.
Both the examined methodology (the built-measure-learn loop) and the examining (compositional) methodology are important for writing studies. The examined methodology can clarify the embedded assumptions of stasis in design methodologies, which are increasingly used in TPC investigations (see below). Meanwhile, the examined methodology illuminates dialogic collaborations in workplace writing research, addressing boundary limitations in case studies.
Below, I first review relevant literature on these two methodologies, then introduce the study and method. I analyze four specific design-centered encounters in SE’s history, characterizing these encounters with a compositional methodology. I conclude by discussing implications for design methodologies and compositional methodologies in TPC.
Literature Review
In the introduction, I introduced the examined methodology, the build-measure-learn loop, and the examining methodology, a compositional methodology that fluxes with the variable boundaries of dialogic encounters. Here, I review relevant literature on each.
Design Methodologies and the Build-Measure-Learn Loop
TPC has long used design methodologies, which provide overarching frameworks and processes for developing a design object. TPC journals have drawn on design methodologies such as participatory design (Evia & Patriarca, 2012; Spinuzzi, 2005a, 2005b; Thominet, 2021), contextual inquiry and contextual design (Beyer & Holtzblatt, 1998; Potts & Bartocci, 2009; Smart, 2002), usability testing (Barnum, 2002; Friess & Liles, 2023; Johnson et al., 2007), user experience/user interface research (Cosgrove, 2023; Kessler et al., 2021; Rose & Schreiber, 2021), and Design Thinking (Pellegrini, 2022; Pope-Ruark et al., 2019; Tham, 2022). Design methodologies allow designer-researchers and participants to co-investigate and co-create, drawing on participants’ tacit knowledge about their work to incrementally develop artifacts that meet their unique needs. Design methodologies typically presume defined, stable categories of people to whom the design artifact is offered. These people are represented by participants in the design research. They are typically characterized as users—a term that frames participants solely in relation to the design artifact, (Kessler et al., 2021, p. 383), omits non-consumers (Divine & Zachry, 2025), and ultimately implies a unidirectional relationship with the artifact.
Design methodologies incrementally iterate the design artifact through cycles in which participants and the designer codesign the artifact. Designers define parameters, including user categories and tasks to test. Iterations move the artifact from abstract representations (such as conceptual diagrams) to concrete, near-production-level prototypes and processes (such as functional devices and websites) (e.g., Pellegrini, 2022).
At first glance, the build-measure-learn loop seems like a prototype-focused design methodology, since a design object represents the final offering, eliciting the feedback of stakeholders—a category that might include users or participants as well as nonparticipant decision-makers who are also interested in the process, such as buyers or investors (Ries, 2011). The design object may not contain all envisioned features, but it must allow the startup to measure its impact on customers and other stakeholders. In the build-measure-learn loop, the startup repeatedly builds a design object, measures stakeholder feedback, then learns from that feedback by identifying future development steps, looping to the next iteration of the cycle. Since the focus is on eliciting learning, early design objects can be quite abstract: conceptual diagrams, sketches, renders (Ries, 2011; Stevenson et al., 2024). Design objects are iterated, becoming more concrete, eventually yielding a production-quality version that can be manufactured and sold (Nguyen-Duc et al., 2019; Stevenson et al., 2024). Since they emerge from iterative cycles with stakeholders, design objects (ideally) come to address stakeholders’ needs, concerns, and values.
Despite these similarities, the design objects in the build-measure-learn loop are deployed differently from artifacts in other design methodologies. Most strikingly, the build-measure-learn loop is not user-centered. Instead, in each encounter, varying compositions of stakeholders evaluate claims that the design object embodies. Whereas design methods as normally used in TPC research tend to focus narrowly on functional users, the build-measure-learn loop is focused more broadly on finding and co-creating with combinations of stakeholders beyond the users being served by the device.
This focus on combinations of stakeholders is a key difference. Startups are said to be temporary organizations in search of a business model (Blank, 2013; Stayton & Mangematin, 2018), and as such, they seek many potential paths forward, examining many possible combinations of stakeholders to identify potentially durable compositions. Such stakeholders include external mentors, potential customers, investors, non-investor funders, and partners, as well as internal employees, contractors, and the founders themselves—and sometimes users. Beyond that, each stakeholder may vary compositionally: The startup may gain founders, customers might include additional roles in the approval chain, partners might multiply as the offering becomes more concrete. These compositional variations mean that any claims may be evaluated in unforeseen terms.
As I have discussed elsewhere (Spinuzzi, 2025), the entrepreneurship literature characterizes these design objects under the headings of “prototypes” or “minimal viable products” (MVPs) (Khanna et al., 2018; Nguyen-Duc, 2020; Nguyen-Duc & Abrahamsson, 2016; Nguyen-Duc et al., 2019; Stevenson et al., 2024), conceived as any representation of the final product that can be used to gather information during the build-measure-learn loop. 1 Nguyen-Duc, who has coauthored several case studies on such design objects (Khanna et al., 2018; Nguyen-Duc & Abrahamsson, 2016; Nguyen-Duc et al., 2019), characterizes these encounters using the 6W3H framework (Nguyen-Duc, 2020). This framework asks nine questions about the MVP:
What should it include?
What should be measured with it?
Why should it be built?
Who will build it?
For whom will it be built?
When will it be built?
How will it be built?
How much does it cost to build it?
How long does it take to build it? (p. 88)
He visualizes these encounters with Figure 1. Here, the design objects (“What”) are surrounded by the other questions. Each dotted circle represents a build-measure-learn loop (Nguyen-Duc, 2020, p. 88). This figure implies linear development (“evolution”) in which the series of MVPs yields a finished offering.
A diagram in which the “What” (design object) is iterated across loops. Source. Nguyen-Duc (2020, p. 88), used with permission of author.
However, Nguyen-Duc and collaborators trouble that progression with Figure 2, which shows branching hypotheses in a lattice of design objects (Khanna et al., 2018, p. 183). A startup can test different hypotheses with different design objects oriented to different “for Whoms,” rather than incrementally refining an offering. Thus, a later design object could be more abstract, less concrete, and refined than an earlier one.
In these diagrams, hypotheses (H1, H2, etc.) are tested with MVPs or design objects (M1, M2, etc.). Different hypotheses might be tested in the same MVP, and MVPs can branch off to follow different developmental paths. Source: Khanna et al. (2018, p. 183), used with permission of author.
To examine the build-measure-learn loop methodologically, I turn to a compositional methodology.
Compositional Methodology
In TPC, we often turn to qualitative case study methodology for a rich exploration of work, bounded by some principle such as a work object or set of participants (Spinuzzi, 2023b). However, the build-measure-learn loop (Table 1) challenges such bounding principles: each loop may bring in different objects, people, locations, and durations. Thus, we need an examining methodology that accounts for boundaries fluctuating across loops. Although Nguyen-Duc and collaborators characterize their investigations as case studies, the 6W3H framework belies this assumption: Each design encounter involves not just more or fewer stakeholders (“for Whom”) and propositions (“Why”), but also different ones. Since these encounters are bounded differently, they cannot constitute a single case study, nor a set of comparable case studies (Dumez, 2015).
Instead, the design object poses the “ontological multiplicity of the epistemological object” (Lury, 2020, pp. 156–157): Each design object is positioned differently in different dialogic encounters, even though it represents the same eventual object. Thus, it requires “a compositional methodology” (p. 3): instead of “responding only to the initial presentation of a problem,” it must “compose[] the problem again and again” (p. 5). Lury argues that a problem space represents a problem in terms of relations among givens, goals, and operators (p. 2). Since a problem becomes a problem through investigation, the researcher must understand the problem space as a space of methodological potential (p. 3). Put differently, the problem space is itself a methodological choice that may need to be adjusted during the investigation. Rather than a linear process (determine a research question, then bound the phenomenon to study, then collect data, then analyze them), a compositional methodology involves iteratively recomposing the boundaries until a research question, bounded phenomenon, data collection, and data analysis mutually emerge.
For instance, whereas most design methodologies hold the proposition and stakeholders to be stable while the design object is varied, the build-measure-learn loop treats all three as variable in each dialogic encounter (Table 1). Furthermore, in each encounter, new stakeholders may emerge (such as different roles in the customer decision chain), using different criteria for evaluating the claim. The problem’s boundaries are unclear going into each encounter; the problem space is repeatedly recomposed.
Jornet and Damşa (2021) consider this issue in terms of units of analysis, arguing that research methods “emerge and take shape in and through the very work of inquiry” (p. 3), and, thus, researchers should seek “[e]cological units [that] denote evolving social wholes [and are] actually found in and through inquiry” (p. 4). They argue that “to investigate and come to know an object involves relating to it both intellectually and affectively through concrete experience/activity” (p. 4), and that “the validity and rigor of observations, from an ecological perspective, is determined by relevance to practice” (p. 4). Similarly, Matusov (2007) advocates a “partial methodology” whose unit of analysis is dialogic (grounding meaning in difference) rather than dialectic (grounding meaning in unity): “units of analysis have to be always viewed as partial, incomplete and open. . . . defined in part by the studied object, in part by the researcher’s focus, in part by the audience of research and in part by the research participants (as distinct from the research object)” (p. 326). For such a partial methodology, “the units of analysis are incomplete with regard not only to their object of the study, but also their subject of the study: to whom the study is addressed. A study should not just be a story about third persons for an academic community but also a dialogue with people who participated in the study” (p. 328).
Responding to Matusov’s argument, Lund and Vestol (2020) caution that Matusov’s view is relativistic: In affording multivoicedness to develop dialogic truth, they charge that he omits a “clear tension and reciprocity resulting in a new synthesis” (p. 3). Meaning in difference cannot yield a unity: How can we develop a conclusion if we accept all voices as valid rather than synthesizing them? After all, SE developed their product through these dialogical encounters rather than leaving it in an eternal limbo of directionless dialogue. Yet that development did not dialectically yield a unified offering that resolved all tensions. Rather, compositionally varying dialogues in one encounter yielded givens for subsequent dialogues, givens that a subsequent dialogue could question. In the process, some dialogic partners were jettisoned (although some echoes of their dialogue might persist in the form of absences and negative capabilities).
To elaborate this compositional methodology, I draw on conceptual terms: dialogical cycles, fractional objects and design objects, claims, and stakeholder huddles.
Dialogical cycles: How do we conceptualize the build-measure-learn loop?
In the build-measure-learn loop, we can understand each design object as the focus of a dialogical cycle, an encounter in which differently positioned stakeholders evaluate and propose changes to the design object. Guile and Spinuzzi (2024) characterize the dialogical cycle in terms of loops: in each loop, different stakeholders are drawn into the encounter while others exit. However, whereas Guile and Spinuzzi characterize the dialogical cycle as iterating an object until it coheres, I argue that these cycles can lead to branches of different possibilities. Different design objects are evaluated in different dialogic encounters, sometimes simultaneously, leading to different lines of development.
Fractional objects and design objects: What to build?
Startups are organized post-bureaucratically, as temporary arrangements of specialists in search of a sustainable business model (Blank, 2018). Their work is projectified, that is, organized around an open-ended project (Guile, 2012) whose endpoint is an offering to some future composition of stakeholders who can be stabilized. I characterize this offering as a fractional object (Law, 2002). For Law, objects such as SapienTap are assemblages of “multiples”—including technical designs, specific features, prototypes, and social and political purposes—that have “no single centre” (p. 3). Thus, he argues, the performances of the multiple stakeholders involved in a project “make objects that cohere” (p. 3) as they make connections between continuity and discontinuity and, simultaneously, address the “tensions that are made in the process of centring” (p. 112). The resulting fractional object is coherent enough to anchor collaborative activity, yet incoherent enough to provide traction to the different stakeholders attempting to transform it. Startups might orient to multiple, mutually exclusive possibilities simultaneously, trying each out, mitigating the risk of failure by pursuing diverse strategies with different compositions of stakeholders. By its nature, a fractional object is emergent and unstable, involving different implementations that test the interests and values of various stakeholders. The emergent fractional object must interest some composition of stakeholders that can sustain existence and growth.
A design object is a single performance of the fractional object (e.g., a prototype, schematic, or MVP) built to test a stable association among What, Why, and for Whom during one dialogic cycle. During that cycle, it is evaluated by a specific composition of stakeholders in terms of a specific proposition or claim. Put another way, the What, Why, and for Whom are all variable across cycles (Table 1). With this variability, the startup must actively connect performances to develop a fractional object.
In SE’s case, the fractional object it was attempting to develop, “SapienTap,” was composed of a decade’s worth of artifacts: physical prototypes, 3D-printed casings, off-the-shelf components, patent filings, schematics, demonstration videos, explanatory hang tags, pitch decks, renders, microcode, data, battery configurations, dashboards, and many others. Among these artifacts were design objects (“What to build”), evaluated in terms of claims (“Why”) by compositions of stakeholders (“for Whom”). SE sought a combination of What, Why, and for Whom that could form an association stable enough to support a sustainable business, one built around a mass-manufacturable device that would eventually be marketed as a product, plus an associated dashboard, plus a subscriber-based service.
Since design objects vary so much, each dialogic encounter centered around a design object may have bounds that vary significantly from those of other encounters.
Claims: Why is a given dialogic encounter orchestrated?
As we saw in Table 1, design methodologies test propositions. But in the build-measure-learn loop, such propositions are variable from one loop to the next, serving as a starting point for dialogue rather than as a scientific hypothesis. Such a proposition functions as an exploratory claim that stakeholders evaluate as they consider a design object from the standpoints of their different needs and values. Unlike a scientific hypothesis, a claim is not supported or falsified, but rather evaluated: How likely is it to be true, and under what conditions? Since different stakeholders may evaluate the claim according to different criteria, and the stakeholder composition varies in each encounter, the claim’s main function is to elicit dialogue—dialogue that remaps the problem space by exploring its relationships among What, Why, and for Whom. Thus, not only do different claims imply different boundaries to the problem space in different encounters, but also the same claim may imply different boundaries in the same problem space, depending on how it is evaluated.
Stakeholder huddles: For whom is the design object built?
Finally, these dialogic encounters happen within stakeholder huddles: temporary compositions of stakeholders who collectively evaluate a design object and claim. Huddles include startup founders and external stakeholders (e.g., customers, users, investors, and funders). Thus these dialogic encounters defy a stable case boundary: each one involves different stakeholders, different design objects, and different claims and evaluative criteria, and happen in different places, at different times, with different durations. These differences imply different scopes of data for each encounter.
With these conceptual terms established, I developed an examining compositional method for understanding the examined design methodology.
Method
To explore SapienTap as a fractional object, I sought dialogic encounters in design objects that SE offered to different huddles. To analyze such encounters, I triangulated interviews with SE’s founders and SE’s archive to identify four design objects spread through SE’s history, then collected additional data on stakeholders encountering each design object, including publicly accessible websites. I investigated each encounter as a separate dialogic cycle involving a huddle considering a claim. Thus, case bounds fluctuated for each dialogic encounter, being delimited by the huddles around the different design objects.
To reduce the data to these four design objects, I selected a frequent topic: the battery. This topic was consistent across design objects across 10 years of data (2016–2025); it was the focus of multiple huddles; it highlighted conflicting interests within and across these huddles; and consequently, battery compromises were explicitly discussed in archival documents. The four design objects were (a) described with detailed data across the interviews, archives, and publicly accessible information, allowing robust triangulation, and (b) spread across the startup’s history.
Below, I overview the startup in more detail, then describe data collection, reduction, and analysis.
The Startup: Sapient Engineering (SE)
This article is based on two related studies reviewed by the author’s institutional review board in 2017 (No. 2017-02-0070) and 2022 (No. 00003725). The 2017 study was determined to be exempt, while the second was approved.
SE’s story began in early 2016, with Alan (then a computer engineering student) experimenting with an Arduino microcontroller. He considered creating a shower alarm clock: when his alarm went off, the shower would turn on, so that by the time he stepped into the shower, it would be hot. But this idea meant wasting water. After doing some research, Alan discovered that bathers often don’t get in the shower immediately once the water is warm: 20% of water in an average shower is wasted.
So Alan flipped his idea, adding a motion detector. Now the device reduced warm-up water waste by running the water until it was hot, then pausing shower flow until the bather stepped into the shower. By mid-2016, he had identified a market segment for this device: hotels.
Surprisingly, when he initially described the idea to hotel general managers, they consistently asked the same question: “Will this stop our guests from steaming their clothes in the shower?” It turned out that in addition to warm-up shower waste, hotel guests sometimes behave in other wasteful ways. They sometimes leave the hot shower on for hours to steam their clothes. Or they turn on a shower, then pass out drunk, leaving the shower on overnight. Or they turn the shower on to create white noise for relaxation or to prevent eavesdropping. These “long shower events” (about 1.11% of hotel showers take over an hour, about 0.001% take over 4 hr) create leaks and mold, requiring expensive mediation.
Thus an easily installed, unobtrusive, battery-powered, motion-controlled shower adapter intrigued hotel managers. Hotel guests often treat hotel resources as if they were infinite and free. But with this device, guests could conserve water and energy without having to alter their own behavior. Functionally, they could be better people because their moral decisions had been delegated to the device (Latour, 1992).
Based on his initial work, Alan started SE to develop SapienTap, whose consistent value proposition is that the hotel will “save more than you spend.”
But as any engineer can tell you, engineering is the art of compromise (Petroski, 1996). To attract stakeholders and deliver on its value proposition, SE had to explore stakeholders’ wants, needs, and values, absorbing these into the fractional object of SapienTap. These stakeholders went beyond customers. For instance, SE received funding from National Science Foundation Small Business Innovation Research (NSF SBIR) grants, which support US-owned businesses that advance knowledge and understanding. Some early investors were interested in addressing problems in the hotel industry. Others, including a VC firm that provided seed funding, were attracted by SapienTap’s “green” technology: its potential to reduce water and energy waste. And SE’s founders themselves were attracted to the project for still other reasons—reasons that they didn’t entirely share with each other, few of which were monetary. Its design objects had to cumulatively probe all these associations—in addition to potential customers—to yield an offering that could attract some set of stakeholders.
In addition to managing water flow, SapienTap also connects to the hotel’s WiFi and sends shower data to SE’s servers, including shower event length, volume of water used, and energy consumption. These data are shown in a dashboard so that the hotel manager can see utility savings and detect problems with individual showers.
From 2016 to 2025, SE created many design objects, from a rudimentary first prototype built with an Arduino board to short production runs that were deployed in paid pilot and demonstration programs in hotels. These design objects had quite different qualities and components, loosely cohering as “SapienTap” and representing an eventual mass-produced device.
SE’s three founders (Table 3) are its only full-time members. Although they lead SE’s development efforts, they also engage with a rotating set of contractors, funders, potential customers, users, and suppliers.
Founders.
Note. Titles and join dates are from founders’ resumes as of April 2023.
Data collection
I collected interviews, archival materials, and publicly available information.
Data Sources.
Data Reduction
Following a nonexclusive coding scheme, I first coded interviews with deductive starter codes based on elements of Lean Startup methodology: Audience, BMC, Design, Evidence, Funding, Market, Pitch, Production, Supply, and VP (value proposition). Next, I followed an emergent open coding strategy, developing 75 additional codes under the starter codes. Through this emergent coding, I selected design decisions related to the battery: 20 codes related to Design, with nine specifically related to the battery. Appendix A shows the relevant codes.
I then applied the coding scheme to a database of selected archival materials (2016–April 2023) including Lean Startup elements (pitches, BMCs, and “MVPs”) and contextual documents related to these elements (e.g., process documents on pitch competitions, grant proposals, press releases, investor communications, and documents related to internal testing and pilot studies). Omitted from this database were internal files that did not relate to the above (e.g., code files, personal documents, internal financials).
From the coded materials, I identified materials describing four dialogic encounters centered around design objects. These materials included grant proposals, calls for proposals, and reports; pilot study and demo proposals, data, and reports; pitch decks; and investor updates. I contextualized these with founder interviews.
Data Analysis
After reducing the 2016–2023 data, I used the coding scheme to do the following:
Develop a timeline based on documents and interviews.
Identify interview data related to design decisions and motivations.
Identify documents related to design decisions and results.
After selecting documents, I
triangulated data sources to identify convergences and divergences (cf. Sabaj et al., 2023),
collected supplemental archival materials relevant to the encounters produced between March 2023 and May 2025,
collected publicly accessible materials, such as websites of named suppliers, partners, and subcontractors, and
conducted member checks with the cofounders in 2025 by soliciting comments on article drafts. (As Matusov [2007] argues, “The research participants have to have a chance to reply to this analysis and findings as much as it is possible in order to develop the dialogic truth of the research” [p. 328].)
Findings
Table 5 shows selected dialogic encounters bounded by what (design objects), why (claim), and for whom (stakeholder huddle). Results of each encounter feed into subsequent or simultaneous encounters.
Selected Dialogic Encounters Bounded by What, Why, and for Whom.
Below, I examine the four design objects, the claims they explored, and the huddles they anchored within each dialogic encounter. Critically, although each encounter explores a claim, the dialogue and resulting design decisions go beyond that claim to address the broader concerns of the huddle.
DO1: Schematics for a Device Using a Turbine Generator (2016–2017)
DO1 was a schematic from an SBIR grant proposal. Originally submitted in June 2016, this proposal asked the NSF to fund the development of an embedded turbine generator to charge an embedded Li-Ion battery. After receiving comments, SE revised and resubmitted the proposal in December 2016. The proposal was unsuccessful. By 2017, SE had submitted a new proposal pivoting to removable batteries. To examine the dialogic interaction around this design object, I collected and analyzed the schematic, relevant interviews from SE founders, and SE’s correspondence with the NSF.
What (the design object)
This design object was a schematic showing SapienTap’s components, including a 3.62-cm turbine generator that could charge the battery whenever the shower was on. In the accompanying text, SE explains: Powering the [SapienTap] IoT device using only [removable] batteries requires the user [hotels] to replace or recharge the batteries which is an unacceptable maintenance task for them. Further, powering the device using a turbine-based embedded micro-hydro-generator produces unacceptable results due to the noise and wear and tear of a spinning turbine in long-term installations. See attached letters of support from interested customers for more information. . . . To address this problem, we propose constructing a micro-hydro-generator constructed of a novel new material.
This abstract schematic came between two more concrete design objects. According to their December 2016 FastLane document, SE had produced “a Low-fidelity MVP [prototype] which we have used to validate a product/market fit. Through this process, we have learned key customer insights and barriers to adoption of our initial low-fidelity prototype.” Customers cited three key objections to this initial prototype:
I. Our MVP must not disturb the guest shower experience. The primary aim of our upcoming pilot study is to quantify this risk.
II. Our MVP must generate and store enough energy to power the device for 5 years without recharging or replacing the battery.
III. Our MVP cannot be larger than the existing prototype.
If the NSF accepted the proposal, SE could create a turbine generator that met these requirements.
Why (the claim)
DO1’s claim was something like: SE can develop a novel turbine generator.
For whom (the huddle)
In this encounter, the huddle was made up of SBIR reviewers and SE founders.
The dialogue
SE initially argued that customers required a 5-year battery life, both in their December 2016 FastLane document and their 2017 resubmission—something that, they believed, would require a turbine generator and embedded battery. In the FastLane document, they argued that customers would accept SapienTap “only if it can run significantly longer than 6 months without recharging the battery”; otherwise, it would require “too much maintenance for a device that will be installed in all 300 of their rooms.” SE added: “We may be able to increase this surface area by creating ribbings, similar to a heat sink, however, our customers have expressed a need for the device to be easily cleanable, so we will not consider these geometries.” SBIR reviewers were unconvinced by this initial argument.
SE continued the dialogue by applying for another SBIR grant in 2017, this time describing a device with 4 AA batteries and no turbine generator. The SBIR panel considered the device “over-engineered” and suggested removing Wi-Fi. SE responded: “We have achieved 6 months of battery life with our current prototype to date. However, as part of this phase I effort, we will further increase battery life by (1) moving to a low-power MCU, (2) replacing our li-ion battery with 4 AA alkaline batteries, and (3) further firmware upgrades which minimize WIFI use and optimize sleep states when the shower is not in use.” They also argued that requested features, such as monitoring water use, could only be delivered with Wi-Fi.
The outcome (design decisions)
SE was caught between what its customers demanded and what SBIR reviewers would support—and constrained by the limits of existing battery technology. Customers’ maintenance constraints included not just longer battery life but also the device design, since “ribbings, similar to a heat sink” would lengthen battery life but require extra maintenance. SBIR reviewers responded that other IoT devices could last 2 years without a generator. SE then abandoned its turbine generator but kept Wi-Fi. As Chandra said in 2023, customers found this change acceptable because switching to AA batteries allowed them to integrate SapienTap into their existing maintenance supplies and routines: “they know what a maintenance guy needs to do.” Similarly, Alan said in 2023 that budget hotel chains “change the batteries, like, in their smoke alarms and in their remote controls. They buy AAs in bulk.” SE had found an argument that made removable batteries acceptable to customers.
SBIR reviewers were right: In May 2019, SE reported extending battery life to over 2 years with 4 AA batteries, satisfying customers’ concerns without a turbine generator. And in 2023, Alan said that budget hotel chains are “not at all worried about changing AA batteries every year and a half.” SE had failed to find support for the turbine generator, but they had succeeded in better understanding the huddle’s evaluation and finding a compromise that would satisfy it.
DO2: Pilot Prototype 2 (2019–2020)
By early 2019, SE had developed a prototype (“Pilot prototype 1,” later termed version 1 or “v1”), and one hotel chain (HC1) financed a paid pilot test in one hotel shower. This pilot validated their battery life, sensors, and ability to save over 20% on utility costs. Based on these results, they convinced a second hotel chain (HC2) to conduct a 120-room paid pilot test between October 2019 and March 2020. To examine the dialogic interaction around this design object, I collected and analyzed proposals and reports written to both HC1 and HC2, interviews with the founders, testing data, a concept paper, investor reports, a webpage from the partner who designed the v1 showerhead, and publicly available information from HC2’s website about HC2’s decision chain.
What (the design object)
In the HC2 pilot, DO2 was several hand-assembled units of a working prototype, powered by 4 AA batteries.
Why (the claim)
SE’s June 2019 proposal to HC2 specified two success metrics:
Save [HC2] at least 20% of their shower utility costs.
Achieve a high level of guest satisfaction.
For whom (the huddle)
This pilot drew several stakeholders into the huddle. First, HC2 executives included the chain’s CEO, VP of Procurement, and three other directors. These executives approved the pilot and were updated on its changes. Second, hotel guests were brought in via 15 interviews, online reviews, and complaints reported to front desk workers. Finally, the founders were active in this huddle.
The dialogue
In this encounter, the dialogue mainly focused on the two claims above. The dialogue helped SE quantify its savings in greater detail. By November 2019, SE reported that “11% of showers were >45 minutes” and “30 showers lasted longer than 3 hours”—quantifying HC2’s need for the device. By May 2020, SE had “collected data on 2,407 shower events, which is the largest study of hotel shower behavioral waste to date,” and could report “20.8% of shower time reduced.” They also quantified long shower events: The longest shower event recorded was 12.6 hr, while the “top 1% of all shower events averaged 1.7 hours of flow time.”
Guest satisfaction was weakly positive: The two online reviews were split; interviews reported a 6/10 satisfaction rating, and front desk staff “reported relatively few complaints” about the device.
Yet device testing also revealed problems with the hand-assembled prototypes. An April 2020 spreadsheet reported battery-related problems: unexpectedly drained batteries, power shorts due to poor soldering, and smoking batteries. In addition, three units leaked—a problem that a sealed permanent battery and turbine generator would have mitigated.
Although not reported in the documents, this dialogue revealed an additional issue mentioned in the interviews. The shower adapter fit between the shower arm and the existing showerhead and was meant to be unobtrusive. But Alan and Brent separately affirmed that HC2’s Director of Design found this device to be aesthetically at odds with the hotel’s brand. Whereas previous discussions had focused on utility savings and maintenance, now aesthetics became a salient barrier to adoption.
The outcome (design decisions)
In a member check, Alan alleges that this version failed “because the sensor wasn’t universally compatible with all shower heads in the adapter form factor.” The adapter’s sensors couldn’t “see” around showerheads beyond a certain size. Yet “Customer demand for the hypothetical product (yet to be delivered) remained higher than ever.” So, as a design object, DO2 succeeded. In a November 2021 concept paper, SE asserted that: “The pilot allowed us to find and fix potential bugs in our product, conduct accelerated aging tests using temperature and pressure cycling fixtures, test our product in a semi large-scale rollout, and, most importantly, gauge how customers and users react to our product. During this refinement phase, we were also able to reduce the cost per manufacturing unit of our product and we plan to consistently continue our efforts on this front.”
SE reported to investors in August 2021 that “based on our learnings, we are developing our next-generation model, and have partnered with [a volume manufacturer].” Alan told me the next-generation (“v2”) model was an integrated showerhead designed to satisfy Directors of Design. Budget hotel chains “pay, like, 26 cents per showerhead” but would prefer elevated aesthetics, “the equivalent of a $300 luxury rainfall showerhead”—one that would be bundled into SapienTap’s subscription cost. In addition, “the switch to the showerhead . . . is solving a lot of engineering problems”: Brent said it provided “a lot more space to work with” and its unobstructed sensors obviated v1’s problem with seeing around an existing showerhead. This design pivot was an unanticipated but crucial development emerging from this huddle.
This design pivot took some time and required new contractors to supply the prototype and to provide design-for-manufacturing. The next design object involved both versions of the device.
DO3a and 3b: Paid Deployment and Data Dashboard (Early 2023)
In 2023, SE conducted a paid deployment with a third hotel chain (HC3). This paid deployment was in three phases; I discuss the first two here.
What (the design object)
According to a 2023 NSF progress report, SE provided two design objects during this deployment.
Phase 1 involved DO3a
v1 shower adapters for 1-room and 10-room tests, and
early prototypes of its analytics dashboard, which showed metrics from the shower adapters.
Phase 2 involved DO3b
v2 showerheads for a 100-unit building, and
a more advanced analytics dashboard.
To examine the dialogic interaction around this design object, I collected and analyzed the proposal, reports, and updates written to HC3, interviews with the founders, testing data, photos of the v2 showerhead, investor reports, and publicly available information about HC3’s decision chain as well as SE’s potential design partners.
Why (the claim)
In Phase 1, SE tested whether DO3a could scale up to 10 rooms and whether the analytic dashboard worked and was useful. In Phase 2, SE tested whether DO3b worked with hotel Wi-Fi and whether the installation procedure worked.
For whom (the huddle)
This huddle consisted of HC3 executives, who were interviewed “to establish robust software specifications tailored to the demands of this industry,” and SE founders, but not hotel guests. It also involved the partner that designed the v2 showerhead.
The dialogue
As summarized in a January 2024 update to HC3 executives, the dialogue covered several issues. First, HC3 strongly preferred the v2 showerhead, which provided better aesthetics, flow, and a ball joint option. The elevated-aesthetics showerhead was offered “free” to hotels (received though a SapienTap subscription), eliminating showerheads from HC3’s capital expenditures.
Second, SE reported performance improvements, including tampering resistance and better Wi-Fi connectivity, and further quantified long shower events.
Third, SE promised that by 2025, they would integrate the turbine generator first proposed in 2016. This generator could increase projected per-shower savings from 26% to 45% by eliminating capital expenditure on batteries. The turbine (which was always on the roadmap, according to Alan and Chandra) was back for two reasons. The first was that the v2 design provided more room for it. The second had to do with DO4, which was being tested at the same time.
The outcome (design decisions)
This dialogue resulted in two notable design decisions that, again, went well beyond the original claims.
The first was to commit to the v2 showerhead. As they mentioned in an August 2023 presentation to HC3, they “completed the smart shower head [v2] production design. We expect the smart shower head to save significantly more than the current adapters [v1].” V2 launched in October 2024 as a paid deployment with 8 months of recurring payments and 120 rooms at one location, soon expanding to five locations and to 50 locations after that.
The second was to return to the turbine generator that DO1 had originally proposed. In a 2024 SBIR technical report, SE used new behavioral data to argue that removable batteries were not viable: “The device was programmed to only save water for the first 10 minutes of each shower to allow our batteries to last 2 years,” but “the average hotel shower duration is 30% longer than reported in residential studies” and “showers that are longer than 4 hours . . . remain unoccupied 80% of the time on average & cause costly moisture damage.” As a result, “we’ve proposed a new SBIR Phase I to develop an embedded microturbine” which will “save our customers and the environment more than double our current battery-powered product.” Long shower events “occur in 1 out of 1000 showers . . . and in a 300 room hotel, this calls for daily battery replacements.” With this turbine generator, SapienTap “can capture the entire 30% of shower behavioral waste while also eliminating the maintenance burden of battery replacement from hotel staff.”
DO4: v1 Prototype and Dashboard (2023)
As SE prepared the HC3 phase 1 paid deployment, it also sought other possibilities. One was the Environmental Security Technology Certification Program (ESTCP), which demonstrates and validates novel technologies at military installations. Military installations had been considered a possible SapienTap market since 2018, when SE unsuccessfully applied to a defense innovation program. But in January 2023, ESTCP specifically sought demonstration projects that improved water management and water resilience planning. SE contacted ESTCP, engaged in pre-proposal dialogue, and finally submitted a revised proposal in July 2023. By September 2023, they were able to confirm interest. The demonstration started in October 2024. To examine the dialogic interaction around this design object, I collected and analyzed the ESTCP call for proposals, SE’s proposal, reports, presentations, fact sheet, and updates written to the DoD, an SBIR technical report, interviews with the founders, investor reports, and publicly available information about the DoD program and the testing locations.
What (the design object)
Strikingly, DO4 was the v1 shower adapter—identical to the DO3a units. But whereas DO3a was treated as near-production-quality, DO4 was treated as an early demonstration. That was because the DoD had very different needs. When the DoD considered SE’s pre-proposal, they insisted on two changes, as Alan summarized: “rip out the Wi-Fi” and “rip out the batteries; this thing must be self-powered.” He added, “We thought we had battery life figured out finally, like, like last year, and then DoD threw us a curveball. . . . The AAs came from trying to build a product that would fit in the economy hotel market.” Unlike that market, the DoD required security (Wi-Fi posed a potential security threat) and sustainment (reducing reliance on supply lines and maintenance).
The DoD’s first requirement was easy, but the second was impossible for DO4. As Brent told me, “we're definitely not [building in a turbine generator] for the DoD [demonstration]. Like for this iteration, it’s just that there’s not enough time and funding to develop it.” SE’s January 2023 response to ESTCP reviewers promised to disable the Wi-Fi on the demo units, instead implementing local data storage. And it argued that since v1 units could last for 2 years, compared to the 3-month demonstration period, they would not require maintenance during the demo. Since an eventual DoD-focused product had to be self-powered, they added: “In January 2023, we submitted a letter of intent to the Department of Energy for a grant application to develop this micro-turbine technology. We will also submit an application to the NSF PFI program in cooperation with [a research university] for the same purpose.”
They included a picture of an off-the-shelf turbine and explained how they would redesign SapienTap to accommodate it. Additionally, they affirmed that this change would benefit their other market, hotels. In other words, they repositioned v1, which as DO3a had been considered a late demo for HC3, as an early demo for the DoD, sufficient for productively organizing a huddle around a claim. DoD approved the demo.
Why (the claim)
SE responded to the ESTCP call for proposals, which emphasized that “demonstrations are intended to generate supporting cost and performance data for acceptance or validation of the technology.” To that end, DO4 tested these claims, which were laid out in both their July 2023 final revised proposal and their September 2023 presentation: that it could
quantify total water and energy usage
calculate shower water wastage
model behavioral wastage in DoD
For whom (the huddle)
The September 2023 final presentation listed several parties in the huddle: “DoD Energy Managers, Operations & Maintenance, utility providers, and IT (Cyber Security)”; users (through surveys); base management (through surveys); two SE subcontractors; and SE’s founders.
The dialogue
As Chandra told me, “The panel that reviewed our application kind of suggested, is there a way to go out of the battery mode? And that's when we suggested, you know, this mini-turbine has been in the back of our mind for some time, that could be a possibility for the future. So if we're going to design something, it would be for a market that’s . . . open to a no-battery situation.” In a 2023 interview, Alan similarly characterized the DoD battery request as “build a turbine.” He added, “And the turbine will be much more environmentally sustainable than disposable batteries.”
The outcome (design decisions)
As had been suggested in the pre-proposal feedback, SE had committed to a turbine design for their v2 showerhead. In a March 2024 SBIR technical report, they stated: Multiple DoD purchasing decision makers have plainly stated that, in order to achieve scale within DoD, we must eliminate all maintenance burden. They stated that “preventative maintenance does not happen in DoD facilities.” The one and only maintenance burden that our product has is battery replacement.
And in a March 2025 ESTCP fact sheet, SE recounted the demo results: User satisfaction surveys showed 45% positive and 55% neutral feedback, with no negative responses, indicating general acceptance. Despite strong performance, the need for regular battery replacement was identified as a significant implementation hurdle for DoD facilities. This led [SE] to propose a future self-powered version using a micro-turbine to eliminate this maintenance burden.
These updates indicated that to serve the DoD, SE required a turbine generator. SE used these updates to justify this design decision, not just to the DO4 huddle, but to other huddles.
Reporting to Other Huddles, Cohering the Fractional Object
Although we have focused on dialogic encounters in which different design objects and claims were offered to different stakeholder huddles, with different scopes and boundaries, these encounters were not hermetically sealed. In fact, SE’s founders, as the only constant across these encounters, frequently reported one huddle’s dialogue to others: funders such as NSF and ESTCP grants and investors, customers such as hotel chains and the DoD, pitch competitions, and subcontractors. SE repeatedly used each design object and claim to focus a huddle’s dialogue in one encounter, then characterized that dialogue to a second huddle in a second encounter, sometimes almost simultaneously. These characterizations typically justified design decisions to the second huddle, including battery-related decisions: It’s not that SE demands a turbine, or a 2-year battery life, or removable AA batteries—it’s that customers do, evidenced via the results of each loop. In representing each encounter to other huddles, SE cohered SapienTap as a fractional object, even as it developed unpredictably. This coherence was loose, not necessarily building in all huddles’ contradictory insights, but instead finding combinations that could form lasting settlements for some stakeholders. The results of each dialogue yielded givens for the next one. In contrast, a dialectical approach incrementally improves a design through sequential encounters with a single, stable group of participants (e.g., Bødker, 1991).
Still, these premises were often more flexible than characterized. In 2016, SE argued for a turbine because customers insisted on a 5-year battery life; when SBIR rejected that argument, SE wrote a second proposal characterizing customers as accepting a 2-year life. In 2023, when ESTCP insisted on a self-powered device, SE affirmed that feature would also be important for the hotel market (although Brent admitted that hotels never complained about the 2-year battery replacement cycle) and used ESTCP’s insistence to mount a new argument to NSF for turbine development funds. That is, SE had to reinterpret, re-represent, and continue dialogic encounters to keep SapienTap coherent.
SE also kept SapienTap coherent through decisions about design, production, and market. As mentioned, the near-production-quality DO3a almost simultaneously served as an early-stage DO4, representing a potential branch in product development. As Alan said, “Over the next year, or so, we’re gonna have to figure out . . . how to integrate these requests and somehow homogenize these, these two markets [budget hotel chains and the DoD]. Or maybe only one can survive.” In interviews, Brent expressed doubt that SE could accommodate both markets, while Chandra affirmed that the hotel market was much easier to understand, more homogeneous, and with a simpler decision chain. Could the two markets cohere through a single, coherent device? Or would SE need to serve the two markets by producing two separate devices?
Where Are They Now?
SE has successfully cohered a single market: Hotel chains. It has focused on DoD-owned hotel chains, which are functionally similar to budget hotel chains (vs. barracks or bases). That coherence involved rethinking SapienTap’s features so that these apply across DoD and non-DoD hotels. In 2024 and 2025 investor decks, SE offers three service levels: the lowest level is powered by removable batteries, the standard level is self-powered with a turbine, and the highest level is self-powered and includes analytics. The standard level satisfies the DoD’s requirements by minimizing maintenance and supplies while cutting Wi-Fi. SE also lists interested hotel chains, mixing in both DoD and budget hotel brands. Alan reports that SE is currently fielding a paid deployment across 120 rooms of a national economy hotel chain, with “5 more buildings going in next 2 quarters, negotiating a contract for 50 locations,” and the chain is interested in eventually deploying SapienTap across their entire enterprise. SE’s dialogic encounters with multiple huddles have provided a way forward, yielding both a coherent offering and a coherent market that needs it. Despite headwinds caused by the 2025 tariffs, as of August 2025, they are on track to raise funds that will allow them to mass-produce their completed device.
Conclusions and Implications
For Design Methodology
The examined methodology has implications for how TPC understands design methodologies. Specifically, we must interrogate design methodology’s incrementalist assumptions. Although design methodology illuminates stakeholders’ tacit concerns so they can be integrated into a final product, it tends to assume that both stakeholders and propositions constitute stable categories. This study troubles that assumption. As Lury (2020) argues, research problems are often recomposed again and again. That recomposition has been limited by ontological assumptions embedded in design research, which often posits a restricted and stable set of representative users (Spinuzzi, 2005a). But in this study, the design object anchors different huddles composed of different collections of stakeholders, evaluating different claims; these huddles are unstable because SE is questing for a set of stakeholders, not assuming one, and the claims are starting points for dialogue in huddles, not just hypotheses to be tested. The fractional object, SapienTap, cannot satisfy all huddles. Put differently, SE did not just use its design objects to test products, product features, or product-market fit; it also used design objects to test compositions of stakeholders. Thinking about design objects in these terms thus advances us toward a methodologically more sophisticated understanding of design objects and design research.
Additionally, this case disrupts a common orientation in design research: toward end users. Instead, SE started multiple dialogues with multiple huddles, seeking one or more ways forward that could be acceptable to both SE and some coalescing market. As we’ll see below, this orientation has implications for agency.
For Case Study Methodology
We can also draw lessons from the examining methodology used to study these design objects and the build-measure-learn loop. Workplaces have always been less clear-cut than we like to think. That is especially true in startups, temporary organizations seeking a sustainable business model. For such workplaces in flux, studies must challenge rather than assume boundaries and stability. Although case study methodology continues to be a valuable way to study workplaces, it relies on setting case boundaries—a difficult methodological choice when studying unstable work (Spinuzzi, 2023b).
Under these circumstances, we must make a conceptual decision about what to study. In this article, I offer one such conceptual decision: the fractional object, which is made to cohere across diverse dialogic cycles, with different huddles, evaluating different claims. Different design objects stand in for the eventual device across cycles of not-necessarily-linear development. The fractional object lets us conceptualize how design objects enable exploratory, emergent, and unpredictable collaborations, while huddles let us conceptualize stakeholders who engage in dialogue to evaluate claims according to diverse criteria. Since these huddles fluctuate in composition, size, and complexity, this compositional methodology included additional, principled data collection focused on each huddle’s stakeholders as they carried on dialogue.
This brings us back to the earlier-referenced disagreement about dialogic methodology (Lund & Vestøl, 2020; Matusov, 2007). Matusov argued that units of analysis should be kept partial, incomplete, and open, focused on differences among dialogue partners; Lund and Vestol countered that a dialogic approach led to relativism rather than the development that dialectic provides. But a dialectic assumes a relationship leading to unity. In contrast, SE pursues various dialogues with various compositions of stakeholders, changing the fractional object in different ways, carrying some dialogical agreements forward and keeping other ideas (such as the turbine) in reserve despite disagreements as they pursued different potential compositions of problem, market, and device. In March 2023, SE considered hotels and the DoD as two potentially exclusive markets, with the hope but no expectation that they could homogenize these markets. Faced with two developmental directions, instead of seeking a unity, they chose to see where both led.
And this brings us back to agency. Who is driving this development? Gherardi and Nicolini (2005) argue that actor-network theory tends to tell two types of stories: One in which an entrepreneur retains agency, and one in which agency is ecologically distributed. It is easy to read this study as the former: each huddle included the founders, who then represented the results of each huddle to others, so we could interpret SE founders as retaining agency over the process and guiding SapienTap to coherence. But that is because we are following their fractional object, making SE a constant across the encounters. (Imagine if, instead, we were following the ESTCP committee as they reviewed different proposals, or HC2 executives as they considered different operational innovations.) In seeking to develop a device that can satisfy multiple needs, in trying to thread the needle with some of the stakeholders across these huddles, SE had to accept the agency of those other stakeholders into the fractional object as well: Stakeholders’ constraints had to cohere as a device, codesigned across huddles, working with the material limits of components such as batteries and sensors as well as the manufacturers and supply chains that produced and transported them. From an ecological standpoint, these stakeholders all exerted agency, and to keep SapienTap coherent, SE had to address their feedback and needs. As Brent told me, SE’s goal is for SapienTap to be “sticky,” a goal that informed further plans such as integrating the dashboard with hotel chains’ utility bill data systems. To exert its own agency, SE had to dialogue its way into a device in which (some of) its dialogue partners could recognize their own agency.
Footnotes
Appendix
Selected Codes.
| Code | Description |
|---|---|
| AUDIENCE | Audiences of competitions, accelerators, consultants, grants, investors, public, sales |
| BMC | Business model canvas |
| DESIGN_BATTERY_LIFE | Requirements for battery life |
| DESIGN_BATTERY_LIFE_18m | 18 month battery life |
| DESIGN_BATTERY_LIFE_1y | 1 year battery life |
| DESIGN_BATTERY_LIFE_2y | 2 year battery life |
| DESIGN_BATTERY_LIFE_5y | 5 year battery life |
| DESIGN_BATTERY_LIFE_6m | 6 month battery life |
| DESIGN_BATTERY_LIION | Li-Ion |
| DESIGN_BATTERY_REMOVABLE | AA, AAA |
| DESIGN_BATTERY_TURBINE | Turbine for recharging; turbine, generator |
| DESIGN_CONSTRAINTS | External design constraints |
| DESIGN_FORM | Shape form of prototype or product |
| DESIGN_FORM_ADAPTER | V1 attachment form factor |
| DESIGN_FORM_CLEANABLE | No fins so it can be cleaned; fins, ribbing |
| DESIGN_FORM_FINS | Fins or ribbings. "We may be able to increase this surface area by creating ribbings, similar to a heat sink" |
| DESIGN_FORM_SHOWERHEAD | V2 showerhead form factor |
| DESIGN_FORM_UNOBTRUSIVE | Unobtrusive design; unobtrusive, uninterrupted vs. visible |
| DESIGN_IOT | Integrated WiFi; smart, internet, IoT |
| DESIGN_PARTNERS | Fixture/fitting partners for designing showerheads |
| DESIGN_PARTNERS_ACQUISITION | Fixture/fitting partners potentially interested in acquisition |
| DESIGN_PARTNERS_LICENSEE | Fixture/fitting partners interested in licensing technology |
| EVIDENCE | Evidence offered for claims, including external studies, pilot studies, internal residential data, and third-party data |
| FUNDING | Data related to funding |
| MARKET | Market for the device |
| PITCH | Pitch decks and video pitches |
| PRODUCTION | Related to how they produce products (3D printing, components, assembly) |
| SUPPLY | Related to suppliers (sensors, chips, supply chain) |
| VP | Value proposition |
Funding
The author disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This work was supported by a grant from the IC2 Institute.
Declaration of Conflicting Interests
The author declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.