Thoughts on "Start with the Issue"

I have finished reading "Start with the Issue", which is recommended in various places.

イシューからはじめよ――知的生産の「シンプルな本質」

安宅和人 (著)

Amazon

Overall rating: +2 (Highly recommended!)

Although I understand in my head that "narrowing down the problem to be solved" is important, it's often difficult to put into practice. This book describes the necessary steps from the motivation of "increasing productivity", and explains the specific approach and rationale. The core is "narrowing down the problem", which is described in detail and concisely.

As I'll mention at the end, I felt that there are many points that are important for engineers as well, and I think this book can be recommended especially to those who are responsible for a wide range of software development.

For each chapter, I've added points I thought were important and fictional failure examples from an engineer's perspective on "what would happen if you didn't follow this". It might be interesting to read while imagining these scenarios.

Introduction

To increase productivity, it's important to be clear about "what to answer"

This is the main theme of this book, that is, to be issue-driven. Since details will come in later chapters, only the proposition is made here. By the way, when you hear "productivity", the "speed of completing a certain task" that comes to mind is one factor in improving productivity, but not everything.

Engineer's failure example: Even if you quickly and perfectly create a tool that no one uses, productivity is low

Don't worry, think

• Worrying: Assuming there's no answer
• Thinking: Constructing logic to get closer to the answer assuming there is one

If you've been thinking seriously for a while and can't make progress, you might be worrying. It's important to take a break and reflect on what the answer is, whether you're constructing logic to get closer to the answer. It's good if you can realize "Ah, I'm worrying now" (requires training).

Engineer's failure example: I spent a long time thinking about (worrying about) a solution to a problem, but didn't get any closer to the answer. In fact, the problem to be solved was different (common in competitive programming)

Prologue

Productivity is output relative to input

The more you achieve low input and high output, the higher the productivity. Input is easy to understand as it's the time and effort spent, but what is high output? This topic continues next.

Engineer's failure example: Even if you spend a year creating a calculator app with cutting-edge technology at the time, productivity is low

The value of work is defined by two axes: "issue degree" and "quality of solution"

High output = defined as doing high-value work. And the value of work is determined by two things: "issue degree" and "quality of solution".

• Issue degree: The necessity of answering this problem in your current situation
• Quality of solution: The degree to which you can clearly answer that issue

Engineer's failure example: The API of a service right after release was slow, and the cause was found to be memory swapping. I spent half a year doing meticulous tuning on the application code and somehow regained the necessary speed. However, it was just the framework consuming memory regardless of the increase in the number of users, so it would have been enough to just increase the instance memory a little

To increase the value of work, first increase the issue degree

If you try to increase the quality of the solution before increasing the issue degree, you have to work on many low issue degree tasks. As a result, the time taken increases, there's no such thing as hitting the mark if you try many times, motivation decreases, and the quality of the solution also decreases.

Therefore, first focus on increasing the issue degree (narrowing down the problem). By providing sufficient consideration time, outputting solutions and receiving feedback, the quality of the solution increases.

When considering the issue degree, it's important to disregard "ease of solving" and "ease of tackling" (it's easy to filter here).

It's important to focus on the "right problem" and do the "right training" (... it's easy to say in words, but there are many things we can't do...)

Engineer's failure example: Wanting to eventually create a popular smartphone app, I continued to create ToDo apps using various technologies and languages. As a result, I couldn't create a popular smartphone app

Chapter One

Identify the issue

Problems should not be solved first, but start by identifying "what to answer".
It's also important to have a conversation partner who is familiar with or knowledgeable about the field.

When identifying, don't stop at a vague point, but take a stance and form a specific hypothesis.

• ✗ "What's happening with aa users?"
• ○ "Are aa users on a declining trend?"

Engineer's failure example: In a subscription service, I was told "The number of users is decreasing, so take measures!" So I increased the number of new users by running ads and improving the LP. However, the real issue was with the continuation rate, and the number of continuing users didn't increase, so sales didn't exceed advertising costs

Always verbalize issues and hypotheses to reduce fluctuation.

• Include subject and verb to eliminate ambiguity
• Not Why, but What/Where/When
• Include comparative expressions

Engineer's failure example: "Let's think about why the response time has deteriorated"

What is a good issue

• Essential options
  • = Questions that will be key in the future
• Deep hypothesis
  • Denial of common sense and assumptions
  • Explanation in a new structure
• Can be answered
  • If there's no prospect of answering with current methods, there will be no output even if you work on it

Bad issues

• Those that don't really need to be answered
  • Named "pseudo-issues"
• Those that hold true even if the subject changes
  • If sufficiently narrowed down, it should be an issue limited to the subject

Engineer's failure example: As the number of users was decreasing, I did a large-scale code rewrite for UI improvement. However, when I later conducted user interviews, the problem was "too many unnecessary notifications", which wasn't improved in the renewal (pseudo-issue)

Information gathering to decide on issues

• Touch primary information
• Know basic information (common sense)
• Don't collect or know too much
  • Knowledge increases, but wisdom dulls after a certain amount of knowledge

If you still can't decide, the following methods can be used.

• Delete, fix, or concretize variables
• Visualize (draw pictures, plot)
• Work backwards from the final form
• If only obvious things come up as issues, repeat "So what?"
  • The so-called why-why analysis
• Consider extreme cases and explore key variables
  • What if the number of users became 1/10? etc.

Engineer's failure example: I was told by someone in the company, "There's a voice in XX department wanting a tool that does ○○, so please create it." I made it as told, but when it was done, XX department said it was unusable, and we had to start from specification planning again

Chapter Two and Three

Analyze issues to improve the quality of the solution

Issue analysis is done by writing the following.

• Storyline
• Decomposition of issues
  • Not "create a story by considering the meaning from a large amount of collected data", but think "how can these be verified if the hypothesis is correct"
• Decompose into "answerable size" and essentially meaningful chunks
• The following patterns are effective
  • Decompose into three: Where/What/How
  • Work backwards from the final form
• Storyline assembly
  • Sharing premises / Defining issues / Answering each issue / Direction to aim for
  • Work equivalent to scriptwriting and naming
• The following patterns are effective
  • Lining up Whys: Parallel reasons for the final message
  • Sky-Rain-Umbrella: Flow of confirming issues / deepening issues / conclusion to reinforce the conclusion
• Storyboard
  • Create appropriate comparison axes
• Insert specific numbers
  • Consider whether you want difference / change / pattern, and make it into a figure
• Write down the method of data acquisition

These are rewritten as the examination progresses.

Engineer's failure example: Team A speculated the cause of performance degradation from user number trends and behavior logs. This took time, and it took several months to find the true cause. On the other hand, Team B set hypotheses such as "memory consumption proportional to the increase in the number of users" and took the approach of creating tasks and collecting data to verify them, identifying the cause in a shorter time

Engineer's failure example: I concluded that to handle the current traffic, we need to upgrade the instance type by one level. But when I communicated the conclusion without assembling a storyline, the necessity wasn't recognized and the budget wasn't approved

Engineer's failure example: Because I took benchmarks of each module without drawing a storyboard, I didn't know if I could omit too detailed values or unrelated data, and in the end, I didn't take the necessary values

Chapter Four

Analysis from storyboard

The phase of analyzing and outputting results based on the storyboard.
It's easier if you pay attention to the following.

• Start with the important ones among the sub-issues
• "Premises" and "insights"
  • Be careful of analysis with "predetermined answers"
  • It's smoother if you estimate approximate values in advance
  • Don't stick to methods
• Identify the necessary level of completion and don't overdo it
  • To increase completion, it's better to quickly summarize and go around once more than to do each one carefully
  • Prioritize speed

Engineer's failure example: In the development of an in-house tool, we entered the phase of implementing by module units. We started development without prioritizing or scheduling, and after a while, when we asked each module's person in charge, we found things like "libraryizing parts that aren't used elsewhere", "code with extremely low memory consumption but zero readability", "overly high-function UI". The integration test was a mess, and it ended up taking a year until operation

Chapter Five

How to effectively turn the results so far into papers or slides.

• Assume the receiver (reader) is "intelligent but ignorant"
• Focus only on the essential and simple
• Refine the storyline
  • Check logic / Refine flow / Prepare for elevator test (pitch)
• Refine charts
  • Message along the issue / Refine axes / Figure according to the message

Engineer's failure example: I showed the cost reduction from container clustering as a percentage and explained it to the management along with the development advantages. However, it didn't convey well how much the expenses would decrease, and in the end, it wasn't adopted

Summary

The explanation is systematic and the claims are very easy to understand. Also, because the author is both a top-tier consultant and a biologist, he provides new perspectives and interpretations that are not found in similar books.

The structure of the book is also easy to understand, and by following it in order, you can experience the process of answering a single issue and summarizing the results. Also, it checks "Is the issue not wavering?" at key points, so important things are repeatedly imprinted.

As engineers also do problem-solving work, there are many things that are common, relatable, and experienced. The above failure examples are fictional stories, but I think various examples will come to mind when engineers read them.

And the fate of this kind of book, easier said than done. This book also mentions this at the end. It's essential to actually apply what you've learned and gain experience.

If you're even a little interested, please give it a read. There's also a Kindle version.

イシューからはじめよ――知的生産の「シンプルな本質」

安宅和人 (著)

Amazon