SCRUM?

If anybody from outside the Engineering Team wants to "do SCRUM", then you have a problem. You should first ask yourself, where is this coming from? What do they think that SCRUM will solve? And then try to fix that. You will be much better off.

Documentation?

If somebody else outside the teams wants to have "documentation", then you might have another problem. This could mean a lot of things, depending on context, but most of the time, somebody is asking for what I call a "static documentation" for internal use. Again, the team needs to figure out what is the actual problem we would like to solve.

• Maybe there's a team of Customer Support/Success that needs to learn the product better and demands documentation.

If that's the case, why not make the actual product easier to understand? If a member from the CS team has problems understanding how something works, there's a high probability that the users feel the same way. So instead of writing some documents that are useful for a period of time and then get outdated, the team should consider making changes right in the product so that there is no need for this document to begin with.

• Maybe somebody feels that onboarding any new person to the team takes a long time

• Perhaps somebody feels that a new engineering team member takes too long until they understand how to provide value to the product

Product Options

A lot of times, there is a new feature put up on the "wanted" list. And when you look at it, or you ask questions about it, the conversation usually ends up with small decisions such as:

• let's include a toggle for that so that users can change something related to something else
• let's make that "configurable"
• let's do both options

If that's the case, it's a strong signal that the product is being built based on assumptions.

You know what's better? User-feedback. Proper ones. And then a product manager capable of asking the right questions, filtering through the noise and so on.