Design-Free requirements are important for two reasons, and hard for two other reasons.
Design-free requirements are hard because you “know what you want” when you should be documenting “why you want it.” Writing design-free requirements can be hard when you don’t trust your development team to “do the right thing” even though it is not your job to design the solution.
Kano Analysis, while initially created to understand customer satisfaction with features, can be used by product managers to better understand customer problems. I gave a presentation last week for the Product Management View webinar series on Kano Analysis for product managers.
Concise requirements give your team a useful, easy to read and easy to change understanding of what must be done. Great requirements exist to do three things:
Writing valuable requirements is important. It doesn’t matter how well your teams execute if they are off building the wrong products / capabilities / features. The right products and capabilities are the ones that have relevant value.
User stories can make requirements management a lot easier. They shift some of the communication from up-front documentation to ongoing dialog. That’s the main reason they work so well for agile teams. And agile teams focus on “what’s next?” instead of an ever-changing “what’s everything?” The problem is, when those conversations are working well, it is easy to forget to make sure that what you’ve done is actually enough. Add a small dose of traceability, and you can easily validate the completeness of your user stories.
When defining requirements, you always start in the context of a goal – either a user goal or a corporate goal. You need to be aware of both. Having a positive user experience is important, and requires a user-centered understanding. Achieving your corporate goals might be in conflict with some user goals.
Blue Ocean Strategy provides an interesting reactive analysis of companies and markets. Personas are used to understand your customer’s needs. Combining the two provides powerful proactive insights when positioning your product for market success.
A lot of books and blogs and experts tell us to use “The System shall…” when writing requirements. Read on to find out why that’s not a very good idea.
Growth is a make or break measurement for products and companies. Investment is often determined by expected value, which is based (in part) on expectations of growth. When you create a product, there are aspects of growth – how many people can use your product, and how many people do use your product. When dealing with a freemium business model, there are two elements of use - paid use and free use.
No cell for Dell. According to Kaufman Bros. analyst Shaw Wu, carriers rejected prototypes from Dell because the “lack of differentiation.” As product managers, we know the importance of keeping up with the Joneses, but we also know the importance of including differentiated value in our product offerings.
These articles are written primarily for business analysts and product managers. Hopefully they are helping you with thinking, doing, and learning. Welcome aboard!
Latest Articles
Comments on all Articles