John Peltier
Agile Product Management, Marketing, and More
ProductCamp Austin – Winter 2009
Jan 10th
On Saturday, January 24, 2009 it appears that I will be attending ProductCamp Austin. ProductCamp is part of the BarCamp family of participant-driven conferences, focused on product management and marketing.
Paul Young describes the experience of ProductCamp:
You head to the back wall and read the session names, offered by people just like you. You recognize a friend-of-a-friend’s name who is giving a session about “Connecting with Customers.” That sounds good – you use one post-it note. You see another session about “Agile Product Management.” Your engineering team is moving to Agile so that might be a good session to attend, and use your second note. As you step back to consider your third note, you see a dozen other people doing the same thing, and people feel geniuely torn about what to vote for – there are so many good sessions to choose from! Finally, you put your last sticky on a session called “Career Building in Product Management and Marketing.”
The conference currently cites over 156 participants including representatives from small startups to large technology players such as Dell, Cisco, and AT&T. I look forward to the organic mingling of people in the product management field, to sessions led by people experienced in the field, and of course to the happy hour after it’s over!
Hope to see you there!
Metrics
Dec 29th
I just ran across an interesting presentation on the use of metrics in product management by Dan Olsen, which shines some light on the art of convincing the business side of the organization of the value of a proposed solution. Though the metrics in the presentation are primarily website-related, including click-through rate and rate of registration for a site, the concepts are still applicable to all types of business cases.
Particularly insightful is the idea of graphing the ROI of various benefits in an attempt to illustrate the value proposition (slide 26). Those customer benefits which have the highest importance to the user, but which have the lowest current satisfaction rate, may be the ideal benefits to bring to the table first, or as labeled within the slide deck, “upside potential.”
Have a look!
Documenting Requirements
Dec 28th
The language of requirements is a challenge to explain: there is an art involved in writing declarative statements that specify what needs to happen without inadvertently limiting the implementation. Certainly, the choice of words is important: words like “select” and “supply” are more vague than “click the radio button for” and “type into the text box,” but there’s more to it. I’ll elaborate on that in a future post.
I continue to be more convinced that multiple methods of delivering requirements are needed to draw a complete picture. So even though one might have the language challenge under control, various types of models (both graphical and verbose) can help to provide views into the system’s requirements from all sides. But how do they relate to each other, and how do the models relate to the declarative statements that provide the granular detail of what is needed?
The methodology I’ve seen implemented most frequently, when boiled down to brass tacks, is just interviewing and observing users and identifying requirements, and then backing them up with more intricate system models. The more I reflect, however, I think there may be a smarter way. One approach I’ve seen from a few sources is to depict the system’s primary uses in the form of use cases, which can be further broken down into any number of scenarios that depict the use case with specific input values and paths through the use case; and then, writing requirements that support each use case. One point made in a highly recommended article at TechTarget.com is: requirements that don’t tie back to a use case may be a warning sign of missing use cases. Working through a deliberate methodology like this might be a step towards preventing any significant gaps in requirements capture.
The above article from TechTarget also considers data elements, and recommends entity-relationship diagrams to zero in on the data elements. As a product manager, I see that fitting in a little deeper into the cycle at the business analysis/design stage, not at the customer requirements/analysis stage. What do you think?
Non-Functional Requirements as Stories
Nov 30th
In a prior post, I suggested that the use of a thorough checklist of possible non-functional requirements categories is a good way to probe for the relevant requirements on a specific project under consideration. As I think about it now, I realize it may also help to review non-functional requirements of other projects as another source of inspiration.
My point for writing today, however, is the idea that regardless of how one arrives at those requirements, one can still use the user-story format for recording them. Particularly when the requirement is a business-level or business-driven requirement rather than a customer-driven one, this format allows the recording of the source of a requirement so that it is easier to explain and remember later:
Consider the example of the CTO constraining the team to use the existing orders database. (This was the real situation; the team was considering a second orders database that would be sychronized at night. The CTO overheard this and said “no!”) If we wrote this requirement as simply “Must use existing orders database” it would be entirely possible that a few months down the road we wouldn’t remember why we should be constrained in that way. We’d ask the product owner if she cared if we used a secondary database, and she’d say she had no objections. And we’d make a mistake of using one. Embedding the person who wants something can be very useful.
In my own experience with collecting and then analyzing requirements for several active projects (Each at a different phase of development) I have run into the problem of not remembering the source of requirements at a later date. The author also suggests thinking of them as “constraints,” rather than “non-functional requirements” — which is a suggestion the linguist in me finds appealing, as it is a more naturally meaningful phrase.
While the CIO suggestion above does illustrate the way I find the user story format to help solve the requirement-source problem, I have a related problem that I have yet to solve: remembering the details of a negotiation. Over time, different stakeholders may make differing or even competing requests. Later in deelopment, when these stakeholders ask why their suggestion was not accepted and implemented, I have a hard time remembering the rationale for a particular decision. Thoughts, anyone?