When you code, you either produce a working program or you don’t. There isn’t partial credit for a program that mostly works. Even if only one line is written incorrectly within a hundred lines of working code, the entire feature is considered broken. Oftentimes, these types of small errors creep in when you are only able to give your work half your attention. Therefore, a common pre-requisite to producing great code is having uninterrupted “maker time” when you can dive deeply into a problem to figure out its solution.
In contrast, there is the concept of “manager time” where work can be done in piecemeal fashion and still lead to results. However, I believe that being effective in any endeavor, including management, requires a period of intense focus. In product management, the feedback loop simply isn’t quite as immediate, which has lead to the flawed conclusion that long periods of concentration are unnecessary for good work.
When a product manager digs through data spreadsheets, users insights and competitive analysis, a meaningful amount of raw processing power is required to synthesize and organize all of the information. The results of this process are usually tickets, specs, and requirements, which can be categorized as the action steps for the team. Next, a product manager has to lead the team in executing on these action steps to build product features and enhancements (and to fix bugs). After that, code gets shipped and consumers start to react to the new changes. Then, data starts to pour back in about how the product is doing – How do customers like feature X? How is engagement with feature Y trending? Finally, the product manager analyzes that data and uses it to inform the next round of decisions.
Sometimes, this full cycle can take weeks, or even months, before the company can make any type of conclusive judgment the on how well the manager did in deciding on the plan of action. It is clear though that the plan of action plays an integral part in determining the success or failure of the product. If the right feature wasn’t prioritized or if the wrong feature was cut from the roadmap, then there are consequences. Similarly, if the wrong view is being rendered or if the wrong variable was being passed to a method, there are also consequences.
However, in the latter situation, the feedback is almost immediate. If you run a broken function, an exception is thrown. Maybe the error is caught later on by QA. In either case, you as the programmer know pretty quickly that something isn’t working. And a common cause of these errors is writing complex code when you’re not focused.
Granted, managers can check email or sit through meetings in varying bursts of time, but if they are to come up with effective roadmaps and clear action steps, long periods of concentration are absolutely necessary. It may not be immediately apparent that product managers are doing maker-type work due to the long feedback cycle, but in reality, even managers need a maker’s mentality in order to be effective at their jobs. Or, perhaps another way to look it is just that we are all makers.