The OBEY sticker campaign can be explained as an experiment in Phenomenology. Heidegger describes Phenomenology as “the process of letting things manifest themselves.” Phenomenology attempts to enable people to see clearly something that is right before their eyes but obscured; things that are so taken for granted that they are muted by abstract observation.

The FIRST AIM OF PHENOMENOLOGY is to reawaken a sense of wonder about one’s environment. The OBEY sticker attempts to stimulate curiosity and bring people to question both the sticker and their relationship with their surroundings. Because people are not used to seeing advertisements or propaganda for which the product or motive is not obvious, frequent and novel encounters with the sticker provoke thought and possible frustration, nevertheless revitalizing the viewer’s perception and attention to detail. The sticker has no meaning but exists only to cause people to react, to contemplate and search for meaning in the sticker. Because OBEY has no actual meaning, the various reactions and interpretations of those who view it reflect their personality and the nature of their sensibilities.

Many people who are familiar with the sticker find the image itself amusing, recognizing it as nonsensical, and are able to derive straightforward visual pleasure without burdening themselves with an explanation. The PARANOID OR CONSERVATIVE VIEWER however may be confused by the sticker’s persistent presence and condemn it as an underground cult with subversive intentions. Many stickers have been peeled down by people who were annoyed by them, considering them an eye sore and an act of petty vandalism, which is ironic considering the number of commercial graphic images everyone in American society is assaulted with daily.

Another phenomenon the sticker has brought to light is the trendy and CONSPICUOUSLY CONSUMPTIVE nature of many members of society. For those who have been surrounded by the sticker, its familiarity and cultural resonance is comforting and owning a sticker provides a souvenir or keepsake, a memento. People have often demanded the sticker merely because they have seen it everywhere and possessing a sticker provides a sense of belonging. The Giant sticker seems mostly to be embraced by those who are (or at least want to seem to be) rebellious. Even though these people may not know the meaning of the sticker, they enjoy its slightly disruptive underground quality and wish to contribute to the furthering of its humorous and absurd presence which seems to somehow be antiestablishment/societal convention. Giant stickers are both embraced and rejected, the reason behind which, upon examination reflects the psyche of the viewer. Whether the reaction be positive or negative, the stickers existence is worthy as long as it causes people to consider the details and meanings of their surroundings. In the name of fun and observation.

Shepard Fairey, 1990

Overview

Below are the answers to a few questions about the difference between SaaS application design and application design.

Key principals SaaS design

• By relying on common web patterns, SaaS designs have more of a “walk up and use” quality which drive most of the design decisions.
• As is typical with most software, SaaS applications release with a core set of services, then add feature to those services or add entirely new services.
• SaaS interactions tend to be narrower and shallow, i.e. the On Demand user drills ‘into’ and ‘out of’ an object and associated content appears as part of this ‘linear’ interaction.
• SaaS can sell every ‘aspect’ of the solution, e.g. IOD is selling ‘services’ and the ‘number of connections’
• SaaS marketing tends to pitch ‘services’ or ‘platform’ offerings
• The SaaS designer may focus on the design of a particular ‘service’ or addition to the ‘service’ for a shorter time period than with thick application design. The designer, however, should also focus on the application’s long term goal, e.g. IOD’s long term goal to become a platform. Therefore, IOD has specific long term platform design goals that should be taken into account when early application activities are planned and executed now.

General Questions

In what ways does the design process of a traditional application/tool need to vary for a SaaS application?

Despite the typical issues and the extreme speed at which the product is developed, the same user centered design process should be used, however, the designer should:

• selectively focus Ux resources on select issues / features
• create a more definitive process timeline where studies are planned either 6, 9, and 12 months in advance
• focus on only one to three design proposals for a cycle.

The reasoning behind this approach is because any more than a few designs will not make it into the development cycle and / or will be de-prioritized for the next release.

Specifically, Informatica On Demand’s four-month delivery timeline causes features to be promoted in and demoted out of the product overnight due to some or all of the following:

• time to build constraints,
• lack of Development resources,
• lack of feature definition,
• lack of design time,
• lack of customer need definition i.e. is this the feature the customer real expects for this release

How should the designer “think” about designing SaaS?

Four things that effect design:

• user’s proficiency / expertise, needs, and expectations
• development resources, cycle, and time to market
• designer’s materials and process
• timeline

The speed at which decision-making and design need to occur should not effect how the designer approaches a design. However, due to the time limitation, I will say, the designer (I) depends more on anecdotal evidence when working on SaaS products.

Is the real factor with SaaS the fact that one is continuously rolling out new and updated features every 4 months?

The continuous feature design and update every 4 months does not really affect the way a designer’s thinking because the product’s design is considered in its ‘entirety’.

With IOD, there was an initial product definition and user experience design then Development builds the core product. Once that core product had been built, the other elements previously defined and designed are built by Development in an ongoing process. At this point, the designer’s roll becomes more of a ‘design shepherd’ because they find themselves

· checking the quality of the previous build,

· modifying the existing design to mimic the elements Development were able to build due to technical limitations, and

· filing bugs against the elements Development created in a vacuum.

How does that fact affect a designer’s ability to plan and contribute?

Unlike other types of conventional applications and tool applications, where timelines allow time to ‘sell a design direction’ up and down the ladder. Rolling features out every four months forces the designer to work lockstep with the user experience development team to create an extremely strong and trusting relationship. And it is this 4-month cycle that makes the synchronization tighter.

Moreover, because the designer is so involved with the Development group, more design problems are presented to the designer, therefore, they are able to implement more consist solutions.

Unfortunately, the ability to plan is more complex because the question becomes ‘do I (the designer) work on known problems OR do I try to find and resolve possible issues?’ Therefore, opting for working on ‘known problems’ relegates research and studies to a secondary position.

Specific application questions

Service(s) versus product feature(s)?

Designing for a ‘service’ versus a ‘product feature’ is different in that interaction and visual design are tighter. ‘Services’ and ‘product features’ appear as a family, however, the designer has more latitude when creating interactions and experiences for a product’s feature. Services require more consistency between experiences and interactions, especially if they are self serve.

Functionality breakdown?

When looking at the ETL possibilities, the IOD product management team extracted the most basic functionality and tried to create parity. IOD ‘services’ tend to be discrete components in a suite of products, i.e. the ‘service’ is designed and developed as a whole solution. Moreover, other elements may be added to enrich the interaction or the service but the service can stand alone without the ‘enrichment’.

Selling service(s) versus product feature(s)?

There is only a slight difference between selling services versus product features. When selling SaaS services, almost every aspect can be sold separately. When selling product features, they are typically sold as a whole package with limited breakdown.

Specific application technical questions

Zero install (and its implications)?

Zero install is a misnomer because 1) there is always, as I understand it, an ‘agent’ that connects the user’s computer to the vendor, and 2) by general definition ‘zero install’ implies that the computational processing happens on the server. Neither of these points are the case with SaaS applications.

Professionals using SaaS application have stated that they expect a download for communication with the ‘service.’ However, the download user experience is crucial because any of the following can cause a user to be dissuaded by the product:

• lack of information surrounding where the application is installed,
• not knowing what exactly it is doing,
• not knowing how to interact with the agent outside of the application (e.g. restart the agent),

Again, lag time or missing information surrounding any of the items listed lead to confusion for first time users during testing and me as a proficient novice user. Moreover, company firewall settings and data (server) access are huge issues for SaaS applications that are being used by people in passing or those who are acting ‘under the radar’

Fewer objects to manage?

Not all SaaS applications use fewer objects or have fewer features than other applications. I believe some of these applications have fewer objects and features to increase ‘walkup usability.’

Specific design related questions

Faster iterations?

The cycle times impact the designer and the design because the cycles are shorter, more condensed. This forces the designer to push for closure on design, design decisions, scheduling, be extremely flexible, and track all decisions energetically.

Quarterly releases?

IOD releases every three to five months.

Incremental functionality?

IOD has delivered complete user facing core services with additional features added in subsequent releases. However, this is typical to most products I have worked on thus far, i.e. release with a core set of features, then add functionality to those feature and broaden the core.

As a designer entering at the end of the core definition, it was important to become extremely familiar with all interactions and Development’s reasoning behind each feature. These interactions and reasons shaped future designs because users have set their expectations on how the application is going to work based on their prior experience. In essence, the designer is almost forced to select from previously created interactions for their new designs. While it is ultimately the designer’s decision to design the best experience, the previously created interactions and Development’s reasoning also drive the various designs.

User feedback?

User feedback for some SaaS is very direct (email link, support link) and is placed prominently in the application space.

For IOD, Help and Feedback links are placed in the upper right hand corner – a common web pattern. The placement of Help in this common and highly visible location offers users assurance through commonality. Moreover, as with other applications, the Solution Managers and Product Managers collect user feedback directly from customers.

Guided tasks versus unstructured tasks?

For Informatica Cloud products, we should offer beginner (wizard assisted) and expert (unaided) modes, if possible. If this is not possible, the designer should adhere to this common practice and offer a guided experience through the most basic creation tasks and access to the more advanced elements during viewing and editing objects.

How to manage large sets of objects?

In Cloud, we provide filtering options for large data sets.

Interaction styles?

Even today, IOD’s development team is focused on stability and new features using the existing technology. The IOD’s web-based interactions are ‘simplistic / crude’ by comparison to the desktop’s interactions. With the Informatica On Demand tool being browser based, this places another level of difficulty on any design activities because the interaction needs to be common to the web 1.0 browser’s user experience for the most part.

Of course, richer interactions are available via various widget toolkits. However, there are issues with each of the widget toolkit options, e.g. proprietary language.

One final thought…SaaS interactions tend to be narrower and shallow, i.e. the On Demand user drills ‘into’ and ‘out of’ an object and associated content appears as part of this ‘linear’ interaction. By comparison, interactions associated with applications can be broad and deep. Understanding this design decision / philosophy will help the designer understand users’ expectations that come from commonality and legacy.

Group ‘psychological makeup’

Team psychology?

One of the things I have noticed from Siebel On Demand (an application) and Informatica On Demand (a tool) is that the team has a team mentality – one for all and all for one. Of course, each individual takes ownership and pride in their section of work and they all tend to pull together to accomplish the delivery.

Moreover, on either of those teams there was very little in fighting or back biting within the team based on what I saw working with development, marketing, product management, quality assurance, and solution management.

Sales team psychology?

SaaS Sales teams are working for smaller deal sizes. The IOD Sales team are working and closing deals in days or weeks as opposed to months or years.

This allows the Sales team to have more contact with more customers which create more datum points from which to form opinions about what is needed in the product. Ultimately, this drives the solution manager and their decision process to pick which features go into the product and may drive the designer to gather information about these requests during interviews and testing.

Dev team psychology?

Based on the shortened timelines, the Dev team tends to be more direct and decisive. As with all products, Dev can decide to make the final call on some items ‘to make the delivery date.’ Ultimately, this effects which features are selected from the design.

Moreover, understanding how the Cloud Development team was going to react to the introduction of new user interface interactions, let alone new interface elements that would require new technology, has caused me to be more cautious in my design proposals and opt for existing interactions rather than introduce a new interaction unless it was truly necessary.

Influencing the team?

The same psychological influences are at play when designing for SaaS and applications. The designer still needs to be ahead of the curve and sell their designs and ideas to the broader team.

Specifically, to get ahead of the IOD curve, the designer should:

• be well versed with the existing design
• the design’s history
• and the team
• understand the product’s “perceived problems” from the customer and the team perspective
• perform usability tests and field research to understand the actual problems
• pick a few of the key problems to develop a concept with anecdotal evidence and sell it to the senior executives like Ron Papas, Krishnan, and Ron Lunasin

So I am going on a year and a half at Informatica and I do have to say, I am pretty happy…and I wonder why. Looking at my track record I spend less than years in any position. Moreover, in the past, I would have start considering how to move on by now for one reason or another. But again, I am as pleased as punch with my current position and the work I have been doing for the last year.

With that said, I would like to call out reason for leaving and staying in a position or company.

LEAVING

• Company – Reading the writing on the wall should be one of the tools any designer has in their ‘bag’.  Having ridden the tsunami created by the dot com pop, I have left companies where the people where imploding.  Having been part of more companies / business units that where is start up mode, I have seen these groups tear themselves apart via infighting.
• Co-workers – Being in a teams has its advantages aand disadvantage

STAYING

• Great location – currently, the location where I work is absolutely beautiful
• Interesting work – being an industrial designer, my interest tend to wain as the time goes on if the work does not change.
• No other job to be had – one of the best reasons to be in valley…options

“Where did the Office team at Microsoft get their inspiration and ideas for the last version of Microsoft Office?”

I’ve been asking this question to different teams of developers every month, for the past 15 years. Every team comes back with the same list of sources, even though, over that period, there have been no less than six new versions of Office and tremendous advances in technology.

The answer is always “from watching and listening to the customers and users of the previous versions of Office.” In other words, the newest version can only exist because there were previous versions. Microsoft’s team has been iterating their designs, one after the other, to get to where they are today. And they’re still iterating.

Iterations are a key piece of any engineering effort. You take an idea, develop it into something, try it out, see how it works, and then start all over again. Microsoft, and every other software company, does this with every new version.

Of course, the release of the new version of Office isn’t the only iteration since the last version. The team has iterated hundreds, if not thousands, of times, using the same exact pattern. It’s just that they don’t show those iterations to the public (and only some iterations to the armies of alpha and beta testers).

And this is one of the great paradoxes of design management: The vast majority of iterations are never seen by anyone outside the team. So, it looks to the outside world that, when a great product comes out, that the team just sat down, thought it through, and built it, without any trial or errors. But nothing could be farther from the truth.

Dissecting A Successful Iteration

Iterations are key to successful design. They help reduce risk by letting us get all the bad ideas out of our system early, keeping only the best of the best.

Unfortunately, we’ve found that many teams don’t know how to iterate effectively. Good iteration is a deliberate activity, with four important stages: planning, implementing, measuring, and learning. The best teams focus on each stage appropriately, making sure they get the most out of it. While iterations can be very short, (we’ve seen teams that can iterate a dozen times in a single day,) the best teams don’t short change any of the stages.

If you’re familiar with Agile development, these stages will sound very familiar. That’s because there are parallels between the types of iteration we do when designing great user experiences and what developers do when building applications. The big difference between UX iterations and Agile iterations is that most Agile iterations focus on coding something, whereas UX iterations can have alternative deliverables, such as wireframes, or persona descriptions.

Interestingly, iteration didn’t originate in either the UX or Agile worlds — its origin goes back to the beginning of engineering practice, hundreds of years. And most interestingly, the stages are still the same today:

Stage #1: Planning

In the planning stage, we decide what we want to learn from this iteration and how we’ll make it happen. We’re not planning what the final design will be, only this iteration. Planning doesn’t have to be a complex process, but it is a necessary part of the conversation.

We go into the iteration with a specific problem in mind. It’s in the planning stage that we decide how we’ll try to tackle that problem and how we’ll tell if we’ve succeeded.(Because it’s easier to understand what to plan once you understand the other stages, we’ll come back to it a little later.)

Stage #2: Implementing

The implementing stage is the most famous part of the iteration. It’s where we create the prototype or deliverable we want to get feedback on.

What’s important to remember about the implementation is that we just want to build out those portions that we’re looking for feedback on. If our final design will have certain functionality, say print capabilities, that we’re not quite ready to look at, then we don’t have to build that portion.

In fact, we can get quite lean. For example, if we are only interested in how the data will show up on the screen, we can hard-code the data into the prototype, eliminating any need to implement a back-end database for this iteration. Conversely, if we’re only interested in whether the server can handle the transactions at a reasonable speed, we only need to write a program that stresses the transaction engine, ignoring the UI.

Stage #3: Measuring

Measuring is a critical stage of the iteration. It’s where we collect the data that will help us decide if our iteration is moving us forward, or if we have to rethink the way we solve our problem.

How we measure will depend on the information we’re trying to collect. If we want to see whether the user interface works for the user, we conduct a series of usability tests. If we want to see if a particular interaction sequence feels right, we just try it out ourselves. Measuring doesn’t have to be a complex process — it just needs to reflect what we’re trying to assess.

Stage #4: Learning

Learning is the final stage and one we often don’t pay enough attention to. In this stage, we take the data we collected during the measuring stage and identify the lessons we’ve learned.

Some lessons will be affirmative — they’ll tell us that the ideas we’ve generated achieved the goals we set out. Some lessons will be more constructive — telling us that we haven’t reached our objectives, but giving us ideas on what to do differently. Using what we’ve learned, we’ll then go back into the planning stage to decide what we want to get from the next iteration.

Revisiting the Planning Stage

Now that you’ve had a chance to see all the stages, let’s take a closer look at the planning stage. As I mentioned earlier, the planning stage is only about this iteration. We want to plan out exactly how we’ll implement and measure. We want to ensure we have the resources necessary to collect the data and to provide the time for identifying what we’ve learned.

Here’s an example plan: We’ll start by deciding what we want to learn in this iteration. Can we can come up with a checkout flow that makes sense with users using the point redemption process? We decide that we can do it with a paper prototype, starting with modifying the existing checkout process with the new functions. We’ll test it with a handful of shoppers, who we’ll recruit from other parts of the company, like the accounting department. We’ll give ourselves a half day to do the paper prototype and a half day to run our usability tests, wrapping it up with one hour debriefing meeting.

Best Practices for Successful Iterations

Over the years, we’ve learned some tricks to ensure we get the most out of our iterations:

First, you need to allocate as much time and effort to the Measuring and Learning stages as you do to the Planning and Implementing stages. If you find yourself taking two weeks to implement, but only give yourself a day for measuring, then something’s out of balance. It’s a common mistake for teams to short themselves on measuring, thereby not getting a chance to learn everything they should.

Second, look for techniques to shorten implementation. Make sure you’re only implementing functionality that is necessary for this iteration — leave the other functionality for future iterations, when it will matter. Also, look to prototyping techniques and deliverables that get you the answers you want quickly. We like paper prototyping because it’s very fast to get something a user can play with.

Explicitly looking at your process for iterating will give you a chance to refine your techniques, while helping you get the most out of your design process.

Iterations and the Prototyping Process

Iterations are a key part of the prototyping process. If you’re looking to improve your prototypes, you’ll want to attend Richard Rutter and James Box’s full-day seminar at the UIE Web App Summit, Wireframing and Prototyping for Highly Interactive Web Apps.

Share Your Thoughts with Us

Have you started to put together frameworks? Is this something you’re exploring? Share your thoughts and comments at the UIE’s Brain Sparks blog.

February 2009

Precision Questioning and Precision Answering are tools for working with complex situations in smart ways. The current global economic situation certainly qualifies as complex! Almost every day we have a chance to see, through the window created by the media, national leaders, economists, business executives, and journalists asking questions about the changing economic climate. Even these experts, however, can be stymied by the complexity of the situation.

For many of us who aren’t experts, when complexity threatens to become overwhelming we move to the sidelines of the conversation. With PQ+A as part of your repertoire, however, you don’t need to be an expert to ask useful questions that keep you in the discussion. And in situations where you need to tame complexity, one of the most helpful intellectual skills you can develop is your ability to ask questions about assumptions.

So this month, during times of great complexity, we want you to use your environment to build your assumption questioning skill. We are going to ask you to try this: every time you turn to a source of news, analysis, or opinion, use the PQ+A Toolkit and its detailed examples of assumption questions to build your ability. In fact, get out your PQ+A Toolkit right now, and follow along as we take a look at assumptions in some of the news and analysis we’ve been reading.

Existence Assumptions
We hear a lot of talk these days about “bubbles.” For instance, you might be familiar with the mortgage bubble that started downward pressure on home prices, or the consumer debt bubble that might be next to pop. Have you been reading about the bubble created by zombie banks? To really understand the economic climate, we need to ask about the existence of all of these so-called bubbles.

Existence assumptions help you sort out whether or not all of these bubbles are equally real. Some people claim, for example, that there’s an enormous bubble created by credit default swaps. But apparently, if that bubble were to pop, each player’s losses would be more or less matched by their gains. So does a bubble exist in that market?

Whenever you encounter provocative headlines such as depression, epidemic, crisis, or panic, ask yourself and others: does this condition actually exist? We guarantee an interesting conversation will result.

Uniqueness Assumptions
Since we are talking bubbles, let’s ask this: how many bubbles are there in the contemporary economic situation? Are they distinct from one another? In what ways are they unique, and in what ways do they overlap?

These questions about uniqueness assumptions—applied to bubbles or meltdowns or any other financial jargon—will help you sort out what is happening by getting a better picture of where concepts border one another. Knowing the boundaries of the intellectual terrain helps you tame the complexity.

Measurement Assumptions
What assumptions are people making about the validity of key metrics in the current economic climate? We’ve been hearing a lot about unemployment rates, for example. You probably know that the numbers of unemployed people reported in the press typically exclude people who have been unemployed over a longer term or who have given up looking for a job. What do you see differently if you adopt a different measure of the unemployment rate? Understanding more about the assumptions embedded in measurement helps you form a more accurate picture of a situation and also spot areas of unmeasured or untapped complexity.

Measurement assumptions also matter when you want to compare across groups. For example, if we want to understand the economic situation from a global perspective, perhaps we need to understand measurement assumptions for phrases like “economically active population,” and “currently available for work,” vs. “seeking work” as they apply across different populations and national boundaries.

Possibility Assumptions
Possibility assumptions are particularly important when we start to talk about solutions to complex problems. One way of understanding the debate between economists and politicians about a “stimulus package” is to unpack people’s assumptions about what it is possible to change in this situation. For example, we might ask in the current economic climate: are we assuming that it’s possible to safely let the air out of all the bubbles?

Political leaders might be wondering about the possibility of global financial collaboration. Is it possible to bring world leaders together to address a global financial crisis in a coordinated manner? (Political crises don’t necessarily engender the possibility of cooperation!)

Value Assumptions
If we determine it is possible to let the air out of the economic bubbles, we could then ask about value assumptions associated with that possibility. For example, even if it is possible to break the consumer credit bubble, is it a good idea to do so?

Value assumptions show you where you are taking for granted that something is bad vs. good, positive vs. negative. The press tends to construe current economies around the globe as bad for everyone. In the long run, however, who stands to gain the most from the current situation? (One answer: in the current climate, the business for fortunetellers is expanding, not contracting!)

Audience Assumptions
When economists talk about recessions, trade deficits, and national debt, they tend to assume that everyone in their audience understands the technical meaning of these words. If you don’t fit the characteristics of the assumed audience, you will have a chance to form and practice many types of questions of clarification. Of course, we urge you to do that whenever you encounter technical terms that you don’t understand.

But here is another audience assumption we’ve been seeing a lot these days: a newspaper columnist writes something like: “We need to think about how the downturn is affecting the people at the bottom of the ladder. They keep our economy running.” Hey, we say to ourselves, is it really the case that “we” the readers are thinkers and decision makers, and “they” aren’t reading this column? Audience assumptions can help you re-think your implicit ideas about we vs. they or us vs. them and then reconfigure your solutions to complex challenges in ways that become more inclusive.

Category Assumptions
We’re swamped in category assumptions in the current financial situation. Consider how many times you’ve read about a “mortgage” crisis, a “regulatory” crisis, a “credit” crisis, and “a crisis of confidence” in the banking system. As we begin to divide the market into categories like these, we come to take for granted that these categories correctly or meaningfully represent what is happening. What if, beneath the surface, there is now a completely different kind of crisis? What if separating these topics into categories masks the reality of a holistic financial crisis that has evolved in such a way that it is essentially unrelated to any one of these categories?

When we examine category assumptions, our thinking about the complexity of the problem and the necessary solution opens up to consider different directions or ideas that are not immediately obvious. Category assumptions often blind us to new ideas or to seeing complex situations in holistic ways. Every once in a while, challenge the expert assumptions about categories if you want to see new approaches to the situation.

Similarity Assumptions
In the United States, for people of a certain generation, the word “depression” automatically invokes a picture of a 1930′s era dominated by soup lines and public works projects. Asking about similarity assumptions will help break down these types of automatic pictures, because they help us sort out how this situation is similar to or different from the economic and cultural situation in America at that time. Your questions might sound like this: comparing 2009 with 1931 or 1935 or 1939, what are the similarities in population, culture, consumerism, literacy, and other relevant concepts? What are the differences in economic instruments and economic regulation, as well as culture, consumerism, population density, and population distribution?

Comparison across time and across rapidly changing circumstances is tricky stuff-whenever you find yourself thinking that now is similar to then, stop and ask more questions about similarity assumptions.

Time/Constancy Assumptions
Last month in Vervago’s skill sharpener, we suggested that questions about time and constancy assumptions should become your best friend in the current economic situation. The changing circumstances and the evolving responses to those circumstances provide us with challenges on multiple fronts. Most of what we know about the situation is dynamic, because very little in our economic climate is constant just now. Learn to ask more questions that sound like: how has that topic or situation changed in the last days, weeks, or months? How do those changes reshape the picture I have of the situation now as opposed to the picture as it was a few days, weeks, or months ago?

Practice Taming Complexity
One of the deepest lessons that PQ+A offers is that you do not need to be an expert in a topic area to ask precise and valuable questions. To answer the questions – yes, that sometimes requires expertise. But as Precision Questioners, we don’t need to become overwhelmed by complexity or give up and sit passively on the sidelines of conversations about the changing world.

Every day this month, as you listen to the news or read about your marketplace, use one of the nine types of assumption questions we reviewed above to tame its complexity and gain a better view of what is happening. Keep this list in the same place and add to it each day. By doing this, you will find that as your list grows, you can identify those questions about assumptions that are most pivotal to your work and to your own changing economic circumstances.

If you’re looking for other forms of support as you learn to use PQ+A in a non-PQ+A world, contact QuestionMaster@vervago.com.

Download PDF version