I've started working as a developer fairly recently, having worked as a systems administrator before.

My understanding of how a software development team using Agile functions is that the "what we need to implement" communication happens mostly in one direction, from the product owner to the developers. Developers can express their concerns to the product owner about technical debt, but coming up with feature ideas should not be one of their main responsibilities.

The company I'm working at has a different view. To them, developers should not only go to the product owners of their own team to suggest feature ideas, but also to the product owners of other teams if they think they have something to contribute to that team's product. The idea is that we're all one big Team <company name>, and all developers should use their expertise to push features they think will be useful.

Is such an approach "normal", for lack of a better word? Am I being too passive, should I take the initiative and start pushing ideas to product owners? Conversely, has the company got it completely wrong and I should look for employment elsewhere?

  • 15
    Sure, programmers often know a lot of things that the product owner never has heard of. Take web development, there are services, apis, any amount of libraries and plugins and user interface items. We often work with customers who do not have much more than a rough idea what they want to do, but no knowledge what are the common ways to implement them or what additional features would be possible. Feb 11 '14 at 15:27
  • 1
    Do you feel any resentment or negative consequences for not suggesting features? It sounds like your company wants to encourage the practice and not punish those who don't.
    – JeffO
    Feb 11 '14 at 17:22
  • This is the normal process in two companies I've worked for. I've come to realize the business folks just don't have a clue for how valuable us developers are in solutions/problem solving skills. Jumping ship your likely to run into the same issue. Suggesting new features to product folks as if it was there solution, is called managing the managers and works well. The only issue is it means you don't get credit for your ideas but at least your features get implemented.
    – Jason
    Feb 11 '14 at 20:31
  • IMO this is a very good thing and very healthy. Product owners may be experts on the business domain but are likely not aware of every new technology or technical approach that is available. In addition, developers may have insights about the system that comes from the different perspective of working directly with the code. You definitely want to stay with a company that welcomes ideas from everyone, no matter the role. It doesn't mean that the owners are clueless, it means that they are open to everyone's ideas.
    – Ken Liu
    Feb 11 '14 at 21:46

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.

  • 1
    I don't interpret my company's philosophy as asking developers to come up with stories, and I don't recall seeing that happen. What I think they want is, once an idea has been emitted and a developer has taken ownership of its execution, it's the developer's responsibility to champion that idea until the end.
    – louniks
    Feb 11 '14 at 17:17
  • 1
    So you're saying that alarm bells ring when a developer thinks of an idea that a product owner didn't think of? Why would that be such a bad thing? Feb 12 '14 at 16:13
  • 1
    Throwing ideas around is fine - it's part and parcel of the planning game. If it was a new story, I would question this. Stories deliver customer value which to be frank developers aren't normally best placed to assess (unless they're domain experts). Whether something appears in the iteration is determined by story value and developer effort in the planning game. Developer involvement in creating stories could cause a potential conflict of interest here. This isn't to say it couldn't happen - just that the product owner would then need to champion it, otherwise it is the tail wagging the dog.
    – Robbie Dee
    Feb 12 '14 at 16:46

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.

  • I think you've nailed it - I've landed in a team working with technologies that I have very little experience with, therefore it is difficult for me to be proactive. There will have to be a learning period during which I remain passive. Afterwards, once I start feeling comfortable with the technology, I can start being proactive.
    – louniks
    Feb 11 '14 at 16:26
  • 1
    @louniks no you're missing the point. The technology is not what matters. The business is what matters. How transparent are the business people? Are you aware of how the business intends to make money? Are you aware of how the product you're working on fits with the other products in the company? If not then your employer is being unfair to you. You can't suggest features if you don't know the business plan. Feb 11 '14 at 17:11
  • 3
    @RibaldEddie I disagree with the last part. Anyone should be free to suggest features. Management and product owners are still free to determine if the feature goes anywhere. Don't overlook the possibility that a developer with sufficient domain and technical knowledge could come up with a huge, money-making feature that's completely outside the original business plan. A product owner may never come up with the same idea due to limited technical knowledge.
    – Dan Lyons
    Feb 11 '14 at 17:51
  • 1
    That sounds like a dangerous situation to be in: it means that the business people you are working for don't know what they are doing. It's THEIR JOB to be experts in this area. Otherwise why are they there? Seriously. If developers are providing this kind of insight then the developers might as well just run the company. Anything else is waste. Feb 11 '14 at 19:56
  • You don't always need detailed domain knowledge to suggest technical improvements...
    – Robbie Dee
    Feb 11 '14 at 22:13

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

  • +1 Thats a really comprehensive answer. The "Conclusions" work as a good TL;DR. Feb 12 '14 at 4:19

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.

  • Seems like at Google the devs are spending some of their time being a product owner.
    – JeffO
    Feb 11 '14 at 17:17
  • Google employees working on their own projects isn't the same thing unless you're talking about another initiative?
    – Robbie Dee
    Feb 11 '14 at 22:11
  • @RobbieDee Yes, right. They work on their projects, but google sells services that comes out of the projects. Feb 11 '14 at 23:59
  • What I mean is that such projects don't necessarily reside within the sphere of an existing agile project. They may be completely autonomous.
    – Robbie Dee
    Feb 12 '14 at 8:30

Not the answer you're looking for? Browse other questions tagged or ask your own question.