(7 votes, average: 3.71 out of 5)
Loading ...
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.
(3 votes, average: 5.00 out of 5) Loading ...
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.
(11 votes, average: 4.45 out of 5) Loading ...
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.
(2 votes, average: 4.50 out of 5) Loading ...
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.
(Be The First to Rate This Article) Loading ...
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.
(2 votes, average: 4.50 out of 5) Loading ...
Jump forward in time to the day of your next big product launch (first release, new features, new market segment, etc). And your site/application crashes due to the “unexpected” demand. All you can do now is look for a bucket of water to put out the fire. What could you have done to prevent this disaster? Jump back to today and start doing it!
(4 votes, average: 4.50 out of 5) Loading ...
Just because your requirement is not a user story does not mean you have to throw it out when planning your next sprint. See one way (that is working) for managing non-functional requirements with an agile team.
(33 votes, average: 4.79 out of 5) Loading ...
User Stories are one of the key agile artifacts for helping implementation teams deliver the most important capabilities first. They differ from use cases in some important ways, but share more commonalities than you might think.
(7 votes, average: 5.00 out of 5) Loading ...
There’s really only one way to travel down a waterfall – in a barrel. A lot of people died this way, but some survived. Software projects have been predominantly waterfall projects since the start of software projects. And stakeholders rode down those projects, basically in a barrel. The people riding Niagara Falls 100 years ago didn’t know if they would survive until they got to the end. Stakeholders in waterfall projects don’t know if they will succeed until the end.
An agile project is dependent upon tight interaction (and feedback) with stakeholders.
If you’re running an agile project, and your stakeholders are old-school barrel-riders, how do you make it work?
(1 votes, average: 5.00 out of 5) Loading ...
Satisficing probably makes more sense than perfecting your product.
Can? Open.
Worms? Everywhere.
Are we really saying “don’t make it perfect?” Yup.
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!
