Frequency is not only a product question. It is a memory question. A developer must remember the pain at the moment they see the product, and a manager must remember the pain when the budget conversation arrives. Weekly pain gives the company more chances to earn both.

The wedge should also create visible contrast. A faster deploy, cleaner failure message, shorter review cycle, simpler local setup, or more reliable preview environment creates proof that travels. The user can show the before and after without a vendor in the room.

This is why infrastructure wedges are often tricky. The value can be enormous, but the first moment may require risk, migration, or permission. If the first step is heavy, the wedge has to be painfully urgent or the motion needs a human-assisted path.

A strong wedge is not just painful. It is teachable. The user can explain it to another developer in one sentence and prove it in one session.

A DevTools wedge has to hurt often enough that the buyer remembers it without being educated into caring. Occasional pain can produce interest. Weekly pain produces adoption. Daily pain can produce habits, internal advocacy, and budget.

Many DevTools companies choose wedges that are technically impressive but commercially weak. They solve a problem that appears during a migration, a replatforming cycle, a rare production incident, or an advanced edge case. The demo looks strong because the technical problem is real. The motion stalls because the problem is not frequent enough for the user to change behavior now.

The better wedge sits inside an existing rhythm. Build, test, deploy, debug, review, monitor, query, document, provision, secure, cost-check, and hand off. Those loops already exist. A product that improves one of them does not need to create a new ritual from scratch. It can attach to a moment developers already recognize.

The wedge scorecard should ask five questions: how often does the pain happen, who feels it first, what workaround exists today, what evidence proves improvement, and what second user is pulled in after the first user succeeds? A wedge that cannot pull in a second user may be useful but commercially isolated.

The classic failure is the admired product that never becomes a company standard. Developers praise it, star it, share it, and still do not bring it into production workflows. They like the idea, but the wedge does not occupy a recurring enough moment to become necessary.

The founder has to separate admiration from pressure. Admiration sounds like "this is cool," "I would try this," or "we should look at this next quarter." Pressure sounds like "we hit this every Tuesday," "this blocks the release," "this makes reviews painful," or "we built a spreadsheet around the workaround." The first can fill a waitlist. The second can create adoption.

This is why the first proof moment has to be close to the pain. If the painful moment is deploy confidence, the product should not require a long platform migration before it can show a safer deploy. If the painful moment is local setup, the user should not need to become an administrator before the tool proves anything. If the painful moment is debugging a model output, the user should not need a full governance program before they can inspect one failure clearly.

The wedge also needs a social path. A single developer can try a tool alone, but most durable DevTools wedges pull in a second role: reviewer, platform owner, security lead, teammate, manager, or incident commander. That second role matters because it turns private relief into shared proof. A preview deployment is useful to one developer; it becomes more powerful when a designer, PM, reviewer, or QA partner can use it too.

There is a trap on the other side: chasing the loudest pain instead of the repeatable one. A severe production incident may create urgency, but if the company only appears during rare emergencies, adoption becomes episodic. A smaller pain that happens every week may create a better business because it gives the product more chances to become normal.

This is why wedge work should include calendar analysis, not only persona analysis. Ask where the target user already spends attention during a normal week. Which meeting, review, deployment, incident, planning cycle, or support thread creates the opening? A wedge with a clear calendar slot is easier to revisit. A wedge with no recurring slot has to fight for attention every time.

The company should also know what "good enough" looks like in the current workaround. Some workarounds are ugly but stable. Developers will not replace them for elegance alone. They replace them when the new path gives them proof they can defend: fewer failed checks, faster review, a cleaner rollback, a better trace, a simpler handoff, or a setup path the next teammate can repeat.

The operator test: if a target user skipped the product for two weeks, what would break, slow down, or become visibly worse? If the answer is mostly emotional preference, the wedge needs more pressure.

If the test fails, the wedge probably needs either more urgency or a lighter first step. The company should not respond by adding more surface area. It should ask whether the pain happens often enough, whether the current workaround is visibly worse, and whether the first proof moment can happen before the buyer has to accept too much risk.

A useful customer interview question is: when was the last time this problem cost you an afternoon? The answer is better than asking whether the problem matters. Developers can intellectually agree that many things matter. The wedge lives where memory, irritation, and consequence meet. That is where a tool can earn a repeated habit.

This is part 2 of 10 in Building DevTools Developers Actually Trust.