Pitching a New Feature
March 12, 2005 11:39 AM Subscribe
How would a nobody consumer go about contacting a major corporation about adding a new area to an existing piece of software? This software in question is already updated all the time, it seems like it would be easily implemented, and would bring in new revenue.
I've found articles on Google detailing how to pitch an idea, but I'm not at that stage. How do I go about finding the right people to talk to?
I've found articles on Google detailing how to pitch an idea, but I'm not at that stage. How do I go about finding the right people to talk to?
Ideas are pretty cheap, believe it or not.
Most major software corporations are innundated with ideas, internally and externally. They make it very, very hard to submit ideas because they just don't want them. 9 times out of 10, when you mention the feature idea to someone who works on the project, they'll have already thought of it.
Really good software organizations often set all the features months in advance. It's because of strategy. Even the small software organizations I've worked for have had long laundry lists of improvements they would love to get to, but they just can't. In fact, a lot of times your favorite feature winds up in the software because an engineer stayed late for a month.
I'd think your best bet is to get someone inside the organization to champion the idea. Good candidates include the product managers, the project managers, or the senior engineers. That group will have to agree to the idea eventually anyhow.
How you go about doing that, I have no idea. For example, the senior engineers are exactly the group of people the business doesn't want you talking to.
posted by maschnitz at 12:25 PM on March 12, 2005
Most major software corporations are innundated with ideas, internally and externally. They make it very, very hard to submit ideas because they just don't want them. 9 times out of 10, when you mention the feature idea to someone who works on the project, they'll have already thought of it.
Really good software organizations often set all the features months in advance. It's because of strategy. Even the small software organizations I've worked for have had long laundry lists of improvements they would love to get to, but they just can't. In fact, a lot of times your favorite feature winds up in the software because an engineer stayed late for a month.
I'd think your best bet is to get someone inside the organization to champion the idea. Good candidates include the product managers, the project managers, or the senior engineers. That group will have to agree to the idea eventually anyhow.
How you go about doing that, I have no idea. For example, the senior engineers are exactly the group of people the business doesn't want you talking to.
posted by maschnitz at 12:25 PM on March 12, 2005
If you want to be paid for the idea, forget it, there's no way. If you just want a better product, something to think about in addition to what you eventaully settle on (ie it's a dumb idea and a slim chance, but maybe should be mentioned anyway) might be to look for a major/bulk user of the software that would clearly demonstratibly benefit from the change, and try to get their (considerable) weight behind it. This would hopefully involve having a friend on the inside, but might be a case of asking/emailing to find the right person in the company to talk too, and then send them a letter or take them to lunch, explain the idea, give them a short concise pre-written letter to the company, stamped envelope etc, a copy on CD in case they want to make alterations before signing/sending. Basically, minimise the amount of their time that you waste, make it as easy as possible, be convincing. It's a bit of a weird thing to do (I don't think I know of anyone doing this), but who knows? :-)
Since it's a big company, anyone invloved in purchase decisions (which is who you're after) will likely be used to being schmoozed by representitives in fancy resturants with nifty giveaways and material. Maybe ask a sales rep friend for some insider advice?
posted by -harlequin- at 12:59 PM on March 12, 2005
Since it's a big company, anyone invloved in purchase decisions (which is who you're after) will likely be used to being schmoozed by representitives in fancy resturants with nifty giveaways and material. Maybe ask a sales rep friend for some insider advice?
posted by -harlequin- at 12:59 PM on March 12, 2005
Response by poster: I'm not expecting to get paid, I just think I have a lucrative idea for an add-on category for a piece of software, and I know lots of people would use it. I guess one could liken it to saying "Hey Amazon! You guys should add a Farm Animals category to your website. There's a huge market for people wanting to download ponies."
posted by ArsncHeart at 1:15 PM on March 12, 2005
posted by ArsncHeart at 1:15 PM on March 12, 2005
Does the program have a plug-in architecture, e.g. like Photoshop? You might get further by contacting a smaller third-party developer, who would write and sell code to extend the program's functionality.
posted by AlexReynolds at 1:17 PM on March 12, 2005
posted by AlexReynolds at 1:17 PM on March 12, 2005
Some companies have links on their websites for Joe User to submit feature requests. Have you checked that angle out?
BTW, what product are you hoping to get the feature added to?
posted by glyphlet at 1:19 PM on March 12, 2005
BTW, what product are you hoping to get the feature added to?
posted by glyphlet at 1:19 PM on March 12, 2005
Maschnitz is right: the only practical way of getting your pet feature into a product is to find someone on the inside who will take it over personally and make sure that it gets done. Assuming you have managed to identify and contact some engineer inside the organization, here are some tips for improving your chances of success:
- Focus on the problem; let the engineer think up the solution. Engineers love to brainstorm, and getting your contact riffing on different ways of solving your problem is a good way of getting them personally involved in the project. A good engineer likes to solve specific problems using general mechanisms. Maybe they will reinvent your particular solution; maybe they will come up with something even better. Maybe they wrote it six months ago and they're just waiting for it to ship.
- Engineers like to work on interesting, challenging problems. Don't make the idea sound easy; make it sound simple and focused. Engineers don't (generally) mind work; they do mind endless, vague, poorly-specified projects that chew up lots of time without actually getting anywhere.
- Be specific - really specific. Tell the engineer what it is you're trying to accomplish, what you're doing to accomplish it, why that's a pain in the ass, and what steps you would like to eliminate.
- Never ever ever imply that the software sucks! For all you know the person you are talking to wrote the code that would need to be changed, and has always wanted to add your feature but has never had time. Or perhaps it simply never occured to them that someone would try to use the product the way you want to.
- Don't say say things like "it would be easily implemented". Figuring out what it would take to implement some feature is a significant part of an engineer's job. There are endless details involved that you simply can't know about unless you are familiar with the code involved. Maybe it will be easy; maybe it would depend on some major code refactoring; maybe there's some law of physics that makes it impractical. You don't know, and any comments that make it sound like you do will simply cost you credibility in the engineer's eyes.
Furthermore, asking the engineer to tell you what would be involved in implementing the feature is a good way to draw them into your scheme. If there's an easy answer, they'll tell you so, and maybe that's all you need. If the answer is "that would be really hard", don't despair: just say something like, "Oh, well, I'm sorry to hear that. What would be involved, if you don't mind my asking?". Half the time you will get a detailed explanation of just what hidden complexity lurks under the surface of your seemingly simple request, but at least the engineer will remember you as a respectful, intelligent person, and will pay attention to your questions in the future. The other half of the time, you'll get a big technical explanation of why your feature is impossible, and halfway through this explanation the engineer will realize there is a clever solution nobody thought of before, and from that point on they're *hooked*, because the cleverness of that solution is going to gnaw at them until they get a chance to implement it.
In short: be simple, be clear, be respectful. Your job is to point the engineer in the right direction; their job is to invent stuff. Keep that clear and you will do alright.
posted by Mars Saxman at 1:27 PM on March 12, 2005
- Focus on the problem; let the engineer think up the solution. Engineers love to brainstorm, and getting your contact riffing on different ways of solving your problem is a good way of getting them personally involved in the project. A good engineer likes to solve specific problems using general mechanisms. Maybe they will reinvent your particular solution; maybe they will come up with something even better. Maybe they wrote it six months ago and they're just waiting for it to ship.
- Engineers like to work on interesting, challenging problems. Don't make the idea sound easy; make it sound simple and focused. Engineers don't (generally) mind work; they do mind endless, vague, poorly-specified projects that chew up lots of time without actually getting anywhere.
- Be specific - really specific. Tell the engineer what it is you're trying to accomplish, what you're doing to accomplish it, why that's a pain in the ass, and what steps you would like to eliminate.
- Never ever ever imply that the software sucks! For all you know the person you are talking to wrote the code that would need to be changed, and has always wanted to add your feature but has never had time. Or perhaps it simply never occured to them that someone would try to use the product the way you want to.
- Don't say say things like "it would be easily implemented". Figuring out what it would take to implement some feature is a significant part of an engineer's job. There are endless details involved that you simply can't know about unless you are familiar with the code involved. Maybe it will be easy; maybe it would depend on some major code refactoring; maybe there's some law of physics that makes it impractical. You don't know, and any comments that make it sound like you do will simply cost you credibility in the engineer's eyes.
Furthermore, asking the engineer to tell you what would be involved in implementing the feature is a good way to draw them into your scheme. If there's an easy answer, they'll tell you so, and maybe that's all you need. If the answer is "that would be really hard", don't despair: just say something like, "Oh, well, I'm sorry to hear that. What would be involved, if you don't mind my asking?". Half the time you will get a detailed explanation of just what hidden complexity lurks under the surface of your seemingly simple request, but at least the engineer will remember you as a respectful, intelligent person, and will pay attention to your questions in the future. The other half of the time, you'll get a big technical explanation of why your feature is impossible, and halfway through this explanation the engineer will realize there is a clever solution nobody thought of before, and from that point on they're *hooked*, because the cleverness of that solution is going to gnaw at them until they get a chance to implement it.
In short: be simple, be clear, be respectful. Your job is to point the engineer in the right direction; their job is to invent stuff. Keep that clear and you will do alright.
posted by Mars Saxman at 1:27 PM on March 12, 2005
I work for a very large software company and submitting feature requests via the web - believe or it not - does work. We check them all the time and treat them as if they came from the the biggest clients. Don't automatically assume that all companies don't do this.
One bit of advice that I would pass on in addition to Mars Saxman's excellent contributions is to mention "competing product X does this and it's very handy." If the company is at all interested in making life easier for their users, they'll review the request and treat it with respect.
posted by glyphlet at 6:42 PM on March 12, 2005
One bit of advice that I would pass on in addition to Mars Saxman's excellent contributions is to mention "competing product X does this and it's very handy." If the company is at all interested in making life easier for their users, they'll review the request and treat it with respect.
posted by glyphlet at 6:42 PM on March 12, 2005
I would add that if there really is a built-in market for this, and that market is not currently well-served by the software, they know it -- and getting large customers in that segment to lobby individually, or better yet, through a trade association, would be another way to get the software company to listen. Is there an active user's group? What about any evangelization structure in place for semi-pro users, like Microsoft's MCPs?
That said, you should read what Paul Graham has to say about ideas for software:
An idea for a startup, however, is only a beginning. A lot of would-be startup founders think the key to the whole process is the initial idea, and from that point all you have to do is execute. Venture capitalists know better. If you go to VC firms with a brilliant idea that you'll tell them about if they sign a nondisclosure agreement, most will tell you to get lost. That shows how much a mere idea is worth. The market price is less than the inconvenience of signing an NDA.
posted by dhartung at 8:30 PM on March 12, 2005
That said, you should read what Paul Graham has to say about ideas for software:
An idea for a startup, however, is only a beginning. A lot of would-be startup founders think the key to the whole process is the initial idea, and from that point all you have to do is execute. Venture capitalists know better. If you go to VC firms with a brilliant idea that you'll tell them about if they sign a nondisclosure agreement, most will tell you to get lost. That shows how much a mere idea is worth. The market price is less than the inconvenience of signing an NDA.
posted by dhartung at 8:30 PM on March 12, 2005
This thread is closed to new comments.
posted by andrew cooke at 11:52 AM on March 12, 2005