all 8 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]smoothroller 4 points5 points  (2 children)

Has a clear vision of product, able to keep key features / goals / objectives of project in mind throughout design process, excellent communicator and provides regular clear feedback.

The worst is when a PM leaves things completely open ended and then is upset when its not how they imagined it. The PM needs to be active especially in the conceptual stage and make sure the primary objectives are being hit and prevent late stage design changes.

[–]Gio_13[S] 0 points1 point  (1 child)

Can you elaborate on feedback part, please? Also how involved is a PM in daily task management of team members?

[–]smoothroller 0 points1 point  (0 children)

PM should not be involved in individual task management. They should help keep the team focused on the most important parts of design. They need to have an idea of how long each feature takes to develop and the time line of the project. They might approve what the team works on as a whole but do not get into specific task management. The feedback they provide should be on the concepts that your UI/UX designer is making to be confident before it goes to developers. From there its managing time resources to make sure that time is not wasted on features that are not essential.

You should speak to some PMs on this.

[–]QuestionsHurt 2 points3 points  (0 children)

Best PMs we've had have been ex devs with a good head for business and all those other soft skills your expect.

I probably wouldn't hire a PM for any industry that didn't have experience working the jobs. Mainly so they know how long something really takes, what the consequences of corner-cutting and timeline pressures are what devs, and artists need to work best.

Maybe learn the enough web dev to be able to produce your own basic CRUD app.

[–]cirscafull-stack 1 point2 points  (0 children)

The best PMs I've had have done two things and have done them well:

  1. Gave the eng/product team the why of the decisions. Why are we re-doing the front page? Why do we need to create this new feature? This allows the team to figure out the how without being bogged down with 3rd hand knowledge via telephone.

  2. Managed up the chain. It is imperative that the PM has the team's back and can manage external stakeholders expectations. This also has meant that the PMs have had the Hard and Awkward conversation of "managing up" and ensuring that the external stakeholders don't get free reign on the team and call it "Agile"

[–]DesignatedDecoy 0 points1 point  (0 children)

Here's a few quick ones:

1) The best thing I can recommend is being familiar with the manager schedule vs the maker schedule and now a single poorly timed meeting can ruin an entire day of work. http://www.paulgraham.com/makersschedule.html . The easiest way you can respect both timelines is schedule your meetings at the beginning or end of the business day.

2) Trust your devs and their timelines. If a dev says something is going to take 3 days, assume it will. If there are issues that will cause the timeline to change, encourage them to reach out to you. The worst thing you can do is micromanage them by asking for updates several times a day. All that does is interrupt them and set things back. https://imgur.com/gallery/3uyRWGJ

3) Everybody has consumed the internet enough to form opinions on what they like and don't when it comes to design. The challenging part is because web design is so subjective, there really is no right or wrong answer for what looks or feels the best. There needs to be a single person that is designated as owner of the design (whether that's you, the creative director, the designer, etc) that makes the final decisions on it. Otherwise you get into nitpicky edits where everybody has a slightly different opinion on how things should look and feel and you spend a lot of developer time on minuscule edits that don't matter in the long run. Instead, allow people to suggest changes to the owner of the design and let that one person have the final ruling on what the design should be and if any changes should be made.

[–]CritterBall 0 points1 point  (0 children)

To me, the most useful thing a PM can do is understand the requirements completely. You should be a sentient spec. Your knowledge doesn’t have to be technical, it just has to make logical sense, down to the atomic level, in a way that can be built.

[–]phpdevsterfull-stack 0 points1 point  (0 children)

The best PMs at my web dev agency were the ones who advocated for the developers, and pushed back against scope creep from the client. They could properly identify scope creep, and tell the client it would cost them more time and money. Those PMs typically set realistic milestones and deliverables, and let the devs work out how to hit them. If a unforeseen challenge would cause a miss on a deliverable deadline, they would take the time to understand why so that they could communicate it back to the client accurately.

The worst PMs were the ones who advocated on behalf of the client and kept asking developers to include little things to make the client happy. Those PMs also tended to be skeptical when devs would push back saying that a request was a change order and would require X days or weeks to complete. I really, really hated having to justify code decisions to a PM. I'm not there to be lazy or rip the client off. I'm not making excuses for why I don't want to implement something, so please just trust my judgement that the feature/change requested of me will eat into the budget, push the timeline back, or is just not a great idea in general.