Delight, hard to copy, margin-enhancing

Product discovery without a product strategy is a scavenger hunt without a list of items. You can search enthusiastically, all day, and have no way of knowing whether you found anything worth finding. Teams in this state don't look lazy. They look busy, curious and permanently mid-exploration.

The missing piece is rarely more research. It's a filter - something that tells you which of the twenty opportunities on the wall are worth carrying forward, and which are just true.

The shortest useful filter I know is the DHM model, from Gibson Biddle, VP of Product at Netflix. His one-line version of the job: delight customers in hard-to-copy, margin-enhancing ways.

Three conditions. Not one, not whichever is easiest to argue.

The three questions

Does it delight customers? Not "would customers accept this". Delight means it solves a problem they actually feel, well enough that they notice.

Is it hard to copy? If a competent competitor can ship the same thing in a quarter, you have bought yourself a quarter.

Does it enhance margin? Does the economics of the business get better as this scales, rather than worse?

The discipline is in the conjunction. A bet has to clear all three to be strategy. Clear only the first and you have a feature - a nice one, possibly, but not a reason your company wins.

Most strategies only answer the D

This is the pattern I see most often, and it is not a failure of effort. Teams that have invested in discovery get genuinely good at the first question. They know their customers' problems. They can tell you, with evidence, which pain is sharpest.

Then the strategy document lists eleven things that would delight customers, and nothing rules anything out. That is a wish list, and I've written before about why a strategy that accommodates everything commits to nothing.

H and M are what make the list shrink. They are also the two questions product teams are least comfortable asking, because they sound like someone else's job. They aren't.

"Hard to copy" is not the same as clever

The usual mistake is treating hard-to-copy as a property of the feature. It rarely is. Features are the easiest thing in software to clone.

What's hard to copy is normally the thing behind the feature. Netflix's recommendation work is the standard example: the interface could be rebuilt in a month, but the roughly ten billion customer ratings it was trained on could not, and the more people used it the further ahead it got. The advantage lived in the accumulating data and the loop, not in the screen.

So ask it properly: what does this bet accumulate? Data, a network, a brand position, a cost structure, a switching cost, a habit. If the honest answer is "nothing, it's just a good feature", that's fine - build it if it's cheap, but don't call it strategy.

This is also the cleanest argument against copying competitors. A feature you shipped because they shipped it is, by definition, one they already have. It fails the second question before you start.

Margin is not the finance team's question

Product people flinch at the M, usually by handing it to someone else. That's how you end up with a beloved product that gets more expensive to run with every new customer.

Margin-enhancing doesn't mean "charge more". It means the unit economics improve as the thing scales: support load per customer drops, manual work gets automated away, the expensive human step becomes a cheap one, or the bet opens a higher tier people will actually pay for.

Asking it early also kills a specific kind of expensive mistake - the feature that tests beautifully with users and quietly adds a person's worth of manual work per hundred accounts. That cost shows up eighteen months later as a margin problem nobody can trace back to a roadmap decision. It is the same logic as not all features add value, but every feature adds cost, applied before you build rather than after.

It is not a one-time exercise

The DHM answers you write down are hypotheses, not conclusions. "This will be hard to copy" is a bet about the future, and it is wrong reasonably often.

So treat it as an ongoing loop of evaluation and experimentation rather than an offsite deliverable. Write the three answers for each bet, put a confidence level on them, and go and find evidence for the weakest one. That is exactly the job discovery is supposed to do: not generate opportunities forever, but resolve the specific uncertainty that would change the decision.

The relationship runs both ways, and that's the part people miss. Strategy tells discovery where to look. Discovery tells strategy which of its assumptions were wrong. Break either direction and you get the two familiar failures: endless exploration, or a strategy that survives contact with reality only because nobody checked.

Try it on your current roadmap

Take the next three things you plan to build. For each one, write a sentence against each letter. Nothing longer.

• D: which customer, which problem, and how do you know it's sharp?
• H: what does this accumulate that a competitor can't buy?
• M: what happens to unit economics as this scales?

You'll usually find at least one item where two of the three sentences are impossible to write honestly. That item is not necessarily wrong. But it is not a strategic bet, and it should stop being funded as though it were.

If the exercise leaves you with eleven bets that all somehow pass, the problem is upstream of the framework, and that's the conversation our product strategy work usually starts with.