Unless you live in a world filled with unicorns and rainbows, writing realistic requirements is critical. When you set unattainable goals, the best result you can hope for is a frustrated engineering team. Write requirements that are attainable, and your team will surprise you with what they can achieve.
SEO, Search Engine Optimization, is an area that every online website needs to think about. The idea is that the more traffic you can get to your website, the more products you’ll sell. Just because you can lead a horse to water doesn’t mean you can make him drink. What a great opportunity to product manage your website and ask why about SEO.
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.
You have an eCommerce site. You sell products online. Do you cross-sell additional products? Do you upsell to better products? This article explains the difference between cross-sell and upsell, and looks at some real-world data about the effectiveness of both.
Perpetually intermediate (competent) users. Users who briefly exist as novice users and never become experts. Most of your users are competent, and you should design for them. Competent users have different needs and different expectations than novice or expert users. How do you know your user’s competency levels, so you can design for them?
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:
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.
For you product managers out there – here are a couple upcoming productcamp unconferences. For you business analysts, here’s an excuse to do a little domain modeling and practice your UML class diagram skills.
When prices go up, demand goes down. But how much does it go down? Price elasticity of demand is the term economists use for the math that describes this behavior.
Free RSS subscription
(more...)
Subscribe to comments RSS for free
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Aug | ||||||
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | |||
 |
These articles are written primarily for business analysts and product managers. Hopefully they help with thinking, doing, and training. Welcome aboard and let us know what you think!
