Guide · about 6 minutes

How to read someone else's assignment without copying it

Most people open one of these, skim the PDF, feel vaguely behind, and close it. Here is a better way to spend the same twenty minutes.

✳Start with the disagreement, not the format

The first instinct is to study the layout — how they structured the doc, what the tables looked like, how long it was. That is the least transferable part. Formats vary by company and get reset the moment you join one. What travels is the argument: this user has this problem, here is why I believe that, here is what I would do about it, and here is what I gave up to do it.

✳Find the sentence the whole document hangs on

Every strong submission here has one. It is usually a problem statement about a third of the way in, and everything before it is evidence while everything after it is consequence. If you cannot find that sentence, the submission is weaker than it looks. If you can, ask whether the evidence really earns it.

✳Read two takes on the same product

Several products in this library show up more than once. Open two of them side by side. Same app, same brief, two people who noticed different things. That gap is where product sense lives, and it is far more instructive than any single document, however polished.

✳Check what they left out

Look for the second option that was considered and rejected, the number that sizes the problem, and the sentence about what happens when the feature does not work. When those are missing, you have found the thing that would have made the submission stronger. Now go and put it in yours.

✳Then close the tab and write badly

Reading examples has fast diminishing returns. Two good ones and a product you actually use will get you further than fifteen. Write the ugly first version, then come back here to see what a finished argument looks like.

✳What is in the library

Improving Product Sense

Teardown — Pick a product, map its core flows, and say plainly what it does well and where it leaks.
User research — Talk to real users. Come back with problems in their words, not your assumptions.
Solution design — Generate widely, then cut hard. Score what survives and defend the order.
The PRD — Turn the winning idea into a spec: screens, edge cases, metrics, risks.

Meaningful AI Improvement

Find the job — Name the task users already struggle with. AI is the answer to a question, not the question.
Justify the model — Show why a model beats a rule, a filter or a better default.
Design the feature — Entry points, output, controls, and the fallback when confidence is low.
Prove the value — Say how you would know it worked, and what would tell you to kill it.

One honest caveatThese were written by people learning, under a deadline, on products they use rather than build. Read them as evidence of thinking, not as documents a company shipped.