Posted by Tom Grant on September 8, 2008
Sometimes, personal or organizational change depends less on what new techniques you choose, and more on the fact that you're making any choice at all. For example, to some degree, losing weight is about making a commitment to some dieting technique, to be named later. Which diet you choose matters, of course, but it's not the sole determinant of weight loss.
In doing research here at Forrester, I keep having that thought as I skip merrily from topic to topic. Thinking about adopting some requirements tools? Good for you! The acknowledgement that you need better ways to track and analyze what customers want you to build, rather than what you prefer to build, is the first step towards greater product success. Before you choose the right tool, congratulate yourself on making that commitment.
Feel like the development team is going to lose its collective mind trying to apply some waterfall methodology? Congratulations! You're ready to look at the product development process in a whole new way. Soon, you'll be ready to pick the Agile methodology that works for you.
Curious what role product management plays in successful software as a service (SaaS) products? You're already asking the most important question, which is, "How might the people whose job it is to help connect customer needs with product capabilities make SaaS solutions successful?" It's great to know how other people have deployed their PM resources in SaaS projects, but you might have plunged forward without thinking about PM at all. Then you would have discovered that your SaaS customers aren't the same as the on-premise customers, and that they really want a different set of features...
Once you make a choice to follow a different path, the path selected imposes some strictures on how you travel. Different methodologies impose the rules of the road the same way that speed limit signs, onramps and offramps, and trees behind which police cars might be lurking impose discipline on drivers. The traffic signs in Europe might be different, and the police car sirens may make a different noise, but the constant reminders of correct driving habits exist in both cases.
Similarly, picking a requirements tool forces you to have a discussion about requirements. What content is important? For whom? How often should we update it? Where does it fit into strategic and tactical decisions? Who's good at collecting and analyzing requirements? In some companies, that conversation among the different producers and consumers of product requirements may be far more important than the tool itself--though the decision to implement the tool inspires a discussion that probably would not have happened, or reached any conclusions, if there weren't a software implementation depending on the results.
I'm exaggerating a bit, of course, and I'm mixing metaphors wildly. Not every requirements tool, Agile methodology, or PM job description for a SaaS project is made equal. Still, the differences among them are certainly not the only reasons for success and failure. Making the choice to do better, and then receiving reminders through the methodology or tool selected, matter quite a lot on their own.