benkan

Image a one-day sprint. Won't this be Kanban anyway?

Indeed! Engineering teams are built of people with different skills. But they all have to deliver value for the customer (and the company).

No, not a deliverable. I change in behaviour caused by that deliverable.

?

This is addicting. How did you provide the context? Did you provide the main theme of the story? The prompts to ChatGPT must me huge.

Then there wouldn't be a justification for architects and DB specialists to exist. It's a separation of skills into a designated role.

In general or only if there is a Product Manager? Why?

Yes, and i have seen teams working entirely without a formal backlog of user stories. Some use a large wall chart, some use a User Story Map without any kind of Scrum of Kanban process... in some teams this also works.

Maybe one of these link lists can help: https://www.leadinginproduct.com/p/link-books-useful-collect...

They are cheap and useful if you have sufficient time to read, especially the ones about team structures and recruiting. They contain more content about roles and structures.

https://www.leadinginproduct.com/

It's about product management, leadership, engineering organizations, and related topics. I still consider it personal because all of the content stems from personal experience.

And yet, software product managers mostly do not have managerial authority. They manage the product, not the people. But they need to influence the people anyway.

It could be email, but it also be Confluence, Notion, OneNote, or something like that. I understand that you think a chat solution like Slack or Teams or Mattermost is too "chatty", right?

I guess you're right about that. Do you need cycles of two weeks for that? (Scrum officially doesn't force two-week cycles, but it's still the norm)

How do you handle Continuous Deployment then? Only to Staging?

Note: I am a product manager myself I see the team of PM, Engineer, Design, Data, etc. as one team consisting of people with different skills. The skillset of a PM does not include coding, but it helps to have some technical understanding to discuss on eye level. The skillset of a software developer does not include user understanding (for example), but it helps to have some idea of user situation to discuss on eye level. If all functions understand what the others do, the team will be successful.

In my opinion, your experience of product managers sounds like people with poor understanding both of the job of a dev and of the job of a PM. No blame.

Called ‘the hat’, the 13-sided shape can be arranged in a tile formation such that it never forms a repeating grid

When you experiment with a new-to-you data science skill, you need some sort of data to work with. Why be boring?

Notion alternatives for notes, project management, spreadsheets, and whiteboard collaboration

Thank you!

Has anyone more information or a freely accessible link?

The vendor would have a problem with disincentivized usage becaused in the model, it earns the money purely by usage. It is a commercial problem, not a technical one. The company wishes to earn money, yet puts in place a model that decreases its only revenue driver.

I believe that usage-based pricing is valuable to the customer, but I see one problem for the vendor: If each use of the product is billed, this provides an incentive NOT to use the product. In other words, you actively drive usage down.

I'm not saying that I am against usage-based pricing or that it does not make sense, but especially in B2C markets, this might be a problem.

Interesting. The article suggests a "Western" smile culture, but there is also a difference between Americans and Europeans when it comes to smiling.

Scrum is beyond its peak. It is a framework that with diminish in importance and will eventually die. But in today software world, Scrum is just too slow.

Engineers set up pipelines for Continuous Integration / Continuous Deployment in the meantime. Changes can be applied weekly, daily, or even hourly. That actually happens in productive systems:

Use this cheat sheet to move beyond the awkward 1:1 meeting silence, no matter of you are the manager or the employee.

This meeting is not about current operational problems, current operational developments, Jira issues, bug reports, or deadlines. This meeting is a reserved space, usually happening once a month, to talk and think about things like personal concerns, wishes, career goals, fun at work, chances for the company or the employee, or motivation.

I agree. Product managers can build a kind of product instinct or product sense. If you combine that with data, results are best. That's why "data-driven" is not the best approach. A "data-informed" approach uses data and combines it with a strong, opinionated product manager's product sense.

Do you automatically parse Slack messages or is this manual work? I would imagine that manually readign through all these messages is a lot of effort, so ideally you would automate the entire process.

The process of building the digital product management stack: A resource list for tech product managers. Saved first in bookmarks, then in Wordpress, now in Airtable.

Thank you!

BeOS! Good memories. I tried out BeOS maybe 20 years ago until it was dropped. Is it still maintained?

I recommend setting goals first. If you know what is important to you (your goals), how will you know that you're moving towards your goals? You need to measure that somehow. These are your KPIs, and data, or analytics. Check out the OKR framework for a popular version of goal setting and measurement.

Furthermore, if you decide on core fatcs about your product, you should monitor whether you notice any changes. Is the display of the footer your third-level page important? Maybe not. Is the number of conversions on your home page important? Probably so. So you should monitor the latter just to see changes early enough.

If you change somethings, you can make experiments and compare historical data to experimental data. Does data change for the better or for the worse?