Latest nexus reviews

Very informative

scott.sehlhorst — Sun, 29 Jul 2007 18:12:43 -0500

Tons of details, interesting read. Surprising to see how far back (or how recently) many of the "well, duh" concepts we take for granted were first published - like applying the theory of constraints to systems - in the 1980s.

Very technical and very UML specific

nilsdavis — Thu, 12 Jul 2007 16:20:28 -0500

If you aren't using UML, you probably don't need to read this article.

Also, it features one of my favorite nits about examples - it uses a non-technical example (seminar registration and then actually running the seminar) rather than a technical example. I find it much easier to understand something if the example is technical (e.g., an engineering project, building something, software, creating a new flying car), even if the domain of the example is not my domain.

Extremely basic

nilsdavis — Thu, 12 Jul 2007 16:15:36 -0500

I think there are better definitions of agile out there - this article is a little too basic to be a lot of use. The best part of the article was what agile is NOT - such as "Agile is NOT a way to get software without testing". I would have preferred, though, a bit more discussion of how requirements and testing play into an agile project.

Outstanding Practical Advice

scott.sehlhorst — Wed, 27 Jun 2007 00:51:56 -0500

Outstanding advice - and very practical approach to using financials to drive the investment decision. Also some good "don't get stretched too thin" advice. The comment thread is also excellent.

Great Comments

scott.sehlhorst — Wed, 20 Jun 2007 17:41:16 -0500

There really are some nuggets in the comments on her article!

Excellent article

nilsdavis — Mon, 18 Jun 2007 15:38:04 -0500

I thought the most interesting aspect of this article was all the "it would never work at my company" comments. Of Mayer's six rules, several are "Meetings 101" - always have an agenda, make sure there's a note taker, have a time limit. In fact, it sounds like a big part of her success with meetings at Google is that she actually follows these rules and gets others to follow them. Those rules should work at any company.

Two more rules - hold office hours, have mini-meetings - obviously help her with time management, enabling the claim of 70 meetings per week. 70 five minute meetings per week would still leave plenty of time for beach volleyball at the Googleplex. Depending on the company, you could take or leave these - I interpret them as "semantics."

But the last rule (actually #5 in the article) is going to be the sticking point for most of us - "use data" as the basis for decisions, not emotions or politics. Google, Amazon, and Proctor & Gamble are all examples of companies that have a lot of data, and easy ways to create more data and to test ideas. In this article, Marissa doesn't offer advice for those of us without such a testbed, or a product with hundreds of users rather than millions. However, in a talk via the Stanford Entrepreneurial Thought Leaders podcast (http://edcorner.stanford.edu/authorMaterialInfo.html?mid=1554), she made the point that even a small company with a small amount of web traffic can easily test multiple website versions against one another. Getting data about a product is a bigger challenge, but you can read this article as throwing down a challenge to all of us to start developing ways to get more data to inform our decisions.

Clearly this meeting approach, especially the "use data" aphorism, is working for Google, and for other companies who have the data and make good use of it.

Excellent detailed analysis

scott.sehlhorst — Fri, 15 Jun 2007 23:26:53 -0500

Brian's analysis is awesome. I'm not convinced that I agree with his biases of preferred mechanisms - but I do come from a developer who tests perspective. If I were asking a non-developer to write the tests, then I think I would agree with his biases. Either way - a great analysis.

Just as relevant for business analysis as product management

scott.sehlhorst — Fri, 15 Jun 2007 22:57:25 -0500

I like the article - a good visual that puts product goals in perspective. The same logic applies for business analysts when looking at process improvement projects.

Nils - if you get a chance, update it to include business analysis as a category too.

Great breadth of coverage

scott.sehlhorst — Thu, 07 Jun 2007 22:38:01 -0500

Covers and differentiates many different approaches to code-coverage. Also talks a bit about coverage goals, and provides references to books and articles that go into more depth. Great framework to put different testing approaches into.

Used in the real world

scott.sehlhorst — Thu, 07 Jun 2007 22:33:27 -0500

I've had great success using this approach in the real world on an enterprise project. Not only did we get (and pass on) the needed visibility about project progress, but the team members were also able to visualize their own progress. This ended up helping motivate them to be more effective (than they had been) in meeting deadlines and milestones.

Awesome Visual Graph

scott.sehlhorst — Thu, 07 Jun 2007 22:28:41 -0500

There is a fantastic graph showing the "cost to fix" versus the length of the feedback cycle. What makes it awesome is that Ambler has identified the location on the curve where 10 different feedback techniques apply.

Note: I flagged this as expert because the information is most useful when designing a process - but the content can be absorbed by beginners as well.

Duplicate Entry

scott.sehlhorst — Tue, 22 May 2007 14:54:55 -0500

Guess I need to implement the 'prevent duplicate URLS' functionality

Interesting question

scott.sehlhorst — Sat, 19 May 2007 10:51:10 -0500

It does raise an interesting question - should the site admin and/or the community have the ability to push something off the site? Digg has a "bury it" command, and people can give positive/negative scores to reviews (and "poorly scoring" reviews are suppressed in the display by default. Any thoughts on what we should do here?

best top down strategy article I've seen

scott.sehlhorst — Sat, 19 May 2007 10:48:33 -0500

Seriously - not only is the content spot-on, the writing/copy-editing is excellent and the presentation is perfect. It might be a little bit long for a CXO, but is a perfect length for a product manager. It is also very scannable for the bullets / quotes / soundbites.

Great e-book for technology entrepreneurs

craig.brown — Sat, 19 May 2007 01:47:05 -0500

It targets technology forms - what is important for success, but could be appled to other service buiness as well. If you are in a start up you should definitely read this.

Why

craig.brown — Fri, 18 May 2007 20:21:59 -0500

see what happens when you don't have anti drunk filters on your site!

another good idea

craig.brown — Fri, 18 May 2007 20:20:47 -0500

Some good basic tips for product managers. Worth a read.

Good introduction to the topic

scott.sehlhorst — Fri, 18 May 2007 10:40:54 -0500

Good overview and introduction to the topic. Explains the meaning of each area of evaluation (reliability, assurance, tangibles, empathy, and responsiveness. Doesn't go into details about how to quantitatively apply criteria in these areas, or what actions to take after doing the analysis.

A collection of short articles

scott.sehlhorst — Fri, 18 May 2007 10:35:21 -0500

Craig has pulled together links to a series of just over a dozen articles that cover the spectrum of risk management. A handy resource for an introduction / overview of the space. In his roundup article he maps the risk management areas back to the PMBoK areas.

Testing our site

scott.sehlhorst — Fri, 18 May 2007 10:32:04 -0500

I think this article is actually just testing nexus, and not actually an article about testing. And the link just sends you back to the main page of nexus.