3 ms·

I'd really appreciate an article that explained how to say "no" to stakeholders diplomatically. Most engineers and product people understand the danger of featu

I'd really appreciate an article that explained how to say "no" to stakeholders diplomatically. Most engineers and product people understand the danger of feature bloat but are at frequently at the mercy of people who don't. I lead a small engineering team at a product company working for non technical cofounders and this is the hardest thing about my job. Two policies I've implemented have helped me a great deal: 1) We must thoroughly discuss the problem before proposing solutions 2) New features must be discussed and fully fleshed out at least three weeks before they can be built.

pedalpete 11y ago
Maybe you're not saying 'no', you're saying 'not now'. Is it possible to go to the co-founder and suggest that only features which customers will use/buy get built? If it doesn't add to sales, or have some actionable metric as to why it is being added to the product, it doesn't get done. This works for engineering too. No 'refactoring' if it doesn't have a measurable benefit to the company. 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. For each feature in dev, have the co-founder write out the reason it is being built. Here's an example on the current product I'm working on. 1) We'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% 2) We're refactoring component x because it loads on every page and is far too slow. We'll improve response time by 600ms. This will extend page view time by x seconds and increase views by x% 3) We're going to stream our large files where we currently download the entire thing which causes customers to wait for x seconds. We'll see an x% improvement in page load, resulting in x more page visits. You get the gist. At first, I'd suggest the co-founder 'might' 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't match up, he'll hopefully start giving it more thought. On the flip side, it is also possible that the co-founder has good reasons to request these features but maybe hasn't communicated them well to you and the rest of the dev team.
- wefarrell 11y ago
  > If it doesn't add to sales, or have some actionable metric as to why it is being added to the product, it doesn't get done This isn't the problem. There are justifications for new features but adding too many turns the product into a mess. I'd like them to focus more on the problem we're trying to solve and think about the product holistically.
  - pedalpete 11y ago
    I'm comparing this to a similar situation I was in recently trying to advise a group to focus on one problem, not all the possibilities. That is the simple statement, as you said '[how does this feature address] the problem we're trying to solve'? Sometimes adding too many features turns the 'product into a mess', but I would argue that is not always the case. It sounds to me like you have very little confidence in the co-founder to make the right decisions. That may be well justified, it may not be. Sorry I can't help any further.
Terr_ 11y ago
> I'd really appreciate an article that explained how to say "no" to stakeholders diplomatically. "How about this instead" is always better than "no", but that depends on being able to discover their true pain-point rather than what they think could make them happy.

pedalpete 11y ago

Maybe you're not saying 'no', you're saying 'not now'. Is it possible to go to the co-founder and suggest that only features which customers will use/buy get built? If it doesn't add to sales, or have some actionable metric as to why it is being added to the product, it doesn't get done. This works for engineering too. No 'refactoring' if it doesn't have a measurable benefit to the company. 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. For each feature in dev, have the co-founder write out the reason it is being built. Here's an example on the current product I'm working on. 1) We'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% 2) We're refactoring component x because it loads on every page and is far too slow. We'll improve response time by 600ms. This will extend page view time by x seconds and increase views by x% 3) We're going to stream our large files where we currently download the entire thing which causes customers to wait for x seconds. We'll see an x% improvement in page load, resulting in x more page visits. You get the gist. At first, I'd suggest the co-founder 'might' 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't match up, he'll hopefully start giving it more thought. On the flip side, it is also possible that the co-founder has good reasons to request these features but maybe hasn't communicated them well to you and the rest of the dev team.

wefarrell 11y ago
> If it doesn't add to sales, or have some actionable metric as to why it is being added to the product, it doesn't get done This isn't the problem. There are justifications for new features but adding too many turns the product into a mess. I'd like them to focus more on the problem we're trying to solve and think about the product holistically.
- pedalpete 11y ago
  I'm comparing this to a similar situation I was in recently trying to advise a group to focus on one problem, not all the possibilities. That is the simple statement, as you said '[how does this feature address] the problem we're trying to solve'? Sometimes adding too many features turns the 'product into a mess', but I would argue that is not always the case. It sounds to me like you have very little confidence in the co-founder to make the right decisions. That may be well justified, it may not be. Sorry I can't help any further.

Terr_ 11y ago

> I'd really appreciate an article that explained how to say "no" to stakeholders diplomatically. "How about this instead" is always better than "no", but that depends on being able to discover their true pain-point rather than what they think could make them happy.