> There is no point to having a large backlog because the bigger the backlog, the higher the unvalidated assumptions, and the lower the chance that it creates any customer value. I have made too many mistakes assuming that something is valuable, when nobody cares about it. A large backlog should be looked at with an extremely high degree of skepticism, as the size of your backlog is inversely proportional to how often you talk to customers.
This needs a gigantic "YMMV, depends on the type of product and customer, etc" attached to it.
I used to be the PM for a large and complex set of developer tools. The only reason a very large backlog would be filled with unvalidated assumptions is if someone filled the backlog with unvalidated assumptions.
In my experience, a very large backlog can also be filled with validated assumptions, and the way one does this is by talking to more customers.
I can understand an early-stage product having things in the backlog that are unvalidated that probably came from ideation and spitballing sessions in the early stages of planning.
But I would strongly disagree with the premise that "Backlog size is inversely proportional" is a reliable rule of thumb.
I agree that it is critical to make sure the things a team is building provide actual value and will benefit real customers. I think this would be better framed as "Talking to customers is critical to ensure you're building the right things".
This needs a gigantic "YMMV, depends on the type of product and customer, etc" attached to it.
I used to be the PM for a large and complex set of developer tools. The only reason a very large backlog would be filled with unvalidated assumptions is if someone filled the backlog with unvalidated assumptions.
In my experience, a very large backlog can also be filled with validated assumptions, and the way one does this is by talking to more customers.
I can understand an early-stage product having things in the backlog that are unvalidated that probably came from ideation and spitballing sessions in the early stages of planning.
But I would strongly disagree with the premise that "Backlog size is inversely proportional" is a reliable rule of thumb.
I agree that it is critical to make sure the things a team is building provide actual value and will benefit real customers. I think this would be better framed as "Talking to customers is critical to ensure you're building the right things".