A focused home for product decisions

Start with the decision that keeps coming back

A product team can finish a meeting and still leave the important question unsettled. Someone records an action, someone changes a ticket, and a third person remembers a different reason for the choice. A month later, the team opens the same discussion. This illustrative concept for DIJ.com starts with that small, expensive gap: a focused place to record what was decided and when the decision deserves another look.

The first customer would be a product team that already has a task tracker but struggles to preserve the reasoning around its work. The proposed software would sit beside that tracker. Its promise would be specific: open a decision, see the current answer, understand who owns it, and find the evidence that might change it. DIJ could serve as the product identity, with a plain descriptor such as “Product decision records” carrying the explanation at first contact.

Make the record useful before making it clever

The first offer could be a shared decision log for one team. Each record would contain a question, the options considered, the current choice, an owner, supporting links, and a review date. A short “what would change this?” field would be especially useful. It gives a future reader a way to distinguish a settled choice from a temporary assumption without needing to ask everyone who attended the original conversation.

For example, imagine a team deciding whether to add a bulk editing screen. Its record might say that the first version will support changing one field across selected items. The evidence could be three observed support cases, with private customer details removed. The review condition might be repeated requests for multi-field changes. The record would link to the implementation ticket, while the ticket would link back to the reasoning. Neither document needs to swallow the other.

A record should take minutes to complete. If it asks people to reconstruct the entire history of a project, it will compete with work they already have. Start with required fields that someone can answer immediately. Let teams add detail when a decision is costly to reverse. A small interface can still show a useful history: proposed, decided, replaced, and reviewed are enough states for an initial prototype.

Learn from recent work

Before building software, ask a few potential users to show a recent decision that became confusing. Follow the trail through their existing documents and conversations. Ask where the answer stopped being clear, who needed it later, and what happened next. The GOV.UK guidance on in-depth interviews recommends exploring real examples with open questions. That is a useful discipline here: a specific missing decision tells you more than enthusiasm for a hypothetical dashboard.

The founder could first run the idea as a simple template. One team would use it for a handful of live decisions over two weeks. At the end, ask a colleague who missed the meetings to explain a record in their own words. If that person cannot identify the choice or its owner, the problem is likely in the record structure. More notifications would not repair it.

Find a route into the team

A credible distribution path would be a practical decision-record template accompanied by one worked example. Product leads could try the document before considering a subscription. The example should show an ordinary tradeoff, including an imperfect choice and an explicit review condition. A polished fantasy in which every team member agrees would teach very little and make the tool feel disconnected from actual work.

A founder could share this resource through their own professional relationships or relevant communities where useful templates are welcome. The follow-up conversation should focus on what people changed. If users delete half the fields or move the record next to an existing document, that behavior is valuable evidence. The product might become an integration or a lightweight document layer instead of a separate destination.

Build around trust and maintenance

Execution would require thoughtful access controls, reliable export, and a clear approach to sensitive information. Early teams should be able to remove customer names and keep restricted evidence in their existing systems. A link to a private document should never imply that all product users can read it. The interface needs to explain unavailable evidence plainly, without exposing its contents in previews or search results.

There is also an ownership problem after launch. Records become stale when people change roles or projects close. A simple owner reassignment and review queue may matter more than a broad reporting dashboard. Test how a team archives a decision, replaces one, and finds an older answer. Keep the old rationale visible enough to explain history while making the current answer unmistakable.

The GOV.UK discovery guide separates understanding a problem from committing to a solution. Applied to this concept, the next step is a small trial with one product team and a clear question: can someone recover a decision without reopening the meeting? That result would help determine what deserves to be built.

Give the concept an address

DIJ.com could hold the product introduction, the template, and the eventual application under one concise identity. The letters do not need an invented expansion. A clear descriptor and a useful first experience would do the explaining. The domain is available for acquisition separately from this illustrative software concept. An interested buyer can inquire about DIJ.com and describe the direction they have in mind.