Coté's Commonplace Book #40

“For the six months ending April 30, 2018, SUSE saw revenues of $182.9 million, which represents continued growth of approximately 17 percent over the same period in the previous year. Adjusted EBITDA for that period was $56 million, nearly 23 percent year-over-year growth.”

Good discussion of doing product management instead of project management. Also, discussion of user metrics to track design and usability:

“Defining success metrics helps you focus on what’s important in your product and how well it solves the problems you’ve identified. Defining key steps the user must take is also important in order to shine a spotlight on where in the process users are failing. With this data, you can conduct further in-person research to understand why they are failing and devise an even better solution.”

‘That discussion starts with a very concise and useful distinction between project management (the world the government knows) and product management (the world it doesn’t). Project management, they write, is “focused on managing to a plan” – such as managing schedule, budget, risk, policy compliance and then reporting status to stakeholders. “Success for a project manager is delivering a defined scope of work on-time and on-budget,” Johnston and O'Connor note. Product management, meanwhile, “is focused on delivering a product a user wants or needs.” Success for a product manager “is delivering a product that users love — and use to complete tasks (or in the private sector — a product customers will pay for).”’

“In a high level, projects are local optimization efforts. We get a group of people who create new (or improve existing) functionality for our customers and then we pass that onto a team that has no idea why the change was made and how this change was solutioned/implemented. Very often, the quality is low and this Maintenance team needs to deal with the issues. This creates a culture of tolerating low quality, accepting that maintenance/operation teams will deal with problems created by delivery teams, not allowing delivery teams to learn from their mistakes and hence keep repeating them, allow budgets to be set without proper data, treat people like easy-to-replace objects, and so on. This culture is ok with low expectations and tends to increase debt in many aspects like technical, product, talent, innovation, etc. As such, these organizations often run in reactive mode and are constantly catching up with what the competition has brought to the market. Changes are expensive and take too long to get in the hands of the customers.”

Good example of corpdev thinking:

“The preponderance of drugs in the U.S. is consumed by an older population, whose habits change slowly or not at all. Accordingly, it’s likely that Amazon’s online pharmacy will not significantly impact the existing drug industry…. Here’s why: Americans currently spend $450 billion a year on drugs. Walmart is the fourth-largest pharmacy in the U.S., with sales of $21 billion, or 4.6% of the company’s total sales. Let’s say that over the next five years Amazon gets to Walmart’s sales level of $21 billion. If the U.S. pharmaceutical industry grows 2% a year over that time, total drug sales will have increased by $45 billion, or the equivalent of two Walmarts (we are ignoring compounding here), to $495 billion. Walgreens, with its pharmacy selling about $70 billion a year, would barely notice Amazon’s presence.”

‘“There is no doubt in my mind that DIUx will not only continue to exist, it will actually — it will grow in its influence and its impact on the Department of Defense,” Mattis said in a press conference.’

“It seems to me that in our meetings so far we’ve seen many many helper-types — supporters, planners, document writers, and so forth,” he went on. “But it’s a very rare event when we have a meeting with what I would consider to be programmers. One of my most fun questions is to sit in a room with 20 executives, shall we say, and say how many programmers and it turns out there’ll be two — of which one is being transferred for some stupid reason to some other base.”

“The metrics can be broken down into four broad categories — deployment rate metrics, response rate metrics, code quality metrics, and program management, assessment, and estimation metrics.  The DIB also provides general timeframes for what a “good” score looks like for each metric.”

“It’s too soon to have a good sample size. But it seems to usually work. I think it works because there is nobody at Mr. Smith’s workplace – maybe nobody in the entire world – who cares whether Mr. Smith brings a chair into work. Somebody wrote up a procedure for employees using special chairs, so that they’re not the sort of cowboys who make decisions without procedures. Somebody else feels like they have to enforce it, so that they’re not the sort of rebel who flouts procedures. But nobody cares.”