It depends what you mean by feature ideas.

In the planning game, it isn’t uncommon for developers to provide input about a story which might end up in the iteration. However, this is very different from developers coming up with stories on their own.

In mature systems, developers may suggest a way round a known issue which could make it into an iteration.

Enhancements could be OK e.g. adding a graph for a report, but alarm bells would ring for me if developers were coming up with bona fide new stories. If there was real value in this, I’d question why there wasn’t an existing unimplemented story for this or why it never came up in the retrospective.

The reason a lot of developers are “passive,” as you put it, is because it takes a certain amount of domain knowledge and experience before good product ideas come to you. But if they do come, there’s no reason not to suggest them and champion them.

Keep in mind – developers, product owners, sales people, etc., are all on the same team, with the same goal: building a successful product. Work towards that goal however you can.

With your talk of developers and product owners, it seems to me that you have no middle person responsible for the features in your organisation.

Well, in my organisation, I am that person. I am the requirements engineer, the one who learned how to make good specifications and choose features which result in a high quality software with user friendly interaction design. (In other organisations it is the UX person who gets the same job, you might be more familiar with that term).

And I can tell you: Getting a good specification is hard. Of course, developers hate doing it. It is a burden to them – they are there to build a software, not to think about power plays among stakeholders and the mental models of lazy users. But you know what? It is a burden to product owners too. They don’t know any better what features their software should contain than the developers or the users do. Creating a viable specification is a learned skill, and if you never learned it, you can’t be good at it. Sure, there are lots of developers and product owners who can do it, because they had to do it in previous projects. But the average product owner or developer struggles with it, because it is naturally not their job to do it. Not everybody who can drive a car can design a car; similarly, not everybody who can use software can design a software interface.

Can you develop software without a requirements engineer? Sure you can. But putting the whole weight of the specification of it on the product owner’s shoulders is not fair, and not good for the project result. Especially because he is faced with a task which is unusually hard for him, getting input and support from others is very helpful. If you are in such a situation, don’t look at your poor product owner and say “tell me what to make for you and I will make you”, he genuinely doesn’t know what he needs. But a discussion with you will help him articulate his thoughts and explore his ideas.

When there is no requirements engineer in the project structure, there is another problem: there is no moderator. All the developers are on the technical side, all the product owners are on the business side. When the two cultures clash, conflicts can arise, with each side judging the other one stupid and unreasonable (because it uses its own value system to judge). So, do talk with your product owner about possible features, but be polite and patient even when you think he doesn’t deserve it; the project success depends on how well you two can get along, and sometimes taking the suboptimal decision is better than taking no decision at all due to conflict. It might be helpful to establish a hierarchy and give one of you two the last word, as this prevents deadlocked conflicts. If he gets the last word, defer to it even if you feel it is unfair.

About the “passive” part: if you don’t have ideas, don’t try to come up with something just to show activity. If the product owner is already insecure and knows no good criteria for evaluating his or your ideas, strange ideas “just to have something” will make an already difficult situation even more difficult. Coming up with good feature ideas is not magic, but it requires knowledge. If you didn’t learn it from textbooks, you will probably need some years of developer experience, especially in projects where you are exposed to users or user-generated usability data (analytics, satisfaction measurements) before your brain sorts out the patterns for itself and you begin to notice: there is a problem here we can solve. The users seem to be missing something on this page, what can it be? Then you will have good ideas to share.

Conclusion 1: In projects with no requirements engineer, it is good to make suggestions when you have them. Do it with sensitivity and tact – it is imperative to avoid conflict even if it means your good idea gets nipped in the bud.

And if you are on a team with a requirements engineer?

I love hearing feature ideas from everybody! Yes, sometimes the ideas of developers are terrible (when they want to make user interface follow programming logic). Ideas of product owners are also often terrible (when they want the sun and the moon on a shoestring budget – oh, and the user is supposed to enter pages of personal information in highest data quality, without getting anything in return). But it is my job to come up with a specification which is good for everybody on the team. And even if your idea is never going to work, hearing it makes me aware that you have a concern. You might have chosen the wrong solution to suggest, but this doesn’t make your concern any less valid. If you spotted it, it probably needs to be addressed (or I need to come up with a reason why it is not a threat). If you have a requirements engineer responsible for the specification, don’t ever hesitate to go to them with suggestions. If they don’t hear you out, they are doing something wrong (note that “consider” doesn’t mean “accept”).

A requirements engineer has to view the project from the point of view of each stakeholder separately (and sometimes at the same time). We are only human, and we fail at it, often. If you are there to supply your true viewpoint, instead of the viewpoint we think you have, then your input is very valuable.

You can be more free in your behavior here. It is my job to do the sensitivity dance. Don’t be openly aggressive, this hinders my work, but you need less self-control and cultural/communicational awareness, because I can take up the slack. You are also not floating, in a situation where there are two conflicting ideas and nobody can judge which is better. I am supposed to know that, and if it doesn’t work out, it is my head in the noose.

Conclusion 2: If there is a requirements engineer on the team, go to them with product feature suggestions. You don’t need velvet gloves this time.

And lastly, what if there is no requirements engineer, the product owner is overwhelmed and struggling for ideas, the boss is pointedly looking at you, and you have no ideas to offer?

You have a few options. The one is, as you mentioned, to quit. Not all organisations work that way, and if this environment is not suitable for you, find a better one. It will be good for you in the long term.

You can also wait and see if anything changes. The next project can have a more experienced product owner (or one with more leadership). But you can’t stall forever.

The third option is to actually learn some requirements engineering by yourself. This is a skill highly sought these days. Even if you don’t ever plan to take on positions where you are a full-time requirements engineer, having this skill enhances your value as a developer, as it lets you understand better other members on your team (and your users) and makes the development process go more smoothly. And you don’t have to go into the whole depth of it. An entry level textbook which explains tasks, workflows, mental models and user-centered data models will already let you spot lots of improvement opportunities in a software designed by a team of businessmen and developers. Don’t go for the thickest books meant as a reference for academics (like the recent Pohl translation to English) – they are more a list of all possible methods for each small step, without an explanation how to actually do them. Choose something practice-oriented.

If you try it and find that you have no personal interest in the area, that’s still fine. Don’t force yourself to do something you dislike. But you probably should be looking for a job in an organisation with a different team structure.

Conclusion 3: Instead of waiting for years to get an intuitive understanding, read a book or two and you will already have good ideas to supply

Yes, it is quite normal.

There is well known 80% work – 20% innovation model at google, where people 20% of their time devote to something they like. This way, not only they get new features, but a whole new products and services.

Am I being too passive, should I take the initiative and start pushing ideas to product owners?

That depends on your personality. I have worked with really passionate people, but also with people without any emotion that do their 8 hours shift and go home.