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.
Showing posts with label design guidelines. Show all posts
Showing posts with label design guidelines. Show all posts
Wednesday, August 12, 2009
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.
OASIS Product Management Mantras, Chapter 5
Cater first to your users with the least ability … they will dictate an exceptional level of usability.
While I worked in the E-Comerce industry, there was a prevalent mantra which arose as a result of how the Americans with Disabilities Act (ADA) legislation impacted (and benefitted) all electronic commerce. Users with disabilities impact software decisions in an immensely favorable manner. A significant amount of planning went into ensuring that any software path or process was accessible by impaired users, who utilized browsers that included screen scraping applications, which translated text into a computerized voice. This literally means that entire features were planned, from their inception, to accommodate users who might only be able to “see” a screen as a robotic voice that reads it to them. This technology is incredible! These ADA requirements, which were often nonnegotiable, led to an absolutely fantastic end product for all customers. If an application is so accessible as to accommodate a digital-voiced narrator, it is certainly able to accommodate nearly every other user on the planet. Navigation paths, alternate text-based descriptions, user intefaces, buttons, and graphical decisions become so well thought out, that they can’t help but become successful for all users. Coremetrics clickstream analysis proved that if we could cater to a browser which was a screen readers (literally), there would never be a lack of related, successful user activity across the board. When I saw regions of an E-Commerce site that were highly tuned to accommodate ADA considerations, there was never a lack of traffic, use, and (I suspect) efficiency.
While I worked in the E-Comerce industry, there was a prevalent mantra which arose as a result of how the Americans with Disabilities Act (ADA) legislation impacted (and benefitted) all electronic commerce. Users with disabilities impact software decisions in an immensely favorable manner. A significant amount of planning went into ensuring that any software path or process was accessible by impaired users, who utilized browsers that included screen scraping applications, which translated text into a computerized voice. This literally means that entire features were planned, from their inception, to accommodate users who might only be able to “see” a screen as a robotic voice that reads it to them. This technology is incredible! These ADA requirements, which were often nonnegotiable, led to an absolutely fantastic end product for all customers. If an application is so accessible as to accommodate a digital-voiced narrator, it is certainly able to accommodate nearly every other user on the planet. Navigation paths, alternate text-based descriptions, user intefaces, buttons, and graphical decisions become so well thought out, that they can’t help but become successful for all users. Coremetrics clickstream analysis proved that if we could cater to a browser which was a screen readers (literally), there would never be a lack of related, successful user activity across the board. When I saw regions of an E-Commerce site that were highly tuned to accommodate ADA considerations, there was never a lack of traffic, use, and (I suspect) efficiency.
OASIS Product Management Mantras, Chapter 4
All necessary options should be visible, intuitive, and accessible … think one degree of separation.
Kevin Bacon was not too far off the mark: there really are no more than six degrees of separation between you and just about anything you’d care to be in touch with—even in a software product. However, that is not to say that everything needs to coexist in the same screen real-estate. Immediate goals naturally lead to secondary, related goals. It is entirely possible to map out how goals cascade into one another. Within this view of an application, smart decisions about how to create interface flows can be made. In Agile software development, this might reflect a necessary concept of a “genealogical” map of story relationships. (For the layperson, a story translates into a contained, feature-requirement in product development—these are typically small, self-contained, and able to be described in a sentence). A recent story exercise we went through on the Product team yielded 43 stories within the first two days. It might make perfect sense to show how these stories are interrelated in some kind of a family tree. These series of relationships will most certainly positively-affected decisions about how to create software-level, graphical user interface navigation and paths between objectives.
Kevin Bacon was not too far off the mark: there really are no more than six degrees of separation between you and just about anything you’d care to be in touch with—even in a software product. However, that is not to say that everything needs to coexist in the same screen real-estate. Immediate goals naturally lead to secondary, related goals. It is entirely possible to map out how goals cascade into one another. Within this view of an application, smart decisions about how to create interface flows can be made. In Agile software development, this might reflect a necessary concept of a “genealogical” map of story relationships. (For the layperson, a story translates into a contained, feature-requirement in product development—these are typically small, self-contained, and able to be described in a sentence). A recent story exercise we went through on the Product team yielded 43 stories within the first two days. It might make perfect sense to show how these stories are interrelated in some kind of a family tree. These series of relationships will most certainly positively-affected decisions about how to create software-level, graphical user interface navigation and paths between objectives.
Subscribe to:
Posts (Atom)