Product Management

Going through “Product Management in Practice” by O’Reilly publishing, written by Matt LeMay, I found this amazing classification of bad types of product management. Some of us been in one of those roles at least once, so I’ll simply quote those types. The Jargon Jokey The Jargon Jockey wants you to know that the approach you’re describing might make sense if you were working in a hybrid Scrumban methodology but is simply unacceptable to a certified PSM III Scrum Master. (If you had to look any of that up, the Jargon Jockey is shocked by your incompetence—how did you even get this job?) The Jargon Jockey defines words you haven’t heard with other words you haven’t heard and seems to use those words more and more when there’s a high-stakes disagreement playing out. ...

Within organizational debt, there is a volatile subset most likely to come abruptly due, and I call that subset organizational risk. Some good examples might be a toxic team culture, a toilsome fire drill, or a struggling leader. These problems bubble up from your peers, skip-level one-on-ones, and organizational health surveys. If you care and are listening, these are hard to miss. But they are slow to fix. And, oh, do they accumulate! The larger and older your organization is, the more you’ll find perched on your capable shoulders. ...

However, the real productivity killer is not system rewrites but the migrations that follow those rewrites. Poorly designed migrations expand the consequences of this rewrite loop from the individual teams supporting the systems to the entire surrounding organization. If each migration takes a week, each team is eight engineers, and you’re doing four migrations a year, then you’re losing about 1 percent of your company’s total productivity. If each of those migrations takes closer to a month, or if they are only possible for your small cadre of trained engineers—whose time is already tightly contended for—then the impact becomes far more pronounced. ...

A function-oriented structure in which firms have “vertical” groupings such as Marketing, Finance, Operations, R&D, or Customer Service. Each function has a specialty, and these specialties are critical to the performance of the firm. This kind of structure is effective when the organization’s product lines are fairly narrow or serve defined market areas. The Product Manager’s Survival Guide. And now for product-oriented structures: A** product-oriented **structure is commonly used by midsize to larger firms that are divided into product groups, product lines, or even product divisions. ...

While going through the second chapter of Shape Up book, just want to summarise some of the key points of it. Real-world scenario with “calendar feature” was perfectly broken down to the points, except of “point-zero” that is constantly missed out in Cyprus: With only six weeks to work with, we could only build about a tenth of what people think of when they say “calendar.” The question became: which tenth? ...

Basecamp started off in 2003 as a tool we built for ourselves. At the time we were a consultancy designing websites for clients. Information would get lost in the game of telephone between the client, the designer, and the person managing the project. We wanted Basecamp to be a centralized place where all parties could see the work, discuss it, and know what to do next. It turned out lots of companies had this “information slipping through the cracks” problem. Today millions of people across all kinds of industries rely on Basecamp as their shared source of truth. ...

If you’re still not convinced by this, there’s a more details version of it here.

Github recently released its annual report - Octoverse 2018. Ben Halpern descried an interesting fact about the use of emojis in in Github issue tracker. According to Github infographics in the report, “the kindest” development community is Ruby developers. In a sense of support and appreciation for other developers via the use of emojis. Some might say that this metric won’t say much about the “the kindness” of the community. So you might consider also the age distribution of the developers. As younger generation use emojis more often, I would still consider Ruby programming language as a young one (it’s mid 90s). ...

Among numerous metrics on code evaluation (like CRAP index) in product lifecycle, code churn seems to be the one to look for while dealing with post-release and legacy code elimination. Code churn helps you to evaluate file changes across builds. Code churn is a good predictor of post-release defects. Thus, it’s a warning sign if you approach a deadline while your code churn increases. That’s a sign that the code gets more and more volatile the closer you get to your deadline. You want the opposite. You want to stabilise more and more code the closer you get to delivery. > > Codescene Code Churn features One of the features of code churn - is bottleneck finding across developers and tasks. Low commit rates per author can signal the management, that there’s some sort of problem going on: ...

HubSpot tech blog published great article on job balancing and tech leads paradox of gatekeepers gardeners. You might be a gatekeeper if: your team regularly waits for you to review their PRs. your team waits to do the next thing assigned to them instead of taking initiative to find projects for themselves you hesitate to go on vacation because you’re concerned your team will struggle in your absence On the opposite. A gardener might: ...