4 ms·

Well here is the conclusion of the post > Simply put, instead of expecting someone (e.g., product managers) to tell you which product features to develop, you

by polote 4y ago

Well here is the conclusion of the post > Simply put, instead of expecting someone (e.g., product managers) to tell you which product features to develop, you should be able to tell what are the most critical problems your users or product are facing and find the best solutions that fit into your product and engineering strategy.

MrJohz 4y ago
Sure, that seems pretty reasonable to me. Features themselves are broadly a software concern - software developers are in the unique position of being able to say what their code is capable of, and so it makes sense for them to be proposing features as solutions to the problems identified by other parts of the business. That's not to say that the development team should never accept feature suggestions from other places - when a user is very clear that they need a particular button, or the business team clear that they need a particular feature to compete in the market, then sure, that also makes sense. But I think the danger in software teams is less often that they only develop what they want, and more often that they only develop what they've been told to develop, and don't connect the dots. As an example, I worked on internal software for a manufacturing company, and they wanted various alerts to stop manufacturing in certain events. Meanwhile there was a communication tool being developed so that the manufacturing side of the business could talk more easily directly to sales. It was only from the development side that we were able to see how connected these two components actually were, and we ended up proposing a system where the alerts - which were almost always created by the sales/service team - would be built in to the messaging system. This made the whole thing much simpler for us to develop, but also simpler for the manufacturing and sales teams to use - rather than scattering features across the whole app, they lived in one place and worked more consistently. As I understood it, the point of the article is to say that developers should be trying to understand the world outside of their specific domain so that they can make those sorts of connections. Not because they're going to more right than anyone else, but because a team member that understands what's going on in the rest of the team will work better with the rest of the team.

by polote 4y ago

MrJohz 4y ago

Sure, that seems pretty reasonable to me. Features themselves are broadly a software concern - software developers are in the unique position of being able to say what their code is capable of, and so it makes sense for them to be proposing features as solutions to the problems identified by other parts of the business. That's not to say that the development team should never accept feature suggestions from other places - when a user is very clear that they need a particular button, or the business team clear that they need a particular feature to compete in the market, then sure, that also makes sense. But I think the danger in software teams is less often that they only develop what they want, and more often that they only develop what they've been told to develop, and don't connect the dots. As an example, I worked on internal software for a manufacturing company, and they wanted various alerts to stop manufacturing in certain events. Meanwhile there was a communication tool being developed so that the manufacturing side of the business could talk more easily directly to sales. It was only from the development side that we were able to see how connected these two components actually were, and we ended up proposing a system where the alerts - which were almost always created by the sales/service team - would be built in to the messaging system. This made the whole thing much simpler for us to develop, but also simpler for the manufacturing and sales teams to use - rather than scattering features across the whole app, they lived in one place and worked more consistently. As I understood it, the point of the article is to say that developers should be trying to understand the world outside of their specific domain so that they can make those sorts of connections. Not because they're going to more right than anyone else, but because a team member that understands what's going on in the rest of the team will work better with the rest of the team.