(1 votes, average: 5.00 out of 5)
Loading ...
One of my colleagues got into a debate with one of his colleagues about the differences between goals and requirements. His opponent fired the following salvo: “[That] is not a business requirement in any company of the world…”
What you call your requirements is less important than how you communicate them.
(1 votes, average: 5.00 out of 5) Loading ...
I came across a really interesting article LukeW.com, showing how making changes to the way an input form on a website increased interaction by 25 to 40%. The changes reflect the value of thinking outside-in, investing in user experience, and performance measurement.
Bonus: the idea is cool.
(3 votes, average: 4.00 out of 5) Loading ...
You give your requirements to the engineering team, and they look complete. The team builds your product, you launch it and the market soundly rejects it. Why? Because your requirements weren’t complete – they didn’t actually solve the problem that needed to be solved.
(3 votes, average: 5.00 out of 5) Loading ...
Engagement – that’s what this whole product management blogging thing is about. Check out what Tyner Blain readers found to be the most engaging articles in 2009.
(5 votes, average: 5.00 out of 5) Loading ...
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.
(2 votes, average: 5.00 out of 5) Loading ...
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.
(1 votes, average: 5.00 out of 5) Loading ...
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.
(5 votes, average: 4.40 out of 5) Loading ...
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:
(3 votes, average: 5.00 out of 5) Loading ...
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.
(3 votes, average: 4.67 out of 5) Loading ...
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.
Free RSS subscription
(more...)
Subscribe to comments RSS for free
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Feb | ||||||
| 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 | 31 | ||||
 |
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!
