We read it at GitLab as part of a Product Bookclub. one of my best takeaways was using the uphill / downhill construct with my team when refine issues for the next iteration.

What were your thoughts on the decentralized backlog concept?

i’ll have to go brush up real quick . . . i don’t seem to remember that bit

hmm . . it’s an interesting idea that i think works for smaller orgs / colocated folks. Working at a fully remote company having all our issues out and searchable is what helps us collaborate and track interest in issues. As a PM I use that as a signal about what to tackle next

Gotcha, yeah I’m having a hard time imagining that being as practical as having a centralized backlog for the same reasons.

I’m also having a hard time agreeing with “memory” being a metric for how valuable a feature is.

I feel like we’re at an advantage with public backlogs. I can get customer upvotes on issues that matter and then interact with them about the problem the feature would solve to iterate to the right solution space. It was terrifying at first but i can’t imagine doing it any other way now.

I’ve used the memory approach and I feel we’ve had good success with it. I’ve also used tracking systems with some success, though I’ll admit I bias towards memory.

I’ve not used Shape Up but I did read about it last year when it came out, and we interviewed Ryan Springer on our podcast. https://soundcloud.com/troubleshootingagile/ryan-singer-on-basecamp-and-shape-up-part-i https://soundcloud.com/troubleshootingagile/ryan-singer-on-basecamp-and-shape-up-part-ii https://soundcloud.com/troubleshootingagile/ryan-singer-on-basecamp-and-shape-up-part-iii

I think there’s a lot to like about Shape Up, and one of the parts I like is how not generic it is. It is really tailored to their context. I think it could work well for other people in a similar context, or who make appropriate adaptations to their environment.

I think the elements that are least likely to be true in other environments: 1. similar UI/developer staffing split 2. level of empowerment of product people 3. product people doing enough design thinking up front to choose between alternatives of what to work on