When DAUs go flat and leadership wants a fix fast, the instinct is to jump straight to “here’s what I’d build.” That’s exactly the trap Monday’s challenge was testing. Here’s the order that actually works: Context, not just clarify. Don’t ask what success looks like. Ask what’s actually fixed and what’s negotiable. What’s the timeline leadership expects. What’s already been tried. The constraints ARE the case. User, specifically. Not “users” in the abstract. The exact segment who signed up and stopped opening the app. What did they expect when they joined, and where did the app stop earning their time. Problems, three to five of them. One theory (“gamification is weak”) is a guess. Five named drop-off points is a map. Segment the data, name what you find, before touching a single solution. Solutions, plural, then prioritized. Options first. Then defend one. The defending is the interview. The options are proof you didn’t jump to the first idea in your head. Measure in layers. Did the fix ship. Did DAUs actually move. Did the users you talked to feel like the app finally got them.

Pick the closest one, or tell us your specific version in the comments.

What’s the PM interview question that scares you most? The one you hope they don’t ask. Estimation? “Design an app for X”? “Tell me about a time you failed”? Diagnosing a metric with barely any context? Drop it below. No judgment. This is a practice room, not an interview. I’ll go first: mine used to be the vague product-design ones, “design a better alarm clock,” because the openness made me freeze. I’ll share how I got unstuck in the comments.

A lagging indicator tells you what already happened. Revenue. Churn. Monthly active users. By the time it moves, the cause is weeks in the past. A leading indicator is the early signal that predicts it. For a habit app, “habits completed in week one” is a leading indicator for “still subscribed in month three.” One is a rear-view mirror. The other is a headlight. Why this matters for you: if you only watch lagging metrics, you’re always reacting late. If you can name the leading indicator for your product, you can act while there’s still time to change the outcome. Try this: pick any product you use. What’s the one early behavior that probably predicts whether someone sticks around? That’s its leading indicator. Comment yours, and I’ll react to a few.

There are two kinds of product decisions. Ones that are correct and ones that get adopted. The best teams know those aren’t the same thing and plan for both. The Correct Decision answers: does this solve a real problem? Is the UX sound? Does it ship on time? The Adopted Decision answers: does this fit inside how users already think and move? Is the behavior change we’re asking for smaller than the value we’re delivering? Would someone who’s half-paying attention still get it? Most product processes are very good at the first one. Almost none of them formally account for the second. A quick check I run before anything ships: 1. What does the user do today, step by step? 2. Which of those steps does the new thing replace? 3. How many new decisions does it introduce that didn’t exist before? 4. Is the value obvious before the user has learned the new behavior, or only after? If the answer to #4 is “only after,” you have a retention problem waiting to happen, not an adoption problem.