A product discovery approach in which a team builds for an internal need they personally feel before expanding to broader demand. It gives the team firsthand insight into the workflow, pain points, and edge cases. The result is often a usable internal tool and a lower-risk starting point for external validation.
What this approach changes in product discovery
Scratch Your Own Itch is less about “building for yourself” as a slogan and more about using a real internal pain point as a discovery accelerator. Because the team experiences the workflow directly, it can spot friction, edge cases, and missing capabilities faster than it would through abstract interviews alone.
The biggest advantage is signal quality. Internal usage reveals what people actually do, not just what they say they need. That makes it easier to separate useful functionality from nice-to-have features, and it often produces a first version that is already operationally grounded. In discovery terms, that can reduce ambiguity and shorten the path to something demonstrable.
Why it is often a strong starting point
This approach is especially valuable when the problem is familiar but poorly served. A team that lives with the pain can define the workflow in practical terms, choose a minimal scope, and test assumptions without needing a large upfront research effort. It is a pragmatic way to begin when the market problem is still being shaped.
It can also improve speed to feedback. Internal users are easier to observe, easier to interview, and more likely to give precise comments about usability, missing steps, and failure modes. That makes the early product more concrete and reduces the chance of solving an imaginary problem.
For security-sensitive internal tooling, the approach can be useful because it surfaces the operational realities that generic product thinking may miss, such as how people actually handle access, exceptions, or sensitive workflows. An internal pain point around controls, workflows, or secrets handling is often more visible when the builders are also the users, a pattern that aligns with the kinds of issues discussed in the Ultimate Guide to NHIs.
Where the approach breaks down
Building for yourself is not the same as finding product-market fit. A team can overvalue a problem because it is personally annoying, even when that pain is uncommon, low priority, or tied to a very specific internal environment. The result can be a polished tool that is useful, but only to a narrow audience.
The other common failure is generalisation bias. Teams may assume their own workflow is representative of the wider market when it is actually shaped by their tooling, maturity, or technical constraints. That is why “scratch your own itch” should be treated as a discovery input, not the final validation step.
When to use it, and what to validate next
Practitioner note: The approach works best when the team can clearly name the pain, reproduce it repeatedly, and describe who else is likely to share it. If the internal use case is too idiosyncratic, the product may become a bespoke utility instead of a transferable solution.
Common misunderstanding: teams sometimes think the approach removes the need for broader validation. In reality, it only lowers the cost of getting to a credible first version. The next step is to verify that the problem exists outside the building, that the pain is frequent enough to matter, and that the solution still works once the audience widens.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 2 — Inventory and Control of Software Assets | Scratch-your-own-itch often starts with an internal tool for a real operational gap. |
| 6 — Access Control Management | Internal products built from lived pain often touch sensitive workflows and permissions. | |
| Recommendation — Use software inventory discipline to ensure the internal tool addresses a verified workflow need. Review access paths and permissions before turning the tool into a shared service. | ||
| NIST CSF 2.0 | GV.OC — Organizational Context | This approach depends on understanding the specific internal context and pain points. |
| GV.RM — Risk Management Strategy | The method is a way to reduce discovery risk by starting from first-hand evidence. | |
| Recommendation — Define the internal business context before using the problem as a product signal. Treat the internal itch as an input to risk-managed product discovery, not final proof of demand. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets Sprawl | Internal tooling can expose operational friction around secret handling and workflow visibility. |
| Recommendation — Map any secret-handling friction in the internal tool to reduce sprawl before scaling it. | ||
Related resources from NHI Mgmt Group
- What do teams get wrong when they build their own internal security tooling from scratch?
- What is a realistic NHI security maturity roadmap for an enterprise starting from scratch?
- When does secrets discovery become insufficient on its own?
- Should organisations rebuild identity systems from scratch after a compromise?
