Should sales staff interfere in application analysis and design?

Question

We're working on a kind of CMS, a fast, hosted, centralized website builder like Weebly. We also use Scrum development model. But there seems to be some problems here. Our sales manager always come to us, complaining about the design of the application, or UI elements, or stuff like that and hinder development process by making re-works again and again. Examples are:

1. Why do you have item actions like delete and edit in grid items? Just have list actions as a toolbar on top of grids. No item action.
2. Why red color? Use green. That's what people like.
3. Use tree for contents, not grid.

My question is really simple. Is it considered productive, or even normal for sales staff to interfere in application analysis and design?

Answer 1

Absolutely.

The whole point of scrum is to get the product owners feedback at the end of every sprint to make sure you are building the correct things.

The sales manager should not be interrupting you in the middle of a sprint. But when you do the presentation at the end he should be there and you should be writing defects for each and every one of his complaints (he is acting as the voice of the user).

Then when you have your sprint planning meetings these defects should get prioritized with the rest of the product backlog and brought into the sprint backlog as deemed fit. Note the Sales Manager should also be part of the product backlog prioritization (at the product owners discretion). BUT not part of the sprint planning.

Engineers are notoriously bad at implementing interfaces for users (you think differently to your user). The sales team has to sell the product and presumably he knows what sells. His advice on UI layout (how it looks not how it is implemented) should probably be considered better than yours unless you have dedicated UI expert on the team or you are copying some other common interface that is well known and used (in this case you better be able to show it in use).

Note: This is also a useful way to stop repeatedly updating the same thing. Make a backlog item for it. make sure the product owner has seen it if they disagree or think the sales manager is wrong that should be noted in the backlog item and the item closed. If the sales manager now brings it up again you can point him to the backlog item saying this subject has already been discussed and decided.

Answer 2

What you see as interference might simply be them trying to put over new and/or changed requirements. Your example of the colour issue is a prime example of this.

However, your other examples could be seen as interference - especially the way you've phrased them.

What you need to do is arrange regular meetings to discuss the direction and design of the product, but you must get them to state their requirements as either end user requirements ("the user must be able to select all their widgets") or sales requirements ("we must be able to show this data as pie chart") rather than as implementation details. In general it shouldn't matter how you implement something as long as it serves its purpose.

There will be times when the requirement matches a specific implementation detail - e.g. showing a hierarchy as a tree.

Answer 3

Ideally your requirements should be coming from the customer, but the sales staff is also a valuable source of feedback, and the fact that your sales staff is funnelling their requests through the sales manager (and not just inundating you with individual requests) suggests that they are trying to be helpful to the process, and not merely interfering.

Does the sales staff act as a liaison between the customer and the development team? If so, then the sales staff is doing its job. Is the sales staff also a consumer of the software? Then they should be able to provide feedback on the design. If you're doing things right, you should be eating your own dog food anyway.

That said, the design decisions themselves should not be made by the sales staff. The sales staff is merely one of the stakeholders; they should be able to influence, but not dictate, the design process.

You should listen to your salespeople; they are the ones that have to listen to customers tell them why your software is good or bad, and how it should be changed, because they are talking with the customers all the time, so they are theoretically in the best position to provide constructive suggestions.

Encourage your salespeople to provide good, actionable feedback; changing the color of a label to fuschia may not be the best use of anyone's time, but reevaluating the entire color scheme based on feedback from customers that the overall scheme is hard to read, might be.

Answer 4

In Scrum, only the Product Owner can decide what will be built and in which order. So you should just point change requests to your PO so she can prioritize them in the backlog as usual.

Having said that, there is nothing wrong with input from sales dept or anyone else. They probably meet with the users a lot and have valuable insights which you might benefit from. In the end, it's up to your PO to manage (and juggle) feature requests, be it from customers, the team or sales.

Answer 5

It sounds to me that sales isn't properly represented/integrated in your development process. Are they a stakeholder? If they are not, then their input/concerns should likely be funneled through a stakeholder. However, it is possible that they should be a full-fledged stakeholder.

Ultimately, as developers, our responsibility is the technical design of a product (and its implementation). The rest of the design is not our area of responsibility. Lacking a design (not necessarily just graphic) we will fill the void, because we have to. However, that does not mean that it is the best design for the product.

If changes to this design are a problem, then that be must investigated and addressed. Maybe development needs to point out the voids that must be filled before work begins. Maybe development needs to provide for some variability. Maybe issues need to be addressed earlier. (Maybe issues aren't being addressed properly.) Maybe sales needs to understand the impact of their change requests.

One concern I have is that you've phrased this question in a adversarial fashion. It is sales that will be bringing in the money to pay for this development effort. The mindsets may be vastly different, but we have to find a way to cooperate or there won't be anything to sell.

Answer 6

There's a difference between meddling/interfering and making suggestions. There's also a difference between valuable suggestions and useless ones.

If you're being actively interrupted while working on code, that counts as meddling or interfering. In such a case, you have every right to get the salesperson out of your face. Additionally, if your decisions are being undermined by constant second-guessing at meetings, if the salesperson is making an effort to undermine your authority or question your competence, that's certainly unacceptable.

However, if you are simply hearing lots of opinions when you present something, this isn't meddling. It's just unwelcome advice, like you'd hear from a friend who sits on your deck furniture drinking your beer while watching you teetering on a ladder while you paint your house.

It's quite possible that the salesperson is well-meaning and just wants what he/she thinks is best for the customer, even if the suggestions sound silly or capricious.

By making suggestions, your salesperson may be hinting at weaknesses in your design or interaction model. Or they may just have their own personal axe to grind.

If there are solid justifications for changes, it's worth trying to find a way to respond to feedback, even if your actual implementation doesn't end up literally incorporating the specifics of the suggestion; it's quite possible that you'll learn something if you listen. Just keep in mind that the words used in those suggestions may not refer to the actual problem; they're just a proxy to an underlying issue that hasn't been adequately understood yet.

I've sat in meetings where an executive wanted to fiddle with how many pixels to the left some control was instead of discussing what business logic needed to be there, and we certainly found this not a good use of his time or ours. But I've also listened to people complain about the look of something or what type of control was used and it was really a roundabout complaint about how something worked, not what it looked like. Keep in mind that users usually don't know what they want until they've gotten it; if you think of your salesperson as a proxy for an user, there's a good chance he suffers from the same problem.

So don't feel obligated to accept every suggestion, but don't be so quick to dismiss every word coming out of your salesperson's mouth.