Picture this: You’re a newly-minted Product Manager, sitting in one of your first sprint meetings with the Operational group. You’re excited, as you’ve finished up your business requirements, talked it over with the Project Manager you’ve been assigned to get the functional requirements sorted out and even gotten the first round of wires from your UX. You’re ready to move your Product forward, and this meeting is the last step before seeing your work go into the Sprint.
Except, an hour later, you’re left with a vague “Maybe in the next sprint. Project Gusto is taking all of our resources.” and what feels like a pat on the head as everyone walks out.
Project Gusto is a Large Product that is in need of a massive overhaul which is something that everyone on your team knows, but what about your Product? Where do you find the resources to get things done just because your Product is on a smaller scale?
At times like these, of which I’ve been through far too many times in the last year, all I want is a large container of Adult Beverage to drown my woes, or to find the closest first-person shooter to work through my frustrations.
After spending some quality FPS and Wine Time, though, I go back through and revisit my original business requirements, trying to find ways to streamline. Anything that could be pushed out to a new sprint, I de-prioritize. Anything that would be great to have, but won’t really mean much to the end user, I ditch and put in my own personal backlog.
Once I’ve stripped it down to the bare bones of what needs to happen, instead of what I want to happen, I sit back down with my PM and go over where we can trim the fat on the functional requirements. That shiny new survey that would take longer to implement than the page redesign? Gone. A new interactive map of users tweeting about the Product? Maybe we can put a feed stream instead, it takes a quarter of the time to put together, and the shiny interactive part can be worked on before the next tentpole event a few months later on. This really is when it’s important to turn back on your Developer Brain, as it may make or break your ability to slip into the next sprint.
After you’ve pared down to what your Product actually needs, versus how you want to change the world via your Product within a sprint or two, make sure you present it properly. Go through all of the arguments that you would make as a Developer when you do your final read-through on the requirements. You may need to go back and find that one line-item that means you’d have to work a weekend that can be cleaned up and only take a few hours instead. And if there’s no way around that weekend work, make sure you have all of the reasons easy to grab as to why they should be working then. Never forget that it’s about the user at the end of the day, though. Don’t cut something that would make the developer’s life easier to spite the person who will be using your Product.
Just when you think you can’t change anything any longer, read through it again with fresh eyes before sending it over for the sprint planning. When you’ve shown that your Product can be done quickly and with relative ease, you might end up with the needed edge to get your work into the next sprint without putting your roadmap in danger of failing.
