Product Responsibility
Whose responsibility is your software product?
Ideally, no one would write code that didn’t make the app/site/product better. Time spent writing code that isn’t creating a better user experience or bringing in more revenue is a loss. Useless code creates technical debt and wastes everyone’s time.
Obviously, engineers and product managers can’t see the future. They can’t plan the exact right features to avoid wasted engineer time. Despite this, it is essential to focus on defining a strong product roadmap. A poorly thought out roadmap will cause engineers to work on features that don’t improve anything. The lack of increased money/metrics will cause management to panic. They push the product team and engineers to work harder on product features that don’t matter. The company will continue to spin its wheels like this until everyone is out of energy and money. The number one priority of any software company should be the product roadmap.
Engineers often have valuable knowledge and perspective that can help save a product. They are often most acquainted with the technology and ecosystem. iOS app developers know their field and most have a solid grasp on what types of apps succeed. Domain experts bring with them knowledge of the technologies, competitors, and design best practices.
Not all engineers are product or design geniuses, but they still want to feel like their opinions matter. I admit that as a whole, engineers can often be lacking in creativity or just not interested in the product. Some engineers are quiet and analytical. Some are creative and innovative. A software development team is made up of all types of people, just like the rest of the human race. Making the effort to reach out for feedback from developers, designers, testers, etc. will make them feel heard and creates value.
The natural reaction of many engineers who see the product getting worse is to keep their head down and hope for the best. This is bad. The people who are giving 40+ hours a week to build something shouldn’t feel unable to guide the product to success. This is often due to faults in both the engineering and product team. The engineers often feel like they can’t question the executive leadership or product leads. The product team often only seeks feedback about inconsequential details, but feels that they are solely responsible for making the product successful. The product team may not pass engineer feedback up the chain, so nothing changes. The engineer gives feedback a few times, then realizes that his/her advice will not be heard. He/She begins to stop offering advice and hopes the product team figures things out. The engineer needs to take partial ownership of the fate of the product. The product manager should listen and consider any team member’s concerns.
The title “Product Manager” is a bit of a misnomer. The product manager should take majority ownership of the well being of the product. Their title does not mean they are the only one who can guide the product. Engineers assume that providing criticism to a product manager might be overstepping their bounds. Product Managers should lead the project and care for the product. They should also welcome and seek out criticism from all sources.
I refuse to accept that any serious software company wants to hire engineers that only produce code. Many organizations I have worked at expect engineers to produce code without providing significant feedback.
Some teams have stronger product direction than others, but even the greatest product team needs advice from its engineers.
I am an iOS developer working on the mobile apps for eHarmony. I am doing all I can to guide this product to a 5 star app rating and help this product better serve our customers. I want our app to provide real value by creating relationships without anyone feeling ripped off. Feel free to tweet at me with feedback about this article or the eHarmony apps @iAmChrisTruman.
