Skip to content

Instantly share code, notes, and snippets.

@kunagpal
Last active May 17, 2025 23:38
Show Gist options
  • Select an option

  • Save kunagpal/b375b36de3599d155b2929d636f33dde to your computer and use it in GitHub Desktop.

Select an option

Save kunagpal/b375b36de3599d155b2929d636f33dde to your computer and use it in GitHub Desktop.
Problem solving specification

Overview

A brief introduction to the background context behind the current problem's situation:

Why is this problem worth solving?

To determine the relative priority of this problem in contrast to that of many others, ask: What goes wrong if this remains unfixed after a finite amount of time?

How was this problem discovered?

Tracking trends of problem discovery sources helps us focus our efforts more precisely

Who is affected by this problem, and what workarounds are available to them at the time of writing?

Keeping close quarters coordination with these people/groups is paramount for success

Outcomes

This section allows any team member to independantly and objectively judge that the problem in question has indeed been solved well.

When this problem is solved well, who benefits, to what measurable extent, and in what way?

  1. Root cause elimination: One or more recurring problems is eliminated.
  2. Optimization: Solution users are able to perform today's work with less effort.
  3. New capabilities: Solution users are able to perform new pieces of work without a commensurate increase in effort.

Wherever possible and practical, link the listed outcomes to overall company objectives, which will take one of 2 forms:

  1. Make it easier to acquire (and retain) new users (preferably paying ones). The former often has direct new revenue contributions.
  2. Reduce the cost of revenue by eradicating wasteful internal actions.

The above makes it easier to rally support from other teams via a common language of purpose, should the need arise.

Good to have

An optional section to highlight what more can be achieved in this space. While not strictly necessary, this is still important to maintain an appropriate level of awareness.

Parameters

These offer additional considerations of anti-goals that must be obeyed to minimize disruption to all affected individuals/groups (for instance, no downtime during migration from old to new system, or a maximum of 1 hour of read-only enforcement).

Assumptions

Specific, brief points about certain parts of our knowledge of the world that will be proven one way or the other over the course of this problem solving exercise. This section is noteworthy to highlight parts of our systems that are siloed in their context spread across the team(s).

Approach

Options

A (usually tabular) subsection outlining all possible known solution approaches, including their respective pros and cons.

The above list of options is followed up with a justified selection of the most suitable (sometimes least horrible) option that we're proceeding with. If there are pre-existing experiments for any proposed option, this is where you will call them out. Proposed options incurring fewer adoption hurdles will be easier to convince larg(er) target audiences for.

Design

An expansion on the selected problem solving approach, starting with the percieved consumption steps/experience for the target adopters of what is being built. Backtrack from the above to deeper technical details (by repeatedly asking how) to avoid getting stuck in technical rabbit holes/other circular discussions that bring no conclusions. Also make a point to explictly highlight any design decisions being made, this will come in handy for future justification.

Scope

This is our attempt to shape work into more manageable chunks for consistent daily/weekly progress. Apply the following considerations to identify and prune less-necessary parts of work to move faster:

  1. Are there any steps in the selected approach that can be skipped without sacrificing the depth of quality?
  2. Does the proposed solution need to be rolled out to all eligible consumers, or a subset of them?
  3. What is the smallest (reversible) step we can take to verify any pending assumptions, or extract practical + visible results?
  4. What degree of perfection is necessary? (the answer is almost always slightly less than what you may believe)
  5. How much time will each of the above discrete steps take?

Further reading

Optional references to internal/external sources that expand the reader's understanding of the problem space.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment