Product Ethics & Responsible Innovation

Ethics Impact Assessment Core Method

Use when: evaluating a new feature, policy change, or product decision for potential harm before committing to build.

Run through five lenses for any significant product decision:

1. User harm — Could this feature cause direct harm to users? Consider financial loss, privacy violation, psychological manipulation, addiction reinforcement, or physical safety. Think about vulnerable populations: children, elderly users, people in crisis, users with low digital literacy. The question is not "will most users be harmed?" but "could any reasonable user be harmed, and how badly?"

2. Misuse potential — How could bad actors use this feature? If you build a messaging feature, it can be used for harassment. If you build a recommendation system, it can create filter bubbles. If you build identity verification, it can enable surveillance. Design for the adversarial case, not just the happy path.

3. Second-order effects — What happens when this scales? A feature that works fine for 1,000 users may cause problems at 1 million. A recommendation algorithm that's slightly biased becomes systematically discriminatory at scale. Network effects amplify both good and bad outcomes.

4. Power dynamics — Does this shift power toward or away from users? Features that remove user control (auto-enrollment, hidden settings, complicated opt-outs) shift power toward the company. Features that increase transparency, portability, and user agency shift power toward users.

5. Reversibility — If this turns out to cause harm, how easy is it to undo? Data collection is hard to reverse. Algorithmic decisions that deny loans or jobs create lasting damage. Addictive patterns that users have integrated into their behavior are hard to walk back. Irreversible harm demands higher scrutiny.

Document the assessment. Share it with the team. If any lens raises concerns, discuss mitigation before proceeding — not after launch.

Dark Pattern Audit Core Method

Use when: reviewing existing product flows for manipulative design, or evaluating a proposed feature for dark pattern risk.

Dark patterns are design choices that trick users into actions they didn't intend. They boost short-term metrics while eroding trust. Common categories to audit:

Confirmshaming — Making the opt-out option emotionally loaded ("No thanks, I don't want to save money"). The test: would the user feel manipulated if they noticed the framing? Replace with neutral language.

Roach motel — Easy to sign up, nearly impossible to cancel. If subscription cancellation requires a phone call, a retention gauntlet, or hidden menu navigation, it's a roach motel. The test: is the exit path as clear as the entry path?

Hidden costs — Prices that grow during checkout through fees, taxes, or "service charges" not shown upfront. The test: does the user see the full cost before committing?

Forced continuity — Free trials that auto-convert to paid without clear warning. The test: would a reasonable user be surprised by the charge?

Misdirection — Visual design that draws attention away from choices the company doesn't want users to make. Pre-checked boxes, tiny unsubscribe links, or consent buried in walls of text. The test: does the visual hierarchy match the user's interests or the company's?

Privacy zuckering — Confusing privacy settings that default to maximum data sharing. The test: would a privacy-conscious user be able to configure their preferences without a law degree?

Run the audit quarterly. Walk through your core flows as a new user would. Document every instance where the design nudges users toward the company's interest over their own. Prioritize fixes by severity of harm and number of users affected.

Algorithmic Bias Review Specialized Method

Use when: building or evaluating any system that makes automated decisions about people — recommendations, scoring, matching, content moderation, credit, hiring, or risk assessment.

Algorithmic bias emerges when training data, feature selection, or optimization targets systematically disadvantage certain groups. The PM's role is not to audit the model's code (that's engineering/ML) but to define fairness requirements, set up monitoring, and own the decision about acceptable trade-offs.

Define fairness criteria before building. There are multiple mathematical definitions of fairness, and they often conflict. Equal opportunity (equal true positive rates across groups), demographic parity (equal selection rates), and calibration (equal accuracy across groups) cannot all be satisfied simultaneously. The PM must decide which definition matters most for the use case and document why.

Audit training data. If your training data reflects historical bias, your model will reproduce it. A hiring model trained on past hiring decisions will encode whatever biases existed in those decisions. A credit model trained on historical loan performance will reflect past lending discrimination. Ask: does this data represent the world as it is, or as it should be?

Monitor outcomes by group. Even a model that seems fair at launch can drift. Set up dashboards that track model outcomes segmented by protected characteristics. If approval rates, recommendation quality, or error rates diverge significantly across groups, investigate immediately.

Build human review for high-stakes decisions. Automated decisions about credit, employment, housing, healthcare, or legal outcomes should always include human review pathways. Users should know when an algorithm is making decisions about them and have a way to appeal.

Privacy-by-Design Checklist Core Method

Use when: designing any feature that collects, stores, or processes user data.

Privacy-by-design means building privacy into the product architecture from the start, not bolting it on after a data breach or regulatory notice.

Data minimization — Collect only what you need. For every data point, ask: what product decision does this enable? If you can't articulate a specific use case, don't collect it. More data means more liability, more attack surface, and more regulatory risk.

Purpose limitation — Use data only for the purpose it was collected. If users gave you their email for account recovery, don't use it for marketing without separate consent. Purpose creep is one of the most common privacy violations.

Retention limits — Define how long you keep data and delete it when the retention period expires. "We keep everything forever" is not a privacy strategy. Set retention policies per data type and automate deletion.

Meaningful consent — Consent should be informed, specific, and freely given. A 4,000-word privacy policy that nobody reads is not meaningful consent. Tell users what you're collecting, why, and what happens to it — in plain language, at the point of collection.

User control — Give users visibility into their data and control over it. Data export, data deletion, and granular privacy settings should be easy to find and easy to use. GDPR and CCPA require this; good product design demands it regardless of regulation.

Security defaults — Default to the most private option. If a profile can be public or private, default to private. If location tracking can be on or off, default to off. Let users opt in to sharing, not opt out.

Stakeholder Harm Matrix Core Method

Use when: evaluating a product decision that affects multiple stakeholder groups differently.

Map each stakeholder group against potential harms and benefits. Stakeholders include direct users, indirect users (people affected by users' actions), employees (content moderators, data labelers), communities, and society at large.

For each stakeholder-harm pair, assess: Likelihood (how probable is this harm?), Severity (how bad is the harm if it occurs?), Reversibility (can the harm be undone?), and Mitigation (what can we do to reduce risk?). High-likelihood, high-severity, irreversible harms demand the most attention.

The matrix makes trade-offs explicit. A feature that benefits 99% of users but causes serious harm to 1% is not automatically worth building. The PM must decide whether the harm to the 1% is acceptable, whether it can be mitigated, and whether the benefit to the 99% justifies the risk. Making this analysis visible prevents the common failure mode of optimizing for the majority while ignoring harm to minorities.

Ethical Escalation Framework Situational Method

Use when: you've identified a potential ethical concern and need to decide how to act on it within your organization.

Ethical concerns range from "this could be better" to "this is actively harmful." The response should match the severity:

Level 1: Design improvement. The feature isn't harmful but could be more respectful of users. Example: an opt-out flow that's harder to find than it should be. Action: propose the improvement in the normal product process. No escalation needed.

Level 2: Team discussion. The feature has potential for harm that the team should evaluate. Example: a notification system that could reinforce compulsive checking. Action: raise the concern with your product trio, run an ethics impact assessment, and document the decision.

Level 3: Leadership escalation. The feature poses significant risk that exceeds the team's decision authority. Example: a data practice that might violate privacy regulations. Action: escalate to product leadership and legal. Do not ship without explicit sign-off.

Level 4: Refusal. The feature would cause clear, serious harm to users. Example: a dark pattern designed to prevent cancellation. Action: refuse to build it. Document your reasoning. If overruled, escalate further — to the CEO if necessary. If overruled at every level, consider whether this is a company you want to work for.

The escalation framework protects PMs from the pressure to "just ship it." It provides a structured path for raising concerns without being seen as obstructive. The key is documentation: when you flag a concern, write it down. If the decision is to proceed despite the risk, make sure that decision is recorded and owned by someone with the authority to make it.