A friend asked me to answer questions for a survey, with respect to whatever experience I have that's relevant. Here goes.
Please briefly describe your current position at your company, your professional background, and any involvement you've had with new product development.
I've spent ten years doing web development, largely in Java, HTML, and CSS2, but also touching C#, PHP, and JQuery.
Currently, I work for a large web company. I've learned C++, and do some of my code at the user interface level; actual users see the changes I make to our software.
How would you define new product development? What constitutes a new product?
I think of two things here. One is "a completely new product"; something that hasn't existed before. Much more common are "big improvements on existing products", which seems much more descriptive of how "new product" is used today. We're not always inventing the idea of a mousetrap, but we are making better mousetraps. When the difference between the old way and new way of doing something is noticeable to even the most casual user, it's a new product.
What percentage of your time would you say is dedicated to working on new products?
Of the time at work I spend on technical projects, nearly 100%; the company is only ten or so years old, so all of the products are new. In fairness, about half of what I work on was started by others, and about half is code where I wrote line #1, so call it a 50/50 split between new and old.
What percentage of the products that you work on which make it to market/production would you classify as new products?
Again, 50/50; everything we work on that's successful goes to production.
Please walk me through how you've seen successful new products developed, from ideation to launch.
There are three ways to drive ideas:
- Sales driven
- Engineer driven
- User driven
Some mix of the three is necessary. I've found that it's never wrong to put more focus on the users - all of them! - for long-term planning and success. Sales-driven organizations are *great* in the short-run, but fall flat if sales is sacrificing overall user quality for the opportunity to close one or two extra deals. Engineer driven companies are odd the other way; they might produce the best product that no one ever wanted to pay for. But user driven, *if* you can hit it, is ideal; you make a product. People like it.
Have you ever had a great idea for a new product that was started but never saw the light of day? Please expound as much as you can.
Yes. I have more good ideas than I have time to push them right now. I don't know if any of them are great; I haven't pushed on them yet.
On the plus side, having extra ideas gives me a large list to pull from when I have free time. When someone asks "what should we be doing with X", I usually have an answer; it's not always a great one, but something to get conversations started.
What are some typical reasons or roadblocks that prevent good ideas from coming to fruition at your company or in your experience? Any suggestions for how to avoid them if you were given a blank slate?
Getting the right people in the driver's seat - and letting them get the right people on the team - are the most important things I've seen for getting ideas into reality. Those people need to be:
- skilled at that task
- interested in that task
- optionally, but preferably: have their compensation/promotion benefited by success at that task,
- while measuring success in a way the team *all* agrees on up front.
Do idea raisers have the opportunity to stay involved, and if so, how? Do you feel it's important to keep them involved and why?
Largely, yes; you want to have two sets of people working on any project:
- The people who can Get The Job Done, and
- The people Most Passionate about the task.
Hopefully, these are the exact same sets of people. In the case of the person who had the idea, they're often the most passionate person you could possibly have on the job; it was their idea, and if they weren't passionate about it, it wouldn't have taken off! As long as the inventor is a productive part of the team, they should be kept in the mix.
Engineering Elixir Applications, in print
1 week ago
No comments:
Post a Comment