[PMs] We aren't shipping new features fast enough

Laten we beginnen. Het is Gratis
of registreren met je e-mailadres
[PMs] We aren't shipping new features fast enough Door Mind Map: [PMs] We aren't shipping new features fast enough

1. The features we _do_ work on, are taking a long time

1.1. Not staffed with enough engineers

1.2. Only prioritize BIG features

1.2.1. Smaller projects don't bubble to the top with our current prioritization system

1.2.1.1. Should we tweak our prioritization / planning system to better balance quick wins w/ big projects?

1.2.2. 'Enhancements' can't get prioritized

1.2.2.1. Treated same as bugs

1.2.2.1.1. We have too many high-priority bugs

1.2.2.1.2. Existing pain is more visceral than opportunity cost

1.2.2.1.3. Should 'Enhancements' have a different process?

1.3. Bad planning

1.3.1. Not enough design testing earlier on

1.3.2. Not enough thought on dependencies

1.3.3. Not enough planning around all the use cases before building

1.3.4. Prioritizing non-MVP features of a product

2. We aren't working on many new features

2.1. Not enough features ready for dev

2.1.1. Scoping not done

2.1.1.1. PMs behind

2.1.1.1.1. Only 1, now 2

2.1.1.1.2. Trying to do too much?

2.1.1.1.3. Know there are other bottlenecks (design, backend)

2.1.1.1.4. Unclear roadmap

2.1.2. Designs not done

2.1.2.1. Existing designs need to be re-done

2.1.2.1.1. Missing, incomplete, or poor scoping

2.1.2.1.2. No customer validation

2.1.2.1.3. Don't fit into larger product vision

2.1.2.2. Not enough available designers

2.1.2.2.1. Design team is too small

2.1.3. Not enough business pressure

2.1.3.1. Unclear goals

2.1.3.1.1. Company-wide goals process

2.1.3.2. Accountability / lack of repurcussions

2.1.3.3. Significance/urgency of growth goals is questionable

2.2. Not enough available engineers

2.2.1. Too many high-priority bugs

2.2.1.1. General code quality?

2.2.1.1.1. Developers not aware of all implications of code areas they're working in

2.2.1.1.2. Rushing development?

2.2.1.1.3. Inadequate Code Reviews?

2.2.1.2. Lack of quality test docs

2.2.1.2.1. Developers not rigorous enough about identifying areas that need regression testing

2.2.1.2.2. QA not rigorous enough about documenting necessary test cases

2.2.1.2.3. For new projects, assigning QA rep at the beginning who is responsible for driving test doc creation / maintenance from beginning of project (and involving correct contributors, etc.)

2.2.1.3. Lack of automated tests

2.2.1.3.1. Increase automated test requirements for developers?

2.2.1.3.2. Hire QA automation engineer(s)?

2.2.1.4. Letting too many regressions out the door

2.2.1.4.1. Developers not aware of all implications of code areas they're working in

2.2.1.4.2. Lack of automated tests

2.2.1.4.3. QA not doing enough/full regression testing

2.2.2. Too many tech debt projects

2.2.2.1. Feature projects not ready

2.2.2.2. Underestimated effort

2.2.2.2.1. Not fully scoped out first

2.2.2.2.2. Not enough points of view

2.2.2.2.3. Really hard for PMs to gut-check

2.2.2.2.4. Estimating is hard

2.2.2.3. Overvalue benefit/need?

2.2.2.3.1. Existing pain is more visceral than opportunity cost

2.2.2.3.2. Solving for future (while simultaneously pushing it farther out)

2.2.2.3.3. Desire for perfection?

2.2.2.3.4. Learn from our own history?

2.2.2.4. Tech debt projects creating more tech debt projects

2.2.2.5. 'Surprise' High-Priority tech debt projects

2.2.2.5.1. Could we have been aware of 'unknowns' sooner?

2.2.2.5.2. Could we put the 'knowns' on the roadmap?

2.2.3. Engineering team has been too small

2.2.3.1. Hiring more engineers!

2.2.3.2. Need to grow team responsibly

2.2.3.2.1. Can't operationally manage a larger team

2.2.3.2.2. Want to maintain financial leverage

2.2.4. Not enough business pressure