"Start with the Issue" Impressions
目次
- Top
- Introduction
- Increasing Productivity Requires "What to Answer" Clarity
- Don't Get Stuck, Think It Through
- Chapter 1
- Productivity is Defined by Output per Input
- The Value of Work is Defined by Two Axes: "Issue Degree" and "Solution Quality"
- To Increase the Value of Work, First Increase the Issue Degree
- Chapter 2-3
- Defining the Issue
- Issue Hypothesis Must Be Verbalized and Made Clear
- What Makes a Good Issue?
- Information Gathering for Defining the Issue
- Chapter 4
- Analyzing the Issue
- Chapter 5
- Analysis from Picture Composition
- Conclusion
I've finished reading "Start with the Issue", which is highly recommended everywhere.
Overall evaluation: +2 (Super recommended!)
It's easy to understand the importance of "narrowing down the problem" in theory, but it's difficult to put it into practice. This book explains the necessary steps to increase productivity, starting with the motivation to solve problems, and provides a detailed and concise explanation of the approach and reasoning. The core of the book is "narrowing down the problem", which is thoroughly explained.
I felt that there were many important points for engineers, especially for those who are responsible for a wide range of software development. I think this book is highly recommended for them.
Each chapter includes key points that I thought were important, along with fictional failure examples from an engineer's perspective, so it's interesting to read while imagining the scenarios.
Introduction
Increasing Productivity Requires "What to Answer" Clarity
This book's main theme is to start with the issue. I'll introduce it here, and the details will be explained in the following chapters. Note that "productivity" is not just about completing tasks quickly, but about achieving a higher output.
Engineer's Failure Example: Creating a perfect tool quickly, but it's not used by anyone, resulting in low productivity.
Don't Get Stuck, Think It Through
- Getting stuck: assuming there's no answer
- Thinking it through: building a logical framework to approach the answer
If you're stuck, take a break and reflect on your approach. It's essential to recognize when you're stuck and to re-examine your thinking.
Engineer's Failure Example: Spending a long time thinking about a problem, but not getting close to the answer. It turned out that the problem was different from what I thought (a common experience in competitive programming).
Chapter 1
Productivity is Defined by Output per Input
High output with low input is the key to high productivity. While input is easy to understand as the time and effort spent, what constitutes high output is a crucial question.
Engineer's Failure Example: Spending a year developing a calculator app using cutting-edge technology, but the productivity is low.
The Value of Work is Defined by Two Axes: "Issue Degree" and "Solution Quality"
The value of work is determined by the degree of the issue and the quality of the solution.
- Issue degree: the necessity of solving the problem in the current situation
- Solution quality: how clearly the solution addresses the issue
Engineer's Failure Example: Spending half a year tuning the application code to improve the speed, but it turned out that the problem was due to the framework's memory consumption, and increasing the instance's memory would have been enough.
To Increase the Value of Work, First Increase the Issue Degree
If you focus on increasing the solution quality without increasing the issue degree, you'll end up spending more time and effort, which can lead to decreased motivation and solution quality.
Therefore, it's essential to focus on increasing the issue degree (narrowing down the problem) first. By doing so, you can increase the solution quality through sufficient discussion and feedback.
Engineer's Failure Example: Wanting to create a popular smartphone app, but continuously creating To-Do apps using various technologies and languages, without achieving the goal.
Chapter 2-3
Defining the Issue
The issue is not about solving it, but about defining what needs to be solved.
It's crucial to have a clear understanding of the field and to have a knowledgeable advisor.
When defining the issue, don't stop at a vague point; instead, take a stance and create a concrete hypothesis.
- ✗ "What's happening to the users of aa?"
- ○ "Are the users of aa decreasing?"
Engineer's Failure Example: Being told to increase the number of users for a monthly subscription service, so I created a new LP and ran ads, but the number of continuing users didn't increase, and the ad spend exceeded the revenue.
Issue Hypothesis Must Be Verbalized and Made Clear
- Use clear subject-verb phrases
- Use "what", "where", and "when" instead of "why"
- Use comparative expressions
Engineer's Failure Example: Thinking about why the response time is bad.
What Makes a Good Issue?
- Essential choices
- = Key questions for the future
- Deep hypotheses
- Denying common sense and conventional wisdom
- Explaining with a new structure
- Answerable
- If the current method can't provide an answer, it's not worth tackling
Bad issues
- Unnecessary ones
- "Pseudo-issues" that don't require an answer
- Those that can be solved by changing the subject
- If it's not narrowed down enough, it's not a well-defined issue
Engineer's Failure Example: Renovating the UI to improve user experience, but it turned out that the real issue was the unnecessary notifications (a pseudo-issue).
Information Gathering for Defining the Issue
- Get primary information
- Know the basics
- Don't gather too much information
- Knowledge increases, but wisdom decreases beyond a certain point
If the issue is still unclear, the following methods can be used:
- Eliminate variables, fix them, and make them concrete
- Visualize (draw pictures or plots)
- Calculate from the final shape
- Repeat "So what?" to get to the essence
- Aka "five whys" analysis
- Consider extreme cases to find key variables
- What if the user count decreases to 1/10?
Engineer's Failure Example: Being told to create a tool because there's a demand from XX department, but it turned out to be useless for them, and we had to start from scratch.
Chapter 4
Analyzing the Issue
This chapter explains how to analyze the issue using the methods described above.
- Storyline
- Issue decomposition
- Not "collecting a lot of data and finding meaning", but "how to verify the hypothesis"
- "Answerable size" decomposition
- Divide into essential, meaningful chunks
- Story composition
- Premise sharing / issue definition / answers to each issue / direction
- Script-like work
- Effective types:
- Why-why-why: listing reasons for the final message
- Empty-rain-umbrella: confirming the issue / deepening the issue / conclusion
- Picture composition
- Creating an appropriate axis for comparison
- Including specific numbers
- Difference / change / pattern, which one is desired?
- Data collection method description
These will be rewritten as the discussion progresses.
Engineer's Failure Example: Team A took months to find the cause of performance degradation by analyzing user behavior logs, while Team B set up a hypothesis and collected data to verify it, finding the cause in a shorter time.
Engineer's Failure Example: Concluding that the current traffic requires an instance upgrade, but not creating a storyline, so the necessity wasn't recognized, and the budget wasn't approved.
Engineer's Failure Example: Not creating a picture composition, so the benchmark values were too detailed, and the necessary values weren't obtained.
Chapter 5
Analysis from Picture Composition
This chapter explains how to analyze the issue using picture composition.
- Focus on important sub-issues
- "Premise" and "insight"
- Be careful not to assume the answer
- Estimate the rough value beforehand
- Don't get stuck on the method
- Determine the necessary level of completion and don't overdo it
- Focus on speed rather than perfection
Engineer's Failure Example: Developing an in-house tool without prioritizing or scheduling, resulting in a year-long development period with many unnecessary features.
Conclusion
This book provides a systematic approach to problem-solving, which is highly valuable for engineers. The author's unique perspective as a consultant and biologist adds a fresh twist to the book.
The book's structure is easy to follow, and the "issue" is repeatedly emphasized, making it a great read. I think many engineers will find this book relatable and useful.
The fate of this kind of book is that it's easy to say but hard to do. The book concludes by emphasizing the importance of applying what you've learned and accumulating experience.
If you're interested, please give it a read. The Kindle version is also available.