Dear Strategy:
“How can you use a strategy to say ‘no’ to features or developments?”
Let’s say that you have, like most companies do, a development team full of really clever, really creative people. Now let’s say that to that development team you add a fully funded project and a list of product requirements. Sounds simple enough; Development develops the product that you asked for. But in reality, this isn’t always what happens.
Because the development team wants to provide what they feel is the best product possible, sometimes they start to take some creative license and begin thinking about how they can go above and beyond your requirements to make the product even better than you ever imagined it could be. What we call this in the product biz is “scope creep,” and the problem is that it can really throw you off your game if it gets too far out of control.
Aside from the obvious problems that can arise from adding more complexity and risk into your project, scope creep can actually present even larger problems with pricing, placement, promotion, and positioning of your product in the marketplace. So, all in all, scope creep is something you want to avoid.
But the important thing to know with respect to the question being asked is that scope creep usually happens as a result of development teams not knowing the bigger picture of what it is that you’re trying to do in the marketplace. In other words, they may have been given the product requirements, but they weren’t given the backstory. Or, said differently, they weren’t given the product strategy.
With that said, your strategy is not likely to provide any amount of detailed guidance on a project by project basis. But it will provide an overarching narrative for your product line that can be used as the foundation for any related development projects. And that gives not only you, but also your development team, the ammunition to say “no” when warranted.
Of course, all of this assumes you are working in a Waterfall development environment. If you happen to be using an Agile process, then your strategy plays an even more important role because you will (or at least should) be using your strategy to actively choose which requirements you want to develop during each successive design sprint. Because each sprint will focus on a limited number of requirements from a much larger list, you will be naturally forced to choose what to work on, and what not to work on, based on your overall strategy.
So, yeah, strategy plays a critical role in both of these scenarios. In Agile, it may be more obvious, while in Waterfall, you may need to force your strategy into the picture a bit more aggressively. But, no matter which development process you are using, make sure your development team knows what your strategy is.
Then, they’ll be the ones to say “no” before you ever have to.
Listen to the podcast episode
Dear Strategy: Episode 021
###
Bob Caporale is the author of Creative Strategy Generation and the host of the Dear Strategy podcast. You can learn more about his work by visiting bobcaporale.com.
