<story><title>Backlog size is inversely proportional to how often we talk to customers</title><url>https://bitbytebit.substack.com/p/the-size-of-your-backlog-is-inversely</url></story><parent_chain><item><author>idopmstuff</author><text>In my experience, this depends a lot on how you organize possible features&amp;#x2F;improvements&amp;#x2F;etc.&lt;p&gt;I hate the strategy of just taking every idea you hear and throwing it into a ticket. You just end up with this giant icebox of stuff you&amp;#x27;ll never do. If a big new prospect demands one of the ideas that&amp;#x27;s in the icebox be implemented immediately in order to close a deal, you&amp;#x27;re probably still not going to pull it out of the icebox, because you don&amp;#x27;t remember that it&amp;#x27;s there. Instead, you&amp;#x27;ll just create a new ticket for it, and eventually when going through the icebox, someone will go &amp;quot;hey, I think we built this already&amp;quot; and close as dupe.&lt;p&gt;Instead, I strongly prefer to have tickets that at least have some possibility of getting done in the short to medium term, and store other ideas elsewhere. Engineering keeps a list of tech debt that they&amp;#x27;d like to address. PMs keep one list per project of possible improvements. For potential new features&amp;#x2F;products, they write PRDs but don&amp;#x27;t immediately turn them into a bunch of tickets.&lt;p&gt;Ultimately I think the giant backlog of stuff that mostly won&amp;#x27;t get addressed is a sign of weak PMs who are afraid to say no and like to fall back to the comfortable answer that is, &amp;quot;sounds interesting, I&amp;#x27;ll write a ticket for it.&amp;quot;</text></item></parent_chain><comment><author>doix</author><text>I totally agree. The worst thing is going directly from feedback -&amp;gt; ticket. Not only because of what you describe, but also because you end up with a product that is just a list of features without a coherent &amp;quot;idea&amp;quot;. Especially when you&amp;#x27;ve got eager developers that will see some slack in the schedule and just pick up a random ticket because it&amp;#x27;s &amp;quot;easy&amp;quot;.&lt;p&gt;Usually when customers give feedback it&amp;#x27;s to address an immediate need they have, so they&amp;#x27;ll suggest adding a button&amp;#x2F;option&amp;#x2F;toggle&amp;#x2F;whatever. And that&amp;#x27;s fine, but if you do that for every piece of feedback, you&amp;#x27;ll end up with an unusable mess. Especially because it&amp;#x27;s usually very easy to add that one extra button&amp;#x2F;option&amp;#x2F;toggle.&lt;p&gt;You usually require someone to go through all the feedback and try to address the root cause of what they&amp;#x27;re asking for. Sometimes the extra option is unavoidable, sometimes it leads to redesigning some system to be more generic to support what the customer wants + more.&lt;p&gt;I do think the feedback needs to be linked to the work somehow, not hidden away in a separate PM tool or whatever. Ideally retaining the raw feedback, because sometimes when summarizing it, things get lost.</text></comment>
<story><title>Backlog size is inversely proportional to how often we talk to customers</title><url>https://bitbytebit.substack.com/p/the-size-of-your-backlog-is-inversely</url></story><parent_chain><item><author>idopmstuff</author><text>In my experience, this depends a lot on how you organize possible features&amp;#x2F;improvements&amp;#x2F;etc.&lt;p&gt;I hate the strategy of just taking every idea you hear and throwing it into a ticket. You just end up with this giant icebox of stuff you&amp;#x27;ll never do. If a big new prospect demands one of the ideas that&amp;#x27;s in the icebox be implemented immediately in order to close a deal, you&amp;#x27;re probably still not going to pull it out of the icebox, because you don&amp;#x27;t remember that it&amp;#x27;s there. Instead, you&amp;#x27;ll just create a new ticket for it, and eventually when going through the icebox, someone will go &amp;quot;hey, I think we built this already&amp;quot; and close as dupe.&lt;p&gt;Instead, I strongly prefer to have tickets that at least have some possibility of getting done in the short to medium term, and store other ideas elsewhere. Engineering keeps a list of tech debt that they&amp;#x27;d like to address. PMs keep one list per project of possible improvements. For potential new features&amp;#x2F;products, they write PRDs but don&amp;#x27;t immediately turn them into a bunch of tickets.&lt;p&gt;Ultimately I think the giant backlog of stuff that mostly won&amp;#x27;t get addressed is a sign of weak PMs who are afraid to say no and like to fall back to the comfortable answer that is, &amp;quot;sounds interesting, I&amp;#x27;ll write a ticket for it.&amp;quot;</text></item></parent_chain><comment><author>roenxi</author><text>Although the approach seems fine, I don&amp;#x27;t think it creates an advantage. The situation is there are tickets in progress that have engineering consequences and then there is the backlog. How the backlog then gets used is 100% a question of convenience and &lt;i&gt;any&lt;/i&gt; approach that works for the decision makers is fine. If they want to use the backlog as a way to plan upcoming work (as you seem to do) that is fine. If they want to use the backlog as a diplomatic tool to say no gently, also cool.&lt;p&gt;JIRA + a tree of tickets is so bad for project planning I recommend using the backlog as a diplomatic tool and a polite way of letting things get lost. It is is better to use advanced scheduling tools, like a spiral-bound notebook or sticky notes, rather than a backlog. The backlog is for management and politics.</text></comment>