Abstract
Platform governance that is driven by external policymakers and researchers is often disconnected from how and when technology companies actually make decisions about their products. This misalignment creates challenges for meaningful oversight and regulation, as external actors cannot see the internal processes that shape platform design and governance. This article explores the internal dynamics of product development, from prototyping through iteration, and how governance considerations are incorporated or excluded at various stages. Arguing for a reintegration of social science and academic expertise into product decision-making, I propose an updated framework that bridges external governance objectives with the realities of platform power and product design.
Keywords
Over the past decade, technology platforms have become central actors in shaping public life—governing what we see, say, and share online. Yet as their influence has grown, traditional mechanisms of public accountability have struggled to keep pace. The clear lines of authority that once defined public policymaking—rooted in social science literature, policy legislatures, and legal systems—have become blurred. Decisions about safety, speech, privacy, and identity are increasingly made not by public institutions, but by cross-functional teams deep inside private companies. These decisions emerge through product road maps, engineering trade-offs, and engagement metrics—often long before external scrutiny is possible.
This article is motivated by a simple but urgent observation: Academics and policymakers frequently lack the tools and vantage points to engage meaningfully with the internal dynamics of technology companies. Even as concerns about online harm, disinformation, youth safety, and algorithmic accountability mount, external actors are often left guessing how and where decisions are made. As responsibility for those decisions effectively devolves to the monolithic platform, guidance or regulation may become technically unfeasible, with results that are often short-sighted and, in some instances, actively dangerous to the rights and agency of the populations the platforms mean to serve. For example, policymakers pushing for age verification often lack clear insight about how platforms will need to actually design and deploy these systems across multiple teams, leaving them guessing whether their proposed age verification laws truly protect minors or create a privacy minefield (Vyanams Strategies 2025). Similarly, external researchers looking to improve the safety of large language models may not understand how these changes will be implemented by different parts of the organization, and the mechanisms that will be needed to coordinate responses across different teams (Majumdar et al. 2025). Without understanding how AI tools are trained and updated internally, they cannot effectively address unexpected harms like biased content removal or censorship of vulnerable groups. Finally, child advocacy groups and regulators frequently lack insight into how platforms internally define and moderate harmful content aimed at children, such as grooming or violent imagery, making it difficult to assess the effectiveness of safety measures or identify persistent risks.
The result is a growing mismatch between the scale of platforms’ societal impact and the structures available to influence them. Here, I hope to:
(a) offer a grounded, insider-informed view of how tech products are actually made—mapping the product development life cycle, identifying key roles and decision points, and analyzing the organizational dynamics that shape whether governance concerns are surfaced or sidelined.
(b) equip external actors—regulators, researchers, civil society groups, and others—with a clearer sense of how to engage more effectively with platform companies on issues of public interest, safety, and responsibility.
Initially informed by my decades-long experience in leadership roles spanning safety and policy within some of the most influential technology companies, these insights have been validated by my work at Vyanams Strategies (Vys), a product advisory firm that helps companies build better products for children and teens by translating regulation and social expectations into practical product design. We partner with tech companies to evaluate youth risk across the product life cycle, translate regulatory and academic guidance into actionable product design and policies, and build scalable, compliance-ready solutions that improve platform safety for children and teens. Our work suggests that thoughtful governance that truly understands the complexity of product development could allow for greater and welcomed influence on design decisions.
What follows is not a critique of individual products, but an examination of the internal architectures—organizational, procedural, and cultural—that shape governance before a product ever launches. By tracing the life cycle of product development and identifying the structural barriers that limit the impact of external insights, I argue for ending the trap of air-gapped governance, a term from the cybersecurity world that I use in this article to explain the isolation of regulatory, academic, and civil society perspectives from the realities of how products are actually built. This disconnect leaves well-intentioned governance efforts struggling to intervene effectively, too often arriving after key design decisions have already locked in risk. We contend that for platform governance to be effective—especially for vulnerable users like children and teens—it must be embedded within the product development life cycle, not bolted on after the fact.
The Evolving Landscape of Policy and Authority
Over the past few decades, the center of gravity for policymaking has shifted—from public institutions to private firms, from formal regulation to product design. In the late twentieth century, particularly through the 1980s and 1990s, social scientists often played a direct role in shaping public policy within stable infrastructures, i.e., research institutions, regulatory agencies, courts, and ministries. These bodies were built for deliberation, transparency, and consistency (MacKenzie and Wajcman 1999).
But global technology platforms have redrawn that landscape. Today, decisions that carry deep policy weight—how speech is ranked, how privacy is protected, how identity is verified—are increasingly made inside companies, through iterative changes to features, defaults, and code. The institutional apparatus that once accompanied policymaking has not kept pace with this shift. Without research institutions or governments making parallel investments in public technological literacy or accountability infrastructure, product development has quietly become a form of governance.
This change has introduced a high degree of opacity in platform governance. Product choices now function as governance decisions without the procedural safeguards, transparency, or public input that formal rulemaking requires. The pace of innovation routinely outstrips regulatory oversight. Questions that once sat with legislatures or agencies, such as what constitutes age-appropriate design or how civic integrity should be protected, are now answered by cross-functional teams buried deep within companies and often operating without public debate or shared standards.
And yet, it would be a mistake to imagine these firms speak with one voice. Governance inside tech companies is fragmented and distributed across legal, product, engineering, policy, and trust and safety teams, each with its own mandates, incentives, and constraints. Where, then, does a platform’s “policy” reside? In the law of its markets? In user experience flows and trust policies? In the architecture of its recommendation systems? In the training data of its models? Tech companies now operate—often by necessity—as hybrid institutions: part research lab, part infrastructure provider, part market actor, and part regulator. But they do so without the checks, norms, or democratic oversight that traditionally accompany such roles. External efforts to influence platforms often miss the mark not because they’re misguided, but because they misunderstand the machinery they’re trying to move.
What’s needed is a more organizationally literate theory of platform governance: one that begins not with external outcomes, but with the internal conditions of technology production. Such a theory would focus on how decisions are made, by whom, and within what structures. It would take seriously the reporting lines, incentives, metrics, and workflows that shape risk long before a product ships. Only by grounding our understanding in the realities of how platforms operate can we design governance strategies that hold them accountable and identify where influence is still possible.
Inside the Machine: How Products Are Really Made
The product development life cycle
To understand how platform governance actually plays out, we must first understand how technology products are built in practice: the day-to-day decisions, trade-offs, and timelines that define their development. While researchers generally focus on the impact a product has on its users once it is live, relatively few examine the organizational rhythms that precede public launch. Yet it is in these quieter phases—brainstorming product features, writing specs, negotiating a minimum viable product (MVP), and aligning road maps—where long-term governance possibilities are either enabled or foreclosed.
Understanding this machinery—the life cycle, the staging, the roles—allows us to see platform governance not as a matter of values alone, but also as one of timing, influence, and institutional structure (see Figure 1). Decisions that shape global speech norms, safety protocols, and power dynamics online are often made quietly, in Jira tickets and product review decks, long before policymakers or academics are ever aware something is being built. Any theory of platform governance that ignores the rhythms and realities of product development is missing the core terrain on which these trade-offs are navigated.
The Product Development Life Cycle
Blue sky ideation
Product development typically follows a set of iterative phases, though the boundaries between them are rarely neat. A feature or product idea may begin in what’s often called the blue sky phase: a period of open ideation unconstrained by technical feasibility or policy requirements. This is when new bets are seeded, especially in companies with strong founder-led cultures, or when teams are given room to innovate. Ideas may be driven by executive strategy, shifts in market opportunity, user feedback, or simply a compelling internal prototype. These concepts move into the exploration phase, where they are sized, scoped, and, crucially, translated into language that engineers, designers, and leadership can use to evaluate investment.
Prototyping/minimum viable product (MVP)
Once an idea passes initial scrutiny, it enters prototyping or development of a minimum viable product (MVP). Because MVPs are typically low-visibility and high-urgency, critical governance decisions get locked in without broader scrutiny at this stage, making it one of the most consequential yet overlooked phases of the product life cycle. Yet this moment is when engineering resources are allocated, metrics are proposed, and the actual technical infrastructure begins to take shape. In the MVP or prototyping phase, the product shifts from idea to artifact. Product managers, engineers, and designers work quickly to define a stripped-down version of the feature that delivers core functionality with minimal effort. Key design and architecture decisions get made here—how users are intended to interact, what behaviors are allowed or blocked, what data are necessary to power these experiences—and success metrics are defined in terms of value, engagement, growth, receptiveness of the market, and ultimately revenue.
Validation
During validation, early versions are often tested internally (“dogfooded”) or externally, with select users in controlled environments. In this phase, hypotheses about user behavior are tested through A/B experiments, instrumentation, and small-scale rollouts. By this point, key product choices have been made: what the feature does, how it works, and who it serves. In validation, a team’s primary goal is to de-risk the upcoming launch. Are users engaging with the feature as expected? Are the metrics trending in the right direction? Is the system technically stable at scale?
Teams run A/B tests, gather qualitative and quantitative feedback, and build dashboards that track what leadership wants to see: i.e., usage, retention, and impact on company-level goals. But the nature of validation may constrain visibility into risk. Safety concerns, cultural misalignment, or exploitation vectors are unlikely to surface in test environments unless the team knows to look for them and/or has the right instrumentation to detect them. As Lewis and Christin (this volume) argue, metrics like engagement are politically constructed signals shaped by the very actors who depend on them. This vicious cycle reinforces engagement as the primary indicator of success, even in spaces where governance concerns should take precedence. Governance teams may be consulted here, especially if the feature touches on sensitive domains, but their feedback is often expected to “unblock” the path to launch, not pause or redirect it.
Pre-launch
The pre-launch phase brings in a flurry of activity: go-to-market planning, legal review, localization for international audiences, and final quality assurance. This is also when policy and trust and safety teams are most extensively looped in, tasked with flagging potential risks, clarifying enforcement needs, or proposing mitigations. But by this time, the product is often structurally fixed. Budgets are committed, code is locked, and executive eyes are on growth potential. Feedback from policy or safety teams, even if thoughtful, can be perceived as blockers or burdens unless it directly aligns with business goals, regulatory necessity, or public relations concerns.
Launch
The launch phase marks the moment the product moves from internal to public space. It is a pivotal transition: from experiment to commitment, from theory to reality. More teams are involved now, each with a role to play. But structurally, the launch moment is often too late for significant change. Communications and marketing teams shape the external narrative: what the feature does, how it improves user experience, what the company wants the public to know. Messaging is tightly managed to emphasize optimism and innovation, especially if the feature enters a contested or sensitive space. Public policy teams prepare briefing documents and talking points for government stakeholders and advocacy partners. If the feature risks scrutiny, they may coordinate pre-reads or direct outreach. The legal team stays on call to monitor exposure and ensure that product documentation—FAQs, blog posts, and terms updates—remain compliant, if not always fully explanatory. Trust and safety teams enter a monitoring mode, ready to track incidents and triage responses. Product teams are focused on execution. The window for meaningful governance influence has narrowed to the size of a public relations crisis.
Iteration and optimization
Once launched, products enter an ongoing cycle of iteration and optimization. This period is when real-world use reveals edge cases, failure modes, and sometimes acute harms. It’s also when public scrutiny kicks in through media reporting, civil society alerts, or government inquiries. But by then, teams are already focused on new feature sets or expansion goals. Safety patches tend to be reactive, not anticipatory.
Who gets involved and when
A brief glossary
This glossary describes high-level roles. In practice, many actors wear multiple hats beyond the strict definition of their job scope (see Figure 2): Imagine a powerful public policy team making product change requests because of the pressures they anticipate from government actors, or an engineering team flagging potential areas of legal risk in what they are being asked to code.
Growth and acquisition teams design and run strategies to attract new users, increase engagement, and retain customers throughout the product life cycle.
Product managers, who are responsible for the overall strategy and success of a product, define what should be built and why.
User researchers conduct studies to understand user needs, behaviors, and motivations to inform product design and development.
Engineers write the code and build the technical infrastructure that brings a product to life.
Data scientists analyze product usage data to inform iteration, help evaluate experiments, and monitor key metrics.
Product designers, focusing on usability and aesthetics, create the look, feel, and overall user experience of a product.
Product marketing managers are responsible for communicating the value of a product to the market and driving its adoption by users.
Trust and safety teams work to protect users from harm and abuse by creating and enforcing policies on content and conduct.
Legal teams ensure that the company and its products comply with all relevant laws and regulations.
Public policy teams engage with governments and other external stakeholders to shape laws and regulations that affect the company and the tech industry.
Communications teams manage the company’s public image and messaging through media relations, social media, and other channels.
Moments in the Product Life Cycle Where Different Teams Get Involved
Throughout this life cycle, different teams are brought in at different stages. Growth and acquisition teams provide product managers with preliminary hypotheses about what would grow the business. Product managers usually own the process from start to end, acting as the connective tissue across functions. User researchers provide many of the initial insights into what users are looking for, common complaints with how the product currently functions, and innovative product ideas to consider. Also involved from early stages, engineers, data scientists, and product designers shape not only what is built but also how users will interact with it. Along the way, product marketing managers get involved, beginning to shape how the product is intended to land in the market, a role that gives them some degree of influence over the product development process.
On the other hand, trust and safety, legal, public policy, and communications teams are rarely directly involved from the beginning. Instead, they are invited into the process once a product is already well underway—at best, around the validation stage previously referenced. They are then asked to solve for potential safety and compliance challenges, without altering the fundamental shape of the thing being built. These teams are regularly encouraged to “manage by influence”—to shape the attitudes, viewpoints, and behaviors of others through positive methods, without any formal authority. Their ability to influence outcomes depends heavily therefore on organizational politics, executive attention, and the perceived salience of the risk.
Building in opportunities for governance
Recognizing that these internal governance interventions arrive late in the product cycle, many teams like trust and safety, legal, and privacy work upstream by building structures that surface risks to the core teams—the growth and product teams—earlier in the life cycle.
Product safety guidance
One of the more durable tools is product safety guidance, that is, the shared set of principles, red lines, and baseline expectations for how new products should be built. These may include thresholds for risk reviews (e.g., if the product enables messaging, ranking, or anonymity), must-have features like reporting tools or age gating, and guardrails around data sharing or algorithmic personalization. The advantage of written guidance is that it creates consistency and can travel across teams. Teams can also manage by influence to urge product and growth teams to study this documentation even when they are in the blue sky stage. However, the weakness of documentation is that it is static, a death knell in fast-moving environments. These documents risk being seen as legacy paperwork, especially without someone at the table to actively enforce them. Perhaps they are useful for new hires to the company, but they are easy to ignore under pressure and rarely enforced unless leadership insists.
Privacy and safety review
Another common structure is the privacy and safety review, sometimes formalized as a recurring forum where product teams preview what they’re building. These sessions allow legal, privacy, and trust and safety teams to flag concerns, recommend mitigations, or in rare cases, block launches. When done well, they offer a rhythm of accountability and a visible checkpoint for governance inputs. But much depends on how they are set up. If they are positioned as advisory rather than gatekeeping, these teams may come late or not at all. If they are overloaded with low-risk reviews, they can become bureaucratic bottlenecks. And unless reviewers are granted real authority, these meetings risk becoming performative: a stop on the way where product teams “check the box” or perhaps hold back one aspect of the product from launch, without materially changing what they have built.
External feedback
Some teams invite external feedback from academics, civil society groups, or advisory councils throughout the development cycle. This process can surface valuable perspectives, especially on complex or global risks, and create a public record of engagement. However, external input often arrives misaligned with internal timelines and constraints. Even experts in technology policy may not understand the technical architecture or broader product goals, and their recommendations can feel abstract or impractical to fast-moving teams. Underrepresented groups like youth populations cannot meaningfully engage with the product without being brought along earlier in the process (Vyanams Strategies and J 2024). More importantly, there is rarely a mechanism that requires acting on this feedback. When integrated early and when internal champions help translate feedback into actionable terms, external expertise can influence road-map decisions, especially when the feature is high-risk or under regulatory scrutiny.
Embedded liaisons
Another route is to embed governance voices more directly into the process. Some companies embed liaisons in trust and safety or policy to specific product areas, especially where risk is high or reputational exposure is likely. These liaisons attend early-stage meetings, offer design input, and raise red flags long before formal reviews. In the best-case scenario, they become trusted collaborators who can advocate for safety features without slowing momentum. But their influence depends on organizational culture and leadership support. Without structural authority or clear escalation pathways, embedded roles can be reduced to “soft advisors” who are expected to help but not empowered to change direction.
Risk tiering and governance metrics
Risk-tiering systems are another governance tool. In these frameworks, product features are categorized by risk level, typically based on reach, sensitivity, or likelihood of abuse. Each tier corresponds to a required level of review, documentation, and sign-off. A Tier 1 feature might require executive oversight and external consultation; a Tier 3 feature might move forward with basic safeguards. Tiering helps triage attention and ensures that the riskiest launches don’t fly under the radar. But classification can be politicized. Product teams have an incentive to understate risk in order to avoid the process, and reviewers may disagree on how to score novel or ambiguous cases. Without clear enforcement, risk tiers become suggestions rather than gates.
Some companies try to align incentives more directly, incorporating governance metrics into their objectives and key results. For example, they may commit to reducing the number of reports about harm, driving down spam rates, improving reporting flow usability, or closing policy gaps in a new region. When teams are measured (and rewarded) based on these metrics, they’re more likely to prioritize integrity work alongside growth or engagement. But metrics can also distort behavior. If success is poorly defined, or if the metric is gamed to show progress without substance, governance becomes a numbers game. Moreover, these integrity key performance indicators are often overshadowed by commercial ones, especially in leadership reviews or funding justifications.
Dedicated integrity headcount within product team
Finally, one of the clearest signals of commitment is the inclusion of dedicated integrity headcount or budget within product teams. When trust and safety leads or policy engineers are embedded in a launch team from day one, they are positioned to shape design choices, raise implementation constraints, and flag policy mismatches before they become launch-blocking issues. This model treats governance as part of product development, not something layered on later. But it’s resource intensive, and in lean teams, this kind of staffing is often the first to go. Without a clear return on investment, governance work is seen as discretionary, something to cut when timelines are tight or leadership changes.
Each of these governance structures is a potential lever. However, none are foolproof. Their effectiveness depends on timing, authority, and organizational will. What they offer, at best, is a set of doors: structured opportunities to name risks and shift course before it’s too late.
The Trap of Air-Gapped Governance
The concept of air-gapped governance borrows from cybersecurity, where an “air gap” is a defensive architecture; that is, a computer or network is physically or logically isolated from other systems to reduce the risk of compromise (Park et al. 2023). Air-gapped systems are used in nuclear facilities, critical infrastructure, and classified environments: contexts where the cost of breach is too high, and external access must be severely limited. The trade-off, of course, is that air-gapped systems are difficult to update, monitor, or adapt in real time. They are secure by virtue of their separation but constrained by it too. Freelon and colleagues’ (this volume) notion of the “post-API age” captures a parallel barrier: Even as platforms play a regulatory role, they restrict external research access, leaving civil society and academia in a state of what they call “data precarity.”
In platform development, both internal and external governance teams often occupy a similarly isolated position. Trust and safety, legal, public policy, and other responsible innovation roles may be formally embedded within the organization, but they are often structurally disconnected from the product environments they’re meant to help guide. They are organizationally present, but informationally air-gapped—cut off from early product conversations, road-map trade-offs, and iterative design loops. This situation produces governance that is fundamentally reactive. By the time policy or safety concerns surface, core decisions like friction reduction, engagement metrics, and design incentives have already been locked in. Without infrastructure for early-stage input, governance becomes a blocker, not a builder. Even well-founded concerns can be framed as “slowing the team down” or “pushing us off goal.”
External governance actors like academics or policymakers are even more air-gapped than their internal counterparts. They are expected to provide oversight, critique, or guidance on systems they cannot inspect, timelines they do not control, and decisions made through processes they rarely witness. Their analyses often rely on outdated information, well-meaning but seriously incomplete whistleblower disclosures, legal discovery documents, or company-constructed blog posts that reveal little about internal intent or constraints (Simpson and Conner 2021).
These external actors typically engage platforms through formal comment processes, public reports, or policy advocacy. Such interventions are often asynchronous with product timelines and disconnected from the internal decision points that shape risk. Regulators frequently rely on slow-moving enforcement mechanisms or generalized guidance that product teams struggle to map onto their day-to-day work. Academic researchers and civil society groups may offer nuanced critique or innovative proposals, but without access to the operational context (e.g., technical constraints, team resourcing, or market demands), their recommendations can feel misaligned or too abstract to act on.
The effects of this air gap become more acute in high-velocity product cultures. Launch cycles move quickly. Governance cycles do not. Product timelines often leave little room for cultural nuance, regulatory consultation, or inclusive user research. Governance, unlike engineering or design, lacks a standardized layer of implementation. It shows up in different places: user experience copy, backend logic, classifier thresholds, enforcement tooling. And because tech companies operate simultaneously as builders, markets, and de facto regulators, internal authority is contested. Project managers, lawyers, engineers, researchers—each may claim expertise, but none sit at the center of it all.
Just like internal governance teams, external actors are asked to influence outcomes without proximity to the decisions that matter most. The result is a persistent mismatch: Platforms continue to evolve quickly and quietly, while governance remains reactive, delayed, and often excluded from the rooms where design is decided. As a result, even well-founded interventions in the form of regulation, research, or public pressure can fail to resonate with the operational logic of platform development. The further governance actors are from understanding the mechanics of decision-making, the more likely their efforts are to be perceived as naive, misaligned, or easy to ignore.
This is the trap of air-gapped governance: It is a system in which those responsible for managing ethical and social risk are structurally removed from the sites of decision-making that generate that risk. As Meares and Tyler (this volume) argue, an ethical work climate where governance concerns are embedded in culture, not just compliance protocols, is essential to fostering trust and legitimacy, both within and outside the firm. Like its cybersecurity analogue, air-gapped governance is often rationalized as protective, that is, as a way to clarify roles or manage risk. But in a fast-moving, iterative development culture, this gap leaves governance brittle, slow, and out of step.
What Gets Missed: Governance as a Source of Positive Imagination
Much of the conversation about governance so far has centered on preventing harm: reducing abuse, managing legal risk, minimizing fallout after a crisis. These are real and urgent responsibilities, especially in an environment where features can scale globally overnight. But when governance is framed solely as a brake, it not only limits influence, it forecloses possibility. Some of the most meaningful opportunities to build safer, more inclusive, and socially valuable products are missed when governance is treated as a reactive function rather than a creative one.
Trust and safety, policy, and responsible innovation teams often have deep insight into how marginalized users experience the platform. They are closest to the harms but also to the unmet needs. They see where reporting flows break down, where product assumptions exclude entire user groups, where friction could be added to reduce anxiety, or where support could be offered to increase belonging. These teams hear directly from children, caregivers, moderators, educators, and civil society actors. When they’re given upstream access, they don’t just flag risks; they help teams imagine features that work better for more people.
There is precedent for this. Governance-adjacent teams have helped seed important product improvements: teen well-being features that support screen-time regulation, prompts that encourage users to reflect before posting harmful content, safety nudges that reduce exposure to unsolicited messages, and more transparent moderation flows that build user trust. These interventions would not show up through core metrics; rather, they need to emerge from people focused on care, fairness, and long-term resilience.
Yet these ideas often struggle to gain traction, not because they lack merit, but because the governance function is structurally sidelined. When trust and safety teams are brought in only to “poke holes,” they’re cast as constraints, not cocreators. When policy or privacy input is treated as a gate rather than a partner, its generative potential is lost. Governance is expected to fix what’s already been built—not ask more foundational questions about what should be built at all.
This sidelining also extends to external voices. Social scientists, civil society groups, and domain experts often offer insight that internal teams can’t generate on their own. They bring knowledge of vulnerable populations, contested social dynamics, and historical harm patterns that can expand the imagination of what a product could and should do. For example, Pineda (this volume) shows that the “first surveillance” conducted by parents plays a foundational role in shaping children’s notions of privacy and safety. These social dynamics—what he calls the moral economy of the family—should inform internal governance decisions but often go unacknowledged.
If these experts are consulted only after the road map has been fixed—too late to meaningfully shift the problem definition or product goals—their input can seem tangential, misaligned, or unwelcome. What gets missed, then, is not just harm mitigation. It’s possibility: possibility to design differently, to broaden who a product is for, to embed care and fairness into the core of the user experience. Zuckerman and Brickman (this volume) suggest middleware as one such intervention, an approach that reconfigures control and safety at the user level, guided by a “theory of change” that treats users as active participants in shaping platform experience. If governance is to be more than a backstop, it must be structurally positioned to ask foundational questions early, translate across domains, and open up the design space, not just close it down.
Bridging the Gap: How Academics and Social Sciences Can Reintegrate into Product Decision-Making
If governance is going to function at the pace and scale of modern technology, it cannot remain air-gapped from product, from design, or from the knowledge systems that exist outside platforms. For academics and social scientists who want to shape the future of digital life, the question is not just what research to produce but where to intervene, when to speak, and how to make their case. The answers to these questions require moving beyond critique and toward deeper organizational literacy: understanding the internal dynamics of tech companies and adapting strategies to fit the way products are actually built.
The first shift is to understand the organizational chart and the product road map. Not all teams are equal. Not all moments in the product life cycle are open to influence. External actors will often direct their efforts toward pressuring hapless public policy teams, publishing op-eds, or submitting reports to regulators. These can be important levers, but they rarely move upstream product decisions. Scholars who want to shape design must learn how decisions are sequenced internally: who owns which surfaces, when features are scoped, what gating reviews exist, and where informal veto power resides. Influence flows through product managers, engineers, designers, and operations leads, not just policy liaisons or communications teams. Timing matters just as much as insight.
Second, academics must learn to make the case in terms platforms recognize. This advice is not a call to abandon values, but rather to translate them into logics that resonate with internal decision-makers. Instead of abstract appeals to ethics, researchers can present cost-benefit trade-offs, risk management frameworks, or long-tail metrics tied to user trust, retention, or reputational resilience. A finding that “improves safety for minors” might struggle to gain traction on its own. Yet the same finding will resonate when framed as reducing incident-driven enforcement costs, increasing user satisfaction, or aligning with upcoming regulatory standards. It now enters the realm of practical influence.
This approach also means rethinking timelines. Traditional academic research often unfolds over months or years, while product timelines can move from prototype to launch in a matter of weeks. To be effective, governance-minded scholars must engage earlier and faster, perhaps by structuring work in shorter feedback loops, building reusable templates or checklists, and contributing at moments when decisions are still open. This work also requires deeper collaboration with internal governance teams, many of whom are eager for research input but constrained by bandwidth and internal legitimacy. When researchers work with these teams as thought partners, not just external critics, they can help shape priorities from the inside out.
Finally, this is a call to move from critique to co-design. Naming harm is important. But naming alone does not change road maps. To be effective, governance advocates must also be willing to participate in the messy work of building: proposing alternative designs, stress-testing ideas in context, and helping product teams navigate trade-offs between safety, usability, growth, and global scalability. It requires entering the room with a mindset of shared problem-solving, grounded in values but attuned to constraints.
In short, reintegration is possible, but it requires more than publishing papers or sending feedback forms. It requires fluency in organizational dynamics, humility about one’s positionality, and a long-term commitment to embedding governance into the processes that define what tech becomes. The tools of social science—empathy, systems thinking, power analysis—are urgently needed in the earliest phases of exploration, before the future is locked in.
Conclusion
As platforms increasingly function as de facto regulators of digital life, researchers and regulators face a crucial challenge: how to produce knowledge that not only diagnoses harm, but also influences the systems where decisions are made. This article has argued that governance on tech platforms is not simply a matter of formal policy or stated values. It is embedded in product development processes, shaped by organizational structure, and driven by internal incentives. To meaningfully engage with platform governance, researchers and regulators must account for these internal dynamics: how features are built, who holds decision-making power, and when interventions are most likely to succeed.
For scholars of technology, media, law, and social science, this approach requires a shift in posture. Research that seeks to influence platform outcomes must move closer to the mechanics of product development—understanding how teams are structured, how timelines unfold, and how governance concerns are translated (or lost) within engineering, design, and business contexts. It means learning to speak across institutional languages: translating normative goals into frameworks that resonate with internal actors, from product managers to privacy lawyers to machine-learning leads.
This article offers a hopeful early road map for that kind of work. By grounding governance in the realities of the product life cycle, we can better identify the points where influence is possible, whether through co-design, early-stage feedback, embedded collaboration, or organizational scaffolding that elevates public-interest concerns. Researchers are uniquely positioned to support this shift. They bring critical perspective, methodological rigor, and often a deep understanding of marginalized or overlooked user groups. But to move from critique to impact, they must engage on the terrain where product decisions are made, not after the fact, but from the start.
At Vys, we help translate between these worlds, supporting companies in making sense of regulatory and social obligations, while also helping external stakeholders engage more effectively with product realities. What is clear from that vantage point is that platform governance will remain elusive if treated as a purely external matter. It must be understood and reimagined as an internal process shaped by the same tools, trade-offs, and tensions that define how technology is built. For external experts and policymakers, this opens up a new kind of opportunity: not just to analyze platforms from the outside, but to inform their internal organizational incentives.