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?

Post to Twitter Post to Facebook

This article was published on Tuesday, June 9th, 2009 at 2:07 pm and is filed under Business Analysis, Product Management, ProductCamp.
You can leave a comment on this post

5 Comments

  1. Looks like ProductCamp NYC has been moved to the Downtown Association http://www.thedta.com/

  2. This is what I love about ProductCamp. I’m totally geeking out over the diagram. Can’t wait to see what you guys come up with, but I’m sure it will be innovative.

  3. @NYC product camp fans – I updated the venue for NYC per tweet from @BstnMelody and email from Steven Haines.

    @Paul – thanks, yeah, I love that stuff too!

  4. To your observation that there was a “drop-off in attendance as people left before the end of the day – more attendees for earlier sessions,” one possible deduction that you could have used as part of your domain knowledge is that people get tired over the course of the day! Perhaps having an un-conference up until the mid-afternoon and then encouraging topical “scrums” for lively decompression and networking in a large room might encourage people to stay. I’ve managed many workshops in my career, and I find that letting the day’s events correspond to the anticipated energy level of the participants is helpful (e.g. “tactical” stuff in the morning, “pie-in-the-sky”/brainstorming/strategy stuff in the afternoon, and lots of sugar/caffeine).

2 Trackbacks

  1. By Scott Sehlhorst on June 9, 2009 at 8:09 pm

    New Tyner Blain article: ProductCamps and Class Diagrams: http://bit.ly/CtB6R

  2. By Roger L. Cauvin on June 10, 2009 at 1:53 am

    RT @sehlhorst: New Tyner Blain article: ProductCamps and Class Diagrams: http://bit.ly/CtB6R #prodmgmt

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>