twitter
rss
email
calendar
mobile
more infoThe 25 Group Symptom in Second Life
I have been struggling with my first of 2008 posts as it was in theory going to be the predictable predictions post, but I really hate prediction posts and frankly another issue has been weighing more heavily on my mind - the "25 Groups" limitation.
The "25 Groups" problem has been swirling about the grid for many months, and most recently gained more press appeal once it was adopted by vocal bloggers (1) (2) (3) in an attempt to get people to vote on the JIRA entry. I agree wholeheartedly with Ordinal Malaprop's perspectives on this matter and *if* I could log in to Jira right now, I'd quote from some of the dialog there.
I did raise a vote on Jira MISC-208 rather than abstain with the sole intent of raising awareness about how horribly broken Second Life Product Management has become as evidenced so clearly by this single case study, even before it has fully unfolded. I'll get right to my punch line, so we don't miss it:
The group limitation is a symptom, not the cause.
Simply raising the group limit, even without bounds, will NOT solve the problem(s) and may create more trouble.
Simply raising the group limit, even without bounds, will NOT solve the problem(s) and may create more trouble.
Starting with group-owned land and diverging from there, Second Life Residents have found creative ways to use groups to overcome what are otherwise shortfalls or failings in the product. Many group features such as basic instant messaging are unreliable, so why then would the populous request more of a bad thing?
The real problem is that this is a symptom of much larger issues, and the rush to determine a quick fix or even the multitude of workarounds can lead to yet even larger problems. What is required in this case, and many others is some serious root cause and usage analysis that any Product Manager would have likely already done. In fact, I mentioned it before, but I will say it again more firmly:
The real problem is that this is a symptom of much larger issues, and the rush to determine a quick fix or even the multitude of workarounds can lead to yet even larger problems. What is required in this case, and many others is some serious root cause and usage analysis that any Product Manager would have likely already done. In fact, I mentioned it before, but I will say it again more firmly:
It's far past time for serious Second Life
PRODUCT MANAGEMENT
PRODUCT MANAGEMENT
Second Life Product Management is a mess, and this particular feature request "More than 25 groups!" has demonstrated many failings of the current system and attendant process that I won't rant forever on all of them, but here are my two main peeves.
1) JIRA does not replace Product Management
Jira was developed and is used quite successfully as a bug and issue tracking tool and it is not the problem. Putting Jira usability and due process issues aside, the first sign of the problem is that Jira is being used as a catch all repository for everything to bugs, requirements, priorities, assignments, and feature requests. I dare say if you had the intestinal fortitude, you might even find a marriage proposal swirling amongst the chaff. Even worse, the implication that the number of votes something gets determines it's priority is deplorable.
Product Management requires forward thinking and proactive planning based on two things: the product road map informed by a healthy business plan and the data about the operations current deployment. Data can include include anecdotal reports, but it should be balanced with meaningful and verifiable sources of information. I have yet to see a meaningful product road map from Linden; perhaps it's held close to the vest for business reasons, but the closest we've come to insight are blog mentions about things such as Expressive Puppeteering - remember that highly publicized feature?
2) Discussions of solutions to symptoms are dangerous!
Making a simple statement such as "increase the number of groups" is much like walking into your doctor and demanding an increased dosage of pain killers; in the end the results might be strikingly similar. Likewise, alternative solutions to resolve the symptom are often useless and at worst more harmful. Consider the cases: Patient: "I need more pain killers because it hurts when I raise my arm". Doctor: "Stop raising your arm.", or perhaps Patient:"I need more pain killers because it hurts when I raise my arm.", Doctor: "Let's just cut off that arm."
Finally, random discussion about why something cannot be changed technically are valid to and for a particular audience, but lend little to the overall analysis and subsequent collective understanding of an issue. The most important effect of this particular symptom should be to raise awareness about the multitude of issues surrounding what is ultimately the most fundamentally broken element of the Second Life product - sociability and networking.
To actually resolve the 25 group symptom and uncover many others, Linden Lab should take a comprehensive look at the spectrum of how groups are used within Second Life (versus "as designed" use cases) as well as the attendant pain points such as the routine of even simple predictive messaging failures. Let's face it, messaging is hardly a difficult technology to master but on how many occasions have your attempts to message even a moderately sized group failed? Being able to actually contact people in a reliable manner is sort of key to a socially based virtual world, and any product manager might be losing sleep about it.
1) JIRA does not replace Product Management
Jira was developed and is used quite successfully as a bug and issue tracking tool and it is not the problem. Putting Jira usability and due process issues aside, the first sign of the problem is that Jira is being used as a catch all repository for everything to bugs, requirements, priorities, assignments, and feature requests. I dare say if you had the intestinal fortitude, you might even find a marriage proposal swirling amongst the chaff. Even worse, the implication that the number of votes something gets determines it's priority is deplorable.
Product Management requires forward thinking and proactive planning based on two things: the product road map informed by a healthy business plan and the data about the operations current deployment. Data can include include anecdotal reports, but it should be balanced with meaningful and verifiable sources of information. I have yet to see a meaningful product road map from Linden; perhaps it's held close to the vest for business reasons, but the closest we've come to insight are blog mentions about things such as Expressive Puppeteering - remember that highly publicized feature?
2) Discussions of solutions to symptoms are dangerous!
Making a simple statement such as "increase the number of groups" is much like walking into your doctor and demanding an increased dosage of pain killers; in the end the results might be strikingly similar. Likewise, alternative solutions to resolve the symptom are often useless and at worst more harmful. Consider the cases: Patient: "I need more pain killers because it hurts when I raise my arm". Doctor: "Stop raising your arm.", or perhaps Patient:"I need more pain killers because it hurts when I raise my arm.", Doctor: "Let's just cut off that arm."
Finally, random discussion about why something cannot be changed technically are valid to and for a particular audience, but lend little to the overall analysis and subsequent collective understanding of an issue. The most important effect of this particular symptom should be to raise awareness about the multitude of issues surrounding what is ultimately the most fundamentally broken element of the Second Life product - sociability and networking.
To actually resolve the 25 group symptom and uncover many others, Linden Lab should take a comprehensive look at the spectrum of how groups are used within Second Life (versus "as designed" use cases) as well as the attendant pain points such as the routine of even simple predictive messaging failures. Let's face it, messaging is hardly a difficult technology to master but on how many occasions have your attempts to message even a moderately sized group failed? Being able to actually contact people in a reliable manner is sort of key to a socially based virtual world, and any product manager might be losing sleep about it.
Posts
3 comments:
Hello Grace,
first, ta for your insightful remarks. I agree with you but, still did vote on the issue. Not because I need more groups (I'm still comfortably below 25), but because I liked the idea of gathering enough moment on the JIRA to see if any amount of resident complaints could force the Lindens to state their position on development, give us a glimpse of their roadmap, and show how they intend to handle problems widely complained about. As to the issue itself, I defer entirely to Ordinal’s technical knowledge, which is far superior to mine.
Which is quite a lengthy way to tell you that you are absolutely right by talking about the bigger picture : we need a whole health service, not some band aid (or some painkillers, I like your simile :)). But, besides the bigger picture, the clamouring and vociferous requests may also be a crucial part of the process to make LL understand the situation as well. What ways to demonstrate (or remonstrate) on technical issues are there but the P-JIRA ?
Hey Rheta,
Thanks for your comments. I voted as well, for very much the reasons you stated. And you are right, that despite all the shortcomings, Jira is filling a need. I know of no other mechanism at this point. There was a feature voting tool, but that was also a mess.
The unfortunate part is that the manner in which Jira's being used is quite possibly masking issues that would otherwise be exposed.
Post a Comment