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.
- 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.
- “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”.
- Cannot achieve alighnment. E.g. debating on low levels challenges when the alignment issue is happening at the higher level.