DM9: Growth engineering: referrals, sharing and lifecycle messages
Feature flags, growth experiments and ethics
🎯You'll be able to
Use feature flags to release and test growth features safely, and judge growth tactics against fairness and India's rules on dark patterns.
🏠The everyday picture
A restaurant trying a new dish offers it to a few tables first. If guests don't like it, the chef stops serving it tonight, without reprinting the menu.
📘What it really is
- Feature flags turn a feature on or off without a new release, for some or all visitors:
- gradual rollout (5%, 25%, 100%);
- experiments (a flag assigns A or B, DM7);
-
a kill switch when something goes wrong.
-
Flags need care: each one has an owner and an end date; old flags are removed so code stays simple.
-
Growth experiments follow DM7: hypothesis, primary metric, guardrails (complaints, unsubscribes, refunds, page speed), sample size, and a stop rule.
-
Ethics and law: some tactics raise numbers by tricking people. India's 2023 dark patterns guidelines (DM4) name false urgency, basket sneaking, confirm shaming, forced action, subscription traps, nagging and others.
- Real stock and real deadlines only.
- Opt-ins unticked; cancel as easy as joining.
-
No guilt-tripping buttons ("No, I don't care about savings").
-
A simple test: would the customer be glad they were treated this way if they understood it? If not, don't ship it.
- Long-term measures (repeat orders, complaints, unsubscribes) catch tactics that win this week and lose customers later.
📝A worked example
Input: a proposed "Only 2 left!" badge on every product page, to be tested behind a flag.
Steps:
- Check the claim: MittiMart has dozens of each item in stock; the badge would be false.
- Name the pattern: false urgency, listed in the 2023 guidelines.
- Replace the idea: show real delivery dates (the feature tested in Project 2), behind a flag, with guardrails.
Expected output: the badge is rejected before testing; the honest alternative goes to the experiment plan.
🌍Where it's used
- Product teams use flags for gradual launches and kill switches.
- Growth teams run flagged experiments with guardrails.
- Compliance teams review growth features against dark pattern rules.
📝Case scenario
A travel site showed "5 people are looking at this hotel" on every page, generated randomly. Bookings rose briefly; complaints and social media criticism followed when a journalist showed the number was fake. The feature was removed and replaced with real availability.
🖱️Try it
Find one growth tactic on an app or site you use (a timer, a badge, a pop-up, a pre-ticked box). Decide whether it's honest, and name the pattern if not. Success: a one-line verdict with a reason.
⚠️Common mistakes
- Flags that don't go away. Sign: hundreds of old flags in the code. Fix: an owner and an end date for each.
- Testing a dark pattern. Sign: "Let's A/B test a fake countdown." Fix: reject it before testing; a test doesn't make it fair.
- Short-term measures only. Sign: a tactic judged on one week's conversions. Fix: guardrails and long-term measures.
🛠️For your project
Project 2's experiment used a flag-like split to show the delivery date. Your capstone's design notes should say how each growth idea would be flagged, tested and checked against the guidelines.
✅Quick check
What's a kill switch?
Show the answer
A feature flag that turns a feature off immediately if something goes wrong.
Does testing a dark pattern in an A/B test make it acceptable?
Show the answer
No. If it misleads customers, don't build or test it.