Do you recognize this early logo from Amazon.com? Future Now has a great article detailing how Amazon evolved their “add to shopping cart” implementation. From reviewing this summary of the evolution of one feature, we can see that Amazon decided there was value in reinvention. The improved the way their product did something over time. Have you?

Ask A Good Product Manager is a new blog just launched by Jeff Lash, who also authors How To Be A Good Product Manager, one of our favorite blogs.

A look back at the best from this week in the past.

Barry Boehm, inventor of the spiral model of software development, may also be the originator of the CRACK acronym for the type of users we want on our projects. When defining (and executing on) projects, we don’t just want CRACK users, we want CRACK stakeholders. And we want them to stick around. In fact, we’re addicted to them.

We’ve been promoting use cases as the right way to approach agile requirements, and in a recent article, Alistair Cockburn stresses the importance of use cases. Over the last three years, he has found that teams that avoid use cases consistently run into the same three problems. We defer, of course, to Alistair as the expert. But we’ve been independently promoting this practice too. So today, we get a cookie!

A look back at the best from this week in the past.

A successful agile team requires someone on the team to act as the voice of the customer, someone to lead the developers, someone to lead quality assurance, and someone to organize, coordinate, and assure execution. For an agile team to succeed in an enterprise ripe with political resistance to agile, someone has to be the “voice of the team” as well.

You can approach this by classically assigning roles and responsibilities - but that isn’t the only way. Agile teams are most effective when they have specializing generalists who can mutably adapt to the immediate needs.

Too much information about requirements or too little? Too much documentation or too little? Use the NICE framework to get it just right.

A look back at the best from this week in the past.

How do you approach starting a small requirements project as part of a large initiative within a massive enterprise? Do you boil the ocean? Your customer knows she needs “requirements” to give to her development team. She asks you - what will you deliver, and how long will it take? Great questions. If you have to write a statement of work, with time/cost estimates, and a list of deliverables - what would you do?