A quick snapshot of my mental model (as an engineer) on discussing product features.

How to read the graph?

Level 1: What is the problem to be solved? For who? Why is it important?

This answers the job to be done.

Level 2: Where the problem fits in?

This reasons about different perspectives about the problem. Basically, identify which domains/areas to tackle the problem.

Level 3: What are the possible solutions?

This answers the new workflows to solve the problem inside the domain.

Level 4: How to execute the solution?

This answers the implementation details, dependencies-and constraints.

How to use it?

These are a few rules to follow:

The levels above define the levels below

Failed to communicate or align on the top levels results in bad executions at the lower levels.

Common conflicts:

• Shaky work. E.g. when top levels are based on one-sided assumptions or the requirement is competition driven.
• Lost the big pictures. E.g. getting questioned about the intent of the feature. solution is short-sighted or execution is not extensivable.
• Bloated requirements. E.g. “We can do these together!” when the solution can lump multiple problems.

The levels below constitute the levels above

The constraints below limit one level above.

Common conflicts:

• “It is a hack!” E.g. when the problem is addressed in a wrong domain; the solution is pushed through and discarded concerns from execution.

Discuss on a level higher than your problem level

As Albert Einstein said, “we can’t solve problems by using the same kind of thinking we used when we created them”.

Common conflicts:

• Cannot achieve alighnment. E.g. debating on low levels challenges when the alignment issue is happening at the higher level.