ProductCamps and Class Diagrams

For you product managers out there – here are a couple upcoming productcamp unconferences. For you business analysts, here’s an excuse to do a little domain modeling and practice your UML class diagram skills.

Upcoming ProductCamps

There are at least four productcamp unconferences coming up in the near future. I’ve been able to attend (and host sessions at) both of the productcamp Austin sessions, and they were great. If you can make it to a session near you, you definitely should. And if you go, you should help out – these are entirely free, and their quality directly relates to the amount of volunteer support that the attendees give.

1. ProductCampNYC – Jul 18th 2009 @ The Downtown Association, New York City, NY. More info.
2. ProductCampAustin – Aug 2009 (exact day and venue TBD). More info.
3. ProductCampToronto – (everything TBD). More info.
4. ProductCampSeattle – Oct 10th 2009 @ Amdocs. More info.

Check out the comments on this article too – as updates happen in different cities, I’m sure folks will post them here.

[Note: I updated the venue for the NYC product camp on 10 Jun 2009]

If you’re on twitter, you can search for #pcampnyc, #pca, for NYC and Austin productcamp info (respectively). Or follow @ProductCampNYC.

Session Planning

One of the interesting things about productcamp is that it is a barcamp-style unconference. That means it is free, and in theory, there is no centralized planning of sessions. However, there’s a lot of planning that goes into having these unplanned sessions.

Roger Cauvin is one of the volunteers helping to organize the next productcamp Austin, with a focus on sessions. He and I met over some seriously tasty Greek food at Tino’s Greek Cafe in Austin yesterday for lunch to begin planning for the sessions. Our discussion focused around how the attendees will best benefit from the sessions, and what we can do to maximize that benefit.

One idea that came up was looking at addressing the frustration that people feel when there are two simultaneous sessions that they want to go see. At previous productcamps, we used a very simple, on-the-fly scheduling approach:

1. We created index cards for each session and stuck them on the wall.
2. Each person had a few (3?) sticky notes, and stuck them under each session card.
3. The ones that got the most were lined up in the same room (to reduce conflicts in the popular sessions).
4. The rest of the sessions filled up the room/time slots without any particular optimization.
5. We did this sequencing in a couple minutes after everyone quickly “voted” with their post-it notes.

We learned, from “customer” feedback from the first two sessions that there is room to improve:

• People were still expressing frustration about “good session” conflicts.
• We also noticed a drop-off in attendance as people left before the end of the day – more attendees for earlier sessions.

So, if we’re going to improve session planning, one of the things we need to do is understand the details of sessions. This is where domain modeling comes in.

We can create a UML class diagram that represents the domain of planning for (and attending) sessions. This serves as an example of applying the business analysis techniques to gain insight into a problem domain before attempting to define a solution.

We know the following things about the domain:

• There are a limited number of rooms available for sessions.
• There are a limited number of time-slots available for sessions.
• Each session has a topic and presenter(s), and happens in a single room at a single time-slot.
• Each session has multiple attendees.
• Each attendee wants to attend multiple sessions.
• Each attendee has a prioritized list of sessions they expect will benefit them if attended.
• Each attendee can only attend one session per time-slot.
• Each attendee wants to maximize the benefit that they get from the productcamp.

[larger image]

The diagram above shows the relationships that will inform the design of any solutions. For more on how to create UML class diagrams, check out our tutorial series on domain modeling. One challenge of domain modeling is that there are often multiple ways to represent the same relationships. With a goal of “understand the domain” – how would you model this differently?