When we invest in a new firm, I spend the first few weeks getting to know the team to grasp their present issues and offer assistance where possible. The product lifecycle is a frequent topic, from establishing a north star to generating a documented plan to executing and delivering a successful product. I jotted down some of the essential things during the meetings last month. I wanted to emphasize some of the most prominent issues of contention.

Customer-Specific Requests

‍

While I believe that consumers should be a driving force in the roadmap, my advice is to always include a process of interpretation and generalization to client feedback. Many issues/features in some backlogs are identified with a customer name. Instead of "fixing problem y for customer x," it is always preferable to first identify whether additional customers have difficulties similar to y and then develop a feature Y' that would address the more general concern. When it is unclear how this problem pertains to other clients, take a step back and allow yourself more time to find out a pattern.

One option is that the client requested while playing Product Management, which means they had ideas but no proof. A second possibility is that the problem exists. However, your PM did not wholly comprehend its exact nature, making it impossible to compare among clients. Finally, while this consumer may be ahead of the curve and entirely on point, in my experience, this third situation is uncommon. It is frequently connected with the same handful of intelligent customers. Many customer-specific demands are associated with extended onboarding durations, and it is prevalent among organizations straddling the border between services (unwanted) and pure software business models.

Code Monkey" Paradox

‍
Engineers fear becoming code monkeys, a strategy in which they are taught precisely what to do and deprived of creativity. In contrast, when a deliverable needs to be revised, the same engineers frequently argue that the initial specification was insufficiently resilient. Contrary to popular belief, increasing the depth and specificity of requests sent to engineering causes the team to grow progressively poorer at understanding any gaps in a product specification. As a result, a negative feedback loop is created. The makers in the team will become less intuitive, feel less ownership, and offer fewer outcomes as more information is moved from execution to planning. This eventually affects not just the team's conduct but also a self-selection process in which the more autonomous engineers leave, hastening the downfall. The solution requires developers to understand the product and take responsibility for their initiatives' results. Instead of presenting a comprehensive prescription for how to build a solution, the product should focus on a high-level description that emphasizes what the problem is and why it is significant.

Code Reliability vs QA

‍

A powerful QA function frequently results in a negative feedback loop, which leads to poorer code over time. Engineers on the best teams are held accountable for the quality of their code. A team with a low tolerance for defects and a high level of responsibility will innovate to eliminate underlying causes. There will always be defects in production, but when issues are examined, the underlying cause is identified, and permanent mitigations are deployed, the identical bug will never occur again. For example, suppose a developer creates a DELETE query with insufficient restrictions, resulting in a disaster in production. In that case, the same developer may add a clause to their query engine that only performs DELETES if they affect fewer than ten records or throws an error otherwise. Is it common for defects to be caused by a specific individual or team? Are problems often found in a particular service or section of the codebase? Is flawed code more likely to be deployed on Fridays and weekends? Each section will disclose a pattern, which a mechanism or automation can mitigate. Finally, devote effort to investigating non-trivial issues and sharing the findings of root-cause analysis and long-term mitigations with the team. Mistakes will be made, but the number may be decreased if the entire team learns from the mistakes of a single individual. Aside: wherever feasible, utilize data identical (or very close) to production on local computers and staging servers, even if it necessitates additional workarounds to comply with privacy requirements.

Effectiveness > Efficiency (Thematic Roadmaps)

‍

It is easy to conceive software engineers as a fungible resource capable of doing adequately partitioned jobs at a consistent velocity and within predictable deadlines. Individuals are far more productive when they can focus on one problem at a time and have the space to delve deeply into the subject to discover novel solutions. In other words, a good team is less efficient at work allocation, but they are more likely to meet your objectives. An efficient team will appear productive on paper but, in reality, will achieve less. Instead of giving various jobs to developers, I advocate allocating time to aggregate many activities into 2-4 week-long projects focused on a single problem. This frequently results in the team not focusing on the top ten tasks but instead building themes around the top three and locating other issues more profound in the backlog that correspond with them. A product manager's genius is the ability to elegantly weave activities into a captivating story that directs and encourages engineers to achieve something more significant than the sum of chores. Each project should ideally be coupled with a goal (site speed, conversion rate, NPS score). The developer's performance should be measured not just on performing allocated tasks but also on achieving desired business results.

Aesthetics != Design

‍
People frequently mix the broad notion of design with the specific aesthetic feature. For the great majority of things, the most significant design concern is functional design. Specifically, if the product has the appropriate ergonomics to allow the user to navigate the needed processes as smoothly and painlessly as feasible. Indeed, we want our product to have an age-appropriate appearance and feel. However, relying on existing assets, whether open source or for sale, is readily accomplished. When it comes to software, in most circumstances, aiming for a unique style will have a negligible commercial impact at best and harmful ramifications at worst. Iteration is required to create a new design aesthetic, which will take cycles of front-end development, user testing, and so on. Aesthetics are also entirely subjective; thus, the project can swiftly become Frankensteinian if a team has regular designer turnover. Using a well-established design system, such as Material, on the other hand, offers developers an instant library of components for various front-end stacks. Furthermore, starting with a well-established style does not exclude us from injecting individuality into the design through the color palette, typography, white spaces, and unique features.

‍

‍