Michael on Product Management and Marketing has posted the first in his series of product management commandments – Know Thy Customer. He provides five tips on how to know your customer better. We extend his idea to include understanding our customers’ markets, and provide more tips. By analogy, this is the difference between a detective who studies a criminal and a profiler who seeks to understand a class of criminals.
The 8 Goals of Use Cases
Why do we write use cases? For the same reasons that our users use our software – to achieve a goal. In our case, we want to assure that we are creating the right software. By looking at this goal in more detail, we can make decisions that drive the best possible use case creation. Lets apply our product management skills to writing better use cases by writing an MRD for use cases
Writing Good Requirements – The Big Ten Rules
Pragmatic Marketing has a training seminar called Requirements That Work. In support of that, they provide a list of 8 characteristics of good requirements. We change one and add two more to round it out to The Big Ten Rules. Combine this with Michael’s ten tips for writing MRDs, and we’ve got a good handle on how to create a great MRD.
MRD Writing Tips – Ten from Michael Shrivathsan
Michael has posted five (plus five) tips on writing a market requirements document (MRD). Michael has written a good set of tips with detailed explanations and anecdotes. We have re-organized these tips into three general areas of guidance and provide our thoughts.
Ten Essential Practices of Continuous Integration
Martin Fowler has identified the key process elements of making Continuous Integration work. You could even argue that they are the elements that define Continuous Integration (done correctly). We include his list and our thoughts below:
Targeted Communication – Three Tips
Most guides to writing an executive summary miss the key point: The job of the executive summary is to sell, not to describe.
This from Guy Kawasaki’s recent post, The Art of the Executive Summary. Guy’s article is structured towards pitching an idea to a potential investor. We’re going to apply the same rationale to the communication that is key to successful product development – communication from the team, to stakeholders and sponsors.We also communicate with people outside of our team. We communicate to set expectations with customers, users, and clients.We communicate with sponsors, customers, and others who fund our software development. Without these channels of strategic communication, we won’t have a project, or worse, won’t have a customer when we’re done. External communication is strategic communication.
Top ten tips for preventing innovation
At a recent presentation in Austin by Seilevel about the goals and methods of requirements gathering, a member of the audience asked “What can we do with our requirements to assure innovation?” That’s a tough question with an easy answer – nothing.
What if the question had been “What can we do to prevent innovation?” That’s a better question with a lot of answers.
Software Testing Series: Organizing a Test Suite with Tags Part Two
This is the second in a three-part post about using tags as a means to organize an automated test suite.
Part 2 of this post can be read as a standalone article. If it were, it would be titled Top five problems with test automation suites. If you’re only reading this post and not parts 1 and 3, pretend that this is the title.
Five Measures of Product Manager Performance
Joy posted a really good article last week at Seilevel’s requirements defined blog, Measuring product manager performance on internal system products. Her post is a followup to an extensive and heated debate that happened last fall on the Austin PMM forum. It’s a great forum to subscribe to – a […]