Mohammad Reza Notes — Product Manager — marketplaces & e-commerce

The Color of a Day

Wed, 08 Jul 2026 00:00:00 GMT

Recently I built a productivity tool, Producktive — you can read there how it works. This note is about the part that came before: how I got to the idea in the first place.

I used to work a lot, but I saw no progress. Then I got into journaling — bullet journaling especially — and started writing down the tasks I did each day. At first just with a pen, marking the type of each entry: a square for a to-do, an "e" for an event. I wrote a lot. But it was hard to read a day at a glance, and the one thing I most wanted to know, the pages couldn't tell me: was this a productive day, or just a busy one? I was filling pages either way.

One random day, I thought about using colors instead. I started with two: black for grunt work — the tasks I had to do but saw no value in for myself — and blue for the meaningful ones. Right away it gave me something the marks never had: I could see the balance of a day, and I had a goal I could act on — more blue.

Then I felt I needed another color. Life isn't only about work — there are things you do just for yourself: seeing a friend, watching a movie, going for a walk. I gave those their own color, green, and the goal grew: more blue, and more green.

Red came last. Life isn't always kind — you get sick, something goes wrong, a day just falls apart, and you can't expect much of yourself. Red was for those days: not a failure to fix, just the truth of the day, marked and left behind.

For the first weeks, the pages came out mostly black. So I started changing how I actually spent my days — more blue meant more meaningful work, more green meant taking better care of myself. It worked. Over time, black became the minority.

I kept this up in a physical notebook for a couple of months, until I ran out of pages. I went looking for the same one and couldn't find it; the calendars I found weren't what I wanted. So it sat on my shopping list for a while, unresolved.

Around then I started using Claude, and within a week I could feel what it made possible: I could build the thing myself. So I did. I took the notebook and turned it into an app — Producktive. I worked it as a product first, then designed it, then wrote the code — all of it mine, end to end. And I built it the way I think products should start: small, a tight MVP, deliberately minimal so it stays easy to change later.

Of the ideas I had, this was one of the simplest — which is the point. Building something is easy now; building something with a reason to exist is the hard part, and a simple idea gives you nowhere to hide.

I'm still building it, and I'll probably release it as an app before long. For now it's a side project — my playground, the place I get to practice everything at once: product, design, and code. But underneath all of that, it's still doing the one thing the notebook did for me: at the end of a month, I can look back and see, in color, what my time actually added up to. I'd love to hear what you think.

Producktive

Wed, 08 Jul 2026 00:00:00 GMT

import ColorKey from '../../components/ColorKey.astro';

Most productivity apps start from the same assumption — that you have too little structure, and their job is to give you more. More projects, more priorities, more nested tasks, more streaks to protect. You arrive tired and leave managed. This app grew out of a paper journal I kept in four colors for a couple of months — here's how it started.

{/* TODO(owner): this links to /notes/the-color-of-a-day/ — update the slug/route if the origin article gets a different title or collection; the visible link text ("here's how it started") can stay. It 404s until that article exists. */}

Producktive starts somewhere else. It assumes you already do plenty; you just can't see it. The days blur, the effort disappears, and by evening you feel busy without feeling like anything happened. So it doesn't hand you a system to obey. It hands you a page to write on, and gets out of the way.

Logs are just logs

The whole product rests on one stubborn principle: logs are just logs. A daily log is a flat list of what happened — nothing linked, nothing nested, nothing scored. There is no schema quietly connecting today's entry to a goal to a project. The structure lives in the ritual of writing and re-reading, not in the database.

That sounds like a limitation. In practice it's the point. Nothing to maintain means nothing to feel guilty about maintaining. You can log for a week, skip three days, come back, and the app never scolds you or asks you to reconcile anything. It's a notebook, not a manager.

Four colors

Every entry gets one of four colors — the heart of the whole thing:

{/* The four-color key renders from — the CSS-swatch treatment the owner's note asked for, replacing the emoji list (zero-JS, on-brand). Labels and swatch colours live in the component against the --swatch-* tokens. */}

You don't analyze these in the moment. You just tag and move on. But over a month, the colors do something a to-do list never can: they show you the shape of your time. A wall of gray tells you the story of a month spent on other people's work. A healthy green streak tells another. The app never lectures you about the ratio — it just makes it visible, and lets you draw your own conclusion.

Looking back

Tagging in the moment is only half of it. The other half is looking back — and Producktive sets aside two moments for it: a weekly review and a monthly one.

Each pulls together the stretch you just lived. First the shape of it — the balance of colors across everything you logged, so it's clear whether the time ran mostly gray or leaned green and blue. Then the entries themselves, grouped by color: everything you did for yourself in one place, the meaningful work in another, the grunt work and the rough moments each in theirs.

That grouping is the part a plain list can't give you. Scrolling a month of entries tells you little; seeing them sorted into colors tells you exactly where your time went. No score, nothing to optimize — just your own time, laid out so the pattern is hard to miss.

What it deliberately isn't

Producktive has no project hierarchies, no dependencies, no priority flags, no gamified streak you'll panic about breaking. There are no goals to set and no plans to keep up — nothing that rolls up, nothing to carry forward. That restraint is a feature, chosen on purpose and defended every time it's tempting to add "just one more" structure.

Because the promise isn't that you'll finally get organized. It's quieter than that: at the end of a month, you'll be able to look back and see what you actually did — and feel, maybe for the first time in a while, that it added up to something.

That's the whole idea. A calm page, four colors, and a moment each week and month to look back and notice your own life. (The name hides a duck in it — you'll meet him in the quiet corners. He mostly just wants you to write today down.)

Everyone has a flywheel. Almost nobody can prove one.

Tue, 07 Jul 2026 00:00:00 GMT

The word shows up in almost every deck now. A ring of arrows, five or six boxes, each one supposedly feeding the next. The implication is always the same: our growth compounds on itself, so it will keep going and you can't catch us. Most of the time it's a diagram of hope, not a description of a mechanism.

The idea is Jim Collins'. In Good to Great the flywheel is a heavy disc you push — no single shove moves it much, but consistent pushes in the same direction accumulate, and eventually the wheel's own momentum does the work. Amazon later drew the version everyone copies: lower prices bring more customers, more customers bring more sellers, more sellers bring more selection, more selection improves the experience, which brings more customers again. Bezos reportedly sketched it on a napkin. That napkin is why the metaphor is now furniture in every strategy meeting.

Three tests

A real flywheel has to pass all three, and most claimed ones fail at least one.

The loop is closed. The output of the last step is the input to the first. If the arrows don't actually return to where they started, it's a value chain, not a flywheel.

Every link is causal, not correlated. "We grew, and we also hired more people" is not a flywheel — it's two things that happened. Each arrow has to be a mechanism you could explain: this rises, which causes that to rise. If you can't name the mechanism on an arrow, that arrow is decoration.

Momentum compounds. The same push produces more output as the wheel spins faster — because marginal cost falls, or marginal value rises, or both. Without compounding you don't have a flywheel, you have a funnel: linear, and needing to be refilled from the top forever.

That last test is also the one that separates a flywheel from a network effect. A network effect is a property of a product — value rises as users are added. A flywheel is an operating system for the whole business. In practice a network effect is usually one arrow inside a flywheel, not the wheel itself.

Signal-to-noise ratio

Mon, 06 Jul 2026 00:00:00 GMT

Signal-to-noise ratio (SNR) is a measure of how much useful information ("signal") there is relative to irrelevant or unwanted stuff ("noise"). It originated in engineering — in audio or radio, it's literally the ratio of the power of the signal you want to the power of background interference, usually expressed in decibels. A high SNR means a clean, clear signal; a low SNR means the signal is drowning in static.

The concept has spread far beyond engineering because it's such a useful metaphor.

In data and analytics, signal is the real underlying pattern (an actual change in user behavior, a genuine effect of your feature), and noise is random variation (day-to-day fluctuation, seasonality, small sample sizes). A metric with low SNR moves around a lot for reasons that have nothing to do with what you did — which is exactly why A/B tests need enough sample size: you're trying to lift the signal above the noise floor.

In communication and writing, signal is the content that actually informs or persuades, and noise is filler, hedging, jargon, or tangents. A high-SNR case study or email says a lot per word.

In product decisions, signal might be consistent feedback pointing at a real problem, while noise is one loud customer or an anecdote that doesn't generalize.

The practical takeaway is usually one of two moves: amplify the signal (better measurement, clearer writing, bigger samples) or reduce the noise (remove confounds, cut filler, filter out unreliable inputs). Anything that improves either one improves the ratio.

Signal-to-noise in people

The metaphor even gets applied to people. In a clip from The Diary of a CEO, Kevin O'Leary — who dealt with Steve Jobs directly for years — describes Jobs as 80% signal, 20% noise, and Elon Musk as 100% signal. His definition of signal there is worth keeping: the three to five things you must get done in the next eighteen hours; everything that stops you is noise. The percentages themselves aren't measurements — nobody instrumented anyone's attention, and "100%" is hyperbole — but the framing turns focus into the same two moves as everywhere else: know what your signal is, and cut what isn't.

The four risks, and the one everyone skips

Sun, 05 Jul 2026 00:00:00 GMT

Marty Cagan's Inspired reduces product work to four risks: is it valuable to the user, usable, feasible to build, and viable for the business. The list is easy to memorize and easy to misuse.

The misuse is treating it as a checklist you run after building. Cagan's actual argument is about timing: these risks should be attacked during discovery, cheaply, with prototypes — before anyone writes production code. The list is a prompt for what to de-risk first, not a rubric for grading what you shipped.

The other trap is weighting the risks equally. They aren't equal. Teams gravitate toward usability and feasibility because those are testable with familiar tools — run a usability session, ask an engineer. Value is harder to test and easier to assume, which is exactly why it kills more products than the other three combined. A clunky product that solves a real problem survives. A polished product nobody needs doesn't.

One more thing worth keeping: viability is broader than revenue. It's whether the business can and will actually support the product — legal, sales channel, cost structure, brand. Plenty of products die viable-on-paper.

Four risks, then. But really: value first, discovery early, and don't confuse "we can build it" with "we should."

Closing the Checkout Gap: Making Delivery Cost & Timing Visible

Fri, 03 Jul 2026 00:00:00 GMT

import CheckoutFunnel from '../../components/CheckoutFunnel.astro'; import UserSplitPie from '../../components/UserSplitPie.astro'; import StepConversionBars from '../../components/StepConversionBars.astro';

TL;DR

As PM for Pindo's order management system, I owned two conversion metrics: basket-to-order and order-to-paid-order. A large drop appeared at the address-and-delivery stage. By rebuilding the funnel from page-based to event-based, I isolated the real leak — logged-in users abandoned after selecting an address but before proceeding to payment. Through user calls, a survey, and an order-concentration analysis, I found the cause wasn't logistics but missing information: buyers couldn't see when their order would arrive or what delivery would cost.

Instead of a heavy delivery-service integration, I shipped a lightweight, seller-defined shipping estimate on the shipment page. A clean A/B test — treatment up to 63% order conversion, control flat at ~30% — confirmed the lift, and paid-order conversion moved with it (35% → 48%). Shipping-info capture was added to seller onboarding to scale adoption.

Context

I was the product manager for the OMS at Pindo, responsible for two core metrics:

Basket-to-order conversion — turning a viewed basket into a placed order
Order-to-paid-order conversion — turning a placed order into a completed payment

When I took over, the existing funnel ran:

ad view → add to basket → basket view → address & delivery page → payment page → gateway → thank-you page

The data showed a substantial drop at the address & delivery page, but the page-based view was misleading and I couldn't act on it directly.

Rebuilt event-based — each event firing on the action that moves the user forward, not on page load — the same journey looked like this:

Event	Share of cart viewers	Step conv.
Cart viewed User lands on the cart page	100%	—
Continue from cart Clicks "next" on the cart page	72.5%	72.5%
Continue from shipping Clicks "next" on the shipping page	16.2%	22.4%
Purchase clicked Clicks "purchase" on the payment page	9.9%	61.2%
Paid Payment completed at the gateway	7.6%	76.6%

Note on Continue from shipping: reaching this event requires having logged in, selected an address, and committed to delivery.

The critical drop is the 72.5% → 22.4% step: a user counted here clicked forward from the cart but never clicked forward from the shipping page. Understanding what that single number was hiding is where the work started.

The first insight: the funnel hid two different problems

Users browsed as guests all the way up to basket view. They were only forced to log in when they tried to continue past the basket. That meant the 22.4% step was mixing two unrelated problems:

Login friction — a self-contained problem with its own optimizations: OTP SMS deliverability, OTP codes being flagged as spam, OTP length, OTP autofill, and adding Digikala SSO to make logging in easier.
An actual in-flow drop — abandonment happening inside the checkout flow itself, among already-logged-in users.

I split these into separate tracks so login work wouldn't contaminate the analysis of the in-flow drop.

Note on the metric: the event-based view was for analysis only. The conversion metrics I owned were measured against the database, not derived from event or page-view counts — so the diagnostic reframe didn't change the definition of the number I was accountable for.

Breaking the 22.4% into its three steps

Getting from "continue from cart" to "continue from shipping" is really three actions in sequence: logging in, having (or entering) an address, and confirming the delivery details to proceed. Reconstructed from database state (figures rounded), the population splits first:

New users had to do all three steps; returning users arrived logged in with a saved address and faced only the last one. Each step's conversion, among the users who reached it:

Underneath the 22.4%, new users converted through the gate at about 18% — login, then address, then proceed — while returning users, already logged in with a saved address, converted at 40%. Two things fall out of this:

Login and address entry were the friction track. They compounded to lose over half of guest users (75% × 60%) before those users ever saw the delivery details — the self-contained problem with its own fixes (OTP, SSO).
The proceed step converted at 40% in both paths. Returning users — no login friction, no address friction, everything saved — stopped at the delivery-details step at exactly the same rate as users who had just fought through the whole flow. Whatever was losing people there was a property of the page itself, not of accumulated friction on the way to it.

That second observation is what pointed the investigation at the shipping page.

The real finding: a gap between selecting an address and proceeding to payment

With the event-based funnel in place, the churn concentrated in a specific spot: logged-in users selected an address but didn't proceed to the payment page.

I dug into that page to understand why. After entering an address, if you were lucky the seller had defined a delivery price for the item — but you still had no estimate of when the order would ship or when you'd receive it.

To verify the hypothesis rather than assume it, I triangulated across three sources:

User calls. Churned users were logged in, so we had their numbers. I called several directly. Recurring reasons:
- Delivery price unclear (sometimes freight-forward / pay-on-delivery)
- Delivery price too high
- Expected to select a time slot
- Wanted to know when the order would arrive — they might not be home when it ships
A survey built from those reasons to quantify them. Unknown delivery time and unknown/high delivery price landed in the top 3.
An order-concentration check before committing to a solution. ~50% of orders came from sellers in Tehran, but only ~12% of orders were same-city. This told me an inter-city logistics integration wouldn't move the needle — most demand wasn't same-city, so a same-city delivery service would have solved the wrong problem.

The conclusion: this was an information problem, not a logistics problem.

The decision: ship the lightest thing that solves it

{/* TODO(owner): you mentioned framing this through an explicit prioritization method. Options: add impact/effort/confidence columns to the table below, or a short paragraph naming the method you actually used (or would use) and how the chosen option scored. Only add scores you can honestly reconstruct. */}

I considered several solutions:

Option	Trade-off
Integrate a delivery service (e.g. DigiExpress) for selectable time slots	Heavy build; solves time-slot selection but overkill for an info gap, and weak fit given the same-city concentration
Estimate delivery time from order history	Requires reliable historical data; indirect
Let sellers pick their delivery service, then infer a rough estimate	Depends on seller input + mapping logic
Seller-defined general shipping description (chosen)	Familiar pattern (like Instagram shops: "orders before noon ship same day"); easy to implement; directly closes the info gap

I chose the seller-defined shipping description because it was easy to implement and a pattern users already understood from social commerce and other sites.

To populate it credibly, I sorted our top sellers, called them, asked how they actually priced and timed shipping, and used that to build a template other sellers could fill in.

For the experiment, the information was shown on the shipment page — the page I owned and the exact spot where the churn happened.

Validation: a clean A/B test, scoped deliberately

I ran the A/B test on logged-in users, splitting on user-ID parity — the new shipping information was shown to even IDs (treatment) and withheld from odd IDs (control).

What exactly was measured: in both arms, the metric was logged-in users' order conversion on orders from the selected shops — the top sellers whose shipping template had been filled in. Treatment saw the new information on those orders; control didn't. Orders from other shops weren't part of the read, since there was no shipping information to show or withhold.

Why this split is valid: both groups were near-identical at ~30% historically and ran over the same period, so seasonality and marketing hit both arms equally — only the shipment-page change differed.

The ID-parity split also enforced the scope: only logged-in users have numeric user IDs (guests carry non-numeric session IDs), so even/odd splitting mechanically restricted the test to logged-in users — which is exactly the population that reaches the shipment page.

Why the test was a clean persuasion read: I deliberately scoped the experiment to the shipment page only, leaving the top of the funnel (ADP/PDP) untouched. That matters — if I'd disclosed delivery info earlier in the journey during the test, it could have changed who reached checkout (pre-qualifying buyers), and the checkout lift would have been partly a composition artifact rather than genuine persuasion. By holding the top of the funnel constant, the population reaching checkout was the same as control, so the lift reflects the feature actually changing minds at the decision point.

Result:

Order conversion: treatment ~30% → 63%; control flat at ~30% over the same window
Paid-order conversion: 35% → 48% (treatment vs. flat control)
Test duration: ~2 weeks at a 50/50 split

I no longer have access to the exact per-arm sample counts, but at full checkout traffic over two weeks, a 33-point gap between arms is far beyond what noise produces — the control arm holding flat at ~30% throughout is the strongest evidence the effect was real.

After the test confirmed the lift, I launched the shipment-page version to all users; the change held at 100% rollout.

Scope of the claim (being precise)

The honest headline is a 33-point order-conversion lift in the experiment, among logged-in users, on orders from the selected shops that had shipping info filled in — not a platform-wide doubling. Two reasons to state it that way:

The entire study concerns logged-in users — they're the only ones who reach the shipment page, and the ID-parity split enforced that population.
The measurement was scoped to the selected shops. At test time, sellers with the shipping template filled in were roughly ~0.3% of the platform — the hand-picked top sellers I'd called — so the day-one blended effect on the platform-wide number was negligible.

On why the lift is so large: the 63% is the concentrated treatment effect — the change in behavior for buyers who actually saw the new information. The reading that fits the user research is that many buyers were treating unknown delivery cost and timing as a worst-case and abandoning; removing that uncertainty recovered them, even when the disclosed answer was only mediocre.

The platform-wide figure is a projection, never re-measured: at a hypothetical ~35% seller adoption, the concentrated +33pp would translate to roughly +11–12pp platform-wide (≈30% → low-40s%) — contingent on adoption actually climbing via onboarding. Reporting the scoped number alongside the projected one, each with its conditions, is more accurate — and more defensible — than quoting the big number on its own.

Scaling it

To make the win durable rather than one-off, shipping-info capture was added to seller onboarding, so every new seller provided it by default and adoption would climb over time.

What I'd redo

{/* DRAFT — written for Mohammad Reza to correct/replace with his own view */}

Instrument the funnel event-based from the start. The page-based funnel cost real calendar time: the first weeks went to discovering that the number I was staring at was two problems wearing one trench coat. The lesson I carry forward is to audit how a metric is constructed before trusting where it says the problem is.
Preserve the experiment's statistics. The test was clean, but I didn't retain the per-arm sample sizes and significance figures. For a result this large it doesn't change the conclusion — but a defensible number deserves a defensible paper trail, and I'd archive the analysis alongside the launch doc now.

A Metric Dropped. Now What?

Thu, 02 Jul 2026 00:00:00 GMT

Every product person eventually gets the message: a number that mattered went the wrong way. Conversion is down. Repeat rate slipped. Basket size shrank. The instinct — and the mistake — is to jump straight to "let's break down the funnel and see what's broken."

The funnel teardown is real work, but it's near the end of the process, not the start. Most metric moves are explained by something cheaper and more mundane than a broken funnel stage, and if you don't rule those out first, you'll spend a week diagnosing a problem that doesn't exist.

What follows is the sequence I actually run. Each step earns the right to the next one. You don't graduate to the expensive analysis until the cheap explanations are dead.

1. Define the metric before you touch it

A metric is not a number, it's a ratio, and ratios have two moving parts. Before anything else, write down:

The numerator — what event are we counting?
The denominator — over what population?
The time window — daily, weekly, rolling?

This sounds pedantic until you realize how many "drops" are just a ratio moving because the bottom changed, not the top. Conversion rate can fall while the absolute number of conversions rises — you just added more people to the denominator. If you don't know exactly what's on top and bottom, you can't reason about which one moved, and you'll chase behavior that never changed.

2. Is the drop even real?

Before you theorize about users, confirm the number reflects reality and not a change in how you measure reality.

A "drop" is very often an instrumentation artifact: an event that stopped firing after a deploy, a property that got renamed, a logging change, a double-count that someone helpfully fixed. Ask what shipped near the drop date on the tracking side, not just the product side.

This is a thirty-minute check that saves you from days of analyzing a ghost. Do it early, every time.

3. Read the shape of the change

Before pulling a single additional cut, look at the shape of the drop over time. The shape encodes the cause.

A step function — a sharp vertical drop on a specific date — means something switched. A release, a config change, a price update, a partner turned on, an outage. Your job is to find what happened on that edge. Within "step," the edge quality tells you more: a drop-then-recover is a transient (an outage that got fixed, a promo that ended); a drop-to-a-floor-that-stays is a permanent change.

A gradual slope means something is drifting. Nothing flipped; a continuous process is grinding the number down. And "gradual" is where people get lazy and mutter "seasonality," so it's worth understanding why a slope appears. There are three families:

Mix shift. The composition of your denominator is changing even though no single segment's rate moves. If City A converts at 60% and City B at 30%, and you're steadily acquiring more B-type users, the blended rate slides — purely from reweighting. Every segment can be flat while the aggregate falls. This is the Simpson's paradox trap.
Degradation. Something is accumulating. Tables grow and queries slow, so latency creeps up and conversion bleeds with it. Catalog data goes stale. Search relevance rots. The cause is a slow ramp, so the effect is a slow ramp.
Cohort turnover. The population is being reshaped by entry and attrition. A big acquisition spike ages through your funnel over weeks; retention thins cohorts so survivors over-represent some behavior. No individual changed — the pool did.

The unifying idea: a gradual change means the cause itself is continuous. Something is reweighting, rotting, or aging at a steady pace, and the metric inherits that pace. A step means something switched. Knowing which one you're looking at tells you whether to hunt for an event or a process — before you've run any real analysis.

4. Concentration and mix: is it everywhere, or somewhere?

A metric is an average over a heterogeneous population, and an aggregate move is very often a localized move hiding inside a flat average. So before you tear the funnel apart, slice the drop across the dimensions that carry variance for your business.

The dimensions aren't a fixed checklist — you pick the ones that plausibly hold the variance for this metric at this company. For a Q-commerce grocery business, that usually means city, dark store or vendor cluster, category (fresh vs. packaged behave nothing alike), time of day and day of week, courier type, and user segment.

Two things fall out of this one check:

Concentration. If the drop is uniform across every slice, you're looking at a system-wide cause and the funnel teardown is coming. If it collapsed in three dark stores in one city, you have a local ops problem and the funnel analysis would have wasted a day. Where the drop lives determines what kind of problem it is.

Mix vs. rate. This is the subtle one, and it belongs right here — not earlier (you don't have the segmented view yet), not later (by then you've already assumed it's a rate problem). When you segment, look at two things side by side: each segment's rate over time, and each segment's share of volume over time. If the rates are flat but a low-converting segment grew its share, the blend fell without anything actually breaking. The funnel is fine; the population moved.

The cleanest way to settle it: hold the mix constant and recompute. Apply last period's segment weights to this period's segment rates. If the reweighted number matches the old number, it was pure rate. If it matches the new number, it was pure mix. Usually it's in between, and now you've quantified how much each contributed instead of hand-waving.

The decision rule at this node:

Concentrated rate drop in a slice → dig there; it's local and probably causal.
No slice is low, but the blend fell → suspect mix; check whether a low-rate segment grew or a high-rate segment shrank.
Rates uniformly down, shares stable → genuine system-scale degradation. Now the funnel teardown earns its place.

You don't advance to stage-by-stage analysis until you've cleared both concentration and mix, because either one can fully explain an aggregate move without a single funnel stage breaking.

5. The funnel teardown — finally

By the time you get here, you've established the drop is real (not instrumentation), system-wide (not concentrated), and a genuine rate move (not mix). That's what justifies the expensive analysis. You earned it.

A conversion rate is a product of stage-to-stage rates: session → search → add-to-cart → checkout → payment → fulfilled. A drop in the headline lives in one or a few specific transitions. Two disciplines keep this from becoming a fishing trip:

Chase the step that moved, not the step that's lowest. Every funnel has a worst-converting step; that's normal, not your culprit. Diff each transition against baseline. A step that's been 40% forever and is still 40% isn't your problem even if it's the lowest in the funnel. The transition that changed is the one that ships you to the cause.

The located stage names the cause family. Where the bleed sits constrains what could cause it:

Drop at add-to-cart → discovery, search relevance, availability/out-of-stock, or pricing perception. They looked and didn't want it.
Drop at checkout → payment → friction, fees revealed late, delivery cost or SLA shown at a bad moment, address or slot problems. They wanted it but balked at the terms.
Drop at payment → fulfilled → not a user-intent problem at all. Failed payments, cancellations, out-of-stock-after-order, courier failures. They committed and the system failed them.

So the location of the drop already tells you whether you're looking at a demand problem, a friction problem, or a fulfillment problem — before you've formed a single specific hypothesis.

6. Hypotheses that actually discriminate

Once you've localized the stage, you rarely have the deciding data live in front of you. The credible move isn't to guess a conclusion — it's to name a small, ranked set of hypotheses, each carrying three things:

The mechanism — why this would cause a drop at this specific stage, not a generic "maybe UX got worse."
The validation — the specific cut or query that confirms or kills it.
The expected signature — what the data looks like if this hypothesis is true versus if a competing one is.

That third item is the upgrade most people skip. Weak validation looks for evidence consistent with your guess — and almost everything is consistent with something. Strong validation names what the data would look like under each competing hypothesis, so the cut actually discriminates. If two hypotheses predict the same pattern, that cut is useless; you need a different one.

Here's the discipline made concrete for an add-to-cart drop — people are landing and browsing but adding less:

Traffic-mix (check this first). Before concluding "add-to-cart got worse," confirm the input population didn't change. If a campaign dumped low-intent traffic into sessions, the rate falls mechanically — the numerator is fine, the denominator inflated. Confirms if: a low-intent channel ballooned as a share of sessions while the rate within each channel stayed flat. Killed if: channel mix stable and the rate fell within established channels — now it's a real problem.

Availability / out-of-stock. Items people want show as unavailable — the intent is there, the button isn't. Confirms if: OOS rate rises on the same edge date and the drop concentrates in exactly the stores and categories where OOS rose. Killed if: OOS flat while add-to-cart fell.

Search / discovery relevance. They can't find what they came for. Confirms if: the drop lives in search sessions specifically, null-result rate climbed, and it tracks a ranking deploy. Killed if: browse sessions dropped just as hard — then it's broader than search.

The clean discriminator between the last two: availability is "they found it but couldn't add it"; relevance is "they couldn't find it." The OOS rate separates them. If OOS is flat but null-results are up, it's relevance; reverse it and it's availability.

Pricing perception. Prices rose (or a competitor's fell) and the value proposition shifted. Confirms if: the drop concentrates in price-sensitive segments and elastic categories and lines up with a pricing or promo change. Killed if: it's uniform across price-sensitive and price-insensitive segments — if the users who never shop on price dropped just as hard, price isn't the lever.

Run them cheapest-and-most-disqualifying first: traffic-mix, then availability, then relevance, then pricing. Each validation is built so that confirming it and killing it look different in the data. That's what turns a list of guesses into a decisive sequence.

The spine, in one place

Define the metric — numerator, denominator, window.
Data integrity — is the drop real, or an instrumentation artifact?
Shape — step (an event switched) vs. gradual (a process is drifting).
Concentration + mix — localized to a slice, or is the blend moving because weights shifted rather than rates? Hold mix constant and recompute to settle it.
Funnel teardown — only once concentration and mix are ruled out; localize to the stage that moved, which names the cause family.
Discriminating hypotheses — mechanism + validation + expected signature, ranked cheapest-to-disqualify first.

None of this is about knowing more statistics than the next person. It's about order — refusing to spend expensive analysis until the cheap explanations are dead, and refusing to accept a hypothesis until you've named the data that would prove it wrong. The number moved for a reason. The method is just making sure you find the real one.