Can you imagine a time when you might save the cost of plane tickets, travel time, and a real life, in-person experience, to attend a meeting entirely on your computer? As a software veteran who assisted with the creation of virtual tradeshows in the mid-1990's, I can assure you that thoughts of any viable virtual reality for association conferences have been far from my mind in recent years. However, as Moore's Law predicts (and Kurzweil's accelerating change concepts further embellish), technology only continues to get better, faster, and cheaper. Maybe a virtual meeting in the near future isn't so far-fetched.
Most people have heard of the game "Second Life" by now. It is a simulated, digital world accessible through your computer, where it's not unusual to see characters (also called avatars) created by people, reflecting anything from a whimsical, cartoonish portrayal of themselves, to a vision of what they perhaps wish they looked like (and, in most of those cases, I doubt few actually do). During the odd time or two when I've been curious enough to try the game, I was shocked at the complexity of behavior I saw online.
However, to my surpirse, I've heard of many recent examples of these virtual worlds being used for far more than play. In fact, the U.S. Federal Government has used Second Life to train soldiers on how to operate a bomb disposal robot. That certainly holds more credibility than witnessing Second Life being used as an artificial dating site or an outlet for repressed behavior. I guess things are advancing.
In recent market research I have conducted with associations and the leaders who run their meetings and educational programs, statistics of interest in the virtualization of meetings are growing (46% of leaders believe their attendees "would rather have increased options to attend meetings and conferences virtually..."), but still not overwhelmingly. And when it comes to networking, leaders clearly state that technology will never replace in-person dialogue (only 17% of leaders "believe their attendees would rather network with technology than in real life"). So there is a dichotomy in response: the desire to attend virtually exists, but the primary benefit of in-person networking remains a physical world reality. What jumps out as intriguing to me is that based on what I have observed, Second Life is probably more beneficial for virtual interaction ("networking") than anything else I've seen it used for!
One of the facts about any shift in using technology to replace a former physical activity is that education, awareness, and proof are needed, before the support and the desire to transition to something new becomes evident. The proof remains to be seen. Simply by exploring a few of the virtual tradeshow experiences that are out there right now leads me to believe that effective virtual interaction is indeed getting closer.
http://www.goexhibit.com/demo/
http://vshow.on24.com/vshow/on24
As we consider remote content access options at OASIS in the future, it's helpful to keep an eye on this type of development and its uptake in the market. Cool stuff, indeed.
Thursday, September 3, 2009
Wednesday, August 12, 2009
OASIS Product Management Mantras, Fin
In closing....
The bottom line, which spans across every single one of the mantras previously mentioned, is that good product management decisions yield efficiency on all fronts. This includes efficiency across team interaction, feature output, software usability, and customer process. If efficiency is created, countless interrelated objectives also become possible. Some of the more visible pain points that we hear in our industry everyday—such as the desire to have greener processes, the objective to foster remote education, and the need to reduce operational cost—are natural beneficiaries of efficiency. It is our goal for OASIS to ensure that efficiency is created in our product, but most importantly, for our customer.
The bottom line, which spans across every single one of the mantras previously mentioned, is that good product management decisions yield efficiency on all fronts. This includes efficiency across team interaction, feature output, software usability, and customer process. If efficiency is created, countless interrelated objectives also become possible. Some of the more visible pain points that we hear in our industry everyday—such as the desire to have greener processes, the objective to foster remote education, and the need to reduce operational cost—are natural beneficiaries of efficiency. It is our goal for OASIS to ensure that efficiency is created in our product, but most importantly, for our customer.
OASIS Product Management Mantras, Chapter 10
Ensure that everyone (and everything) communicates openly … and remains open to change.
No process, person, or solution is ever perfect. Not even the best-designed product will survive without change and careful refinement over time. One challenge of software development is that foundational technologies advance so quickly, even though it is so easy to build a complex application on top of a particular platform or framework. Often, this development happens reactively, in response to immediate, perceived issues. Because of this, some of the smartest decisions that can be made include the use of best-of-breed design patterns that aren’t bound to a particular technology. Instead, well-selected design (and development) patterns ensure that an application’s distinctive competencies are transferrable, and may be considered to be portable for future technology decisions … with a predictable amount of work. Under the current OASIS design mantra, all decisions that are made related to the next-generation application are built upon best-practice agreements made across the product team early and often. This permits individual teams to run lean, as the former point suggests (since these agreements are known, documented, and communicated widely), but also ensures that architects and key decision makers have been involved with the foundational decisions from which all other concepts are derived. This empowers our teams to run effectively and autonomously, and ensures that decisions which get made today have consideration for the future. Change happens. The OASIS product team strives to be ready when it does.
Since not all change can be predicted, and even the best use of design patterns cannot avoid a certain amount of encapsulation in a particular technology, it is imperative to also acknowledge that the concept of open communication also applies to the software application itself. In a recent survey we conducted, a trend emerged early (and remained consistent) which confirms that “open, service oriented data accessibility” is a top-priority for modern software consumers. This includes concepts like web service availability and API-based access to the application. We will remain aware of these opportunities and ensure that open communication is a universal goal in all of our product management decisions.
No process, person, or solution is ever perfect. Not even the best-designed product will survive without change and careful refinement over time. One challenge of software development is that foundational technologies advance so quickly, even though it is so easy to build a complex application on top of a particular platform or framework. Often, this development happens reactively, in response to immediate, perceived issues. Because of this, some of the smartest decisions that can be made include the use of best-of-breed design patterns that aren’t bound to a particular technology. Instead, well-selected design (and development) patterns ensure that an application’s distinctive competencies are transferrable, and may be considered to be portable for future technology decisions … with a predictable amount of work. Under the current OASIS design mantra, all decisions that are made related to the next-generation application are built upon best-practice agreements made across the product team early and often. This permits individual teams to run lean, as the former point suggests (since these agreements are known, documented, and communicated widely), but also ensures that architects and key decision makers have been involved with the foundational decisions from which all other concepts are derived. This empowers our teams to run effectively and autonomously, and ensures that decisions which get made today have consideration for the future. Change happens. The OASIS product team strives to be ready when it does.
Since not all change can be predicted, and even the best use of design patterns cannot avoid a certain amount of encapsulation in a particular technology, it is imperative to also acknowledge that the concept of open communication also applies to the software application itself. In a recent survey we conducted, a trend emerged early (and remained consistent) which confirms that “open, service oriented data accessibility” is a top-priority for modern software consumers. This includes concepts like web service availability and API-based access to the application. We will remain aware of these opportunities and ensure that open communication is a universal goal in all of our product management decisions.
OASIS Product Management Mantras, Chapter 9
Run lean … this includes teams, specifications, features, and nearly everything else involved in output.
This point is a perfect complement to the former. In order to achieve efficient, continual output, a product team cannot be laden with excessive processes and unnecessary constraints. Certainly, some processes are necessary to keep the product organized and operational. The Agile software development methodology, although perpetually driving progress forward, has many standard operating procedures. However, running as lean as possible achieves certain benefits through quick, intelligent decision making, the ability to self-correct, and a means to design from common sense instead of “design by committee." To quote a decent article I read not too long ago, “a camel is a horse designed by committee.” OASIS shall become a race horse … and a fast, efficient one at that.
This point is a perfect complement to the former. In order to achieve efficient, continual output, a product team cannot be laden with excessive processes and unnecessary constraints. Certainly, some processes are necessary to keep the product organized and operational. The Agile software development methodology, although perpetually driving progress forward, has many standard operating procedures. However, running as lean as possible achieves certain benefits through quick, intelligent decision making, the ability to self-correct, and a means to design from common sense instead of “design by committee." To quote a decent article I read not too long ago, “a camel is a horse designed by committee.” OASIS shall become a race horse … and a fast, efficient one at that.
OASIS Product Management Mantras, Chapter 8
Ensure that development output happens frequently … at the expense of formality and even some bugs.
In any organization, but especially at a small, lean organization, output matters more than almost anything else. This is our individual, internal measure of efficiency. In the Agile software development language, this correlates with a high “velocity” of software feature output. Without requiring a casual reader to understand the nuances of Agile software development, there are some very relevant by-products of this concept that are easily understood. For example, continual output fosters frequent input from users. This input, in the form of usability testing, customer feedback, and analysis of software usage trends (analytics), can be integrated into all future product plans. When this occurs, the benefit is immediate. Short feature release cycles are supported by tangible, real-life data on what has previously been successful. The voice of the customer is reflected in subsequent output almost as quickly as it is received. When this occurs, even the occasional bug or issue is forgotten in the face of how radically the software advances, and how revolutionary the features become for all customers. Oh, and even the bugs are corrected quickly.
In any organization, but especially at a small, lean organization, output matters more than almost anything else. This is our individual, internal measure of efficiency. In the Agile software development language, this correlates with a high “velocity” of software feature output. Without requiring a casual reader to understand the nuances of Agile software development, there are some very relevant by-products of this concept that are easily understood. For example, continual output fosters frequent input from users. This input, in the form of usability testing, customer feedback, and analysis of software usage trends (analytics), can be integrated into all future product plans. When this occurs, the benefit is immediate. Short feature release cycles are supported by tangible, real-life data on what has previously been successful. The voice of the customer is reflected in subsequent output almost as quickly as it is received. When this occurs, even the occasional bug or issue is forgotten in the face of how radically the software advances, and how revolutionary the features become for all customers. Oh, and even the bugs are corrected quickly.
OASIS Product Management Mantras, Chapter 7
Make sure that both you and your users can sum up your product’s key features … in 30 seconds.
This concept is also known as The Elevator Test. This is a great test for pitching your product, feature, or idea. Imagine that you are riding in an elevator with somebody that you just met, and that person happens to ask you what your product or feature “does.” You are traveling only a few floors with this stranger … could you successfully convey your concept in that short time? If the answer is “no,” then something is not right. In an enterprise-grade, robust product, this may not seem like an easy task. However, even SAP has a clear tagline. Clarity of explanation should arise from clarity of feature set scope. Clarity of feature set scope arises from clarity of user goals. Clarity of user goals arises from an acute awareness of real customer problems. This is a paramount goal in all future OASIS development. That is, to ensure that features reflect best-case solutions to real, proven customer problems. In many cases, less becomes more. This ensures that only the most valuable features, which solve the most common and the biggest customer problems receive the most attention.
This concept is also known as The Elevator Test. This is a great test for pitching your product, feature, or idea. Imagine that you are riding in an elevator with somebody that you just met, and that person happens to ask you what your product or feature “does.” You are traveling only a few floors with this stranger … could you successfully convey your concept in that short time? If the answer is “no,” then something is not right. In an enterprise-grade, robust product, this may not seem like an easy task. However, even SAP has a clear tagline. Clarity of explanation should arise from clarity of feature set scope. Clarity of feature set scope arises from clarity of user goals. Clarity of user goals arises from an acute awareness of real customer problems. This is a paramount goal in all future OASIS development. That is, to ensure that features reflect best-case solutions to real, proven customer problems. In many cases, less becomes more. This ensures that only the most valuable features, which solve the most common and the biggest customer problems receive the most attention.
OASIS Product Management Mantras, Chapter 6
Keep your product fun, innovative, and modern … but remember that some things deserve to be simple.
Technology will never stop evolving, and occasionally there will be cutting edge, contemporary graphical user interface concepts that will amaze us all as they are released. However, this bullet can best be illustrated with an example. A current, sought-after trend in so-called modern web application development is the autocompletion textbox. This Ajax-based concept (which really just means lots of updates, with no page refreshes) allows a field to suggest previously entered terms, which could successfully complete what the user is presently typing. Would it make sense to utilize this concept in a location where every entry was expected to be unique? No! Certainly, you could try to implement this feature as overkill, just in case two users were “kind of” trying to say the same thing. But that would just not make good sense. It might actually slow things down and confuse some users. That would be bad. With any new concept or metaphor that arises, this is a worthwhile consideration to make. If the feature doesn’t clearly add value and efficiency in a particular location, adding it risks losing value.
Technology will never stop evolving, and occasionally there will be cutting edge, contemporary graphical user interface concepts that will amaze us all as they are released. However, this bullet can best be illustrated with an example. A current, sought-after trend in so-called modern web application development is the autocompletion textbox. This Ajax-based concept (which really just means lots of updates, with no page refreshes) allows a field to suggest previously entered terms, which could successfully complete what the user is presently typing. Would it make sense to utilize this concept in a location where every entry was expected to be unique? No! Certainly, you could try to implement this feature as overkill, just in case two users were “kind of” trying to say the same thing. But that would just not make good sense. It might actually slow things down and confuse some users. That would be bad. With any new concept or metaphor that arises, this is a worthwhile consideration to make. If the feature doesn’t clearly add value and efficiency in a particular location, adding it risks losing value.
Subscribe to:
Posts (Atom)