Maybe you&#x27;re not saying &#x27;no&#x27;, you&#x27;re saying &#x27;not now&#x27;.<p>Is it possible to go to the co-founder and suggest that only features which customers will use&#x2F;buy get built? If it doesn&#x27;t add to sales, or have some actionable metric as to why it is being added to the product, it doesn&#x27;t get done. 
This works for engineering too. No &#x27;refactoring&#x27; if it doesn&#x27;t have a measurable benefit to the company.<p>By taking this approach, the hope is that 1) the co-founder takes the time to consider what is most important, 2) can articulate that to you 3) the dev team understands why they are building the feature.<p>For each feature in dev, have the co-founder write out the reason it is being built.<p>Here&#x27;s an example on the current product I&#x27;m working on.<p>1) We&#x27;re redoing the search page because x% of users leave the site from that page without taking futher action. We aim to lower that number to x%<p>2) We&#x27;re refactoring component x because it loads on every page and is far too slow. We&#x27;ll improve response time by 600ms. This will extend page view time by x seconds and increase views by x%<p>3) We&#x27;re going to stream our large files where we currently download the entire thing which causes customers to wait for x seconds. We&#x27;ll see an x% improvement in page load, resulting in x more page visits.<p>You get the gist.<p>At first, I&#x27;d suggest the co-founder &#x27;might&#x27; just make stuff up. But if you have something in writing that you can point back to, and then go back to him if it doesn&#x27;t match up, he&#x27;ll hopefully start giving it more thought.<p>On the flip side, it is also possible that the co-founder has good reasons to request these features but maybe hasn&#x27;t communicated them well to you and the rest of the dev team.