You were planning to introduce one new feature for the next major release, but suddenly, somehow, your team finds itself working on seven features all at once—all while under the pressure of meeting the original release date. How did this happen? Simple: The process suffered a little bit of scope giant leap. Solution? That’s also simple: “Let’s just stop working on those extra six features that weren’t part of our original plan.”
But it never happens that way. That’s why it’s called scope creep.
1. Share your product roadmap (early, frequently, and with everyone involved).
When everyone on your cross-functional team can see this high-level view of your product’s plans, priorities, and the strategic thinking behind it all, they will be more likely to understand how a request for what might seem to be a small additional bit of functionality will, in reality, have to disrupt some other part of the product’s progress.
So the more often you refer to and share your product roadmap with your organization, the clearer it will be to everyone that your finite resources for this project can’t afford scope creep.
2. Determine exactly what will constitute scope creep on your plan.
But then there are subtler forms of scope creep. For example, “I know we agreed on doing basic platform support for our app’s first release—just to let users access it with iOS or Android—but maybe we should go for optimum support, and include Windows phones, a desktop version, etc.”
3. Build “scope monitoring” into your routine.
4. Discourage your developers from over-delivering.
We know: This sounds awful. But as a product manager, one thing you should always remember is that your developers will often care deeply about the work they’re doing and will want it to be perfect. And in an ideal world—a world without budgets, or deadlines, or customers eagerly waiting for a finished product they can buy—you’d want your dev team building to perfection.
Unfortunately, though, you are always going to be working against the clock (and the accounting team), so you’ll need your developers to stop short of perfection and do the greatest work they can in the time they have allotted to them.
5. Make it easy to suggest and track great ideas for later.
One final suggestion for avoiding scope creep is to encourage your cross-functional team to contribute their product ideas and requests, and to make it as easy as you can for them to do so.
.. Then make a practice of periodically reviewing these ideas with your team, vetting and scoring them according to your key metrics, and, when it makes sense, updating your product roadmap to accommodate strategically viable items.
35 is a great age for a PM, especially since PM’s often start elsewhere — maturity is a plus here. I’d say there are 3 main ways into it — as an engineer, who starts to do PM-type stuff on a team where there’s no PM. As a designer, who starts to do PM-type stuff on a team where there’s no PM. Or as an MBA who has a good sense for engineering and design. Certifications generally don’t mean anything — communication and leadership skills, good judgment, experience and a proven track record are what matter. But all those things can be demonstrated in previous non-PM roles, in order to make the initial switch.
Also, if you want to be a PM then you’d better enjoy meetings, slides, people, and communicating & convincing all day long, day-in day-out. If those make you say an enthusiastic “yes that’s me!” then jump right in. If not… you’re gonna have a bad time…
<h3>Instant project management for your GitHub issues</h3>
HuBoard is built from the ground up using the GitHub public API. HuBoard issues are GitHub issues, you will never have to deal with synchronization problems. Keep issues where they belong, in the repository with your code!
A better way to manage your GitHub Issues